From kde-usability Mon May 16 17:04:59 2005 From: Lauri Watts Date: Mon, 16 May 2005 17:04:59 +0000 To: kde-usability Subject: Re: KDE Help Center Message-Id: <200505161905.06192.lauri () kde ! org> X-MARC-Message: https://marc.info/?l=kde-usability&m=111626344302854 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1660543102==" --===============1660543102== Content-Type: multipart/signed; boundary="nextPart1774019.Z4rvLuNia9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1774019.Z4rvLuNia9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 tha= t=20 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. =20 This was possibly the most requested wishlist item for khc ever, and was ad= ded=20 specifically by user request and after multiple bug reports. It's importan= t=20 for accessibility reasons, and the fact it was requested so very often=20 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=20 search facility. It's not that easy to get running without some distributi= on=20 set up, and when it is running, it's rather a different scenario than you=20 note below. This is one of those things I would like to hope Tenor will be= =20 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=20 thing worth noting is that unlike most of the other applications that have = an=20 'about' page, we have no real way to ensure that any of the things listed a= re=20 actually there. On some distributions which split things up very granularl= y,=20 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=20 opening konqueror from the panel with no url, or doing it by clicking a lin= k. =20 One way you get it empty, the other way it's started with something already= =20 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 t= he > 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) f= or=20 ~7 months, and coincidentally had a bit of a breakthrough just this=20 afternoon. There are legal constraints on where the notice may be however= =20 (and it's already in a smaller font than the rest of the text) (if you real= ly=20 care I'll explain the specific problem, but this one at least can be marked= =20 down as a bug in the (very slow) process of being fixed.) Ironically my=20 breakthrough resulted in the TOC for the doc going AWOL, and=20 > 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= =20 link from another document), there is then no table of contents at all, and= =20 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 proble= m=20 there is that runtime generation is quite slow (and a cpu hog) which is why= =20 we don't do it already unless absolutely necessary. KHC did in fact at one= =20 time generate the docs at runtime, but it led to a lot of complaints from=20 users (and many were very confused) thinking that since the doc didn't=20 display immediately, it was broken. 2: Generate two copies of the docs at compile time, one with and one withou= t=20 the TOC - the problem with that is compiling the docs already takes a long= =20 time (see 1) and a fair amount of disk space, and doubling both of those is= =20 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=20 in Qt Designer some time ago. =20 > 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 c= an > do to help? My take is, several of us got together at the last KDE Conference and Aaron= =20 mocked up several new interfaces for KHC. There is also a quite substantia= l=20 design document in the sources, with a whole lot of things you covered here= =20 and more, and most of it is coming to similar conclusions. =20 Please don't take that as wasted time, it's not, it's a good confirmation t= hat=20 we had sensible ideas. However - it needs someone to put in some time codi= ng=20 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= =20 local (to the doc) contents page be mutually exclusive, and you can switch= =20 between the two. Opening KHC from an application would start with just tha= t=20 doc's contents visible, and opening it directly would default to the big TO= C. =20 Completely removing the ability to go from "just this doc" to "all of the=20 help" was considered and dismissed, for various reasons (I forget=20 specifically, but have written down around here on another computer - I'll= =20 dig those notes out for you.) > [1] When I tried to use the search tab it wanted to build the search ind= ex > 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 afterward= s, > 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= =20 doesn't work), it will in fact do full text searching of all the handbooks.= =20 Of course, that's quite a task, and unless you use a distribution that sets= =20 this up for you, it's really hard. Until very recently it was hidden=20 entirely if you didn't have the right 'bits', and I guess the error reporti= ng=20 could certainly be improved. Without the right back end, it'll still searc= h=20 just the man pages, which is a: better than nothing, and b: not really good= =20 enough. Bring on full text native to the desktop searching, I say. Regards, =2D-=20 Lauri Watts KDE Documentation: http://docs.kde.org KDE on FreeBSD: http://freebsd.kde.org --nextPart1774019.Z4rvLuNia9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCiNLC/gUyA7PWnacRAk2tAJ4sA9bQ+tOXJUkLBDRSv8vyObhCBgCfbI14 4YU/0tLZm4i6Y+ZcTASMFes= =2eeH -----END PGP SIGNATURE----- --nextPart1774019.Z4rvLuNia9-- --===============1660543102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-usability mailing list kde-usability@kde.org https://mail.kde.org/mailman/listinfo/kde-usability --===============1660543102==--