GNOME Bugzilla – Bug 155751
Typeahead/keynav comments
Last modified: 2005-05-25 09:37:44 UTC
Have been eager to try out the typeahead/keynav features in HEAD, but now that I have,they aren't really quite what I was expecting. A few comments: - On "/" to bring up the location box... I don't have a problem with that, but it seems odd that it doesn't also type a "/" in the location box. Shouldn't one goal of the keynav enhancements be that, if I chose to, I could just type the full or relative (from the currently-displayed folder) pathname of a file as I would in the old-style dialog, hit Enter, and have it open? This way I have to type the first "/" twice, which feels wrong to me. - Would be nice if typing "~" first at least changed the file/folder view to your home directory. Perhaps that should also pop up the location dialog too (with "~/" already filled in), not sure about that though. - On typing "/" in the search field... assuming I've typeaheaded (is that a word?!) enough to match a folder in the current directory, so it has become highlighted, and then I type "/", I would expect the file/folder list to change to the folder whose name I've just typed. Otherwise I've got no idea what to type next, without dismissing the search field, hitting Enter to open the folder, and starting typing again, particularly as there's no filename completion in the search field. This feels extremely inefficient. - It might be nice if the file/folder list in the main dialog updated as I was typing into the Location dialog, to show the contents of the folder that the Location dialog was currently auto-complete on. I know strictly speaking, all the information you need is in the Location dialog iteself, but it might make the whole thing feel a bit more connected-- to me, the location dialog still feels like a bit of an afterthought to appease the keyboard junkies :)
Marking AP2 to reflect accessibility impact.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
*** Bug 150687 has been marked as a duplicate of this bug. ***
IMHO the goal should be to obsolete the Location dialog. I'd prefer to be able to type directly into the file browser, not needing to use the Location dialog ever. Typing '/' should not open the Location dialog but bring me to the root of the filesytem, allowing me to navigate to a directory by typing in the full path (or rather the first characters and pressing Enter as soon as the matching folder is highlighted). Typing '~/' should get me to the Home directory. I completely agree with Calum that the folder should be changed as soon as there's a matching directory and I type '/'. I do however not think that the Location dialog needs to be better integrated, IMO it should not be needed at all.
I agree with sven, to a certain degree. The problem with removing the Location dialog and having FindAsYouType on everything is, as I see it, discoverability.
There are serious accessibility implications to doing this without the location dialog; the contextual changes which the sighted user sees have to be presented to the blind user somehow, and changing icon views or things popping up and down generally present an intractable problem for screen readers. It's far better to have one object, which has the visual attributes of a "text entry", which has focus and which responds to the user keyboard action. it's OK to change the other UI items too, as long as the one which has focus is not undergoing a flurry of changes. In this respect, having a text box which assumes the onscreen focus is far preferable. According to accessibility regulations, _something_ on screen must have a "clear representation of onscreen focus", and all of the changes which that object undergoes will be sent to the screenreader. If that object is an icon view, it's unlikely that a useful output can be presented to the blind user.
How about something along the lines of (read: exact copy) the find toolbar in Firefox?
To be honest, I don't know (about firefox) because I haven't been able to evaluate it yet. Since we will need to figure out a way to work with firefox, presumably, doing "exactly the same thing" might be a reasonable approach, at least the two would be consistent even if suboptimal for accessibility.
The firefox find toolbar is almost certainly not a good example to copy.
Matthias: .. could we get a reason with that? Personally, I don't like it for the following reasons: 1. It's at the bottom of the window. 2. It "suddenly" pops up. 1. would be OK for Nautilus, I guess, because most of the time, my windows are not maximized (as the browser is almost all the time), so it'll be easier to spot.. 2. just feels wrong when it's a toolbar. Anyway, I was just mentioning it to sparkle ideas, because people (as far as I've seen) seem to like it. And what Bill mentions about consistency has to be considered, IMHO, seeing as Firefox has become increasingly popular.
Add 3. It doesn't go away if I'm done searching 4. The close button in the middle of the window looks odd 5. The color coding in the entry background is just a bad idea
From what I recollect: 3. It goes away when you press ESC, or after a couple of seconds of no keyboard activity. Which I guess suits "most people." 4. The close button is to the far left in the build I tried. 5. It is my understanding that people - norwegians at least - generally find red to be "false", "warning", "something is wrong", etc, and green to be the opposite. Seeing as we're in the context of doing a search, it's natural (for me, at least) to assume that my search went wrong when the bar goes red. Of course, this might not be true for other countries. In any case; 2 is a blocker for me, 4 wont be a problem if the find box is presented in a different matter, and if 5 doesn't correspond with the HIG, then don't do colors.
The comments have gotten numerous, so I'll reply to the worthy ones. The initial report mentions these points: - Hitting "/" does not insert a slash in the location dialog -> fixed. - Hitting "~" does not change to your home folder or bring up the location dialog -> this is bug #153213. - Typing "/" while an interactive search is going on should switch to the highlighted folder -> I've filed bug #305385 about this. - Updating the main dialog while one types in the location dialog. I think this would be confusing --- "why is that separate window changing under my feet"? Comment #6 is really about bug #136541. Since a) the first point in the original report is fixed now, and b) the other comments in the original report refer to existing bugs, I'm going to mark this as FIXED. Please continue the discussion in the other, referenced bugs if they are relevant.
My concerns in Comment #6 and related have NOT been addressed, and there don't seem to have been new bugs filed for them. THe problem I am primarily concerned with, and which is the SUMMARY TITLE for this bug (which I changed to reflect comments #4 and later) has not been fixed. Closing this bug, when there are so many duplicates which deal with the discoverability issues, is the wrong thing to do in my opinion.
sorry, I was referring to http://bugzilla.gnome.org/show_bug.cgi?id=136541, the "poor discoverability" bug. I was confused by a bugzilla email notification that pointed to this bug, sorry. Either ignore my comment #14 or consider it in the context of bug #136541. Thanks.