[kde-guidelines] KStyleguide

[Heiko Tietze]

As discussed in "[KDE Usability] Who would help rebooting the KDE HIG and UI Design Patterns?" I propose to prepare the styleguide according Baxley's model. I have done it for two other projects before and it would look like this:

1 Structure
1.1 Conceptual Model
* Vision
* Personas
* Scenarios
* Usability criteria
* ...
1.2 Task flow
* ...
1.3 Organizational model
* ...

2 Behaviour
2.1 Viewing and Navigation
2.1.1 General navigation
* Overlay/Secondary window
* Accordion
* Tabs
* Toolbar
* Statusbar
* Scrollbar
* Paging 
2.1.2 Access functions
* Menus
* Buttons
* Links
* Keyboard Access 
2.1.3 Grouping
* Group box, Panel
* Splitter 
2.1.4 Complex views
* Listview and Grids
* Tree view 
2.2 Editing and Manipulation
2.2.1 Selection
* 1 of a few n selection (Radio button)
* n of a few m selection (Check box)
* 1 of some n selection (Drop-down list)
* 1 of n selection with possibility to add item (Combo box)
* 1 of a huge number of n selection (Extended drop-down list)
* n of m selection 
2.2.2 Unconstrained input
* Edits and Text boxes
* Complex views with direct input (Grid cell editing) 
2.2.3 Constrained input
* Numeric input within a range and with fix steps (Spin control)
* Arbitrary changes within a range for immediate feedback (Slider)
* Special controls (e.g. Date Picker) 
2.3 User Assistance
2.3.1 User-driven information (Tool-Tip)
* User-driven information 
2.3.2 System triggered notification
* Notification
* Controls
* Progress Indicator 
2.3.3 Disruptive messages (Modal Dialog)
* Disruptive messages 
2.3.4 Help System
* Help system 

3. Presentation
3.1 Layout
* Default size and space
* Resizing
* Alignment and placement
* Colour
* Icons 
3.2 Style
* Style 
* Branding
3.3 Text
3.3.1 Localization
* Localization 
3.3.2 Static Text
* Static text
3.3.3 Control labels
* Dialogs
* Menus
* Buttons
* Links
* Tabs
* Check box and Radio button
* Group box 

The most elaborated part so far is Behaviour (which is a shame for an usability expert *g*). Of course the list needs adoption to KDE but the general (numbered) organization makes sense.

Let's try KDE notification as an example:

1 Structure
1.1 Conceptual Model
- KDE users are interested in operation's background. 
- They want to configure the system individually.
- They want to get much feedback.
...
1.2 Task flow
* ...
1.3 Organizational model
- KDE provides a centralized configuration system to make settings effective in general. (There is no good reason to move the configuration from the program itself to KCM without any overlapping feature.)
- ...

2.3.2 System triggered notification
About:
- Notification is shown in a panel next to the system tray.
- Notification panel pops up automatically and disappears after 5s (can be configured ^link).
- User can close the notification manually per close icon/button (?) at the top right corder of the panel.
- Whether or not an application does show notifications is configured in a system configuration module (^link to kcm). The configuration can be accessed at the notification panel left to the close button. (I recommend to rethink this behaviour. If more than these two options are possible, a dropdown menu perhaps via menu button with close as default fits better than close, configure, open trash, etc. as shown in the last ticket.)
- If more than one information is shown the notification panels are stacked.
- ...
Dos and Don'ts:
- Don't show information that concern the actual workflow as notification.
- Make notification text informative and actionable.
- ...
Code snippet:
while i<42 do {
printf(Hello world)
}

3. Presentation
3.1 Layout
- Notification panel's size is 100 x 42px.
- Notification panel cannot be resized.
- Content of notification has 8px space around.
- ...
3.3 Text
- Notification has a caption with system font, sized +1, central aligned.
- Notification text is system standard, justified to panel width.
- ...

So far to start the discussion here. I'm not sure if the separation of behaviour and presentation will work on this level. Pro: to create a common look and feel we should make general guidelines; Con: devs might be confused because of the fragmented information.

Cheers,
Heiko.

PS: About the academy: Probably I'll be there too, depending on how busy I will be the next time. But I don't want to wait two month with the work...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20130515/f3a25a85/attachment.html>