During recent conversations with some of the members of the OpenUsability project, some of the usability work on one of the more exciting applications in KDE, KPDF, was brought to my attention. I managed to catch up with Florian, from OpenUsability, and Albert, one of the KPDF maintainers to talk a little about themselves and their work and about the usability review and followup in KPDF.

Albert Astals Cid
KPDF Developer

Scott: Could you give a little bit of information on your background — where you're from, if you're studying or working, what, where, etc.?

Albert: I'm from Barcelona, in Catalonia (Spain). I'm studying — well not really — as in two weeks I will present the final project of my computer science degree and then I'll look for work, so if anyone wants to offer a good job let me know. ;-)

Scott: How did you get involved in KDE and eventually KPDF?

Albert: I started in KDE translating it to Catalan and I still doing that when I have time. Then I began sending small patches for bugs I found and implementing some features like showing the thumbnail of the current page in the top left part of kghostview and helping Luis Pedro implement thumbnails for all pages. I got involved with KPDF last summer when someone asked why KPDF was still using XPDF 2.x when 3.x was out already and I tried to do it.

Scott:What would you say is your role in KPDF right now? I know that there was a lot of impressive work that went on prior to KDE 3.4 — to what extent were you involved in that?

Albert: Well, right now I'm doing more mantainership work than implementing lots of cool new features like we did in the KDE 3.4 time frame — like fixing bugs and working with other people like Poppler developers. Enrico Ros is the one that is primarily developing new features like annotation support (which may not be ready for KDE 3.5). In the KDE 3.4 development time, the work was 50% mine and the other 50% from Enrico; I did the dirtier work like XPDF 3.0 integration and all the benefits that gave us in rendering and things like enabling search, etc. Enrico did the fancier stuff like the continuous view mode.

Scott: Popper is the Freedesktop.org XPDF fork?

Albert: Yes, Poppler is the fork of XPDF 3.0 code base that is being developed under the umbrella of Freedesktop.org. It is already much better than the XPDF 3.0 code. For example, it uses libjpeg and zlib natively to decode DCT and Flate encoded streams instead of the XPDF code. That is better because those libraries are very widespread and they have had possibly more speed optimization and security checks than the XPDF code.

Florian Grässle
OpenUsability Usability Engineer

Scott: And the same to you Florian -- could you tell us a bit about your background?

Florian: I am student of "Computational Visualistics" (a mixture of computer science, arts, software ergonomics and what have you) at the University of Koblenz, Germany.

Scott: Is that where you're from?

Florian: I am actually from Ellwangen, a very small town in the south of Germany.

Scott: How did you come across the OpenUsability project and when did you get involved there? Did you decide to contribute to KDE or OpenUsability first?

Florian: I came across OpenUsability more than a year ago. It was a time when I was interested in KDE and Open Source usability in general. I noticed that the usability efforts of KDE weren't really centralized, the main activities stuck to the mailing list which we all know didn't make usability work easy. so I wanted to contribute, do something and contacted the OpenUsability project and finally got in touch with KDE and Open Source usability.

Scott: OpenUsability is something that we've seen a bit of information on recently in the KDE world. Could you give a short description of the project and where it is right now?

Florian: As the web page states, "OpenUsability.org is a project that brings Open Source developers and usability experts together". On the one side there are Open Source projects that realize that usability is a main factor to make a quality piece of software. On the other side usability experts realize that working with Open Source projects is a real chance to get involved with the development process at a pretty early stage. At least that was my motivation to get involved with KPDF.

Working Together
KPDF Usability Review

Scott: So how did you guys meet up? Was that something that happened through OpenUsability?

Albert: Kurt Pfeifle suggested that I ask for usability help on OpenUsability. I thought that we did not have serious problems with usability but an expert might find some. So I went there, registered the project and in one or two days Florian was already working on doing a KPDF usability review.

Florian: I was checking the news section at OpenUsability when I read that KPDF was looking for usability advice. I had the feeling that KPDF was an important application within KDE and spontaneously decided to join.

Scott: What kind of feedback does OpenUsability provide to application developers?

Florian: First developers can expect a so called "usability inspection". This means that a usability expert is evaluating the application with regard to the platform guidelines and usability heuristics. If problems with the interface are found the issues are noted down with suggestions and some explanations so that the developers can follow the rationale behind it.

Scott: Well, I guess I mean something a little more concrete — one of things you hear sometimes from developers is that usability work is more or less completely subjective opinions. "user control", "freedom" and "efficiency" all sound great, but how do you evaluate those?

Florian: whenever I come across a possible problem I try to figure out whether it actually is one and whether it matches a given heuristic like the ones of Jakob Nielsen. Then I figure out how important the issue is by imagining the user's work flow and common tasks. Above all it needs experience.

