I would point out that categories are already an excellent implementation of pagination, which works with spatial and conceptual memory, and allow for one choosing between contiguous or paginated scrolling.
(Yes, remembering "which category was that" is no different from "which page was that", except that you have control on categories and they most often have some sort of link to the kind of application)

I don't have a clear opinion yet about categories, the pagination has several advantages over scrolling btw, apart from the good points already noted by Allan and Jakub it's a lot easier to do, one click will get you always to the same position w/o the need of carefully aiming and dragging stuff with the mouse. I'd just avoid squares as in the mockup since they could be confused with workspaces.

Am I right to suppose that pagination does not mean that swipe-scrolling should be removed?

(In reply to comment #3)
> Am I right to suppose that pagination does not mean that swipe-scrolling should
> be removed?

Without knowing the background to this, I would say yes. Swipe scrolling would certainly be nice to have if we page through applications. (Sorry for the slow response!)

Thought I already bike-shedded here, but probably I decided against it after writing something. Well, I guess I'm feeling less circumspect this morning:

Paging is a bad design unless you have some reason to think that the first page is the page that users usually want. If you can order by relevance or frequency, it has some benefits. If you are ordered alphabetically, as we are, it's really annoying.

(In reply to comment #5)
> Thought I already bike-shedded here, but probably I decided against it after
> writing something.

You are probably referring to https://bugzilla.gnome.org/show_bug.cgi?id=649795#c5.

If you're going to show it in alphabetical order, why not do dictionary-style pagination:

AisleRiot Solitaire - Empathy
Evolution - Movie Player
Orca - Terminal
Transmission - XChat

or

A - Em
Ev - M
O - Te
Tr - X

but that may be a little cryptic and confusing

I think we should carefully think about the ordering, alphabetical is nice for visual memory, launchers are always in the same position (among the pages). Say need that app in page 2 second place, it would always be there if you don't install other software. Frequency is good for keyboard launching ala quicksilver and for quickly find stuff. when I type "i" I would like to get inkscape, not iagno for example.
We could go for a mixed approach, I think that if you actually search for an application (enter overview and type something) the one which matters is only the most used, so when I press "i" I could get inkscape in the first position and then the rest ordered alphabetically, in case of just click "applications" we could just show the first 5 most used apps then the rest ordered alphabetically. We may want to add some indication for the application ordered by frequency to make things clearer.

Unless the user has complete control over the order that icons are going to appear then I think pagination like this is bad. You, also, have to then worry about what happens when a user deletes an app (do all icons shift upwards by one, occasionally jumping from page 2 to page 1, etc...), and what happens when you install a new app. Right now it's fairly logical and you know to go looking alphabetically. Users probably aren't going to want to go all the way to the last page to find a new app and if the icon gets added to the first page then spatial memory is ruined.

In fact, I thought the current alphabetical list w/ scrolling and the categories listing at the side was an improvement over what Apple has planned for their "Launchpad" view. This seems like a step backwards to me.

Other options might be to keep the main view of icons alphabetical but allow users to re-order icons within each category view.

(In reply to comment #5)

> Paging is a bad design unless you have some reason to think that the first page
> is the page that users usually want. 

I think that depends on a few factors. One is the input device being used in combination with the interaction methods that we provide. Scrolling tends to be faster than paging if you have a mouse with a scroll wheel. Paging has the advantage when combined with swiping and a touch pad or touch screen, on the other hand. Is it possible to have efficient mouse interaction with paging?

The other factor is the number of applications that are preinstalled on the system . Paging will work better with fewer preinstalled apps (which should be a goal for other reasons, anyway).

One major point in favour of paging is the UX advantages of swiping as opposed to clicking or using a scroll wheel. Swiping up and down and from left and right would be a *much* more pleasant and satisfying way to navigate the overview, and it would reproduce the physical type of interaction that we did with window resizing. I definitely think this is a good way forward.

> If you can order by relevance or
> frequency, it has some benefits. If you are ordered alphabetically, as we are,
> it's really annoying.

The advantage of paging is spatial memory - you find each launcher as a result of its position. The arrangement of the launchers would need to be static, therefore. One possibility would be to introduce the ability for users to move launchers, though I'm not sure about that.

Hi, there are some essays about scrolling vs paging. I think this one is a worth reading for this case:

http://psychology.wichita.edu/mbernard/HSEF.Paging.pdf

"This study examined the performance and preference of individuals searching for information presented within search results that were displayed in either mostly paging or mostly scrolling formats. The conditions were: ten links per page at ten pages, fifty links per page at two pages, and one hundred-links on one page. Overall, the fifty-link condition had the fastest search time and was the most preferred. Users perceived that the hundred-link condition was more difficult to find information, presented too many choices, and looked less professional than the ten-link condition. The results suggest that a moderate amount of paging and scrolling was optimal. However, when forced to choose between the two, users preferred paging, even though paging took more time to find information than did scrolling. "

I agree that pagination, like on an iPod Touch, is something to be desired if GNOME Shell will ever take off on touch devices. At the same time, though, there is nothing necessarily better or worse about a categories view. Maybe in System Settings -> [somewhere] or an "options" button in the overlay (though that's less than ideal) there could be an option to enable/disable the behavior. The following options could be present:

* Lock Applications List (assuming that the applications can be freely arranged for spatial memory purposes)

* Sort by: [would include Name, Date Installed, Category (then sorted by Name)], Last Used, etc.]. In the case where the applications list has been modified by the user after one of these pre-set sorts was selected, it would be set to "Custom", indicating that the applications are in a user-defined order.

On a related note, whether or not categories are enabled, pages are much more efficient than scrolling. What would be the equivalent of several seconds of scrolling in GNOME Shell 3.0 could be done in miliseconds of scrolling (assuming that each scroll up/down is equal to switching one page). Ctrl+Left/Right could also be used to switch pages, while the list could remain keyboard navigable by not using the Ctrl modifier key. Ctrl+Up/Down could also work.

And I know I'm not a designer; just thought I'd give my two cents as to how this could be done.

(In reply to comment #0)
> 
> I'd also add that paginating the apps would make the application view mirror
> the how workspaces work under the windows view. 

This question might be a bit of a tangent here but since we dont have the workspaces displayed; How would this work when user wants to drag-n-drop new apps to a specific workspace or to a new workspace?

It may be nice to add some bling to the page transition, ala http://jimmac.musichall.cz/log/?p=1181

People generally recognise that a horizontal strip of dots means 'pages'. Can we say the same for a vertical arrangement? I don't think they'll know know what the dots are.

Vertical pages would have a nice symmetry with workspaces. That was especially advantageous considering the possibility of having a left/right logic to move between windows and applications and up/down to browse through each category. Now that we're possibly moving away from that model (see  http://jimmac.musichall.cz/log/?p=1181) those advantages are diminished, however.

If horizontal pages are conflicting with the messaging tray, let's just not show it in the overview (bug 636117).

continuing on the flow of this discussion, I have a proposal.
I filed a new bug, since it doesn't involve a pager.
https://bugzilla.gnome.org/show_bug.cgi?id=659309
check it out, 
thanks
alex

(In reply to comment #16)
> https://bugzilla.gnome.org/show_bug.cgi?id=659309

I just had a look at the ideas around that bug report. So far, keeping one long list and structuring it in categories is my favorite option.

The current solution is hard to browse because the apps are ordered alphabetically, which means that completely unrelated ones are often located side by side. Furthermore, it is compact and without any internal structure other than said sorting. These two together mean that the user has to scan the whole wall of icons until the desired application is found.

Sections may offer some aid, but it is known that errors in selecting the wrong category are not uncommon. With the current solution, these mistakes mean that the user has to backtrack and try another category, which is cumbersome and frustrating.

Having an annotated, structured list would be easier to browse while at the same time reducing the penalization for guessing the wrong category: if the app is not where you thought it would be, you can just keep scrolling.

https://live.gnome.org/GnomeShell/Design/AppPickerRefresh

Is this still something we want, or are we happy with the scrolling in its current iteration?

Making this a dupe of the bug where implementation is taking place.

*** This bug has been marked as a duplicate of bug 706081 ***