GNOME Bugzilla – Bug 91610
Yelp pane usability
Last modified: 2005-06-15 20:33:33 UTC
Having "Home" on the toolbar makes sense when yelp is being used as a standalone help editor. However, when using it as an application-help tool, it implies it will go to some useful hub for the application help and it actually takes you to a totally useless page :) (in that context). Maybe not displaying this when launched from an app would be better?
It should probably be displayed anyway, but another name would be fine with me. Any suggestions?
Thoughts, usability?
"Contents"? Or could that be mistaken for "contents for the current application"? (If so, something like "Bookshelf"?)
Yes, currently Contents is the view when you actually read a document. Perhaps these names needs to be rethought? There currently are three views: [HOME] [Contents] [Index] I've thought about perhaps not have the [Index]-page but instead have a View->Index in the View menu which gives you the Index-list to the left of the main-viewport. And change [Index] -> [Search] and have a full text search view there. Perhaps all of these tabs should have a name change to something better and more intiutive. Suggestions are appriciated.
Well, FWIW I'd expect any modern Help browser to have Back, Forward, Contents, Index and Search features available directly in the main window (i.e. not just in the menus). Actually, come to think of it I did some mockups for improving the nautilus-based help browser before, quite a while back now... don't know how relevant they are for Yelp though (or whether they were even any good to start with!): http://developer.gnome.org/projects/gup/proposals/scrollkeeper.html
Hi Guys. I've been playing with yelp from the point of view of exploring how Calum's suggested mockups would fit into it, and have some ideas I'd like to share with you. Currently, Calum's mockup includes quite a chunk of functionality which is missing from yelp (for example, the degrees of freedom in deciding what the scope of Index searching should be)-- I've tried to look at how his idea of adding tabs to yelp could be simplified to match yelp's current functionality. (Incidentally, adding tabs to yelp seems an indispensable way to improve its navigability ; the problem of losing what you had been looking at when you switch from content-viewing to index-searching mode would be gone.) At any rate, as I looked at yelp + Calum's tabs, I was reminded of the usage of tabs in the KDE Control Center. Check it out: http://primates.ximian.com/~anna/kde-cc-index.png http://primates.ximian.com/~anna/kde-cc-search.png http://primates.ximian.com/~anna/kde-cc-help.png The way this works, basically, is that you can use the tree presented on the index tab to navigate to the capplet you want to use. Or, if you aren't sure which capplet you want, you can use the search tab to find a set of capplets that corresponds to your keyword. If that isn't enough for ya, you can switch to the help tab, and read some documentation about the capplet you have selected. Obviously, the help tab doesn't make sense in the context of yelp. But if you replaced it with a history tab -- so that you had an "Index" tab where you can navigate through help, a "Search" tab where you could find all the help articles relating to a given keyword or command, and a "History" tab for keeping track of what you've read-- then, this paradigm might make sense for yelp. This is basically just a simplifying of Calum's idea-- the point is, if you fire up yelp and study it carefully, it takes little imagination to see how kde-style tabs could easily fit in. What do you guys think? Any merit in this at all? Any way that I could clarify this explanation? -Anna
You'd need 4 tabs: * Contents (of current help file) * Index (of all of help) * Search * History Or perhaps history is superfluous. Presumably, in this model, the current "Home" view would be discarded totally (as it's replaced by the "Contents" tab)?
Hi Andrew et al, Hmm-- mayhap we are imagining different things. It seems to me that one doesn't actually need separate Index and Contents panes, if one provides appropriately easy to use navigation. (see mockups below) Granted, Mikael and the yelp team definitely have the last words on this, but, I'd like to make sure that I have made myself understood -- and that I understand your point(s) of view. I made some glade'd mockups of how I envision tabs working in yelp; I hope this serves to articulate my position. Obviously, these would need the appropriate menus and toolbar items. :) http://primates.ximian.com/~anna/yelp/index.png http://primates.ximian.com/~anna/yelp/search.png http://primates.ximian.com/~anna/yelp/history.png Maybe you are right, and history is superfluous. Also, there is probably a better way to present the navigational links on the index page-- maybe nesting them? Anyway, I'll pipe down now and let someone else have a turn on the soapbox. cheers, Anna
They look nice :-) The only moans I'd have is: 1. Why is the current-help-contents in both the history and index tabs. Is it even relevant in the history tab? 2. Protect the user from a huge treeview. Your index tab looks nice although it might be better to use: ----------------------------------- Home Applications Multimedia <b>Volume control tool</b> Introduction Usage To Adjust the Volume To Switch the Volume Off To Access Additional Features ----------------------------------- The top bit is good indented, but shouldn't expand to a tree of all the documentation installed on the system (like I think KDE does) because it's too huge. And making the index page in a help book bold separates the "Topic contents" from the "Installed help contents" that the pane is being used for. I am not a usability expert, but my 2p.
Hmm.. how is this different besides the fact that you called the contents/home-view "Index" and the index-view "Search"? The only difference as I can see it is that you used a notebook instead of the toolbar buttons. Is that a usability improvement or just a preference? (I'm asking since I'm not very good at usability). Also, I'm unsure about having the categories showing up on top of the contents tree of a document. It works nicely here since both lists are short. In reality they aren't very often, and you would have to scroll the tree to find what you are looking for. Thanks for the reviews and comments all, I'll have to read them through more carefully and try to do something about this :)
Hi Micke. This isn't fundamentally different; I was trying to give you some more usable options which match (more or less) with your current feature set. The notebook is a usability thing-- it should prevent you from losing what you were reading when you switch views. eg, with yelp currently, if I switch to searching mode, there is no easy way to flip between (or compare) multiple pages. Using a notebook gives a concrete way for the user to keep track of more than one page at once. Further, this design provides you with more navigational context for any selected item, because you get the tree of links (eg, Home, Applications, Multimedia in the screenshot I posted) . This is especially useful if you are surfing around through help, trying to understand which application or command would help you accomplish a given task. The links function as breadcrumbs in a webpage; they're like a ladder for the user to climb around on. This is important because it makes your users more likely to be able to find a given page again-- which in turn makes yelp a safer program to experiment with. Let me know if I can be more helpful. -Anna
Created attachment 23286 [details] IRC Log from UI-Review on Mon. Jan 12th regarding this bug
Mass moving Yelp bugs to new maintainer.
Since this seems to have been resolved in recent times (Button is now labeled "Help Topics" which seems to fit better) and there has been no activity for over a year, I'm going to close this as fixed.