GNOME Bugzilla – Bug 594607
Bars (menu bar, toolbar and url bar) needs to be revamped since GNOME decision to use "Text beside icons" toolbar style
Last modified: 2009-12-20 17:53:54 UTC
Since GNOME decision to use "Text beside icons" toolbar style for version 2.28, we see that 50% of Epiphany bars are empty in normal use cases ! see screenshot attached Maybe the bars should be revamped (i.e. placing url form and tools icons on a same bar)
see decision to use "Text beside icons" toolbar style for version 2.28 : http://mail.gnome.org/archives/gnomecc-list/2009-July/msg00015.html reasons for that were : "My reasoning is: 1) This reduces the amount of vertical space uses in toolbars, allowing more room for actual content 2) Important buttons are given a larger size than other buttons, meaning better fitts-law for these buttons. 3) This seems to be a good compromise between "icons only" and "icons and text" 4) It seems to be more similar to other environments" I think we should take care of the 1st reason and allowing more room for the web page
Created attachment 142766 [details] 50% space for nothing in bars
IIRC, this used to be because the default toolbar layout style setting in gnome was "text below icons", and epiphany devs could not put the address bar on the same toolbar by default because it would have looked weird (Bug #412385 or another?). Now that the gtk folks decided to just use text-besides-icons as the default layout style, maybe a new default layout could be reconsidered for epiphany.
http://www.mail-archive.com/epiphany-list@gnome.org/msg01260.html Reinout van Schouwen, Tue, 21 Mar 2006 : In the latest Epiphany UI-review [1] the conclusion was that we should not override GNOME defaults w.r.t. text/icon settings. However we should start a discussion before 2.16 about if we still want text below icons as the default. Personally, I like text *beside* icons a lot better. (In this case, only labels flagged as priority text will be shown.) [1] http://xhtml.md/misc/epiphany/ui-review/ui-review.log (or http://web.archive.org/web/20070223233006/http://xhtml.md/misc/epiphany/ui-review/ui-review.log ) Here we are see also https://bugzilla.gnome.org/show_bug.cgi?id=105983 http://mail.gnome.org/archives/epiphany-list/2003-April/msg00071.html
(In reply to comment #4) > http://www.mail-archive.com/epiphany-list@gnome.org/msg01260.html > Reinout van Schouwen, Tue, 21 Mar 2006 : Yes, that's what I said back then. Can you be a bit more specific about the point you are trying to make?
Sorry, i just wanted to point out what was the state of the discussion before the new GNOME decision to use "Text beside icons" toolbar style, to help putting this bug report in its context, nothing more
i'd like to make some suggestions about bars : About Bookmarks button in toolbar : I'm not sure it needs a "priority text" label nor it has to sit in toolbar by default : 1°) There already is a Bookmarks menu with direct access to bookmarks and an entry which acts the same as the bookmarks button 2°) Bookmarks button launches a dedicated window with search field but the url bar already allows to search a bookmark both from its name or its tag Therefore i think that button should be removed by default. At least, it should not have a "priority text" label. Of course user still can bring it back thanks to the toolbar editor. About History button I'm not sure what to do with it. It seems that it can be more useful that the Bookmarks one since there is no menu for it (only a submenu). However are beginners at ease with floating windows like the History and the Bookmarks one ? I tend to consider that for beginners one application=one window About Home button : I don't use it but i'm pretty sure it can be very reassuring for beginners. Let it in the toolbar with a "priority text" label (=don't change anything about it) Besides i know that some companies like creating a time-efficient start page on their server with useful bookmarks for their employees. About separators I suggest to keep them since they help a bit to understand the GUI. - I guess that back, forward, stop & reload could be grouped together. They are about the same workflow : acting on the current page (stop & reload) or from the current page (back & forward). - Home and url bar (and Go button) could be grouped together : they are about going somewhere else, somewhere not related to the current page. - Zoom in & out are - like the fisrt group - about acting on the current page. They could be grouped with back, forward, stop & reload but i think that these button are less often used therefore placing them in the right corner could be a better choice. Besides it's consistent with Nautilus. Since Epiphany has a toolbar editor, i think that the GUI has to be designed for beginners first, since advanced users are able to change defaults. Attached is the corresponding mockup : nothing very original though
Created attachment 142951 [details] mockup that corresponds to the above comment (url bar and toolbar are merged)
In a next move, you could decide whether keeping the Go button outside the url bar or moving it into the url bar (GtkEntry widget)
If the Go button was moved into the url bar, we could imagine having Go and Stop buttons combined : the Go button would ever be displayed except while the page is loading : during the loading task, the Stop button would be displayed instead of the Go one. You can look at Chromium for a mockup.
(In reply to comment #10) > If the Go button was moved into the url bar, we could imagine having Go and > Stop buttons combined : the Go button would ever be displayed except while the > page is loading : during the loading task, the Stop button would be displayed > instead of the Go one. Overloading the function of a button to do multiple things according to cicrumstances, is not the type of UI simplicity that Gnome strives for, IMHO.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 412385 ***