Gnome HIG vs. Greg's recommendations; list search not working

[Jörg Hartmann <jhartmann aquilacoop de>]

Hi there,

first a side note: the search function of your list archive doesn't give any
results. So I could not look if this was already discussed beforehand. (I
did not like to manually browse through all posts ...)

Well, this is the topic:

Greg Merchán (hi Greg, put a Content-Type into your page and make it valid
XHTML ...) took the time to propose some GUI changes for Epiphany.
http://www.phys.lsu.edu/students/merchan/GNOME/Recommendations/Epiphany/

I'd like to note that this partly violates the GNOME HIG - or should be
interpreted in a non-violating way.
http://developer.gnome.org/projects/gup/hig/1.0/

His 1st point ("page icon" alias favicon within the location entry) is well
and important. Here Epiphany's present GUI violates both consistency and
HIG: it puts something flat into the toolbar which is not a representation
of an active tool element. Yes, the favicon is part of the representation of
the location entry (not necessarily a page), not of anything separate.
That's why all major browsers put it into the location entry. (Like a file
browser which puts the file icon into the file name column, just before the
file name, with nothing in-between.)

Greg's 2nd point's first sentence is not fully consistent. Even if the
location (or the site it belongs to) does not offer a special favicon, the
icon is a representation of the selected location. So it should always
reflect this by showing either the favicon or, if there's no favicon and you
still need an icon, by showing a standard icon for locations of the
corresponding type. (Like file browsers show standard icons for certain
types of links or link files.) An Epiphany application icon should only show
up there if the selected location is of a type that has this icon as it's
standard icon ...

While Greg is right that the location entry's drop-down list looks not very
funny, his alternative proposal is both violating the Gnome HIG as well as
inconsistent with his own reflections on the favicon. While he correctly
proposes to put the favicon where it belongs logically (into the location
entry, since it represents this), he proposes the opposite for the location
entry's drop-down list. Of course, this should also be where it belongs. As
it's name already indicates ("location entry's drop-down list"), that's
optically within the location entry, not flat besides it (as if it was a
separate button). That GTK+ drop-down lists don't look that great compared
to those of Mozilla-XUL or other OS GUI's is a problem that can only be
solved by enhancing GTK+ (and so the Gnome HIG), not by building proprietary
Epiphany GTK+-counterparts. One might propose to make drop-down lists look
like they do in Mozilla Firebird (or even M§ .NET if one likes everything
flat), but this is something to propose to the Gnome GUI people, not
Epiphany.

I fully agree with Greg's 4th point (moving the lock icon to the left). And
by the way, I don't think that showing no lock icon at all when the page is
_not securely transferred_ (like some other browsers do), but showing it
_when the transfer is secured_, is fully stupid, since it's exactly that
what a user needs to take notice of and care about: that his transfer is
_not_ secure. (100% stupidity shows IE: an alert box when the user enters an
SSL-secured site instead of alerting when he enters a _not secured_ one ...)

Greg's 5th point is HIG-violating. Neither is the lock icon an active GUI
element (like a button), nor are (Gnome) statusbars flat at all. Look here:
http://developer.gnome.org/projects/gup/hig/1.0/windows.html#primary-windows
So Greg did not "change the bevel around the lock icon to match that of the
statusbar". Instead he changed both bevels ... (The left part of the present
Epiphany statusbar is inconsistent with Gnome HIG statusbars, the right part
--progress bar-- is HIG-compliant.)

Well, Greg is right: when there is nothing done, then there's also nothing
to report within the statusbar. What's "done" - especially when the window
shows an empty page? There's actually nothing "done" at all with that page.
The statusbar is for reporting the status of _what's in the window at that
time_, not what's "done" before. Did you ever see any other application's
document window state a document load would be "done"? You get the point ...

For windows with no progressing action, Greg's 7th point may be correct (and
would leave more space for other messages, if required): when there's no
progress to report, then there's no need for a progress bar. But while there
_is_ progress (when something loads), then a progress bar makes good sense,
especially when loading long documents.

Well, besides that statusbars and their elements shouldn't be flat, point 8
is o.k.

Point 9 (app name in title bar) is funny: "when no page is loaded". When is
this? An empty page _is_ a page. Epiphany windows with no page at all -
simply don't exist. So there's no need for this point.

Again, point 10 clearly violates Gnome HIG: document windows shall show the
document name, main windows of non-document apps shall show the app name. Is
"Loading..." the name of a document or an app? ;) Well, it's also not very
useful: when someone is waiting for a page to be loaded completely, he
better can start reading (e.g. the page title) instead of guessing what is
"loading ..."

Point 11, 13: The throbber does not only indicate loading of the page itself
but instead loading of _any_ content. (When a banner refreshes, the throbber
indicates this.) So spinning arrows within the location entry (which only
represents the user-selected main location, not gif locations etc.) are not
an appropriate alternative. And don't forget that _any_ GUI animation is
REALLY BAD DESIGN and against all accessibility guidelines. (Gnome HIG
explicitly states accessibility.)

Point 12 reflects the imprecise mixing of favicon and "page icon". No, the
icon of a location entry (points 1 and 2) does not represent the same as the
icon in a window's title. Just like the location entry is different from the
window title itself. The former represents the location, the latter the
loaded document itself. So while the location entry's icon corresponds to
the entered location, the icon within the window's titlebar corresponds to
the document - just like the title itself. Just think of a file browser:
there you have icons for links (link files), and you have icons for the
original document files (which the link files link to). Well, if there's a
favicon that represents a whole site and all of it's documents, then both
the location icon and the window icon will be the same. Otherwise they are
different. (I still don't know if an icon for a location entry that has no
favicon is really needed at all.)

So that were my humble thoughts on this. Feel free to correct my mistakes.

Cheers,
Joerg H.