Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Customization UI Thoughts

12 views
Skip to first unread message

Stephen Horlander

unread,
Aug 6, 2009, 5:53:24 PM8/6/09
to dev-us...@lists.mozilla.org
I have spent quite a bit of time reading through the comments sparked
by the initial mockups for Firefox 3.7–4.0 (https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups
). Probably too much time. Amid the sea of feedback there were several
prominent recurring themes. I don't agree with all of them but one I
do agree with is "I hope I can change it back to the way it was".

Once you get beyond the "OMG change!" feel of the comment, the essence
of it is really one of the more spot-on bits of feedback I came
across. Firefox has always been about customizability. Through themes,
extensions, all the built-in options and even about:config you can
pretty much make it behave how you think it should behave. Beyond the
fear of change is the fact that people use their browsers differently
and they want to continue to do that. Firefox should (and does)
facilitate that.

This all may seem rather obvious. I don't think anyone has suggested
the inability to add back back toolbars or permanent tabs-on-top
placement. Quite the opposite really. I think this fear is partially
being fueled by instances in the past where some bit of UI changed in
a significant way but couldn't be reverted manually. The AwesomeBar
gets thrown around a lot as an instance of immutable change thrust on
users. Which is a valid complaint because it altered a longstanding
behavior. However sometimes UI evolutions need to permanently supplant
their predecessors. The tradeoffs just need to be sufficiently weighed.

So, where does that leave us? Assuming we don't have a Menu Bar by
default how would someone customize their interface? Right click menu?
Slap a menu option for each toolbar under the Tools button? Just move
the "Toolbars" menu item as-is from View to Tools? Or simply have a
"Customize Your Interface" option. I have done some exploration on
this last idea.

Instead of just using the Customize sheet/window to add icons and new
toolbars we could combine everything into a unified visual interface
for adding, removing and rearranging elements.

Currently the customization UI is pretty clunky. You get a really
messy box with misaligned icons all over the place. For some reason
the scrollbar is inset into the window. Worse still when you go to add
something there is very little indication of where you are going to
place the item. You get a drop maker on Windows, on OS X you don't
even get that. The lack of visual feedback and flow makes customizing
your toolbar pretty cumbersome.

http://www.stephenhorlander.com/images/dev-usability/Current-Customize-Window-(Default).png

I built some wireframes to illustrate how this could potentially work
and look. There are two versions of pretty much the same concept. They
both explore more visual and thorough manipulation of interface
elements. The key difference is that one is more controlled (closer to
what we have now) and the other is more freeform.


1) Controlled Version
In this version built-in toolbars have a predefined place and are
simply turned on or off (added or removed).

- Overview
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(Controlled)-(Overview).png

Just going to give a quick overview, the wireframes have more details
both visually and textually:
• Split the Customization window/sheet into two "Panes". Toolbars on
the left and Toolbar Items on the right.
• Clean up the icons: Align them in a grid, reduce the padding around
them and try and group them better.
• Slide in close buttons on toolbars that can be removed.
• Slide in a button to move the Tab Bar.
• Move the icon options to the bottom left(below the panes across
from the "done" button) and free up some more space.
• (Not Shown) Potentially change the look of the browser chrome in
some way to indicate you are in customization mode. Texture, color,
darker, lighter, etc.

- Adding a Toolbar
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(Controlled)-(AddToolbar).png

• Click on the "+" button to add a toolbar.

- Removing a Toolbar
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(Controlled)-(RemoveToolbar).png

• Click on the "X" button to remove a toolbar.

- Moving the Tab Bar
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(Controlled)-(MoveTabBar).png

• Wording here isn't very good. Probably a better way to describe
what you actually want to do with the Tab Bar.
• Click on the "Shift Down" button to move the Tab Bar.

- Adding a Toolbar Item
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(Controlled)-(AddToolbarItem).png

• This is one area where I think it would really pay to have more
animation.
• Should be obvious 1) where the item can go and 2) where you are
placing it. Right now neither is very obvious.
• I think it should also be obvious that you are removing the item
from the pane.


2) Freeform Version
This version is much more freeform. Instead of toggling toolbars you
would have the ability to place them in a variety of places. You could
drag and reorder them based on preference. Allows for more
customization but might also be overkill (not to mention lot's more
work ;)).

- Overview
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(FreeForm)-(Overview).png

Differences from Controlled version:
• "Grippies" give a tactile indication that a toolbar can be
rearranged/moved.
• Allows for variable placement of toolbars.

- Adding a Toolbar
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(FreeForm)-(AddToolbar).png

• Drag a toolbar out of the Toolbars pane to add to the window.
• "+" indicates that it can be added.
• Glowing area indicates where it can be added.
• Other toolbars slide out of the way.
• Matches the process for adding an item to the toolbar.

- Removing a Toolbar
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(FreeForm)-(RemoveToolbar).png

