[kde-guidelines] KStyleguide

[Thomas Pfeiffer]

On Wednesday 15 May 2013 10:03:36 Heiko Tietze wrote:
> 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:

[...]
 
> 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.

Sounds great!

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

Seems like I missed that ticket. Who proposed to have more than the close and 
configure buttons at the top?
Action specific to a certain notification are shown inline and not at the top, 
and currently I don't see any other buttons then the aforementioned to 
there...

> Dos and Don'ts:
> - Don't show information that concern the actual workflow as notification.
> - Make notification text informative and actionable.
> - ...

This is probably the most important part (and we're likely to need many more 
bullets in this list), because we need to make clear to developers that they 
should not try to use notifications for all sorts of crazy things which they 
were not meant for.

> Code snippet:
> while i<42 do {
> printf(Hello world)
> }

Yes, code snipped ftw (to be replaced with the actual code needed to create a 
notification, of course ;) )!
 
> 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.

See my reply to David's reply for this.

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

I think we can start working on the HIG before Akademy, but dicsussing the 
topic there would still be very helpful to coordinate our work and decide what 
to focus on in the future.

Cheers,
Thomas