Scott: Was KPDF your first project to work on from OpenUsability?

Florian: No, I am also a member of the Konversation OpenUsability project. I helped with designing the KMail folder properties a few months ago as well.

Scott: Could you give a little background on the methods?

Florian: Basically there are several aspects a good interface should fulfill — like preventing errors before they happen and the user has to deal with them or giving the user control and freedom over the application (and not vice versa), offering an efficient interface and so on. During the heuristic evaluation the usability expert checks whether these requirements are met and sorts out possible problems

Scott: What were the first steps? So, Florian did a usability report, but how did that transfer into addressing those issues in development?

Albert: Well, after he made the report we met several times in the #kpdf IRC channel to discuss some of the issues. The discussion had three main parts: the first were things that I agreed with him and were easily solvable — those fixes went into out source code quite quickly, the second part were problems I did not understand or I did not think were usability problems — we discussed those and I "lost" in some items and Florian "lost" in others. The bigger problems were with the third group — the third group involved things that were not easily fixable like issue 1.4:

1.4 The label of the entries in the "left panel" are only visible if the panel is resized to fit their width. To prevent users from having to resize it a way to show the labels independently should be found.

Suggestion: On a mouseover use a tooltip to reveal the label text when it can't be fully displayed.

That cannot be solved from inside KPDF because it's not possible with Qt. So, I made a patch and sent it to Qt people, unfortunately it was not accepted. Other problems involved some kind of new feature or fix inside KDElibs, as KDElibs is more open and reachable for a KDE developer that could be easily solved.

Scott: Of the things that were actually implemented — what were some of the more interesting ones? Which items surprised you?

Before
After

Albert: One of the things I first though was not worth implementing but after doing now think is pretty important is issue 1.1. It is related to how the current page gets marked in the thumbnail list. Previously only the space around the page margin was highlighted. Florian suggested the thumbnail should not fill the whole width of the thumbnail list so you could see also the top and the sides of the thumbnail highlighted. That improved the quick visualization of which is the currently selected page a lot as with the previous scheme you where not sure if it was the page below or above the highlighted number. (see screenshots)

Scott: Ok, this one's for both of you — were there any real annoyances in dealing with "the other kind"? Often there's clear frustration between our, uhm, louder group of folks on the KDE-usability list and developers — how does that compare to your current work?

Albert: Well, the work has moved at a quick pace and been quite productive but there are always some differences. Like, for example, when Florian told me how much he hated how KPDF merged its menus with Konqueror and told me, "We should find a better way of doing that." I explaining him that this can not be done on the KPDF side as it is really a KPart issue and that should be discussed and programmed at a higher level.

Scott: Yes, I've wondered about that too and how it works with these reports. Users — and usability people, I would assume — just see applications, not components and libraries and such. You've already mentioned a couple of cases where that caused problems (Qt, KParts) — any comments on how things like that can be addressed in the future?

Albert: Well, it's a difficult thing to solve, the best thing is trying to make libraries and classes as most flexible as possible (yes, even more than they currently are) so that each application can adapt them to their own uses because each application can have a different focus or way of working and as such needs to use a class in a special way that potentially was not thought of by the person that created it.

Florian: On the KParts side I have the feeling that it's not too clear what they are meant for — are they meant as a preview or a feature reduced application within the main application (i.e. Konqueror)? I can imagine that it is pretty difficult for users to sort out when to use the embedded KPart and when to start the actual application behind it and what the benefits of the embedding actually are. It must be pretty irritating to see Konqueror's toolbars and menu entries change and hop around depending on which view state it's currently in. So I would like to see them mainly as some sort of quick preview for images, PDFs and such files. Then it's our job to find out which interactions these files have in common (like zooming in and out or rotating) and find a solution to present them in a way users can easily understand. They shouldn't have to wonder whether the respective action is meant to deal with Konqueror as an application or the embedded KPart view as a subpart of it. One thing that's still unknown is whether users are really using the KParts in the first place... I hope KDE 4 will have room for such thoughts.

Scott: Are there any other major challenges that come to mind in working together like this? And connected to that, do you see this way of working as something that you both feel was beneficial? Is this something that can work in Open Source in general?

Florian: Sure. The benefits of Open Source Software for usability engineers is the immediate response one gets directly from the developers and not through some obscure marketing manager. It's an opportunity to get in touch with software development at a very early stage. That's something usability engineers normally can only dream of. So I can only encourage other usability engineers to get in contact with Open Source projects. It's fun after all and the chance to practice one's usability skills. The great majority of developers aren't as stubborn as one may first think and indeed willing to accept constructive input. On the other side I hope developers realize that usability engineers don't try to be super-smart or want to know everything better. In the end we are both interested in making Open Source software better.

