Latest revision as of 09:50, 15 June 2012

Methodology

Current vision

current vision, ideas, concepts and terminology: are we thinking the same thing when we say a term?
identify user scenarios, what do you want to do, why and in what situation

in the machine (example: being at work on a document while discussing about it simultaneously on email, chat and audio call)

what in current suituation of things matches with this?
what doesn't?
Try to answer the problem without looking at other answers..

  "because it works on OSX" or even "because it works on Plasma Desktop" are not valid answers ;)

Thinking instead for a moment about the other solutions: why the solution of other system does work/why it doesn't work?

High level "manifesto" points

natural feeling ui
few user interruptions
settings always correct for what i'm doing now
right level of mono/multitasking in different situations (complete

dedication to a task vs listening mucic/glancing over news items while working)

...

User scenarios

working on a document while talking about it
doing a presentation
doing a call
...

Define sub task

Define sub tasks of the "manifesto" points, more deltailed, but still not regarding implementation

Tasks examples

Organic ui

transitions.
realistic light effects.
High performance, but highly usable, UI when "candy" effects are disabled. (I.e., Compositing yes, Effects no.)
"One-Handed Desktop" via Mouse Shortcuts on platforms which can support mice. (NOTE: Windows appears to provide very limited capabilities, in comparison to Linux, Unix, OS-X, and even Blackberry.)
HIG for Gestures, and HIG for Button-based shortcuts.
Must be usable with just a keyboard (i.e., with no Pointer/Mouse device.)
Is our on-screen keyboard widget "good enough"?

Efficience in doing tasks

think in steps required to do a task: not just in "launching applications" that is just an aspect of it
what is and what should be the boundary between what is an app and what is the workspace
generic "information flow" of everything that i see on the screen: includes applications switching, not limited to it

Activities

what are the scenarios and the problem they are designed to solve
what are the ui-wise problems in them right now?
A possible one: gulf of execution (Info)
How to reduce it?

Hardware integration

when to turn on/off bluetooth, audio level, camera?
what to do if i attach a screen? a beamer?
what to do if i disconnect to office wifi and connect to home wifi?
...

Others

Notifications and sys tray items

High level thinking

What are they for?
What are the different use cases, what are the different "types"?
What interaction is needed?
What does the user need to be aware of?

Goals

Identify each category of current notification (i.e needs to persist)
A mockup of how notifications should work
A HIG of when and how items should appear in the sys-tray, and what notifications should be enabled by default. How often can they be emitted (i.e KTp should not emit 5 notifications when the network drops)

A Plamoid Desktop HIG

Expand on the work http://community.kde.org/Plasma#Interface_Standards_and_Research and http://community.kde.org/Plasma/Active/Development/ActiveHIG

We need:

A HIG that is _finished_
If there's a HIG for active, we need a HIG for situations with a mouse and keyboard, where interaction is (and should be) different, but with a very large overlap.
Based on current plasmoids, not a big shakeup, but define consistency whilst things are being rewritten in QML.

Planning for implementation

Write an updated version of what is now "ways of the plasma", ui guidelines etc
identify where the work has to be done for an abstract task item:
- bluedevil
- libplasma
- qml components
- tasks applet
actual coding/documenting/coding tasks up for grab ;)

Useful reads

Results produced at the sprint

@@ Line 32: / Line 32: @@
 ==Organic ui==
 * transitions.
 * realistic light effects.
 * High performance, but highly usable, UI when "candy" effects are disabled. (I.e., Compositing yes, Effects no.)
 * "One-Handed Desktop" via Mouse Shortcuts on platforms which can support mice. (NOTE: Windows appears to provide very limited capabilities, in comparison to Linux, Unix, OS-X, and even Blackberry.)
 * HIG for Gestures, and HIG for Button-based shortcuts.
 * Must be usable with just a keyboard (i.e., with no Pointer/Mouse device.)
 * Is our on-screen keyboard widget "good enough"?
@@ Line 63: / Line 57: @@
 ==Others==
-...
+===Notifications and sys tray items===
+=====High level thinking=====
+* What are they for?
+* What are the different use cases, what are the different "types"?
+* What interaction is needed?
+* What does the user need to be aware of?
+=====Goals=====
+* Identify each category of current notification (i.e needs to persist)
+* A mockup of how notifications should work
+* A HIG of when and how items should appear in the sys-tray, and what notifications should be enabled by default. How often can they be emitted (i.e KTp should not emit 5 notifications when the network drops)
+===A Plamoid Desktop HIG===
+Expand on the work http://community.kde.org/Plasma#Interface_Standards_and_Research and http://community.kde.org/Plasma/Active/Development/ActiveHIG
+We need:
+* A HIG that is _finished_
+* If there's a HIG for active, we need a HIG for situations with a mouse and keyboard, where interaction is (and should be) different, but with a very large overlap.
+* Based on current plasmoids, not a big shakeup, but define consistency whilst things are being rewritten in QML.
 =Planning for implementation=
@@ Line 80: / Line 93: @@
 * http://blog.usabilla.com/the-usability-abc-part-2/#more-3075
 * http://uxmag.com/
+* http://bokardo.com/principles-of-user-interface-design/
+* http://uxmovement.com/thinking/why-rounded-corners-are-easier-on-the-eyes/
+= Results produced at the sprint =
+* [[Plasma/Terminology | Plasma Terminology]]
+* [[Plasma/Workspace_Sprint/Personas | Personas]]
+* [[Plasma/Workspace_Sprint/Games | Games data]]
+* [[Plasma/Workspace_Sprint/Kanban | Kanban dump]]