Plasma/Workspace Sprint: Difference between revisions

From KDE Community Wiki
 
(11 intermediate revisions by 4 users not shown)
Line 31: Line 31:
=Tasks examples=
=Tasks examples=
==Organic ui==
==Organic ui==
* transitions
* transitions.
* realistic light effects
* 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==
==Efficience in doing tasks==
Line 52: Line 56:
* ...
* ...


=Others=
==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=
=Planning for implementation=
Line 62: Line 86:
** tasks applet
** tasks applet
* actual coding/documenting/coding tasks up for grab ;)
* actual coding/documenting/coding tasks up for grab ;)
=Useful reads=
* http://www.andrewschechterman.com/AndrewSchechterman/Qi_Fa_files/UX%20Glossary.pdf
* http://cyborganthropology.com/UX_Glossary
* 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]]

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