Keep bar-style notifications for Firefox 4 on Linux instead of doorhanger notifications which breaks consistency on GNOME desktop
Citizendruide
I copy-paste the first and only comment right now, please, discuss it
here as Bugzilla is not really made and easy to use for discussion...
-- Comment 1 -- From antistress
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/
20100101
Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/
20100101
Firefox/4.0b6
I'm running Firefox on GNOME
New Remember Password doorhanger notification (Firefox 4) breaks
consistency
over the GNOME desktop which uses GTKInfoBar (GTKInfoBar looks like
current
Firefox 3.6 bar-style notifications system) : very bad from my point
of view
and
regarding user experience.
Until know Firefox made effort to integrate well in each desktop and
that is
good if not necessary. Breaking consistency by changing the
notification system
would be an important regression to me.
I think that, on GNOME, Firefox should keep the current Firefox 3.6
bar-style
notifications system.
Thanks
Reproducible: Always
My intial comment was posted under Bug 567814 "Convert Remember
Password
notification bar to a doorhanger notification" (see c#45)
It also applies to Bug 588309 "Convert change password to a doorhanger
panel" for the same reason.
I had a brief discussion under Bug 572482 "[Linux] UI Refresh" which
seems to
be a meta-bug for Linux UI (see c#48 to 52)
Alex Faaborg
better solution to a particular interface, there is an advantage to using
that solution (even if it is different). We've also seen aspects of
Firefox's UI influence the design of Gnome (most recently a discussion
around application buttons that encapsulate the title and main commands).
So these types of changes are more fluid and incremental than a top down
approach where the Gnome team writes a Human Interface Guidelines rule book,
and then every application has to blindly follow it regardless of if a
better solution exists.
The specific advantages of our new panel based system are:
1. Identifiable with low resolution peripheral vision
2. Easy to ignore, by clicking outside to close
3. Easy to bring back, since they have a persistent anchor (supporting undo
if the user changes their mind)
4. Natual mapping to the site identity block that is originating the
notification, making it clear who is asking for what (more important in the
case of the Web, where these notifications involve permissions, and we want
users to consider the identity of the site asking for their physical
location, or a live feed from their webcam, etc.)
-Alex
> _______________________________________________
> dev-usability mailing list
> dev-us...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-usability
>
antistress
Now that i see the big picture i can understand the change even on
GNOME : I surrender.
However i would like to point out 2 things :
I didn't know that the panel could be closed by clicking outside. Not
very discoverable actually. This is related to my 2nd point :
The new panel based system hide tabs buttons if "tabs on top" is
unticked.
In my case i wanted to activate a background tab and the panel prevent
me from switching. Since i wanted to click on a tab button and that my
tab bar was full of tabs, i couldn't try to click outside the panel to
eventually discover it.
I think you should draw the conclusion of the new panel based system
and remove the menu entry that allow users to not have tabs on top.
This looks like an advanced setting which should not be exposed in the
View menu : it clutters the menu for nothing since not having tabs on
top creates a usability problem with the the new panel based system.
You can let the setting in about:config if you want, for advanced
users.
BTW i really like the idea of the anchor which is very practical
(though not very discoverable either, at least until Firefox
implements the whole identity/permission button in the future)
Thanks again
On Sep 21, 10:19 pm, Alex Faaborg <faab...@mozilla.com> wrote:
> External consistency is important, but in cases where we feel we have a
> better solution to a particular interface, there is an advantage to using
> that solution (even if it is different). We've also seen aspects of
> Firefox's UI influence the design of Gnome (most recently a discussion
> around application buttons that encapsulate the title and main commands).
> So these types of changes are more fluid and incremental than a top down
> approach where the Gnome team writes a Human Interface Guidelines rule book,
> and then every application has to blindly follow it regardless of if a
> better solution exists.
>
> The specific advantages of our new panel based system are:
>
> 1. Identifiable with low resolution peripheral vision
> 2. Easy to ignore, by clicking outside to close
> 3. Easy to bring back, since they have a persistent anchor (supporting undo
> if the user changes their mind)
> 4. Natual mapping to the site identity block that is originating the
> notification, making it clear who is asking for what (more important in the
> case of the Web, where these notifications involve permissions, and we want
> users to consider the identity of the site asking for their physical
> location, or a live feed from their webcam, etc.)
>
> -Alex
>
> > dev-usabil...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-usability
Alex Faaborg
> I didn't know that the panel could be closed by clicking outside. Not
> very discoverable actually.
>
Yeah, this makes the first time the user encounters the panel a little
difficult (although for the benefit of streamlining every future interaction
they have with this type of panel). Since the panel doesn't contain a close
button, and everywhere outside of the panel is obviously a rather large
click target, users kind of can't help but eventually discover that these
are click outside to close. We are also planning to visually reinforce how
ephemeral these panels are by making them slightly transparent. However for
the first interaction, there is a moment before users discover that they are
click outside to close, and they might feel slightly confused.
The new panel based system hide tabs buttons if "tabs on top" is
> unticked.
> In my case i wanted to activate a background tab and the panel prevent
> me from switching.
>
This is a problem we'll need to consider some more. One option is for us to
drop the direct association with the site identity block in favor of placing
these notifications in the center of the content area with tab modal panels
(similar to our plans for javascript alerts, and other forms of tab modal
dialogs). Unfortunately this also causes the panel to lose its direct
association with the anchor that can be used to bring it back.
-Alex
antistress
are by making them slightly transparent"
GNOME notification bubles use to have a count down (see at the right
of the Run button here http://www.dijksterhuis.org/wp-content/uploads/2009/01/notification_sample.png
) which is useful to give feedback to the user otherwise he doesn't if
he will have the time to click.
BTW, why having a drop down list in the buble instead of 2 separate
buttons ? Since drop down list hide the choice and requires some mouse
skills it should be used only if necessary i think
On Sep 22, 2:24 am, Alex Faaborg <faab...@mozilla.com> wrote:
> > I didn't know that the panel could be closed by clicking outside. Not
> > very discoverable actually.
>
> Yeah, this makes the first time the user encounters the panel a little
> difficult (although for the benefit of streamlining every future interaction
> they have with this type of panel). Since the panel doesn't contain a close
> button, and everywhere outside of the panel is obviously a rather large
> click target, users kind of can't help but eventually discover that these
> are click outside to close. We are also planning to visually reinforce how
> ephemeral these panels are by making them slightly transparent. However for
> the first interaction, there is a moment before users discover that they are
> click outside to close, and they might feel slightly confused.
>
> The new panel based system hide tabs buttons if "tabs on top" is
>
> > unticked.
> > In my case i wanted to activate a background tab and the panel prevent
> > me from switching.
>
> This is a problem we'll need to consider some more. One option is for us to
> drop the direct association with the site identity block in favor of placing
> these notifications in the center of the content area with tab modal panels
> (similar to our plans for javascript alerts, and other forms of tab modal
> dialogs). Unfortunately this also causes the panel to lose its direct
> association with the anchor that can be used to bring it back.
>
> -Alex
>
> > dev-usabil...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-usability
Allan Caeg
Firefox has a better solution than what already exists, I think, it's best
to integrate that solution to the desktop.
Do we have a list of UI solutions that deviate from the platform? We, people
who work on the desktop, can look at that list so we can integrate them to
the GNOME desktop.
On Wed, Sep 22, 2010 at 4:19 AM, Alex Faaborg <faa...@mozilla.com> wrote:
> External consistency is important, but in cases where we feel we have a
> better solution to a particular interface, there is an advantage to using
> that solution (even if it is different). We've also seen aspects of
> Firefox's UI influence the design of Gnome (most recently a discussion
> around application buttons that encapsulate the title and main commands).
> So these types of changes are more fluid and incremental than a top down
> approach where the Gnome team writes a Human Interface Guidelines rule
> book,
> and then every application has to blindly follow it regardless of if a
> better solution exists.
>
> The specific advantages of our new panel based system are:
>
> 1. Identifiable with low resolution peripheral vision
> 2. Easy to ignore, by clicking outside to close
> 3. Easy to bring back, since they have a persistent anchor (supporting undo
> if the user changes their mind)
> 4. Natual mapping to the site identity block that is originating the
> notification, making it clear who is asking for what (more important in the
> case of the Web, where these notifications involve permissions, and we want
> users to consider the identity of the site asking for their physical
> location, or a live feed from their webcam, etc.)
>
> -Alex
>
> On Tue, Sep 21, 2010 at 1:04 PM, Citizendruide <citize...@gmail.com
> >wrote:
> > _______________________________________________
> > dev-usability mailing list
> > dev-us...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-usability
> >
> _______________________________________________
> dev-usability mailing list
> dev-us...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-usability
>
--
Regards,
Allan
http://www.google.com/profiles/allancaeg#about<http://www.google.com/profiles/AllanCaeg>
+63 918 948 2520
Alex Faaborg
> Do we have a list of UI solutions that deviate from the platform? We,
> people who work on the desktop, can look at that list so we can integrate
> them to the GNOME desktop.
>
I should give this some more thought, but here's what comes to mind off of
the top of my head of aspects that somewhat deviate. Also some of these are
just aspects of Firefox's design approach that I think are generally a good
idea and I would really like to see cross pollinate into other open source
projects:
-The notion of an application button that simultaneously serves as both
window title and contains all top level commands
-Lightweight and reproducible notifications (ok/meh instead of ok/cancel)
-A general hesitation to interrupt the user with (probably) non-actionable
information. For instance, Firefox used to very aggressively inform users
when there were updates available for their extensions, even though the vast
majority of users don't actually care. An analogy to the desktop would be
when the Windows system tray informs me that someone in the office just
turned on a media center PC, or when OS X tells you about spotlight
indexing, or time machine backup. None of these things are likely to be
actionable. I can't immediately think of a good example of a meaningless
GNOME notification, but sometimes just providing the API can be
problematic. I think there's a reason apple didn't ship anything like
Growl, so GNOME might want to seriously consider if giving applications a
way to ping the user with d-bus is a good idea.
-Leveraging the user's spatial memory. Panorama is a good example of the
potential here, and I think the design principles it employs definitely
apply to managing files and applications in a desktop environment.
-Toolbar controls that have a visual hierarchy. This is something that I
would like for us to be able to do on Linux, but isn't really compatible
with the system native icons. I have a post about what I mean by visual
hierarchy here:
http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-contention-between-visual-hierarchy-and-toolbar-customization/
Hopefully that helps, and I'll give this some more thought as well,
-Alex
Allan Caeg
on a wiki/blog post/wherever, that would be nice so it's easier to spread
the word.
Right now, I'm working on bringing something like Panorama to the desktop by
adopting some of its features to GNOME's virtual workspaces. I'll give your
points more thought as well. I informed the GNOME usability team about it
already. I'm looking forward to progress on this.
Peter Lairo
> -Leveraging the user's spatial memory. [..]
>
> -Toolbar controls that have a visual hierarchy. This is something that I
> would like for us to be able to do on Linux, but isn't really compatible
> with the system native icons. I have a post about what I mean by visual
> hierarchy here:
> http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-contention-between-visual-hierarchy-and-toolbar-customization/
There you say: "Creating a visual hierarchy based on things like size,
shape, position and *color* results in *more memorable and recognizable*
products."
I don't think I've ever seen the reasoning for removing the colors from
the Navigation Toolbar buttons. That was a big change. Why are they all
monochrome in Firefox 4?
--
Regards,
Peter Lairo
Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444
Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis
Ron Hunter
> On Thu. 23.09.2010 4:44, Alex Faaborg wrote:
>> -Leveraging the user's spatial memory. [..]
>>
>> -Toolbar controls that have a visual hierarchy. This is something that I
>> would like for us to be able to do on Linux, but isn't really compatible
>> with the system native icons. I have a post about what I mean by visual
>> hierarchy here:
>> http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-contention-between-visual-hierarchy-and-toolbar-customization/
>>
>
> There you say: "Creating a visual hierarchy based on things like size,
> shape, position and *color* results in *more memorable and recognizable*
> products."
>
> I don't think I've ever seen the reasoning for removing the colors from
> the Navigation Toolbar buttons. That was a big change. Why are they all
> monochrome in Firefox 4?
Yes. We seem to HAVE to copy what IE and Google Chrome decide. The
goal seems to be a colorless interface like that in Safari. sigh.
I am sure that extensions will remedy this quickly.
David McRitchie
> the Navigation Toolbar buttons. That was a big change. Why are they all
> monochrome in Firefox 4?
A "necessary evil" to push personas. The MUCH larger mostly translucent
buttons will work with a wider range of personas.
"The Plan" -- http://www.weirdity.com/jokes/creationism.shtml
Peter Lairo
> "Peter Lairo"
>> I don't think I've ever seen the reasoning for removing the colors
>> from the Navigation Toolbar buttons. That was a big change. Why are
>> they all monochrome in Firefox 4?
>
> A "necessary evil" to push personas. The MUCH larger mostly translucent
> buttons will work with a wider range of personas.
If that is true, then that was a very bad decision IMO. I suspect the
vast majority of users - and an even larger majority of novice users
(who need good UI clues) - do not ever use Personas. To sacrifice
usability for so many for some needless wallpapering by so few seems a
poor trade-off. And weren't Themes able to change the buttons' appearances?
Asa Dotzler
> "Peter Lairo"
>> I don't think I've ever seen the reasoning for removing the colors
>> from the Navigation Toolbar buttons. That was a big change. Why are
>> they all monochrome in Firefox 4?
>
> A "necessary evil" to push personas.
Citation needed.
- A
Ron Hunter
I like color, and I really don't like the trend, and this not just
Firefox, toward colorless interfaces. It seems that the thinking is
that the more monochrome the interface is made, the less 'intrusive' it
it to the website that is displayed, making the UI seem 'smaller'. I
can think of no other justification for this trend. Frankly, I hate
this, and have not bought a well known product just because the UI is so
plain, and downright ugly, that I don't believe I could stand to use it.
Color communicates, and isn't that what we are trying to do?