Albert: Well, the main challenge is you cannot code impulsively because it will probably end with a thing that has a few usability issues, so I ask Florian when I want to implement something UI related, that has the problem that he may not be available in that moment and the "coding impulse" you had finishes without having coded anything :-D

Scott: So your work together is ongoing rather than a one-off sort of thing?

Florian: It's a steady flow of mutual exchange I guess.

Albert: Of course. I try to consult Florian about substantial changes we make so that he does not have to redo the usability inspection over and over again from zero. We just readjust it little by little.

Florian: I felt very happy every time I read in a svn log "fix usability issue #"

Scott: How would you compare the importance of a review to say, ongoing cooperation?

Florian: A review is important so that both developers and usability engineers can get to know each other and sort out which way to work together is best. But it is only a start. Equally important is a constant cooperation. It's not like after one review every possible usability problem is found and solved. Open Source applications are constantly changing and need to be rechecked frequently. That's why the so called "usability life-cycle" thinks of usability as a partner during the whole development process.

Albert: Well ongoing cooperation brings discussion with it; you end with a better implementation as compared to working without that ongoing discussion and "fixing things" afterwards because in the later case you already have two people's ideas there.

Scott: Ah, that reminds me of another issue — how have you guys communicated mostly? Email? IRC? OpenUsability forums? It seems that Florian is also reading the SVN commit list?

Florian: I am checking out KPDF on a frequent basis to keep track of the changes and compare to older versions and also recheck my suggestion.

Albert: Well, the communication is mostly in IRC, me interchanged a few mails in the beginning because IRC is too much direct and e-mail helps start things going when you don't know each other. The OpenUsability forum is only used to keep track of the implemented and missing usability fixes.

Florian: I think the forums at OpenUsability.org are a good way for others to get a feeling of what usability work looks like.

Scott: Ok, so, wrapping up — any comments that you'd like to make on KPDF, OpenUsability or interaction between the two? Are there any other "big" steps from here on either in the interaction or the projects themselves?

Albert: I'm happy to see that there are new projects that bring a different types of people to into the KDE community. Basically KDE the community is / was composed of high-tech, knowledgeable people, but most of us don't have other important skills like usability expertise (OpenUsability) or artistic skills (KDE-artists.org). Bringing those people inside the KDE community gives us a better product as usability and looks are very important. It also gives us a broader base to share and discuss ideas that will end in having more innovative programs in the end.

Scott: Thanks guys!

More information on OpenUsability is available at their web site. There will also be a talk at LinuxTag later this week, as well as an OpenUsability booth.

KPDF simply hangs when the sour_curry_apr05.pdf (inside the zip file) is opened. Though it's a sort of bug report, and it is not an error/bug on kpdf part but it would be nice for kpdf to handle errors without hanging.

if we open the same file with KGhostview, we get:
**** This file has a corrupted %%EOF marker, or garbage after the %%EOF.
**** The file was produced by Corel PDF Engine Version 11.633:
**** please notify the author of this software
**** that the file does not conform to Adobe's published PDF
**** specification. Processing of the file will continue normally.

and the file opens atleast with kghostview. Thank you for a wonderful and useful application!

I know that you want better error handling in general, not just for this specific file, but here "soul_curry_apr05.pdf" is displayed by kpdf 0.4.1 whithout any problems and mucj quicker than by kghostview 0.20 using ghostscript 7.07.1.

Hmmm... hard to say, if you don't see any error messages :( I'm using gentoo here. Maybe it's not the place to discuss support questions here, but I attach the library dependencies (ldd /usr/kde/3.4/bin/kpdf) of my kpdf installation as a file.

Or *PDF stuff under all Linux GUIs still stuck with page by page [CENSORED] mode?

Last time I was checking - year ago, SUSE 9.2 - KPDF, XPDF, gview - were still far from anything usable. All were failing simple test: in any location press PageDown, press PageUp - and it must be in precisely location as before. Navigation is just terrible. And I'm not talking about search. And keyboard support - few support space as page down. And most of them try to mimic Windoz with its stinking focus, so pressing space is just plain dangerous: you never know where focus is and what going to happen when you press space. Awful.

I wish Apple had ported Preview of theirs to Linux: fast, simple and convenient. Very very very very good pdf viewer. Best one I have ever seen.

Under Linux if one cannot extract text from pdf - e.g. using pdf2text - reading PDFs are dead business otherwise... The tools are stuck in *STONE* *AGE* and supposed to be extinct by now. I'm just wondering what you people are using them for? Besides sending content to printer they are just useless.

