This blog moved to my private website
(feed)!

Today Olaf published the second checklist in the scope of the HIG Hunting Session - it is about Text and Fonts.

Just like last week, we ask users of the KDE 4 Alpha release to review applications along checklists and report infringements in the bug tracking system. More details in the weekly dot article!

Happy Hunting!

Yesterday, the usability review cycle for KDE4 started. As the HCI working group is poor on man-power, we started an experiment to include the community into the search for obvious infringements of the KDE Human Interface Guidelines: The HIG Hunting Season.

If you recently had a look at the HIG's start page, you'll quickly spot that it's far from being finished. That's why we are preparing HIG checklists which list the most common user interface and interaction problems in KDE3.

Such issues can be stated like bugs, and that's what we ask the community for:

Please review KDE4 applications along the HIG checklists - and report bugs whenever you find an infringement!

Reviews can be performed by anyone - users, developers, technical writers, translators, developers, usability people.. anyone! If you don't have a running KDE4 environment, check out beineri's KDE four live CD or wait for the alpha release which should be available tomorrow or so.

The checklists are published on a weekly basis on the dot. For the first checklist about configuration dialogs and instructions how to proceed, please have a look at this week's dot story.

Developers who receive HIG-related bug reports which require further usability analysis please send a mail to kde-usability-devel.

Happy hunting!

As the result of a long discussion on kde-core-devel, I summarised the suggested application and system shortcuts for KDE4:

• Standard Keyboard Shortcuts
• About Shortcuts and Accelerators

