Jump to content

Plasma/Mobile/Design: Difference between revisions

From KDE Community Wiki
Sebas (talk | contribs)
Created page with "Plasma Mobile is developed in a design-driven workflow. We design features and applications with Plasma Mobiles core concerns of functionality and privacy and design the apps ..."
 
Sebas (talk | contribs)
No edit summary
Line 1: Line 1:
Plasma Mobile is developed in a design-driven workflow. We design features and applications with Plasma Mobiles core concerns of functionality and privacy and design the apps fitting to different form factors. Apps or system components can be specific for a device such as a smartphone, but may also be applicable and useful on other types of devices, such as laptops.
Plasma Mobile is developed in a design-driven workflow. We design features and applications with Plasma Mobiles core concerns of functionality and privacy and design the apps fitting to different form factors. Apps or system components can be specific for a device such as a smartphone, but may also be applicable and useful on other types of devices, such as laptops.
This design process is iterative in nature and combines input from interaction designers, visual designers and developers in all stages. A guideline for a design process looks could be:
===Requirements Analysis===
The first step is mapping the requirements by describing the problem. In this phase, the following questions should be answered:
* Which problem do we want to solve?
* How do we want to solve this problem (may be on an abstract level)?
* Which user-facing functional changes do we want to make?
===Interaction Design===
* How does the user "experience" the described functionality?
* Where does the new feature fit into the application's workflow?
* How should this be presented in terms of interactive controls?
* Which options should be provided?
* How can these actions be labeled and presented to the user in a self-explanatory way?
===Visual Design===
The visual design stage is all about how it should look on the screen. Relevant questions that should be answered in this stage are
* How should the wanted functionality be presented?
* Which graphical elements are necessary for functional and visual aspects of the new feature?
* Which supporting hints, such as animation or transition effects should be provided, and which function do they serve?
* Which graphical elements are necessary, on top of existing theming and graphical elements
* Mockups are useful tools to convey results of this stage in order to move on to the next stage.
===Implementation===
In this stage, the developer works on the code for the application, getting feedback or additional details from the previous stages. This work can be done based on mockups and it's generally helpful when someone has already thought of which UI options should be found where. Good presentations of the design work help developers to make smart choices in the architecture. Developers are usually happy to receive mockups that look good, and try to make the resulting UI match (or exceed) the ideas of the designers.
===Review===
In this stage, we have a critical look at the result of the implementation and look how it can be improved or polished further. Review should blend into the implementation stage as soon as possible, as to steer the development of the UI in the expected direction. 
===Profit!===
The feature reaches the user, through testing packages and eventually in a stable release, via system images, packages or app stores. This is just the beginning, since it's the point where feedback comes in, often in the form of bugreports, but also regularly in comments from ragingly enthusiast users that appreciate the work done. Time to think about the next iteration, how can the feature be made more valuable, better understandable, or just a lot more appealing or useful?


The following tools help you to design a well-integrated, good looking and functional appliation or feature.
The following tools help you to design a well-integrated, good looking and functional appliation or feature.
Line 12: Line 45:
More details about [https://techbase.kde.org/Projects/Usability/Principles/KDE4_Personas these personas]
More details about [https://techbase.kde.org/Projects/Usability/Principles/KDE4_Personas these personas]


==Human Interface Guidelines==
We are currently working on extending KDE's [https://techbase.kde.org/Projects/Usability/HIG Human Interface Guidelines] also for mobile devices. This is an area where your expertise and help would be much appreciated.
==Where do I find other Plasma Mobile designers?==
Coordination of design related topics is done in the [https://forum.kde.org/viewforum.php?f=293 Plasma Mobile] and [https://forum.kde.org/viewforum.php?f=285 Visual Design Group] sections of the KDE forums.
Coordination of design related topics is done in the [https://forum.kde.org/viewforum.php?f=293 Plasma Mobile] and [https://forum.kde.org/viewforum.php?f=285 Visual Design Group] sections of the KDE forums.


Design assets, such as mockups are shared via [https://share.kde.org share.kde.org], KDE's owncloud instance.  
Design assets, such as mockups are shared via [https://share.kde.org share.kde.org], KDE's owncloud instance.  
'''TODO:  this stuff should be made available without needing an account'''
'''TODO:  this stuff should be made available without needing an account'''

Revision as of 01:32, 11 August 2015

Plasma Mobile is developed in a design-driven workflow. We design features and applications with Plasma Mobiles core concerns of functionality and privacy and design the apps fitting to different form factors. Apps or system components can be specific for a device such as a smartphone, but may also be applicable and useful on other types of devices, such as laptops.

This design process is iterative in nature and combines input from interaction designers, visual designers and developers in all stages. A guideline for a design process looks could be:

Requirements Analysis

The first step is mapping the requirements by describing the problem. In this phase, the following questions should be answered:

  • Which problem do we want to solve?
  • How do we want to solve this problem (may be on an abstract level)?
  • Which user-facing functional changes do we want to make?

Interaction Design

  • How does the user "experience" the described functionality?
  • Where does the new feature fit into the application's workflow?
  • How should this be presented in terms of interactive controls?
  • Which options should be provided?
  • How can these actions be labeled and presented to the user in a self-explanatory way?

Visual Design

The visual design stage is all about how it should look on the screen. Relevant questions that should be answered in this stage are

  • How should the wanted functionality be presented?
  • Which graphical elements are necessary for functional and visual aspects of the new feature?
  • Which supporting hints, such as animation or transition effects should be provided, and which function do they serve?
  • Which graphical elements are necessary, on top of existing theming and graphical elements
  • Mockups are useful tools to convey results of this stage in order to move on to the next stage.

Implementation

In this stage, the developer works on the code for the application, getting feedback or additional details from the previous stages. This work can be done based on mockups and it's generally helpful when someone has already thought of which UI options should be found where. Good presentations of the design work help developers to make smart choices in the architecture. Developers are usually happy to receive mockups that look good, and try to make the resulting UI match (or exceed) the ideas of the designers.

Review

In this stage, we have a critical look at the result of the implementation and look how it can be improved or polished further. Review should blend into the implementation stage as soon as possible, as to steer the development of the UI in the expected direction.

Profit!

The feature reaches the user, through testing packages and eventually in a stable release, via system images, packages or app stores. This is just the beginning, since it's the point where feedback comes in, often in the form of bugreports, but also regularly in comments from ragingly enthusiast users that appreciate the work done. Time to think about the next iteration, how can the feature be made more valuable, better understandable, or just a lot more appealing or useful?


The following tools help you to design a well-integrated, good looking and functional appliation or feature.

Vision Statement

TODO, pending finalization of discussion on mailing list

Personas

Based on the vision statement, applications should be designed for the following personas:

  • "'Berna (office worker), says "I want to feel safe"
  • "Susan" (recreational user), says "I want to be creative and flexible"

More details about these personas

Human Interface Guidelines

We are currently working on extending KDE's Human Interface Guidelines also for mobile devices. This is an area where your expertise and help would be much appreciated.

Where do I find other Plasma Mobile designers?

Coordination of design related topics is done in the Plasma Mobile and Visual Design Group sections of the KDE forums.

Design assets, such as mockups are shared via share.kde.org, KDE's owncloud instance. TODO: this stuff should be made available without needing an account