GNOME Bugzilla – Bug 699087
Keyboard navigation broken
Last modified: 2013-05-02 19:29:31 UTC
Since Nautilus 3.6 (I think) the typeahead-find has been removed in favor of search-on-type. This has broken keyboard navigation. In a directory with a large amount of files, arrow keys are not a convenient form of keyboard navigation. The previous typeahead-find worked reasonably well when knowing your destination. This was also consistent with Windows Explorer; Mac I'm not familiar with. For those who remember their most used directory structure and those who duplicate a standard directory structure, e.g. across different projects, typeahead-find would considerably speed up navigation. While the improved search is great, it was unnecessary to remove typeahead-find along with it. Search and navigation are two completely different actions. Due to the delay and incremental population of results, search is not really usable for navigation and I'd argue it's probably more confusing for casual users than a selection change caused by typeahead-find since it forms a new view different from the normal one-directory-at-a-time view. Therefore, I suggest a restoration of keyboard navigation, which probably requires putting the search back behind Ctrl+F.
(In reply to comment #0) > Since Nautilus 3.6 (I think) the typeahead-find has been removed in favor of > search-on-type. This has broken keyboard navigation. Hi, Osmo. Thank you for the report. I agree that this change was disruptive and broke the way we were used to navigate by typing. It doesn't mean that keyboard navitation is broken now. It is different. In some aspects it is even better. > The previous typeahead-find worked reasonably well > when knowing your destination.[...] > [...]For those who remember their most used directory > structure and those who duplicate a standard directory structure, e.g. across > different projects, typeahead-find would considerably speed up navigation. Search can be used in the same way and it works reasonably well too. Example: navigating from / to /usr/share/applications, type-ahead-style: https://docs.google.com/file/d/0B2EIazSIJFlCV2d5M3lJQ0I5eXc/edit?usp=sharing Using search, I can even jump directly to a directory deeper in directory structure, which considerably speeds up navigation. Example: https://docs.google.com/file/d/0B2EIazSIJFlCU2tLNFNYdGx0MjA/edit?usp=sharing > While the improved search is great, it was unnecessary to remove typeahead-find > along with it. It was necessary for consistency with other GNOME 3 applications and GNOME Shell Activities overview, where you can just type to start searching. > Due to the delay The delay was an indeed an issue. The situation is significantly improved in nautilus 3.8, as you can see in the videos above, thanks to this commit: https://git.gnome.org/browse/nautilus/commit/?id=e153ba8046f52680b98a5fc209c2b4161b193d2d > and incremental population of results Yes, there are some cases where this gets troublesome: bug 687002. But there are possible solutions which do not require giving up on search-on-type. > for navigation and I'd argue it's probably more confusing for casual users than > a selection change caused by typeahead-find since it forms a new view different > from the normal one-directory-at-a-time view. I'd argue otherwise. Nowadays, casual users are more familiar with navigate by searching (they use http://www.google.com/ and the such) than navigate by browsing directores (who uses http://dir.yahoo.com/ and the such?). > Therefore, I suggest a restoration of keyboard navigation, which probably > requires putting the search back behind Ctrl+F. Giving up on search-on-type is unlikely to happen (bug 680118). However, a restoration of the find feature is up for discussion: it may involve putting find behind Ctrl+F: bug 681871. Do you want me to mark this as a duplicate of bug 681871?
Thanks for the status report and links. It seems this this is still a work in progress and I should at least upgrade to 3.8. I still don't quite like it. Heavy actions should be behind complicated keys and light actions behind simple keys. But if it's not coming back, it's not coming back. You can mark this as a duplicate of whichever of those bugs, I'll CC myself and/or comment on the constructive ones remaining open.
*** Bug 699455 has been marked as a duplicate of this bug. ***
Keyboard navigation is very much broken, and the provided rationale seems very gratuitous. I can argue that users are used to exactly the opposite given that other operating systems follow exactly the "broken" pattern. Is the claim that users are more familiar with navigate by searching based on usability testing? Or just a feeling? Users are indeed used to searching on Google. However, nautilus is far from being Google, and every other relevant file manager does exactly what nautilus did. Breaking this actually breaks every expectation of a user who has ever touched a user file manager with a keyboard, and UX design should meet the user's expectation rather than frustrate them. Note #1: today's casual users (as mentioned) will most likely click their way through the files, or click a Search Icon, rather than resort to a keyboard with no obvious interface (power feature). Note #2: Even if the entire rationale was acceptable, the sheer amount of time that it takes from clicking a few words and the interface updating (by the way this also breaks user's expectations as files start moving around) is simply unacceptable and mostly unusable.
Regarding consistency. It seems that the gtk+ filechooser still uses typeahead-find, which is also bound to Ctrl+F, while search is accessed via the sidebar, Alt+P with the keyboard. Shouldn't the filechooser be a closer reference point than different applications or the shell's activities screen? It seems odd to make nautilus more high-level and consistent with other applications, while the development of gnome-documents and gnome-music etc. is filling that exact space and marginalizing nautilus use more for the low-level and power user.
There's a plan to make the file chooser and Nautilus more consistent in general: see bug 679334. I don't know whether the GTK/Nautilus designers plan to remove type-ahead find from the file chooser too as part of this effort.
(In reply to comment #4) Please don't take those words out of the context of their context. I was replying to the quoted argument, and all I did was "argue otherwise". I did not provide a rationale for anything. I'm not a nautilus maintainer. I'm just helping with bug triaging. And it's with the bug triager hat on that I am now marking as a duplicate of bug 680118, with the reporter's acknowledgment as per comment 2. I'm doing so because, despite the different tone, both reports ask for the same solution. Please report specific issues with keyboard navigation separately. There may be more than a single solution for a specific problem. (In reply to comment #5) In addition to what Adam already said, I don't know any specifics with relation to type-ahead, but there is one change with relation to search in the file chooser: http://blogs.gnome.org/mclasen/2013/04/23/gtk-hackfest-days-3-and-4/#comment-650 Take a look at Federico's blog for more information on the work in progress: http://people.gnome.org/~federico/news-2013-04.html#gtk-hackfest *** This bug has been marked as a duplicate of bug 680118 ***
(In reply to comment #7) bug 680118 really shows how this community handles itself (blocked users, insults, irrational reasoning, etc). It's not the software, it's the user that is broken. Thank you for your time.