• Closed Toolbar animates back to the Toolbars pane.

- Moving the Tab Bar
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(FreeForm)-(MoveTabBar).png

• Moving the Tab Bar would be a more manual process, but it could go
more than two places.
• Titlebar would reappear if moved from the top.


3) Menu Version
- Wireframe: http://www.stephenhorlander.com/images/dev-usability/Wireframe-(CustomizationUI)-(Menu)-(RightClick).png

• More like a secondary or alternative option. If you wanted to
quickly toggle toolbars on or off you could do so from a menu. Exactly
what we have now except there would be an option to move the Tab Bar
and more options for toolbars to toggle (Menu Bar, Status Bar).

• Right-click menu on a toolbar item would have an option to remove
it from the toolbar.


I really like the idea of a unified and more visual interface for
customizing Toolbars and Toolbar Items. What is in place now sort of
accomplishes that, but it seems clunky if not hard to use. It
certainly isn't enjoyable, informative or intuitive.

Thoughts, suggestions, comments and angry shouting are welcome :)
• Is this totally off-base/terrible/ugly/etc?
• Have a better idea?
• Something totally off the wall?


(I hope this comes out ok because I have no way to preview or take it
back)

Alex Faaborg

unread,
Aug 7, 2009, 4:29:45 PM8/7/09
to Stephen Horlander, dev-us...@lists.mozilla.org
I have a ton of thoughts on this, but unfortunately haven't had a
chance to reply in detail yet. Here is the set of thoughts on the top
of my head:

> 1) Controlled Version
> 2) Freeform Version
> 3) Menu Version

I think having very large and obvious grippy areas on the toolbars
ends up working better than a "shift down" button or contextual
commands, since both of those are kind of meta, and the grippy things
are really direct manipulation and have a well established visual
affordance. So of the three I think 2) freeform version will be
considerably easy to use than the other two.

The one big problem with direct manipulation customization interfaces
is how you remove something. I've seen this solved with the addition
of a trash can, or annoying descriptive text "drag back to the window
to remove." I think this is the only area where direct manipulation
really falls down, we need to do things like have close buttons
(controlled version) as well as remove contextual commands (menu
version), in addition to perhaps a direct manipulation trash can in
the customization palette.

==A few platform requirements for the customization itself==

-we need the ability to draw the control that the user is currently
dragging around, so customization feels much more like actual direct
manipulation. It needs to feel like you are picking the control up
and actually moving it around.

-as you mention having animations would be really helpful as well. OS
X in particular does an absolutely fantastic job of sliding controls
out of the way as you drag a new control in, complete with biological
motion (speeds up as it start to move, and slows down before coming to
a complete stop).

==A few major platform requirements that cover why we broke
customization in the past==

-we really need the ability for multiple instances of the same control
to appear in a customization palette (like separate back and forward
buttons, and a combined keyhole set, as the major example of us
breaking customization due to a technical limitation in the past).
This gets even more important if we are going to have a menu bar and a
page/tools set up, and if we are going to try things like a stop/go/
reload combination button.

-we need the ability to change the visual form of a button depending
on it's location. So for instance, allowing the stop button to attach
on to the end of the location bar when it is placed there, or morph
into an independent button when it is placed elsewhere. The form
would need to be based on both what is on either side of the control,
allowing for things like (but not specifically) this:

http://people.mozilla.com/~faaborg/files/20081021-visualHierarchyAndCustomization/protoKeyhole.png

I also have a long post about some of these challenges that we've
faced that tries to explain how we got to the current theme and
intentionally decided to break customization (because we had to given
our limitations). People may have already read it, but if not it
provides a good set of background information about Firefox 3 and 3.5:
http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-contention-between-visual-hierarchy-and-toolbar-customization/

-Alex

> _______________________________________________
> dev-usability mailing list
> dev-us...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-usability

DonGato

unread,
Aug 17, 2009, 7:50:21 AM8/17/09
to
Any of the two first designs seem rather nice. I'm not particularity
fond of the menu option as it will still need the old icon
customization window. I agree that the current customization window is
not nice at all and needs a replacement, and your propositions (1 and
2) look like a really good and innovative way of fixing it.

About the "OMG change!" I would say it's not like that. The problem,
this time, is that people aren't identifying a real breakthrough in
those changes. In my case, with the awesome bar, I got distracted at
first but I thought that it could work and now I love it. In any case
my initial reaction was, something new, might be useful, let's try it.
Now, with the tabs on top I already tried it (in Chrome) and don't
find them useful at all so I know what to expect. Integrating the go/
cancel/reload button is another problem because I don't use the go
button at all and cancel and reload in the same place might be
confusing and lead to canceling when you wanted to reload (I don't
know what application I used with this concept but I was really
frustrated with it).

In any case, I'll rest peacefully thinking you already acknowledged
that taking away customization from Firefox users would be unwise and
against its own philosophy.

0 new messages