So I expect Linux still has no decent eBook reader? Or is there anything new appeared?
And search - does search work? or as usual it just present but finds nothing?

P.P.S. If you guys will implement in some way user defined bookmarks - as opposed to predefined bookmarks tree - that would be great. For now Adobe wants one to buy Adobe Acrobat - think of it - just to be able to add bookmarks. Silly, isn't it? And no other pdf viewer provides them. Wouldn't be just great if I would be able to make bookmarks for places of PDF I have to work often with, so I do not have to search for them all the time. Why so obvious feature not yet made to any pdf suit? Imaging every day crawling thru 1.5k pages pdf with no bookmarks. Brrr.

I think the parent was refering to the creation of bookmarks, not the use of already created bookmarks. What is wanted is the ability to edit PDF files at least minimially in a visual mode. Think: "mozilla -edit" for PDF.

Reading the KParts and preview stuff in the great article, I am thinking about one program or feature I am missing using KDE. I miss something like a Image Viewer, that does its job like the one in Windows. Currently I use Kuickshow, but I am not satisfied with it. The image is always very big, it is not in the center of the screen, I have no opportunity to view the next or previous picture with the mouse; I need the Page Up and Page Down keys on my keyboard. If I use the embedded viewer, I have a large image, and scrolling, scrolling, scrolling...

Is there a program available that does something like the Windows Image Viewer does? (Displays the image in the center of the screen, scaled to a "nice" size, abillity to view next picture, previous picture, rotate picture, print picture... with the mouse??)

I am not a Coder, but a program like that shouldnt be to hard to code i think. I would like to suggest it otherwise, maybe the KDE Image Viewer?? ;)

gwenview has a kpart, that allows you walk through your images like a dia show. There are two kparts, one with a sidebar containing the images in the current directory and one without the sidebar.
The kparts are very simple, and with one hit on the icon in konqueror you can switch between the gwenview view and konqueror view

Try KView. That works much better than Kuickshow for me, and has almost all of the features you asked for, screen-centered, next and previous images available by button (or keyboard, naturally with KDE's keyboard shortcut configurability, which I've taken advantage of to remap next/previous to space/backspace), image rotation, etc, without having too MANY image editing features when I primarily want a viewer.

Zoom is /slightly/ more complex, but only due to how it can be customized. There are zoom-in/out buttons, and a combo-box with standard size selections and the ability to type in arbitrary sizes. One can configure kview to zoom the image to the window (as you likely would on a laptop), the window to the image (as I do, with dual 2048x1532 400x300mm viewable screens to work with), or whatever works best. One useful feature is that in window to image zoom mode, KView "remembers" the size I select, from one image to the next. Thus, if I set it to 200% zoom for one image, the next is still 200% zoomed. Likewise of course if I set 50% zoom.

Only two frustrations, and they aren't enough to stop my use. (1) KView evidently wasn't designed with dual screen use in mind. While most applications honor my KDE preferences as to what screen to open on, KView insists on initially opening centered across the total work area, which on dual screens means split across them! While centering across the workspace would often be desired, KView needs a configuration option to (a) always open centered on the working screen (b) always open centered on a specific screen (c) always open centered on the total work-area (current implementation) (d/e/f) always open in the upper-left-corner of the above (useful when viewing many images of widely differing sizes), and (g) conform to KDE's global window settings (should be the default). At minimum, the KView window placement behavior should be enforceable with the KDE Specific Window Settings dialog, which it now ignores, so one can /force/ the desired behavior from KDE/KWin, even if KView doesn't contain the options internally. Luckily, however, KView WILL maintain a new window location if I move it once opened, even as the window resizes to fit the various viewed images, tho it reverts to split over the two screens the next time I open it. If it tried to center for each image, I'd quickly find a new favorite image viewing app!

(2) If I'm viewing an image and rotate it, then go onto the next, KView asks if I want to save changes. KView is primarily an image VIEWER, NOT an image EDITOR. It's not named KEdit (or KImageEdit). Thus, while saving the rotated image is an acceptable /option/, the default behavior should be to simply view the image, no prompting to save the changed image when advancing to the next/previous image.

One of the other advantages of KView, as opposed to some of the other suggestions you've gotten, is that it's part of the the KDE-base install, as part of the kdegraphics package. Thus, it's always in sync with the latest KDE version and doesn't require installing anything extra.

If I compile a document with pdflatex and the package "hyperref", I get support for all sorts of acrobat reader extensions, such as opening at a particular page, the default view size, fullscreen, bookmarks, etc.

Will kpdf ever support any of these - or is it just a wrapper for xpdf?
k.