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

List:       kde-usability
Subject:    Re: KDE Help Center
From:       Lauri Watts <lauri () kde ! org>
Date:       2005-05-16 17:04:59
Message-ID: 200505161905.06192.lauri () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 16 May 2005 14.04, Markus Mauder wrote:
> Hello everyone,
> this is my first try at evaluating a program's usability. I hope it turned
> out ok.

Comments below.  I'd just like to say thank you for taking on the beast that 
is KHC :)

> 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.

Problematic.  

This was possibly the most requested wishlist item for khc ever, and was added 
specifically by user request and after multiple bug reports.  It's important 
for accessibility reasons, and the fact it was requested so very often 
suggests it's actually very useful to some people.

> 2) There is a search tab, a search bar and a search button. Which one do I
> use?

Most of the search issues are down to distributions enabling (or not) the 
search facility.  It's not that easy to get running without some distribution 
set up, and when it is running, it's rather a different scenario than you 
note below.  This is one of those things I would like to hope Tenor will be 
solving.

> 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.

This one I would like to see implemented.

> 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 mockup is very nice, I expect we can try do something like this.  One 
thing worth noting is that unlike most of the other applications that have an 
'about' page, we have no real way to ensure that any of the things listed are 
actually there.  On some distributions which split things up very granularly, 
the page could look very empty :)

> 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.

It's identical because it's the same application. It's no different than 
opening konqueror from the panel with no url, or doing it by clicking a link.  
One way you get it empty, the other way it's started with something already 
open.

> 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:

It's not a per application help system - we don't have such a thing :)

> 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.

How good are you at XSLT? I have been attempting to fix this (it's a bug) for 
~7 months, and coincidentally had a bit of a breakthrough just this 
afternoon.  There are legal constraints on where the notice may be however 
(and it's already in a smaller font than the rest of the text) (if you really 
care I'll explain the specific problem, but this one at least can be marked 
down as a bug in the (very slow) process of being fixed.)  Ironically my 
breakthrough resulted in the TOC for the doc going AWOL, and 

> 4) The manual's front-page features another table of contents
> suggestion:
>  Use the sidebar for this.

The problem there is if you type help:/kpdf in konqueror (or follow such a 
link from another document), there is then no table of contents at all, and 
navigating the document would be more difficult.
 The two most obvious solutions are also very problematic:
1: Regenerate the docs at runtime, with TOC or not as required - the problem 
there is that runtime generation is quite slow (and a cpu hog) which is why 
we don't do it already unless absolutely necessary.  KHC did in fact at one 
time generate the docs at runtime, but it led to a lot of complaints from 
users (and many were very confused) thinking that since the doc didn't 
display immediately, it was broken.
2: Generate two copies of the docs at compile time, one with and one without 
the TOC - the problem with that is compiling the docs already takes a long 
time (see 1) and a fair amount of disk space, and doubling both of those is 
likely to just lead to a lot of user complaints.

> 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 .
>
That's actually not a million miles away from something we actually mocked up 
in Qt Designer some time ago.  

> 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?

My take is, several of us got together at the last KDE Conference and Aaron 
mocked up several new interfaces for KHC.  There is also a quite substantial 
design document in the sources, with a whole lot of things you covered here 
and more, and most of it is coming to similar conclusions.  

Please don't take that as wasted time, it's not, it's a good confirmation that 
we had sensible ideas.  However - it needs someone to put in some time coding 
it, and that is what we don't really have available.

What we basically came down to was to have the global contents page and the 
local (to the doc) contents page be mutually exclusive, and you can switch 
between the two.  Opening KHC from an application would start with just that 
doc's contents visible, and opening it directly would default to the big TOC.  

Completely removing the ability to go from "just this doc" to "all of the 
help" was considered and dismissed, for various reasons (I forget 
specifically, but have written down around here on another computer - I'll 
dig those notes out for you.)

> [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?

If you have htdig installed, with appropriate patches (the default install 
doesn't work), it will in fact do full text searching of all the handbooks.  
Of course, that's quite a task, and unless you use a distribution that sets 
this up for you, it's really hard.    Until very recently it was hidden 
entirely if you didn't have the right 'bits', and I guess the error reporting 
could certainly be improved.  Without the right back end, it'll still search 
just the man pages, which is a: better than nothing, and b: not really good 
enough.  Bring on full text native to the desktop searching, I say.

Regards,
-- 
Lauri Watts
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]