3.7 Theme Suggestions
Gervase Markham
The issue that has been raised in the past regarding combining Reload
and Stop is the one about "what if you click "Stop" but it changed to
"Reload" just as you are clicking, and your page vanishes again?".
If we are going to combine the two, could we mitigate this problem by
animating the transition from Reload to Stop over, say, 1s, and
disabling the button during the animation? That way, if someone is
clicking around the time of the transition, they'll either get what they
want (if they get in just before) or nothing will happen and they can
notice the change going on.
So the sequence would be:
- Disable Stop button (instantaneous)
- Fade button to disabled Reload button (1 second)
- Enable Reload button (instantaneous)
2) Home button as a tab
What happens if someone clicks the Home tab, and then does something on
the home page which navigates to a new page? I think it would be cool if
a new tab "budded" from the Home icon to end up in leftmost position on
the tab bar. We could animate this process to show what was going on; if
H is the home icon:
|H| |Another tab| ...
->
|H New page| |Another tab|
->
|H| |New page| |Another tab|
Gerv
Alexander Limi
> 1) Combined Reload/Stop
>
> The issue that has been raised in the past regarding combining Reload and
> Stop is the one about "what if you click "Stop" but it changed to "Reload"
> just as you are clicking, and your page vanishes again?".
>
> If we are going to combine the two, could we mitigate this problem by
> animating the transition from Reload to Stop over, say, 1s, and disabling
> the button during the animation?
That is indeed what has been proposed.
> 2) Home button as a tab
>
> What happens if someone clicks the Home tab, and then does something on the
> home page which navigates to a new page? I think it would be cool if a new
> tab "budded" from the Home icon to end up in leftmost position on the tab
> bar. We could animate this process to show what was going on; if H is the
> home icon:
>
> |H| |Another tab| ...
> ->
> |H New page| |Another tab|
> ->
> |H| |New page| |Another tab|
>
Not a bad idea. The downside is of course that it would split up the app
tabs. But definitely worth considering.
We're still working on the precise interaction model for the home tab (both
the simple incarnation we hope to land in 3.7, and the more featureful
version in 4.0), so expect more about this when we do the writeup for the
home tab and the app tabs (which the home tab is in many ways a
specialization of).
--
Alexander Limi · Firefox User Experience · http://limi.net
Gervase Markham
> That is indeed what has been proposed.
Super!
> Not a bad idea. The downside is of course that it would split up the app
> tabs. But definitely worth considering.
Could other app tabs appear to the left of Home?
Or, getting really funky, the tab could bud off home, slide over all the
apps tabs, and end up on the left of the other tabs!
Gerv
Alex Faaborg
> 2) Home button as a tab
>
> What happens if someone clicks the Home tab, and then does something
> on the home page which navigates to a new page? I think it would be
> cool if a new tab "budded" from the Home icon to end up in leftmost
> position on the tab bar. We could animate this process to show what
> was going on; if H is the home icon:
>
> |H| |Another tab| ...
> ->
> |H New page| |Another tab|
> ->
> |H| |New page| |Another tab|
We haven't had a chance to document this yet, but the initial idea is
for links to other domains on the home tab to open in new tabs (and on
a side note I think we may want to switch our pref so that all new
tabs open to the right of the tab that spanned them).
What's nice about this approach is that it is kind of a trick to
introduce users of the home button to the concept of tab browsing.
For instance, if you type yahoo mail into Google on the home tab, you
ultimately get:
[H] [Yahoo Mail]
Now, the user would normally hit the home button and go to their next
most visited site, ebay:
[H] [eBay] [Yahoo Mail]
Hopefully at this point the user realizes that Yahoo mail didn't go
away, they can click on it and realize that it is faster to switch to
the tab than to load the page from scratch. And suddenly they have
learned how to use tab browsing.
Unfortunately we don't have great (or really any) usage metrics, but
anecdotally I believe of the user population that doesn't understand
tab browsing, there is a high correlation with heavy home button usage.
-Alex
> _______________________________________________
> dev-usability mailing list
> dev-us...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-usability
Alex Faaborg
yeah, so we also haven't documented this yet, but the idea is that to
create an "app tab" you simply drag a current tab to the left of the
home tab. It will become small and persistent like home. This ends
up being a pretty clean and simple interaction, and avoids complex
terms in a context menu like "appify this tab" etc.
It's important that the app tabs stay grouped together on the far left
because we were thinking that they aren't going to scroll out of view
when we go into overflow mode on the tab strip.
-Alex
Gervase Markham
> yeah, so we also haven't documented this yet, but the idea is that to
> create an "app tab" you simply drag a current tab to the left of the
> home tab. It will become small and persistent like home. This ends up
> being a pretty clean and simple interaction, and avoids complex terms in
> a context menu like "appify this tab" etc.
Presumably that won't be the only way? (Accessibility, drag-and-drop
being an advanced feature, discoverability, yada yada)
Gerv
Alexander Limi
There will most likely be a context menu item that performs the same action.
I agree that we shouldn't rely on drag and drop exclusively, it's hard to do
for some people, and on some types of (input) devices.
Alex Faaborg
feature isn't designed around drag and drop but rather tab order.
On Sep 15, 2009, at 12:40 PM, Alexander Limi wrote:
> 2009/9/10 Gervase Markham <ge...@mozilla.org>
> There will most likely be a context menu item that performs the same
> action.
>
> I agree that we shouldn't rely on drag and drop exclusively, it's
> hard to do
> for some people, and on some types of (input) devices.
>
> --
> Alexander Limi · Firefox User Experience · http://limi.net
Alexander Limi
> But you can reorder tabs with the keyboard right now, right? This feature
> isn't designed around drag and drop but rather tab order.
Right, but neither drag/drop or keyboard reordering have sufficient
discoverability. At least IMO. :)