[kde-guidelines] KStyleguide

[David Edmundson]

On Wed, May 15, 2013 at 11:03 AM, Heiko Tietze
<heiko.tietze at user-prompt.com> 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:
>
> 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.
> - ...
>

Can I suggest we separate the tasks  "how an app developer should use
existing KDE libs" and trying to change what the KDE libs do.

I suggest we do this because otherwise we will spiral into redesigning
everything anew and not really come up with anything that developers
can actually benefit from. This is something I've seen happen before.

In this example, from a technical point of view the app developer has
absolutely no control over how the notification is shown. A developer
can only set the the raw text + icon + actions.
The content size + font + margins + resizing is down to the native
notification display system which is generally, but not always,
Plasma. Given the developer has no control, there would be no point
listing it.
Whether there's an icon to configure the notifications or changing the
font size is trying to change what's there and not saying how one
should use what's there.

Obviously if there is a view that some KDE library behaviour is wrong,
we can and should still follow that up in the relevant channels,  now
is almost the perfect time to do that. However, we should avoid
writing these things into the HIG.

David

> 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...
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>