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
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.
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.
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: How long ago was this?
Florian: That was two months ago.
Albert: Here you can find the news item.
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?
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!