Firefox 3.7 and 4.0 Theme/UI Proposed Direction
Stephen Horlander
mind for Firefox 3.7 and 4.0.
https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
The article has specifics about what is being changed and the
rationale behind it. I have tried to address much of the feedback
received thus far inline with the rationale. Things that didn't fit
into a section have been placed in a broader "Feedback/Concerns/
Questions " section. I will be updating this article over time to
address changes and feedback.
It is split up into two sections, one section for 3.7 and one for 4.0.
The 3.7 section is fairly firm, well discussed, and is what is
actually being proposed for 3.7. At the least it should be considered
features/changes that we are actively seeking to get implemented. The
4.0 changes are farther out and closer to the early brainstorming
phase. These ideas are looser and more in flux.
It would be most helpful if feedback on 3.7 could focus on specific
change proposals. Constructive ways on how to improve the ideas,
potential issues with that could arise, etc. Discussing the current
Page/Tools menu items for example.
Feedback for the 4.0 ideas can be much more broad and radical as they
are definitely not as firm. Although analyzing a particular idea for
improvements/changes is still welcome.
I will be monitoring both here and the Wiki Talk page for feedback/
discussion.
Looking forward to more feedback! Thanks.
- Stephen
Can Bolaban
nightly builds or just in final builds?
Alex Faaborg
and tools menus. Just off of the top of my head (we would obviously
want to get actual data), candidates might be:
Page
-Cut / Copy / Paste
-Print
Tools
-Private browsing
-History
-Downloads
-Addons
Quick mockup:
http://people.mozilla.com/~faaborg/files/daf/menuIcons.png
The advantage of this is that it enables you to quickly spot a common
command without having to parse actual language, which is particular
helpful since these are getting a bit long.
Recommendation to only use icons for common commands here: http://msdn.microsoft.com/en-us/library/aa511502.aspx#icons
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
David McRitchie
> I wonder if we should give icons to the most used items in the page
> and tools menus. Just off of the top of my head (we would obviously
> want to get actual data), candidates might be:
>
> Page
> -Cut / Copy / Paste
>
> Tools
> -Private browsing
> -History
> -Downloads
> -Addons
>
> Quick mockup:
> http://people.mozilla.com/~faaborg/files/daf/menuIcons.png
>
> The advantage of this is that it enables you to quickly spot a common
> command without having to parse actual language, which is particular
> helpful since these are getting a bit long.
>
> http://msdn.microsoft.com/en-us/library/aa511502.aspx#icons
Good, surprised IE8 doesn't already, it looks very familiar.
You don't want to give the impression of replacing, it was stated a little better
in the last reference as
"If you use icons, don't feel obligated to provide them for all menu items"
Justin Dolske
> There is a new Wiki page detailing the direction the UX team has in mind
> for Firefox 3.7 and 4.0.
> https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
I really like the clean look of the 3.7 mockup. It feel like something I
want to touch, with well defined regions... An Aero Glass canvas,
toolbar buttons, and a surface for tabs.
The way the bookmark toolbar blends into and becomes a background for
the tab area makes me wonder if there's more we could do with that...
IE, it looks like something underneath the tabs, so why not make it such?
It could, for example, contain the bookmarks organizer, a bookmarks
desktop (drag your icons into piles, ala Windows' Desktop), a speed-dial
type thing (as has been proposed for new tabs), or even a collection of
widgets (on a 3D sphere! *groan*). In effect, it could be an
always-present-but-peeking-out background page for the browser to use
for something.
A few other random thoughts:
* I'm sure the menubar removal will result in lots of kvetching, but I
agree it's important to do. Not just because it fits in with
new-Windows, but as a long-overdue pruning of menu clutter. But it feels
like we could even go a bit further, as they're still a bit long. 6 edit
items? [Cut thru Redo] 3 printing items? 4 bar-visibility items?
* The Page/Tools buttons are meant to contrast with each other -- one
for stuff specific to the page, one general to the brower. Perhaps
instead label the Tools button as "Browser" to make that distinction
more obvious? Keeping these short, even when addons want to put things
there, would be good... A generic "Tools" submenu under each would help
attract such stray items.
* The 4.0 mockup feels a lot busier to me, but it's also showing a lot
more going on. Maybe it would be useful to show mockups of the proposed
UIs in both a "stock" and "loaded" configuration?
* Technical nit: The horrid, horrid "Character Encoding" menu is gone.
However, this is apparently extremely useful for certain locales where
web servers are commonly broken. We'll probably need a plan for how to
deal with that. Maybe only include it in localized builds where this is
a common problem?
Justin
Justin Dolske
> I wonder if we should give icons to the most used items in the page and
> tools menus.
My first reaction to this was a bit of revulsion -- it seems like some
apps like to jam a bunch of these little icons in, and the result is
just extra visual noise.
But after looking at your mockups for a bit, I think it can work if done
cautiously. For me, the key is to essentially ignore the actual icon,
and just judge it as a navigation waypoint. [Jack Tripper's Law: Three's
Company, Four's A Crowd. :-)]
For example, in your mockup the icon makes "Print" easy to find. Not
because it's a printer icon, but because it's the last icon (or the icon
in that learned rough-position). "Save" similarly gets a boost, because
it's right above that icon. OTOH, the icons for Cut/Copy/Paste don't
seem useful. They're already at the top of the menu, and the cluster of
icons diminishes their individual usefulness.
OTOH, the Private Browsing and Addons icons have some usefulness
inherent to the icon design, because they're strongly associated with
the feature.
Justin
John J. Barton
> There is a new Wiki page detailing the direction the UX team has in mind
> for Firefox 3.7 and 4.0.
> I will be monitoring both here and the Wiki Talk page for
> feedback/discussion.
I'd like to see an explicit discussion of how extensions fit into the
UI, both visually and interactively. I guess extensions are important
and mostly the extension UI is of the form "like Firefox does" or "er, I
guess we can put a button in the status bar". Of course extensions can
do anything, but the question in UX is not the possible but the best. If
the UX team give some thought/consideration/advice we might drift in the
right direction.
(like putting the tabs back on top in Firebug ;-)
jjb
Alexander Limi
> On 9/15/09 12:04 PM, Stephen Horlander wrote:
>
>> There is a new Wiki page detailing the direction the UX team has in mind
>> for Firefox 3.7 and 4.0.
>>
>> https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
>>
>
> I really like the clean look of the 3.7 mockup. It feel like something I
> want to touch, with well defined regions... An Aero Glass canvas, toolbar
> buttons, and a surface for tabs.
>
Lickable indeed. All hail Stephen's mad visual design skills. :)
> The way the bookmark toolbar blends into and becomes a background for the
> tab area makes me wonder if there's more we could do with that... IE, it
> looks like something underneath the tabs, so why not make it such?
>
> It could, for example, contain the bookmarks organizer, a bookmarks desktop
> (drag your icons into piles, ala Windows' Desktop), a speed-dial type thing
> (as has been proposed for new tabs), or even a collection of widgets (on a
> 3D sphere! *groan*). In effect, it could be an
> always-present-but-peeking-out background page for the browser to use for
> something.
>
Interesting, I'll mull these over for a bit. Thanks for the idea!
> A few other random thoughts:
>
> * I'm sure the menubar removal will result in lots of kvetching, but I
> agree it's important to do. Not just because it fits in with new-Windows,
> but as a long-overdue pruning of menu clutter. But it feels like we could
> even go a bit further, as they're still a bit long. 6 edit items? [Cut thru
> Redo] 3 printing items? 4 bar-visibility items?
>
As discussed on the Talk page of the Menu
Cleanup<https://wiki.mozilla.org/Talk:Menu_cleanup>on the wiki, it
might be an option to move everything that has to do with
editing to the context menu, at least on Windows. Then again, it's a risky
thing to do in some ways, and definitely can't be done on OS X. But since
we're keeping the menu bar there, perhaps it's a non-issue.
> * The Page/Tools buttons are meant to contrast with each other -- one for
> stuff specific to the page, one general to the brower. Perhaps instead label
> the Tools button as "Browser" to make that distinction more obvious? Keeping
> these short, even when addons want to put things there, would be good... A
> generic "Tools" submenu under each would help attract such stray items.
>
We have discussed calling the menu "Firefox", as in "open the Firefox menu…"
— which is consistent with how Mac OS X works, and might even make sense on
Windows as a combined branding/functionality element. It rhymes with the
Windows 7 "orb", but isn't quite as bad.
I really dislike the word "Tools", it makes very little sense, it's too
abstract. The name of the application you are using seems appropriate, but
may feel a bit weird to some. Since I spend most of my time in OS X, it
makes sense. I'd love some feedback on this from people that spend most of
their time on Windows 7 or Vista.
* The 4.0 mockup feels a lot busier to me, but it's also showing a lot more
> going on. Maybe it would be useful to show mockups of the proposed UIs in
> both a "stock" and "loaded" configuration?
>
I agree — but the 4.0 stuff is still in flux, and it's useful to show "how
bad it can get when everything is shown". Extensions and even bookmarks
could be hidden in the mock-ups, but it's a good discussion point for now.
> * Technical nit: The horrid, horrid "Character Encoding" menu is gone.
> However, this is apparently extremely useful for certain locales where web
> servers are commonly broken. We'll probably need a plan for how to deal with
> that. Maybe only include it in localized builds where this is a common
> problem?
That's exactly what we have discussed (but apparently not documented
anywhere yet :). I had a great conversation with the people in the Support
team — which it is my intention to have involved every step of the way,
since they both will be the ones on the receiving end of these changes, and
also the ones that know our current users best. They mentioned that certain
locales used this functionality a lot, and we then agreed that this could be
moved out of the Developer menu for those particular locales.
It's still there for everyone, just a bit more hidden in locales where it
makes less sense.
--
Alexander Limi · Firefox User Experience · http://limi.net
Alexander Limi
I can definitely give you a rough draft summary of our thoughts so far:
- Let extensions primarily live in the top area along with the other UI
elements, see Firebug and downloads in the toolbar
here<https://wiki.mozilla.org/images/f/f6/Fx-4.0-Direction-Phase-01.png>
.
- Recommend strongly (with appropriate public lashing for non-conformance
;) that everything related to a particular extension is put in the menu
belonging to that extension, similar to (but not exactly like) the proposed
new notification
UI<http://people.mozilla.com/%7Efaaborg/files/20090821-notification/newNotification-i1.png>
.
- There are of course exceptions to this, where it makes sense for the
add-on to integrate in other locations, but the situation right now is
pretty horrible. I have 6 extensions installed, and the amount of menu noise
they cause is quite remarkable. (Extension names hidden to protect the
guilty ;)
- We definitely want to hear from advanced add-ons with special
requirements (like Firebug!) on what we can do to accommodate their needs if
they fall outside of the common cases.
- Figure out a good way to do overflow if you have too many extensions
for the space available.
J M R
> There is a new Wiki page detailing the direction the UX team has in mind
> for Firefox 3.7 and 4.0.
> https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
>
Why is the "keyhole" button still there? It wastes vertical space and
provide no real usefulness.
Why haven't the address field and search been combined?
The "bookmarks toolbar" creates a too great separation between top and
lower elements.
For example: the page button (it's state on the wiki: "One of these
buttons has items that apply to the webpage and another to the
application itself.")
If the "page" button belongs to the visible page then the placement of
the "bookmarks toolbar" creates a too great separation that makes that
connection unlikely. On other browsers the page and tools buttons are on
the level of the tabs.
Ehsan Akhgari
> > * Technical nit: The horrid, horrid "Character Encoding" menu is gone.
> > However, this is apparently extremely useful for certain locales where
> web
> > servers are commonly broken. We'll probably need a plan for how to deal
> with
> > that. Maybe only include it in localized builds where this is a common
> > problem?
>
>
> That's exactly what we have discussed (but apparently not documented
> anywhere yet :). I had a great conversation with the people in the Support
> team — which it is my intention to have involved every step of the way,
> since they both will be the ones on the receiving end of these changes, and
> also the ones that know our current users best. They mentioned that certain
> locales used this functionality a lot, and we then agreed that this could
> be
> moved out of the Developer menu for those particular locales.
>
> It's still there for everyone, just a bit more hidden in locales where it
> makes less sense.
>
Another plausible space for that menu could be on the page context menu,
since it's not exactly a purely developer menu, and it's related to the
page, so putting it in the context menu shouldn't cause much surprise.
--
Ehsan
<http://ehsanakhgari.org/>
Axel Hecht
I think that we're still on a globe where "some locales" is
underestimating the problem.
I wonder if there are better things we can do with the menu, like making
the choice of encodings restrict to those that don't trigger bad chars,
perhaps not displaying the menu when you only have ascii on the page. Or so.
My job might be tainting my personal experience here, but I don't think
too much.
Axel
Axel Hecht
My pet extension is Foxclocks, any idea how to hook that up to the UI?
Axel
belt...@mozilla.com
Please, let's not do it this way. It doesn't add anything to the
discussion at hand as our primary focus is on 3.7, which will maintain
all the same extensibility options for add-ons as 3.5. Let's not
distract ourselves.
When it comes time to examine this question in detail (after the 3.7
design is finalized), instead of focusing on single add-ons, we should
take some time to investiate what the 80% of the most popular add-ons
do, and then make sure we know how to integrate those.
cheers,
mike
Benjamin Smedberg
> * Technical nit: The horrid, horrid "Character Encoding" menu is gone.
> However, this is apparently extremely useful for certain locales where
> web servers are commonly broken. We'll probably need a plan for how to
> deal with that. Maybe only include it in localized builds where this is
> a common problem?
I don't think that doing it only in certain browser locales is a good
solution: we have evidence that even in Asian countries where this is most
common a goodly percentage of users are using en-US builds. The language of
the browser UI is not a good proxy for the potential languages (and charset
difficulties) of pages that users will be viewing.
That said, the charset thing sucks: I wonder if we could heuristically
detect that "something's not right" enough of the time that it could be
corrected with a notification bar.
--BDS
Benjamin Smedberg
> It would be most helpful if feedback on 3.7 could focus on specific
> change proposals. Constructive ways on how to improve the ideas,
> potential issues with that could arise, etc. Discussing the current
> Page/Tools menu items for example.
It feels funny that the bookmarks toolbar is visually grouped with the tab
strip/content area instead of with the location bar: the bookmarks toolbar
is the mouse-y equivalent of the awesomebar, at least in my experience.
The back/forward buttons don't have a dropdown: I use the dropdown very
frequently in at least one particular situation: I searched for something,
followed a link and started navigating around, and I want to get back to the
search results... the dropdown is a lot less painful than clicking back some
arbitrary number of times until I get back to the search results.
Visually I'm confused by the the two buttons at the right of the tab strip.
It looks as if both of them will open a new tab, although I'm pretty sure
that the one on the far right is meant to be the tab selector popup.
I'm concerned that File:Exit is a lot less discoverable, which is a problem
because it's the only way to trigger session save/restore. It would be nice
if the application context menu (the one you get when you click the top left
Firefox icon) were customized to include a "Exit Firefox" menu. Typically
the only reason I use the "File" menu is to quit Firefox so that it will
save my current set of tabs. Reading through the mockup the Exit menu item
is in the tools menu, but I wouldn't have thought to look there for it.
Also, it would be nice to have a "Exit Firefox" in the taskbar context menu
for Firefox. Currently there is a "Close All Windows" menu item (provided by
the OS, I think), but this doesn't do session save correctly.
The Tools menu contains "History" and "Recent History" items. How do people
actually use these items? It seems to me that history and bookmarks are two
sides of the same coin and that history, if it's important at all, ought to
be in the star menu instead of the tools menu.
There's something about a notification bar for a "locked profile". what does
that mean?
--BDS
Vincent Moutoussamy
On Tue, Sep 15, 2009 at 9:35 PM, Can Bolaban <can...@gmail.com> wrote:
> when will we be able to use this theme? will it be used in 3.7/4.0
> nightly builds or just in final builds?
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Vincent.
Gervase Markham
> That said, the charset thing sucks: I wonder if we could heuristically
> detect that "something's not right" enough of the time that it could be
> corrected with a notification bar.
If we got fonts with no glyphs...
Or if a spelling checker was installed, we run it over every rendered
page. If > 20% of words are unknown... of course, this means you have to
know what language a page is in.
Just brainstorming here...
Gerv
Gervase Markham
> I can definitely give you a rough draft summary of our thoughts so far:
>
> - Let extensions primarily live in the top area along with the other UI
> elements, see Firebug and downloads in the toolbar
> here<https://wiki.mozilla.org/images/f/f6/Fx-4.0-Direction-Phase-01.png>
I just finished watching Aza's Google Tech Talk about Jetpack. His
example Jetpack app was a status bar widget, and he used jetpack.status
to add stuff to the status bar.
If he's successful in getting there to be 100,000 or 1,000,000 Jetpack
script developers, then our UI is going to become a lot less changeable.
What does "jetpack.status" manipulate if we remove the status bar? Do we
just break every Jetpack which uses that function? Or perhaps does it
manipulate that small section between the URL bar and the bookmarks button?
We can perhaps tell addon authors that they need to update their addons
for each release, although that's hard enough. Are we really going to be
able to coordinate the update of 100,000 different people's Jetpacks?
A problem to mull over...
> - Figure out a good way to do overflow if you have too many extensions
> for the space available.
The bar is quite a bit taller than a 16x16 icon. Can we double-stack
them, like the Windows tray area does if you make the taskbar double-height?
Gerv
Boris Zbarsky
> Or if a spelling checker was installed, we run it over every rendered
> page. If > 20% of words are unknown...
Then you're reading a typical web forum? ;)
-Boris
Bill Barry
> There is a new Wiki page detailing the direction the UX team has in
> mind for Firefox 3.7 and 4.0.
>
>
> The article has specifics about what is being changed and the
> rationale behind it. I have tried to address much of the feedback
> received thus far inline with the rationale. Things that didn't fit
> into a section have been placed in a broader
>
> It is split up into two sections, one section for 3.7 and one for 4.0.
> The 3.7 section is fairly firm, well discussed, and is what is
> actually being proposed for 3.7. At the least it should be considered
> features/changes that we are actively seeking to get implemented. The
> 4.0 changes are farther out and closer to the early brainstorming
> phase. These ideas are looser and more in flux.
>
> change proposals. Constructive ways on how to improve the ideas,
> potential issues with that could arise, etc. Discussing the current
> Page/Tools menu items for example.
>
> are definitely not as firm. Although analyzing a particular idea for
> improvements/changes is still welcome.
>
> feedback/discussion.
Sure it is fine if you have one or two extensions but consider that if
Firebug gets an icon button here then probably so would Greasemonkey,
Stylish, IETab, Adblock Plus and MeasureIt (and these are merely the
ones I have, one of my coworkers has another 4 extensions with similar
UI semantics).
Also what is going on with the favicon in the urlbar. Afaik searching
google isn't done over https, yet the area is blue like it is secured?
Also in the current UI it would say "google.com" (all lower case too)
because that is what site is secured. It is only when there is an EV
cert that it says the company name (and then the area is green). Are
these semantics changing (again)? I do understand the pointlessness of
the lock icon, but surely consistency is the best way to get users to
learn about their security. Wasn't that why there was this big deal in
designing this UI area in the first place?
I really dislike the idea of merging the search bar with the location
bar. The location bar is not for finding things but rather going places.
Occasionally it helps you find the place you want to go, but that is a
side opportunity not a purpose. As such it should always show where you
are or where you are going (moving the status bar link functionality
here seems like a good idea in this light). I suppose it could be
combined as long as the places functionality remained the focus (when
searching you look for _things_, but the location bar shows _places_).
Something like this:
https://wiki.mozilla.org/images/5/51/Mock_search_urlbar_combo.jpg
Bill Barry
> I'm concerned that File:Exit is a lot less discoverable, which is a problem
> because it's the only way to trigger session save/restore. It would be nice
> if the application context menu (the one you get when you click the top left
> Firefox icon) were customized to include a "Exit Firefox" menu. Typically
> the only reason I use the "File" menu is to quit Firefox so that it will
> save my current set of tabs. Reading through the mockup the Exit menu item
> is in the tools menu, but I wouldn't have thought to look there for it.
> Also, it would be nice to have a "Exit Firefox" in the taskbar context menu
> for Firefox. Currently there is a "Close All Windows" menu item (provided by
> the OS, I think), but this doesn't do session save correctly.
discussion I have found it very useful.
John J. Barton
> 2009/9/15 John J. Barton <johnj...@johnjbarton.com>
>
>> Stephen Horlander wrote:
>>
>>> There is a new Wiki page detailing the direction the UX team has in mind
>>> for Firefox 3.7 and 4.0.
>>>
>> ...
>>
>>> I will be monitoring both here and the Wiki Talk page for
>>> feedback/discussion.
>>>
>> I'd like to see an explicit discussion of how extensions fit into the UI,
>> both visually and interactively. I guess extensions are important and mostly
>> the extension UI is of the form "like Firefox does" or "er, I guess we can
>> put a button in the status bar". Of course extensions can do anything, but
>> the question in UX is not the possible but the best. If the UX team give
>> some thought/consideration/advice we might drift in the right direction.
>>
>
> I can definitely give you a rough draft summary of our thoughts so far:
Thanks!
>
> - Let extensions primarily live in the top area along with the other UI
> elements, see Firebug and downloads in the toolbar
> here<https://wiki.mozilla.org/images/f/f6/Fx-4.0-Direction-Phase-01.png>
This would be extremely unpopular with Firebug users. The Firebug UI
opens in the bottom of the page and users routinely minimize/unminimize
Firebug many times as they work on the page. The current status bar
button works great; a button at the top would be much less effective.
> .
> - Recommend strongly (with appropriate public lashing for non-conformance
> ;) that everything related to a particular extension is put in the menu
> belonging to that extension, similar to (but not exactly like) the proposed
> new notification
> UI<http://people.mozilla.com/%7Efaaborg/files/20090821-notification/newNotification-i1.png>
I can't read this image in Firefox even on the maximum magnification.
> .
> - There are of course exceptions to this, where it makes sense for the
> add-on to integrate in other locations, but the situation right now is
> pretty horrible. I have 6 extensions installed, and the amount of menu noise
> they cause is quite remarkable. (Extension names hidden to protect the
> guilty ;)
But without examples it is difficult to know whether you are talking
about our music or the noise added by Those Other Guys ;-)
> - We definitely want to hear from advanced add-ons with special
> requirements (like Firebug!) on what we can do to accommodate their needs if
> they fall outside of the common cases.
I guess that the total number of issues is not very large because the
points of contact on the UI for most extensions are not very numerous. I
think we could assemble and discuss the key integration points with good
effect.
We should also consider moving some function from extensions into
Firefox, or on to a common extension base. For example, highlighting
elements (Firebug inspect) is a key ingredient of any extension for
visual UI manipulations.
> - Figure out a good way to do overflow if you have too many extensions
> for the space available.
This will be a serious problem since any extension features that gets
hidden by being part of the overflow is basically broken as far as the
user is concerned.
jjb
Gijs Kruitbosch
> That said, the charset thing sucks: I wonder if we could heuristically
> detect that "something's not right" enough of the time that it could be
> corrected with a notification bar.
>
> --BDS
Could we formalize some of the knowledge some people have of this stuff? I
remember asking people on IRC about charsets going wrong during an cvs-to-hg
import, and just giving them an example (an u + umlaut had become garbage) and
people accurately being able to tell me what had happened (UTF-8 interpreted as
ISO-8859-1 or vice versa, I don't recall). I don't recall who this was,
unfortunately...
Anyway, point being, could we auto-detect such most common cases, rather than
building a generic thing like Gerv suggested? (which might not work if, indeed,
loads of people use slang/zonelang/l33t or whatever they call it these days)
~ Gijs
Bill Barry
even at an 90% threshold.
Wouldn't it be better just to check if >1-5% of the visible characters
on the page do not have glyphs in the current encoding?
Mike Beltzner
> If he's successful in getting there to be 100,000 or 1,000,000 Jetpack
> script developers, then our UI is going to become a lot less changeable.
> What does "jetpack.status" manipulate if we remove the status bar? Do we
This is the wrong way to think about this; if we get more people using
API mechanisms like jetpack.status to indicate that they want to
contribute to a statusBar, then if we discover a better UI mechanism
than a permanently present statusBar, we can have the API use that new
mechanism.
This makes us more, not less flexible.
> A problem to mull over...
Again, though, not one we need to do right now. Starting with the
premise that we can't make any changes which will have any affect on the
6,000 Add-ons out there will result in us never evolving or considering
changes to our UI. We should discuss problems we want to solve with the
existing UI (including good opportunities for UI extensibility) and
potential solutions, then do fitting to our existing ecosystems
afterwards. This is a classical platform/product tension (ask the folks
who work on Eclipse, f.e.) and it can be solved, but it takes discipline
in how you approach the issues.
cheers,
mike
k m
> On 9/16/2009 10:25 AM, Gervase Markham wrote:
>
> > If he's successful in getting there to be 100,000 or 1,000,000 Jetpack
> > script developers, then our UI is going to become a lot less changeable.
> > What does "jetpack.status" manipulate if we remove the status bar? Do we
>
> This is the wrong way to think about this; if we get more people using
> API mechanisms like jetpack.status to indicate that they want to
> contribute to a statusBar, then if we discover a better UI mechanism
> than a permanently present statusBar, we can have the API use that new
> mechanism.
>
> This makes us more, not less flexible.
The right way to go about would be to first propose an alternate
system and then propose removing the statusbar saying the new system
works better. It is too dramatic to propose removing the statubar
without any alternaives.
JM
> There is a new Wiki page detailing the direction the UX team has in mind
> for Firefox 3.7 and 4.0.
>
>
> The article has specifics about what is being changed and the rationale
> behind it. I have tried to address much of the feedback received thus
> far inline with the rationale. Things that didn't fit into a section
> have been placed in a broader "Feedback/Concerns/Questions " section. I
> will be updating this article over time to address changes and feedback.
>
> It is split up into two sections, one section for 3.7 and one for 4.0.
> The 3.7 section is fairly firm, well discussed, and is what is actually
> being proposed for 3.7. At the least it should be considered
> features/changes that we are actively seeking to get implemented. The
> 4.0 changes are farther out and closer to the early brainstorming phase.
> These ideas are looser and more in flux.
>
> It would be most helpful if feedback on 3.7 could focus on specific
> change proposals. Constructive ways on how to improve the ideas,
> potential issues with that could arise, etc. Discussing the current
> Page/Tools menu items for example.
>
> Feedback for the 4.0 ideas can be much more broad and radical as they
> are definitely not as firm. Although analyzing a particular idea for
> improvements/changes is still welcome.
>
> feedback/discussion.
>
>
> - Stephen
starting to like what I see for 3.7. I definitely like the combining of
the stop and reload buttons and the home button on the tab bar. I
guessing you will still be able to right click the toolbars and
customize them?
As for 4.0-I don't want the location bar and search bar combined. If you
have it this way by default, fine, but at least keep an option to switch
them back to being separate. And I don't want the tabs on top either.
I like the profile button next to the minimize button, as well as the
profile options such as having different sets of bookmarks. That's
definitely a good idea.
I have a suggestion for either 3.7 or 4.0. It would be nice if the
install button was included by default in the addons manager. I add it
every time I install firefox using about:config, but it would be nice if
it was included by default.
That's all for now. Thanks!
Jesper Kristensen
> That said, the charset thing sucks: I wonder if we could heuristically
> detect that "something's not right" enough of the time that it could be
> corrected with a notification bar.
The browser could hide or maybe just disable the Character Encoding
menu, when it will have no effect. In HTML 4 (I haven't checked HTML 5),
the browser is only allowed to user other methods like this menu, when
the website does not specify a character encoding. Last time I checked
(it was a long time ago, might be different now), Firefox did follow the
spec, and changing the selected value in the Character Encoding menu had
no effect on pages, which specified a character encoding. Hiding or
disabling the menu in these cases would also make it easier to tell web
developers: "If Firefox shows the Character Encoding menu on your site,
then your site is broken, and you should fix it".
And please remove all UI, both in the Character Encoding menu and in the
options dialog, which allows the user to make permanent changes to how
Firefox should select a character encoding. Changing these preferences
can only lead to a broken browser, and I have had to deal with several
support requests, where a user wanted to fix the characters on one site
permanently instead of using the Character Encoding menu on every visit,
which only resulted in that most other websites did not display
correctly, and the user could not remember how to get back. (This is
even worse in Thunderbird)
Jesper Kristensen
> There is a new Wiki page detailing the direction the UX team has in mind
> for Firefox 3.7 and 4.0.
> https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
(Comments on 3.7)
On https://wiki.mozilla.org/Menu_cleanup "These are removed from the new
menu setup, they remain if you enable the menu bar again"
If we are not confident removing these, we should not do so. Having some
menu items in one menu structure and not in another sounds like a way to
make users use both the new and old menu bar to get all the needed
functionality. I would vote for removing these items from the old menu
bar as well.
Are the Cut/Copy/Paste/Select All/Undo/Redo items in the Page menu
really needed? Aren't they already in the context menu?
"Hiding of the menubar by default would only occur on Vista and Windows
7. Windows XP would retain the menubar by default as would Linux and of
course Mac. Holding Alt on Vista/7 would show the menu (which can also
be toggle on). "
I really don't like this one. I appreciate visually integrating into the
platform, but I don't like completely changing functionality based on
platform. Firefox should be able to do the same no matter which platform
it runs on. However Linux, Mac and XP expects applications to have a
menu bar, so maybe on these platforms you could still keep the Page,
Tools and Bookmark buttons, but instead move them and style them like a
menu bar, so that they are placed in the top of the window/srceen
instead of to the right of the window, and have a menubar style instead
of a toolbar style.
Having both the old and new menus also feels strange. Have anyone
studied which parts of the new way in e.g. IE that some people don't
like? If it for example is only is the visual appearance, which annoys
people, we could just add an option to customize that appearance, but
still keep the new structure, and vise versa.
If the old menu bar is visible by default on Mac/Linux/XP, are the
Page+Tools+Bookmarks buttons then hidden. If not that would make a lot
of duplicate UI, which is really not nice. If they are hidden, that
would also be a pain, as the currently shifting position of the Options
item is a pain, shifting positions of all menu item would be even worse,
especially when doing support or writing tips on how to use Firefox.
(Comments on 4.0)
I guess when you click an app tab, the "app" is opened in that tab and
not visually creating a new tab. How is the user supposed to know if an
app tab is open or not (and thus taking up computer resources, and maybe
even money, if the app is fx pay per minute tv or something). I like the
way Windows 7 does it by adding a border if the application is running,
while having no border if the application is not running.
David Dahl
> The 4.0 extension buttons in the main UI idea sucks pretty hard IMO.
> Sure it is fine if you have one or two extensions but consider that if
> Firebug gets an icon button here then probably so would Greasemonkey,
> Stylish, IETab, Adblock Plus and MeasureIt (and these are merely the
> ones I have, one of my coworkers has another 4 extensions with similar
> UI semantics).
>
I was just thinking the same thing. Perhaps a new "statusbar" call it
"extensionbar" is placed in a vertical position below the lower right
scrollbar. It takes up the same horizontal space as the scrollbar, and
just makes the scrollbar shorter by how many extension icons are placed
there. Of course there are pages that do not require firefox to render a
scrollbar, but that seems a minor point, I'm sure we can work around
that. Ideas?
Justin Dolske
> Just brainstorming here...
* Use a crowd-sourced, web-service lookup to correct the encoding, and
pref the menu off by default... Then most pages just work, and motivated
users can enable the menu (and their choices get pushed to the
webservice for the benefit of others). [*insert handwaving about privacy
and caching here*]
Justin
Alex Faaborg
> studied which parts of the new way in e.g. IE that some people don't
> like? If it for example is only is the visual appearance, which
> annoys people, we could just add an option to customize that
> appearance, but still keep the new structure, and vise versa.
I believe keeping the alt key functionality is primarily an
accessibility feature. A lot of users have built up muscle memory of
using the alt key to access particular commands, and in many cases the
visual impact of having a new menu bar appear isn't an issue because
the user is interacting with the application using a screen reader.
Also as strange as having a traditional menu bar appear when you hit
the alt key is, it is the new normal on Vista and 7 (for not just IE
but also more fundamental things like interacting with the file system).
> If the old menu bar is visible by default on Mac/Linux/XP, are the
> Page+Tools+Bookmarks buttons then hidden. If not that would make a
> lot of duplicate UI, which is really not nice. If they are hidden,
> that would also be a pain, as the currently shifting position of the
> Options item is a pain, shifting positions of all menu item would be
> even worse, especially when doing support or writing tips on how to
> use Firefox.
The additional work in creating support documents is an issue, but
like with moving Options, it's of course really important for controls
to be where the user expects them. As for issues related to people
switching between operating systems regularly, I really wish we had
some data on how common that is. I know amongst all of us it is
incredibly common (I'll have 3 or 4 platforms running at any given
time), but for average users my impression is that switching operating
systems throughout the day is really uncommon.
> I guess when you click an app tab, the "app" is opened in that tab
> and not visually creating a new tab. How is the user supposed to
> know if an app tab is open or not (and thus taking up computer
> resources, and maybe even money, if the app is fx pay per minute tv
> or something).
Current plan is for these to always be open (although by default the
only app tab is Home which is created with local chrome). Personally
I really like the functionality of Prism for managing Web apps like
mail, calendar, music, etc. However a lot of people want to live
entirely in the browser, so this brings some Prism style functionality
to the tabstrip. We may also expose additional features to Web apps
running in an app tab, like notification, etc.
-Alex
Bill Barry
>> Having both the old and new menus also feels strange. Have anyone
>> studied which parts of the new way in e.g. IE that some people don't
>> like? If it for example is only is the visual appearance, which
>> annoys people, we could just add an option to customize that
>> appearance, but still keep the new structure, and vise versa.
>
> accessibility feature. A lot of users have built up muscle memory of
> using the alt key to access particular commands, and in many cases the
> visual impact of having a new menu bar appear isn't an issue because
> the user is interacting with the application using a screen reader.
>
> Also as strange as having a traditional menu bar appear when you hit
> the alt key is, it is the new normal on Vista and 7 (for not just IE
> but also more fundamental things like interacting with the file system).
provides access key tooltips as does office 2007 (seems to be related to
the ribbon UI). The choice seems to be either use a ribbon UI or provide
a menubar (which may be hidden if it would normally appear in an area
that is now glass).
Benjamin Smedberg
> where the user expects them. As for issues related to people switching
> between operating systems regularly, I really wish we had some data on
> how common that is. I know amongst all of us it is incredibly common
> (I'll have 3 or 4 platforms running at any given time), but for average
> users my impression is that switching operating systems throughout the
> day is really uncommon.
My unscientific sample says that among my friends who can afford a mac
laptop for home, most have one and switch between their mac at home and
their Windows PC at work.
> Current plan is for these to always be open (although by default the
Oof. I imagine that users might really want to "stop" apps which may be
network- or memory- intensive, such as gmail with talk enabled. How would
they "stop" the app without actually deleting the app-tab which they've
carefully set up?
There will be lots of implementation concerns there too, such as how you
start the browser without having all those app tabs compete for network. We
don't want to make starting Firefox like starting Windows.
--BDS
Alexander Limi
> There will be lots of implementation concerns there too, such as how you
> start the browser without having all those app tabs compete for network. We
> don't want to make starting Firefox like starting Windows.
>
This already has a partial solution with per-tab network
prioritization<https://wiki.mozilla.org/Firefox/Projects/Per_Tab_Network_Prioritization>in
3.6, more sophisticated queuing expected in later releases. :)
--
Alexander Limi · Firefox User Experience · http://limi.net
Ben Lerner
for the menubar to appear *floating over* the existing chrome content,
sort of the way Mac dialog sheets appear floating over the content
below. The rationale for applying this to the menubar is: 1) if users
press the alt key, they're likely expecting the menubar and not the
back/forward button or address bar, so obscuring that UI is not a
problem. 2) The obscured UI still peeks out from the sides of the
menubar, so it's apparent that it still exists, and the standard "oops"
reaction of banging the escape key will clear the menu and fix things.
3) Dropping the menu in like this avoids the annoying
content-jumps-down-to-make-room flicker.
I sort of see this menubar as looking like an upside-down tab, dangling
below the titlebar or merging into the titlebar-space glass (depending
on the mockup). It does *not* take up the full width of the window, but
rather is only as wide as the menus it contains, which allows for the
addressbar UI to show through on the side. Unlike Mac's sheets, I
wouldn't expect the menu to be centered, but still be left-justified in
the window.
One potential problem with this: if a user presses Alt+D, the current
behavior is to focus the address bar, and the menubar never gains
focus. So, something clever would need to happen to distinguish these
two cases...
~ben
Gervase Markham
> Current plan is for these to always be open (although by default the
> only app tab is Home which is created with local chrome).
Aside from the pay-per-view argument, which is quite niche, for people
who have a few such apps won't this have a significant effect on startup
time and memory usage? Even if I don't use my calendar in a session, I'm
paying the memory cost of having it open...
Gerv
Gervase Markham
> Anyway, point being, could we auto-detect such most common cases, rather
> than building a generic thing like Gerv suggested? (which might not work
> if, indeed, loads of people use slang/zonelang/l33t or whatever they
> call it these days)
We already have an automatic charset detection module, which I believe
uses octet frequency analysis. I'm assuming the cases where people need
the menu are cases where it doesn't work. Perhaps we could look into
improving it further?
Gerv
Gervase Markham
> I was just thinking the same thing. Perhaps a new "statusbar" call it
> "extensionbar" is placed in a vertical position below the lower right
> scrollbar. It takes up the same horizontal space as the scrollbar, and
> just makes the scrollbar shorter by how many extension icons are placed
> there.
Not dismissing the idea, but this does mean that the "down" scrollbar
arrow would move depending on how many extensions you had installed,
affecting muscle memory (and, if the status bar is gone, perhaps Fitts'
law stuff about quick access in the bottom corner).
Gerv
Rob Arnold
> Bill Barry wrote:
>
> One potential problem with this: if a user presses Alt+D, the current
> behavior is to focus the address bar, and the menubar never gains focus.
> So, something clever would need to happen to distinguish these two cases...
I checked what IE8 does - you have to release the Alt key to see the menubar
(and then you can continue with your mnemonic keyboard shortcuts as
expected).
-Rob
Alexander Limi
"Current plan" is that me and Faaborg disagree on this, I think the app tabs
should not show up when you open a new window, for the exact reasons you
mention. Also because if I open up a second window, I do it to have a new,
blank canvas to put stuff on, not to carry over what I already have open in
the previous window.
We've scheduled a duel at dawn with water balloons, so we'll find a
resolution eventually. ;)
Alexander Limi
the app tabs. Ignore my comment below. :)
--
Alexander Limi · Firefox User Experience · http://limi.net
On Thu, Sep 17, 2009 at 10:37 AM, Alexander Limi <li...@mozilla.com> wrote:
> On Thu, Sep 17, 2009 at 2:24 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
Alex Faaborg
of what you were talking about, I really have no idea what we should
do when the user creates another window.
Even more problematic is if we don't show the app tabs, what happens
when you close the first window.
On Sep 17, 2009, at 10:39 AM, Alexander Limi <li...@mozilla.com> wrote:
> Actually, I misread that discussion, this is a slightly different
> aspect of
> the app tabs. Ignore my comment below. :)
>
> --
> Alexander Limi · Firefox User Experience · http://limi.net
>
>
>
> On Thu, Sep 17, 2009 at 10:37 AM, Alexander Limi <li...@mozilla.com>
> wrote:
>
>> On Thu, Sep 17, 2009 at 2:24 AM, Gervase Markham <ge...@mozilla.org>
>> wrote:
>>
>> "Current plan" is that me and Faaborg disagree on this, I think the
>> app
>> tabs should not show up when you open a new window, for the exact
>> reasons
>> you mention. Also because if I open up a second window, I do it to
>> have a
>> new, blank canvas to put stuff on, not to carry over what I already
>> have
>> open in the previous window.
>>
>> We've scheduled a duel at dawn with water balloons, so we'll find a
>> resolution eventually. ;)
>>
>> --
>> Alexander Limi · Firefox User Experience · http://limi.net
>>
>>
Bill Barry
> That doesn't get you out if the water ballon duel. But on the topic
> of what you were talking about, I really have no idea what we should
> do when the user creates another window.
>
> Even more problematic is if we don't show the app tabs, what happens
> when you close the first window.
that somehow so that you are not spending extra resources on that tab.
IE:
open two windows
Start gmail app tab in one window
switch to other window
notice that gmail app tab is running
switch to it in this window
notice first window switches to home tab?
Something like this would work I think.
Nickolay Ponomarev
I think the discussion on app tabs is very interesting and deserves a
separate thread.
How much thinking was put into the app tabs? It would be interesting to see
the key ideas summarized, particularly what problems they are trying to
solve and if you've tried comparing handling of app tabs to OS's handling of
native applications.
(I'm sorry for the length of the remainder of the mail, I intended it to be
short - but that's what you get when throwing out an interesting theme for
discussion without documenting your thoughts on it first :p )
I'd like to point out (maybe obvious facts, but they weren't mentioned)
that:
1) there may be multiple tabs belonging to a web-application - e.g. I
routinely open many Gmail tabs (individual messages, views and attachments)
2) It's often convenient not to keep them together on the tab bar, instead
grouping different kinds of tabs based on the task they're related to.
3) It may not be possible to determine the "main" tab of an application due
to their dynamic nature - e.g. I can open a particular message in the "main"
(inbox) Gmail tab, then open a different "Inbox" in a new tab.
This matters, since it means that the "app tab" may need to be transformed
to a regular tab and vice versa.
Have you considered thinking of "app tabs" not as tabs, but as pieces of the
chrome, which serve several purposes:
1) a way to quickly launch an application, like bookmarks on the bookmark
toolbar or the items in the Mac OS X dock.
2) quick access to the application UI, like tabs or (again) items in the
dock.
3) place where app notifications can be shown, like the proposed Page/Tools
buttons in 4.0, Windows tray icons or in some part the items in the Mac's
dock.
When thinking about it in this way, I can see many solutions for the problem
at had (what to do at startup and when opening a new window):
- on startup don't load the app, unless the user indicated they'd like it to
open at startup
- when opening a new window, don't load the duplicate of the app, instead
when app tab is selected display the tab from the first window, when the app
has a single tab or (for example!) an Expose-like view when there are
multiple tabs.
- the app tab could replace the "regular" tab or exist in addition to the
regular tab(s)
Nickolay
On Thu, Sep 17, 2009 at 9:17 PM, Alex Faaborg <faa...@mozilla.com> wrote:
> That doesn't get you out if the water ballon duel. But on the topic of
> what you were talking about, I really have no idea what we should do when
> the user creates another window.
>
> Even more problematic is if we don't show the app tabs, what happens when
> you close the first window.
>
> On Sep 17, 2009, at 10:39 AM, Alexander Limi <li...@mozilla.com> wrote:
>
> Actually, I misread that discussion, this is a slightly different aspect
>> of
>> the app tabs. Ignore my comment below. :)
>>
>> --
>> Alexander Limi · Firefox User Experience · http://limi.net
>>
>>
>>
>> On Thu, Sep 17, 2009 at 10:37 AM, Alexander Limi <li...@mozilla.com>
>> wrote:
>>
>> On Thu, Sep 17, 2009 at 2:24 AM, Gervase Markham <ge...@mozilla.org>
>>> wrote:
>>>
>>> "Current plan" is that me and Faaborg disagree on this, I think the app
>>> tabs should not show up when you open a new window, for the exact reasons
>>> you mention. Also because if I open up a second window, I do it to have a
>>> new, blank canvas to put stuff on, not to carry over what I already have
>>> open in the previous window.
>>>
>>> We've scheduled a duel at dawn with water balloons, so we'll find a
>>> resolution eventually. ;)
>>>
>>> --
>>> Alexander Limi · Firefox User Experience · http://limi.net
>>>
>>>
Axel Hecht
> That doesn't get you out if the water ballon duel. But on the topic of
> what you were talking about, I really have no idea what we should do
> when the user creates another window.
>
> Even more problematic is if we don't show the app tabs, what happens
> when you close the first window.
Could e10s display a single tab in multiple windows? I.e., could we use
that single app tab process, and make it display in multiple windows on
demand?
Though I'm probably on the side of not loading the app tabs unless
they're actually displayed for the first time, and there might be some
clever "caching" that discards the app tab process if it hasn't been
used for a while.
Which might call for some web api for those tabs to go into a light
"only get notifications" state.
Just rambling here.
Axel
Barry van Oudtshoorn
demand. That way, they become more like 'persistent bookmarks' until you
actually click on the tab.
John J Barton
Maybe we need a "not-an-app" tab: these tabs don't get any CPU when they
are not on top. That would make Firefox run faster, smoother, and it
would better for the planet. Then if I want my music to play, I make it
an app tab.
jjb
Mook
Universal chardet is using an old data set (from Netscape circa 2001);
would it make sense to try to re-scrape the current internet and see
what comes up? Unfortunately, this might require more resources than
available.
The current (idl) interface exposes very little about the probabilities
(just "definitely not", "pretty certain" and "maybe"), and nothing at
all about the losing charsets; having that information would be very
useful for the UI too. (If the top candidate and the next differ by
20%, it's probably correct, for example).
--
Mook
Alexander Limi
bvanoud...@gmail.com> wrote:
> Maybe it would make sense to load app tabs' pages lazily -- ie on demand.
> That way, they become more like 'persistent bookmarks' until you actually
> click on the tab.
Indeed, that's one of the features that I am including in the sidebar tab
spec I'm working on right now — lazily loading tabs allows us to make
bookmarks into "tabs you haven't opened yet", as mentioned here:
http://limi.net/articles/reinventing-tabs-for-the-browser/#proposal
"""
One cool consequence of this is that open pages — “tabs” — and bookmarks can
be the same thing for the simple use cases. Similar to the Mac OS X dock, it
doesn’t care whether the application is currently open or closed. This is
something we will talk more about in a later article, but to keep the
discussion focused, we will leave it on the table for now.
"""
I assume we're talking about the same thing? :)
NotDeadMeat
> That doesn't get you out if the water ballon duel. But on the topic
> of what you were talking about, I really have no idea what we should
> do when the user creates another window.
>
> Even more problematic is if we don't show the app tabs, what happens
> when you close the first window.
Would it make sense to move the app tabs to the active window, making
them almost 'always on top'?
NDM.
Gervase Markham
> Universal chardet is using an old data set (from Netscape circa 2001);
> would it make sense to try to re-scrape the current internet and see
> what comes up? Unfortunately, this might require more resources than
> available.
I think smontagu might well know where the bodies are buried with regard
to this function...
Gerv
Benjamin Smedberg
> Could e10s display a single tab in multiple windows? I.e., could we use
> that single app tab process, and make it display in multiple windows on
> demand?
Not really. The layout engine only allows for one presentation at a time. So
you could theoretically move the "single" app between windows depending on
which one was focused, but you could do that today (it's basically the same
thing as tab-dragging).
--BDS
Alex Faaborg
> bookmarks into "tabs you haven't opened yet", as mentioned here:
I'm not really against creating a new model that behaves like the OS X
dock, where all the prominent App/Pages are listed and they may or may
not be open. However, I'm reluctant to introduce this into the
current 3.7/4.0 tabstrip since we have already created a very clear
expectation of "if you can see the tab, it's open." So as Limi
suggests I think we would want to introduce this as part of a more
significant redesign.
As for cases where people want App tabs, but without them opening on
start up, or staying open, etc., it seems like that simply replicates
the functionality of the existing bookmarks toolbar (short cuts to
momentarily launch a Web app). While there are boundary cases (like
pay per content, or slow systems) that break having a lot of
applications loaded as persistent app tabs, I would argue that is more
of a reason to simply not use the feature, as opposed to changing the
nature of the feature.
-Alex
Jesper Kristensen
>> lazily loading tabs allows us to make
>> bookmarks into "tabs you haven't opened yet", as mentioned here:
>
> I'm not really against creating a new model that behaves like the OS X
> dock, where all the prominent App/Pages are listed and they may or may
> not be open. However, I'm reluctant to introduce this into the current
> 3.7/4.0 tabstrip since we have already created a very clear expectation
> of "if you can see the tab, it's open." So as Limi suggests I think we
> would want to introduce this as part of a more significant redesign.
>
> As for cases where people want App tabs, but without them opening on
> start up, or staying open, etc., it seems like that simply replicates
> the functionality of the existing bookmarks toolbar (short cuts to
> momentarily launch a Web app). While there are boundary cases (like pay
> per content, or slow systems) that break having a lot of applications
> loaded as persistent app tabs, I would argue that is more of a reason to
> simply not use the feature, as opposed to changing the nature of the
> feature.
So app tabs is a new drag-and-drop UI for setting your home page to
multiple tabs?
Blair McBride
window, but each window just displays the same instance.
Whether that's done via having the layout engine have multiple
presentations, or simply moving the tab to the focused window - it won't
really matter to the user.
- Blair
Alex Faaborg
> displays the same instance.
I think this is the most straightforward interface, and it gets us
around the problem of dealing with window closure. Let's say the user
opens first window A (which has the app tabs), then second window B
(which does not have them), then they close window A. This would mean
window C would get app tabs if A doesn't exist, but wouldn't get app
tabs if A does does exist? Or, does the user have to shut down
Firefox entirely and start a fresh session to create another window
A? Giving the app tabs to only one window starts to create complex
situations that feel nondeterministic.
However, as Benjamin notes a few comments ago, displaying the same
instance isn't really possible with our current architecture:
>> The layout engine only allows for one presentation at a time. So
>> you could theoretically move the "single" app between windows
>> depending on
>> which one was focused, but you could do that today (it's basically
>> the same
>> thing as tab-dragging).
-Alex
David Regev
> Current plan is for these to always be open (although by default the only
> app tab is Home which is created with local chrome). Personally I really
> like the functionality of Prism for managing Web apps like mail, calendar,
> music, etc. However a lot of people want to live entirely in the browser, so
> this brings some Prism style functionality to the tabstrip. We may also
> expose additional features to Web apps running in an app tab, like
> notification, etc.
>
On Thu, Sep 17, 2009 at 1:37 PM, Alexander Limi wrote:
> "Current plan" is that me and Faaborg disagree on this, I think the app
> tabs should not show up when you open a new window, for the exact reasons
> you mention. Also because if I open up a second window, I do it to have a
> new, blank canvas to put stuff on, not to carry over what I already have
> open in the previous window.
>
If the former ‘current plan’ were changed, then the disagreement on the
latter ‘current plan’ would be moot. That is, if app tabs could be closed
without removing the tab (perhaps by making the closed tab appear more like
a bookmark, or having a different kind of button to connect and disconnect
apps), then there is an obvious solution to the second-window problem: when
a new window is opened, the app tabs all appear but are closed. Similarly,
when the browser starts up, whether an app tab is loaded or not would simply
depend on whether it was running when the session was closed.
As for those additional features, they could still be available to app tabs
even if they are not running. I may close Gmail when I am not using it, but,
if I have “app tab’d” it, I want notifications from it at all times. (Other
features that would be useful at all times: badges, pop-up summaries when
hovering over the app tab.)
William Gianopoulos
> There is a new Wiki page detailing the direction the UX team has in
> mind for Firefox 3.7 and 4.0.https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Directi...
> Looking forward to more feedback! Thanks.
> - Stephen
I am curious, because this looks like Mozilla's left hand not knowing
what its right hand is doing.
The new lightweight themes seem to be being sold as the greatest thing
since sliced bread.
This new UI seems to eliminate all the areas in the UI where the
lightweight theme displays.
What am I missing here?
(please do not construe the above to mean that I actually like the
whole lightweight theme idea in the first place, this just all seems
very inconsistent to me)
Alex Faaborg
control the feel of the entire UI surface and feel more immersive.
Also users may decide to turn menu bar, bookmarks toolbar and
extension toolbars on, in which case the persona has even more surface
area than before.
-Alex
On Sep 26, 2009, at 3:51 PM, William Gianopoulos
<wgiano...@gmail.com> wrote:
Joe Drew
Also, initial e10s plans involve parenting native OS widgets cross-
process, which specifically precludes displaying single tabs in
multiple windows.
However, Fennec-style tile browsing (+ a tile cache) could conceivably
allow for this: share the same tile cache and invalidation, but allow
for different scroll positions. That has very little to do with
electrolysis, though, and is not even on the drawing board.
Klau3
In 4.0, the home tab could be the 'new tab' (kind of widget desktop)
that I have suggested in my blog post. When clicking on the Google
mail widget icon inside this desktop, a new small app tab would open,
placed left, next to the home tab. All app tabs would be controlled by
the home tab (to open/close them, set preferences...)
This would solve several problems:
- We would have more space (bookmark menu, history menu ...)
- One logical place to control the browser and browser apps/add-ons
- Home tab would be widely customizable
- This would make Firefox unique
I feel Firefox is on the right track, but I think it would be nice to
go a step further than the competition.