GNOME Bugzilla – Bug 649795
Make Windows and Applications easier click targets; prettier
Last modified: 2012-05-21 23:17:37 UTC
Created attachment 187509 [details] Mockup for a visual treatment of the Windows and Applications buttons The height of the Windows and Applications 'buttons' - plus the lack of a visible border - makes them rather tricky click targets. Making them taller and identifying the click area would make them easier to hit. It would also be nice if their appearance could be improved. The current off-white selection graphic seems inconsistent with the rest of the shell's visuals and could probably be finessed. I've attached a mockup to give a rough idea of what I mean. (I sure it's not exactly what we want.)
Created attachment 187515 [details] [review] overview: Restlye tab buttons Restyle tab buttons to make them better looking and easier click targets.
I definitely agree the mode switching is suboptimal in the overview. I don't think the proposed solution is enough. We've iterated through a number of solutions, aiming to better communicate the mode switch and proviing a better click targets for these. In addition switching these overview modes will be achievable by horizontally scrolling as soon as we paginate applications rather than scroll them. Current iteration of the design: App picker: http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-application-picker.png Window picker: http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-6-workspaces.png
Review of attachment 187515 [details] [review]: Marking needs work based on Jakub's feedback,
Frankly speaking I think the current design is slicker, I'd prefer not to have another bar, but this design make the button tabs more obviously clickable and also the search field clearer, which is another thing people tend not to get right, so +1 here.
(In reply to comment #2) > In addition switching these overview modes will be achievable by horizontally > scrolling as soon as we paginate applications rather than scroll them. Drive-by programmer design comment: really hate this idea - paging is only good if you almost never have to go past the first page - so it should only be used when ordering is by recency/frequency/etc, and not with alphabetical order.
The benefit of the pagination over continuous scrolling would be spatial memory of where launchers are. That would imply a fixed order defined by the user, so no automatic reordering.
I just filed bug 649998 to deal with the pagination question.
Here's another approach more inline with the current state: http://dl.dropbox.com/u/208474/gnome-shell-tabs.png
I don't think paging a good idea here. * I don't find it helps me locate apps on my iphone (that could be personal). * As mentioned, install/uninstalling an application would change the flow/sort order which wipes out any spatial memory benefit. It can't possibly go in without persistent order defined by the user. * If the pager is to help browsing for applications, how can removing the categories help? * If the pager is to launch frequent apps then we have search for that (and favorites). So in the frequent apps case it is slower that fave/search, and in the unknown apps case its harder because of no categories. I don't see a win here...
(In reply to comment #9) > I don't think paging a good idea here. The paging issue is covered by bug 649998. > * If the pager is to help browsing for applications, how can removing the categories help? See bug 638271.
(In reply to comment #10) > (In reply to comment #9) > > I don't think paging a good idea here. > > The paging issue is covered by bug 649998. > > > * If the pager is to help browsing for applications, how can removing the > categories help? > > See bug 638271. I read the paper and commented on that bug. I think the paper is being too broadly interpreted in this case - with search otherwise prominent. So my first point still stands I think. Why is this discussion split over 3 bugs?
I think that line running under Windows / Applications buttons and Search box adds unnecessary clutter to what is currently a beautifully minimalist display... but what if, instead of buttons, the Windows and Applications text were on tabs?
(In reply to comment #11) > Why is this discussion split over 3 bugs? Pagination (bug 649998) is dependent on but not required by dropping categories (bug 638271), so they are still different questions. This bug is a *completely* different issue. Please direct your comments to the appropriate bug: you're raising the noise level and causing unnecessary bug mail.
Overview relayout is going to happen. Not going to restyle the tabs.