[The table isn't formatted yet - are there volunteers to make it look like these ones? I really hate tables in MediaWiki...]

The suggested shortcuts are a summary of the discussion on kde-core-devel. The alternate shortcuts we originally suggested are left out as far as possible, but we kept the shortcuts which are required to obtain full keyboard access.

One more question to the community: The KDE3 default scheme reserves several shortcuts for text completion - I wonder if they still need to be reserved, or if we should free them for applications?

Apart from shortcuts, the HIG made some progress in the following sections:

• Feedback
• Warning Messages
• Dockers
• Drag and Drop
• Links
• Window Layout

All accessible via the front page. Feedback appreciated (here or to ellen kde org).

Finally, the dialog section in the HIG has made some progress. Thank to Olaf who knows Qt Designer much better than I do, we found a way to create a clean dialog layout for KDE4. The trick is to use the same ratio of spacers on bottom of each group box. Read more in the guidelines!

We are planning to provide some video tutorials how to best use Designer - stay tuned. We'll also upload the ui files when we found a good location (the wiki allows only images).

I appreciate feedback on this, as well as on the other guidelines drafted on this page: "General" and "Modality". Please comment here or write a mail to ellen kde org.

A few weeks ago, Celeste posted specs for standard toolbars for the major KDE applications. Now, we wrote down some general guidelines. Again, please review and give feedback in the comments section, or write to me (ellen kde org). There are still screenshots missing for the standard toolbars.

Especially, we'd appreciate feedback on:

* What standard toolbars (applications) and toolbar components (e.g. zoom toolbar, navigation in documents) should we add?
* Who wants to help us with implementation suggestions?
* If button groups are used, do we still need separators or do the button groups take care for visual separation?

@ 800x600 rule

So far, I'm not sure if we should go for a fixed maximum size or a maximum default size. There is one good reason for a strict maximum size: It better prevents configuration dialogs from being overloaded. "Designing for 800x600" may be understood as "hey, it fits onto the page!". A tricky developer might reduce the height of scalable widgets like the table in the screenshot below, and argue that users can resize the dialog if they want to have a better overview over the element in the table.

I expect that a maximum size will make you think more deeply of what options should be provided on a page, and what should go into an advanced popup.

[image:2719 class=showonplanet align=center]

Also, 800x600 is a rule of thumb. If you really really need more space, you can of course add ~50 Pixels to each dimension. And this rule applies to configuration dialogs only. Other dialogs will still be resizable.

The one strong argument against fixed dialog sizes is accessibility: When increasing the font sizes, the dialog should resize proportionally even for fixed sizes. This, however, should be done by the API. Is it feasible that we get this in the early life cycle of KDE4?

@ Advanced sections

As there was a comment against Advanced sections ("You never find what you are looking for"), I want to make sure that the guideline is understood correctly: The first choice should always be to embed advanced options with their context. That's why foldout sections or popup dialogs are preferred. Only when you have advanced options that don't fith into the other groups, provide an advanced section.

Foldout sections are still missing in the API, by the way

@ Configuration menu

In the standard section, I suggested to move notification into the general configuration dialog. I suggested this as there are various new types of notifications which are not covered in the standard notifications dialog. Notifications are an important setting and they should be covered in one place. That's why they should be located in the general configuration dialog.

I still think that toolbar and shortcut settings should remain in separate dialogs. It's a consistent location all over the applications, and they are rather advanced settings which shouldn't bloat the general configuration dialog.

@ about:config

One suggestion was to introduce searchable about:config dialogs which list all configuration options in text form. I remember to have heard this suggestion at akademy as well, and wonder if it's something that is desired by a broader part of the community?

@ Reset to Defaults

I completely forgot about the "Reset to Defaults" guideline. In KDE3, "Defaults" works differently in (almost) every application. What we need is a common solution.

A quick-fix would be to provide a split button that provides two options:

• "Reset [page title]" e.g. "Reset Fonts"
• "Reset all Settings"

I started to write down some guidelines for configuration dialogs in KDE4. The major differences to KDE3 are:

• Do not overload your configuration dialogs!
• Avoid the usage of tree views in the sidebar of paged dialogs.
• Set the dialog's maximum size to 800x600 Pixels.
• Make sure all dialog pages are sized equally, so the dialog does not resize.
• Provide vertical and horizontal scrollbars on each tab (hide them by default). This allows users who require big font sizes to reach all contents while they can see the tab titles and reach the OK/Cancel buttons.
• Separate advanced preferences from frequently used ones.

Please review the guidelines and give me feedback. I'm basically interested in everything - if you agree on the contents, the format, if there are parts missing, if you need more examples, more concrete guidelines etc. Also, in the lower part of the page, there are some suggestions for new widgets in the standard sections I'd like to see feedback for (font and color requester). You can either use this blog's comment section or write an email to ellen kde org).

In November, OpenUsability announced six mentored projects for students of usability, user interface design, interaction design, or related. We received applications from all over the world - New Zealand, India, South Africa, Europe, South America, USA and Canada. Most of the applicants were highly skilled, and it was sometimes difficult to take a decision. Finally, the following teams formed up:

• Basket

  Student intern: Frank Ploss, Germany
  Usability mentor: Bjoern Balazs, Germany
  Technical mentor: Sebastien Laout, France

  Frank Ploss, student of computer science, performs a usability analysis and redesign of the Basket Notepad for KDE. He adopted the topic for his diploma thesis he just started to write and set up a web page where you can follow his progress.

• GeeXBoX

  Student intern: Francesco De Rose, Italy
  Usability mentor: Celeste Lyn Paul, USA
  Technical mentor: Benjamin Zores, France

  The team had its first kick off meeting in the beginning of January and started its work on a redesign of the GeeXBoX multimedia system. One of the challenges of designing an interface for this kind of system is the low resolution (must be clear enough to read on a TV) and limited input devices (a joystick of simple controller should be enough).

• Open Printing

  Student intern: Andrea Alessandrini, Italy
  Usability mentor: Peter Sikking, Germany

  The goal of this project is to design first low, then medium, fidelity printing dialogs, using the information that is gathered by questionnaires and testing of the integrated usability part of the project. The project will start on the first of February.

• Okular

  Student intern: Sharad Baliyan, India
  Usability mentor: Florian Graessle, Germany
  Technical mentor: Pino Toscano, Italy

  The team is currently in the project management phase and will soon advance the usability of Okular, the next generation document reader for KDE.

• Serendipity

  Student intern: Prabhath Sirisena, Sri Lanka
  Usability Mentor: Ellen Reitmayr, Germany
  Technical Mentor: Garvin Hicking, Germany

  We are currently planning a user survey to collect the major use cases for casual blogging with the Serendipity weblog system. The project progress will be documented in a wiki on OpenUsability.

• SIP Communicator

  Student intern: Fabiana Meira Pires, Brazil
  Usability mentor: Jan Muehlig, Germany
  Technical mentor: Emil Ivov, France

  The team had it's first kickoff meeting on IRC and started its work to design a solution for transparent management of multiple VoIP and IM accounts with different functionality in a single application, namely SIP Communicator.

In addition to the "Season of Usability" openings, we found support for two more projects:

• OpenWengo

  Student intern: Paula Bach, USA
  Technical mentor: Jerome Wagner, France

  Paula will work on one or more of the following tasks to improve the usability of OpenWengo, a VoIP client:

  + Design a a quick launcher for essential functions of the application.
  + Integration of the download/update part with the plugin framework.
  + Addition and integration of 3-way video conferencing.
  + Addition and integration of "video smileys".

• Inkscape

  Student intern: Jennifer Ferreira, New Zealand
  Usability mentor: Alan Horkan, Ireland
  Technical mentor: Cedric Gemy, France

  Jennifer is going to develop user models for the layout application Inkscape.

A big thanks to all students who showed so much interest in FLOSS usability!

For those who were not selected: Please don't hesitate to apply again next season. In the meantime you might have a look at our project openings and lead your own OpenUsability project. Don't be deterred - working in FLOSS is first of all fun!

One year ago, some people from linaccess, barrierefrei kommunizieren, KDE Accessibility and Usability (including myself) passed a weekend on testing the usability of FLOSS accessibility solutions - you might remember our reports from the Accessibility meets Usability weekend. Among others, the Gnopernicus screen reader was usability tested by two blind users. Short after the test, the development of Gnopernicus was (at least partly) stopped for the benefit of Orca which relies on AT-SPI technology.

As preparation for a workshop about German screen readers for Linux I'll attend next week, we now did a first evaluation of the Orca screen reader with Gnome. In cooperation with barrierefrei kommunizieren, I had the opportunity to test Orca with Sebastian, a blind student of computer science. Our focus was mostly set on functioning, but also usability and German localisation.

All in all, we were amazed by the current state of Orca and its integration with the Gnome desktop. Application whose integration was problematic with Gnopernicus, e.g. OpenOffice.org, can be widely operated with Orca.

You can download the full report (PDF, 719 KB).