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.

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