[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    KDE Help Center
From:       Markus Mauder <m.mauder () gmx ! net>
Date:       2005-05-16 12:04:13
Message-ID: 200505161404.14434.m.mauder () gmx ! net
[Download RAW message or body]

Hello everyone,
this is my first try at evaluating a program's usability. I hope it turned out 
ok.

In the comment section of the recent interview with Jes Hall about KDE's 
documentation ( http://dot.kde.org/1116000449/ ) a user calling himself 
fr_dude made a negative comment about the usability of the KDE Help Center, 
which made me curious. Read on for a more detailed review of this program.


Background: I have used KDE since the 2.x days and would describe myself as an 
advanced user. However, I have never made extensive use of KHelpCenter.
The version of khelpcenter tested is 3.4.0 as shipped by KUbuntu.
I hope my cluelessness is put to good use with this review. Enjoy.


There are two scenarios I tested: Starting the help center directly (e.g. 
through the kmenu) and using the help function from within a program (I used 
KPDF, because I figured it would have an up-to-date manual).
I am going to present my observations (and link to screenshots for you to 
compare) and offer my ideas as to what to improve about this (with 
accompanying mockups, because - as always - a picture says more than a 
thousand words).


First off, starting the help center directly (screenshot: 
http://tinyurl.com/7lq99/defaultview_kmenu.png )

The user interface is designed to give access to all available information. 
There is nothing fundamentally wrong with it, but a few things exist which 
impact usability:
1) The tool bar contains buttons of questionable importance to the user. 
Specifically these buttons are:
- increase/decrease font size: I know we have had this discussion before, but 
wouldn't it make sense to set the font size once and for all and not bother 
the user with it in every app?
suggestion:
 throw them out. Font resizing is not a very frequent operation.
- Table of contents: The side bar gives easy access to the contents at all 
times. Why have another button for that?
suggestion:
 get rid off it

2) There is a search tab, a search bar and a search button. Which one do I 
use?
The user can only guess here. Based on experience, I guessed that the search 
button would search the text of the current manual entry, the search bar 
would search the list beneath it and the search tab would search all manual 
entries.
Surprisingly the button was the only thing I got right. The search bar only 
found man pages (not sure it is meant to work this way) and displayed a list 
of them in the content area. This is inconsistant and not expected behavior. 
A search bar usually filters the list beneath it on the fly. This search bar 
neither searches the list nor does it do so on the fly. There is something 
rotten in the state of Denmark.
Unfortunatelly, I didn't get a chance to test the search tab (see [1]).
suggestion:
 There should only be one interface element called search. I am not so sure 
which one should stay though. The most intuitive in my opinion would be to 
keep the search bar and filter the entries in the side bar, which contain the 
word the user enters. Maybe make it full-text and highlight the word in the 
text if the user opens one entry.
3) The main view dublicates the list already visible in the side bar.
suggestion:
 Load a default page with some good content. There are a bunch of 
menu items in the side bar, which might be better off in a more prominent 
space in the content area.
It is likely that the user is looking for basic information on KDE when the 
help system is started from the k-menu (e.g. when they have a first look at 
this new operating system their friend set them up with).
It should be easy for those users to get to this information quickly and 
painlessly. Instead of wasting the content space by dublicating information, 
which is already visible in this window, we should create a selection of 
introductory topics.

Mockup of these changes: http://tinyurl.com/7lq99/proposal_kmenu.png
The start page would of course require a lot more thought. This is just a very 
quick sketch. And I apologize for placing these icons out of context.



The other scenario I tried was running the help function from within an 
application (screenshot: http://tinyurl.com/7lq99/defaultview_kpdf.png )
I know that the program used is the same. However, a few small tweaks to the 
interface could make it more suitable for individual programs.
Currently the interface is identical to the "global" one. The only thing, 
which makes it KPDF's help, is that its manual is selected: The side bar is 
expanded to reveal KPDF's top level entry (not more!) and its title page is 
displayed in the content area.

The user interface suffers the same short-comings as pointed out above. 
Additionally these issues make it less appropriate for a per-application help 
system:
1) The side bar still displays an overview of all available content. Expected 
behavior is that the help is on KPDF not on everything khelpcenter 
knows about.
suggestion:
 only display the content of the KPDF manual in the sidebar. Additionally the 
list of articles in the manual should be expanded to show all sub-topics.
2) The "table of contents" button should be removed. It doesn't serve a 
purpose in this context.
3) Most of text that is visible at start-up is the GNU FDL header.
I am not sure if we are legally bound to have the license at the very top. 
Maybe the purpose is to make the open nature of KDE clear to the user. I can 
only guess here unfortunatelly.
suggestion:
 Use a smaller font for the FDL or encourage the user to participate in the 
development of KDE in a more casual way.
4) The manual's front-page features another table of contents
suggestion:
 Use the sidebar for this.

To give you an idea of what the interface could look like based on these 
suggestions have a look at http://tinyurl.com/7lq99/proposal_kpdf.png .


Hopefully this review gives someone with the willingness and ability to make 
changes to khelpcenter a few ideas. I think that the usability of the help 
system can make a big difference for new users.

What is your take on this? Comments? Is there anything I as a non-coder can do 
to help?

Thank you all for your hard work,
- Markus




[1]  When I tried to use the search tab it wanted to build the search index 
not do any searching yet (screenshot 
http://tinyurl.com/7lq99/searchindexweirdness.png).
After a bit of struggling with the interface, I got it to the point where it 
seemed to build the index. When the search still didn't work afterwards, I 
took a closer look at the search index building process. The only indication 
was hitten behind the "details" button ("htdig failed"). No error message, no 
additional information.
I still fail to see the purpose of the search tab. Someone care to enlighten 
me?
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]