On Wed, 2012-05-30 at 13:32 +0200, Felipe Erias Morandeira wrote: > Hi, > > I have implemented a small prototype of the proposed navigation for > Epiphany, as described in https://live.gnome.org/Design/Apps/Web > > The basic idea is that open tabs are placed in a horizontal list, with > the last visited ones on the left. > > You would click on a thumbnail to open the web page; from there, > clicking on "Pages" would take you back to the overview of open pages. > > I have also implemented an alternative UI where the open pages are > arranged in a 2D grid. > Thanks for great mock up. > > For comparison with the existing solution, this is the command line > command to open the same set of tabs in Epiphany: > > epiphany -n \ > www.reddit.com \ > www.fsf.org \ > www.gnome.org \ > www.google.com \ > www.mozilla.org \ > www.freedesktop.org \ > www.igalia.com \ > www.webkitgtk.org \ > www.webkit.org \ > www.amateurgourmet.com \ > www.reddit.com/r/cooking \ > www.reddit.com/r/funny > > > This application has limited functionality because its goal is only to > quickly test a very specific behaviour. Specifically: > - the list of pages is hardcoded > - frequently opened pages are not displayed under the open tabs > list, as the design calls for > - "Recent", "Favorites"... do not work > - when a website is open, only following links and "Pages" work > > > You can grab the code here: > http://people.igalia.com/femorandeira/files/Ephy_20120530.tar.gz > > > The project folder includes compiled binaries that should work on, at > least, 64-bit Debian and Ubuntu. Just uncompress it and run > > cd Ephy ; ./Ephy > > Note that if you want to build it yourself, you will need the qt4, > qt-webkit and qmlviewer dev. libraries for your distribution; then, > you can just run > > make distclean ; qmake && make > > > The application allows for some customisation through the command line: > > --grid : Display open pages in a grid (default: horizontal list) > --reorder : Open tabs are reordered by last used > --help : Print this message > > ./Ephy --reorder would give you a list without reordering, > ./Ephy --reorder is the currently proposed behaviour > ./Ephy --grid would sort the open tabs in a fixed 2D grid, > ./Ephy --grid --reorder would place the last open tab at the top left > corner of the grid. > I am not sure if 'destroying' the difference between 'opened page' and 'recent page' is best way. The current implementation is wonderful for the initial screen but there is a few cases when you want to know if tab is opened: - Login to free WiFi requires to have window opened all time otherwise the connection won't work (yes - I know it's 2012 and virtually all devices have WPA2 but I don't set up this AP). If user go to other pages - will he be logged out? - Uploading large file (to say YouTube/Vimeo/Dropbox/...). User might want to continue browsing but still use the browser. - Some page have flash animation (or java script animation, or java applet). It consumes lots of resources (memory and cpu). User might want to close it. - Will it preserve volatile state (text fields etc.)? When I write a comment to bug report I often check the data on other pages etc. I might context switch to another task if the latter will be more urgent etc. I guess on mobile the background tabs can be often closed (there are seldom large data uploads, many smartphones have data plans etc.) but it won't be the case with laptops. Also I am not sure if it is best replacement for tabs in all usecases. I use tabs in a few ways (often in different windows) and I guess the use is rather common: - Various 'applications' opened I check periodically (say Google+, Facebook, Twitter...). It seems to be great for it. - Short following links (to check definition on Wikipedia for example). It seems manageable. - Read list for later (IIRC it was suppose to be implemented as separate feature but I guess it should be implemented before removing tabs). > > Please, let me know if this works for you. I know that using QML to > prototype GNOME applications might sound like a strange proposition, > but in this case I just wanted a quick way to test the behaviour > without writing any final code. > > I am open to use a similar approach to explore the design of other > parts of GNOME. > Thanks for work. Such mockups help to understand the concepts behind the design > > Regards, > > Felipe Maciej, PS. Sorry for lots of 'I'. I understand that I may not be a typical user but I guess I found several use cases when the design might not work as well as current one. I am not a designer so it might be just the mockup shortcoming and/or require small changes in a few places.
Attachment:
signature.asc
Description: This is a digitally signed message part