[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-guidelines
Subject: Re: [kde-guidelines] KStyleguide
From: Celeste Lyn Paul <celeste () kde ! org>
Date: 2013-05-23 0:06:55
Message-ID: CAAfNz7ZF91CAB-sxPGCRPFGtWM4zeqckGXFFAfPUp9wgzHzuTw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Notifications are part of my dissertation. I can help worth this section
after I defend in July
On May 15, 2013 6:03 AM, "Heiko Tietze" <heiko.tietze@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.
> - ...
>
> 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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>
>
[Attachment #5 (text/html)]
<p>Notifications are part of my dissertation. I can help worth this section after I \
defend in July</p> <div class="gmail_quote">On May 15, 2013 6:03 AM, "Heiko \
Tietze" <<a href="mailto:heiko.tietze@user-prompt.com">heiko.tietze@user-prompt.com</a>> \
wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>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:<br> <br>1 Structure<br>1.1 \
Conceptual Model<br>* Vision<br>* Personas<br>* Scenarios<br>* Usability \
criteria<br>* ...<br>1.2 Task flow<br>* ...<br>1.3 Organizational model<br>* \
...<br><br>2 Behaviour<br>2.1 Viewing and Navigation<br> 2.1.1 General \
navigation<br>* Overlay/Secondary window<br>* Accordion<br>* Tabs<br>* Toolbar<br>* \
Statusbar<br>* Scrollbar<br>* Paging <br>2.1.2 Access functions<br>* Menus<br>* \
Buttons<br>* Links<br>* Keyboard Access <br> 2.1.3 Grouping<br>* Group box, \
Panel<br>* Splitter <br>2.1.4 Complex views<br>* Listview and Grids<br>* Tree view \
<br>2.2 Editing and Manipulation<br>2.2.1 Selection<br>* 1 of a few n selection \
(Radio button)<br>* n of a few m selection (Check box)<br>
* 1 of some n selection (Drop-down list)<br>* 1 of n selection with possibility to \
add item (Combo box)<br>* 1 of a huge number of n selection (Extended drop-down \
list)<br>* n of m selection <br>2.2.2 Unconstrained input<br>
* Edits and Text boxes<br>* Complex views with direct input (Grid cell editing) \
<br>2.2.3 Constrained input<br>* Numeric input within a range and with fix steps \
(Spin control)<br>* Arbitrary changes within a range for immediate feedback \
(Slider)<br>
* Special controls (e.g. Date Picker) <br>2.3 User Assistance<br>2.3.1 User-driven \
information (Tool-Tip)<br>* User-driven information <br>2.3.2 System triggered \
notification<br>* Notification<br>* Controls<br>* Progress Indicator <br> 2.3.3 \
Disruptive messages (Modal Dialog)<br>* Disruptive messages <br>2.3.4 Help \
System<br>* Help system <br><br>3. Presentation<br>3.1 Layout<br>* Default size and \
space<br>* Resizing<br>* Alignment and placement<br>* Colour<br>
* Icons <br>3.2 Style<br>* Style <br>* Branding<br>3.3 Text<br>3.3.1 \
Localization<br>* Localization <br>3.3.2 Static Text<br>* Static text<br>3.3.3 \
Control labels<br>* Dialogs<br>* Menus<br>* Buttons<br>* Links<br>* \
Tabs<br>
* Check box and Radio button<br>* Group box <br><br>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.<br> \
<br>Let's try KDE notification as an example:<br><br>1 Structure<br>1.1 \
Conceptual Model<br>- KDE users are interested in operation's background. <br>- \
They want to configure the system individually.<br>- They want to get much \
feedback.<br>
...<br>1.2 Task flow<br>* ...<br>1.3 Organizational model<br>- 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.)<br>
- ...<br><br>2.3.2 System triggered notification<br>About:<br>- Notification is shown \
in a panel next to the system tray.<br>- Notification panel pops up automatically and \
disappears after 5s (can be configured ^link).<br>
- User can close the notification manually per close icon/button (?) at the top right \
corder of the panel.<br>- 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.)<br>
- If more than one information is shown the notification panels are stacked.<br>- \
...<br>Dos and Don'ts:<br>- Don't show information that concern the actual \
workflow as notification.<br>- Make notification text informative and \
actionable.<br>
- ...<br>Code snippet:<br>while i<42 do {<br>printf(Hello \
world)<br>}<br><br><span>3. Presentation<br>3.1 Layout<br>- Notification panel's \
size is 100 x 42px.<br>- Notification panel cannot be resized.<br>- Content of \
notification has 8px space around.<br>
- ...<br>3.3 Text<br>- Notification has a caption with system font, sized +1, central \
aligned.<br>- Notification text is system standard, justified to panel width.<br>- \
...<br><br>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.<br> <br>Cheers,<br>Heiko.<br><br>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...<br></span></div> \
<br>_______________________________________________<br> kde-guidelines mailing \
list<br> <a href="mailto:kde-guidelines@kde.org">kde-guidelines@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-guidelines" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-guidelines</a><br> \
<br></blockquote></div>
_______________________________________________
kde-guidelines mailing list
kde-guidelines@kde.org
https://mail.kde.org/mailman/listinfo/kde-guidelines
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic