diff --git a/source/img/Introduction_KDE4_Vision_personas_1_office.png b/source/img/Introduction_KDE4_Vision_personas_1_office.png new file mode 100644 index 0000000..d324cd3 Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_personas_1_office.png differ diff --git a/source/img/Introduction_KDE4_Vision_personas_2_student.png b/source/img/Introduction_KDE4_Vision_personas_2_student.png new file mode 100644 index 0000000..dd742d2 Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_personas_2_student.png differ diff --git a/source/img/Introduction_KDE4_Vision_personas_3_recreational.png b/source/img/Introduction_KDE4_Vision_personas_3_recreational.png new file mode 100644 index 0000000..092bc5f Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_personas_3_recreational.png differ diff --git a/source/img/Introduction_KDE4_Vision_personas_4_decision.png b/source/img/Introduction_KDE4_Vision_personas_4_decision.png new file mode 100644 index 0000000..bddca97 Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_personas_4_decision.png differ diff --git a/source/img/Introduction_KDE4_Vision_personas_5_geek.png b/source/img/Introduction_KDE4_Vision_personas_5_geek.png new file mode 100644 index 0000000..143dd44 Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_personas_5_geek.png differ diff --git a/source/img/Introduction_KDE4_Vision_personas_all.png b/source/img/Introduction_KDE4_Vision_personas_all.png new file mode 100644 index 0000000..1797cb0 Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_personas_all.png differ diff --git a/source/img/Introduction_KDE4_Vision_tal.png b/source/img/Introduction_KDE4_Vision_tal.png new file mode 100644 index 0000000..eb12887 Binary files /dev/null and b/source/img/Introduction_KDE4_Vision_tal.png differ diff --git a/source/introduction/concept.rst b/source/introduction/concept.rst new file mode 100644 index 0000000..c0ce5a5 --- /dev/null +++ b/source/introduction/concept.rst @@ -0,0 +1,98 @@ +Concept +======= + +The conceptual model is the most fundamental aspect of the interface, +describing the relationship between the interface and the outside world. +The purpose of the conceptual model is to draw on the user’s past +experiences so they can readily understand basic operations and +naturally predict functionality in an application. + +Project vision +-------------- + +A vision describes the goal of the project. It can be emotive and a +source of inspiration. For instance, by outlining how the final product +makes the world a better place you can draw upon inspiration to create +the end goal of your project. Describe the project's final goals. +Explain who will use the product, and how he or she will take advantage +from it. Make sure your vision is shared between all project +stakeholders. Leave room in your vision for creativity and changes. Keep +it short. + +A good starting-point is the *elevator pitch*: + +- FOR *target customer* +- WHO *statement of the need* +- THE *product name* +- IS A *product category* +- THAT *key benefit* +- UNLIKE *primary competitor* +- OUR PRODUCT *further differentiation* + +Personas +-------- + +Personas can help identify the target users of your application and +provide a common understanding among the design and development team. A +persona is the representation of a user, based on empirical data. +Personas describe the target users, giving a clear picture of how +they're likely to use the system, and what they’ll expect from it. The +description includes a concise summary of characteristics of the user, +their experience, goals and tasks, pain points, environmental conditions +and even name. + +The KDE usability team has created :doc:`predefined personas ` which we +highly recommended using for your project. + +If you choose to create your own personas, consider the following: + +- Always try to define personas based on empirical data. Feel free to + ask the KDE user experience team (kde-usability at kde.org) for + assistance with the collection of empirical data. +- Add enough information to establish a good impression of the target + user and stay concise. +- Common elements are name, job titles and major responsibilities, + demographics such as age, education, ethnicity, and family status, + goals and tasks they are trying to complete using the application, + physical, social, and technological environment. +- Add a quote that sums up what matters most to the persona and a + casual picture representing that user group. +- Discriminate between primary (the basic user) and secondary + (additional users) persona. If it makes sense, describe the group of + users that is explicitly not supported by an anti-persona. Respect + the law of parsimony and have as few personas as possible. +- Make sure your persona can act in different scenarios. + +User Stories +------------ + +Scenarios illustrate how the users achieve their goals by means of +task-orientated examples. It is supplementary to a persona, providing +together an efficient method applicable in a wide range of applications. + +Use the following guide to help create scenarios: + +- Always try to create scenarios based on empirical data. Feel free to + ask the KDE user experience team (kde-usability at kde.org) for + assistance with the collection of empirical data. +- Take technical configuration, environmental condition, organizational + and social aspects into consideration. +- If available, use real world images to support imagination. +- Try to include problem situations that will test the system concept, + not just straightforward scenarios. + +Target Device Classes +--------------------- + +While thinking about the scenarios, also consider devices of which +class(es) the personas would use in that scenario. Currently, Plasma and +(some) KDE applications target the following device classes: +Desktop/laptop, media center (TV), phone and tablet/convertible. Your +application may target other device classes (like eg. in-vehicle +entertainment systems, kiosk systems, ...) as well. + +Documenting Your Concept +------------------------ + +A useful template for documenting your personas and scenarios is the +:doc:`Project User Research Template `. diff --git a/source/introduction/index.rst b/source/introduction/index.rst index c088617..6cdb89f 100644 --- a/source/introduction/index.rst +++ b/source/introduction/index.rst @@ -1,14 +1,20 @@ Intoduction =========== .. toctree:: :titlesonly: :hidden: vision architecture convergence + concept + personas + research * :doc:`vision` * :doc:`architecture` +* :doc:`concept` +* :doc:`personas` +* :doc:`research` * :doc:`convergence` diff --git a/source/introduction/personas.rst b/source/introduction/personas.rst new file mode 100644 index 0000000..99092b1 --- /dev/null +++ b/source/introduction/personas.rst @@ -0,0 +1,137 @@ +Personas +======== + +.. image:: /img/Introduction_KDE4_Vision_personas_all.png + :scale: 50% + :alt: All personas of KDE + +Berna +----- + +.. image:: /img/Introduction_KDE4_Vision_personas_1_office.png + :scale: 50% + :alt: Berna + +Berna is working as an office clerk in a big insurance. Although a smart +person, she is very unsure when it comes to technology. + +Berna's major work is to check the details of insured events. She writes +reports for her boss suggesting compensation payouts for the cases she +deals with. Berna is a very precise person, and always solves her tasks +accurately. + +Berna twice lost several hours of work because she didn't understand the +options she was offered. Since then, she has been very careful when +probing new functionality. + +Matt +---- + +.. image:: /img/Introduction_KDE4_Vision_personas_2_student.png + :scale: 50% + :alt: Matt + +Matt is a geology student in the last year of his undergraduate studies. +For him, technology is meant to take over annoying and repetitive tasks. + +For his student research projects, Matt has to do extensive research on +the web, and has to manage pictures of stones and other geologic +material. He gains credits by using his notes to create reports and +presentations. + +Matt often struggles to keep track of all his notes. He is looking for +an effective routine, so he can concentrate on the contents rather than +on finding information. + +Susan +----- + +.. image:: /img/Introduction_KDE4_Vision_personas_3_recreational.png + :scale: 50% + :alt: Susan + +While Susan seldom uses her computer for work, it has become an +essential part of her social life. With her computer, she can be +creative and spread this creativity in the world. + +She chats with her friends, shares music, playlists and other media, +creates videos and uploads them to her web space, and runs a blog with +her own style. She can't imagine a life without her laptop. + +Still, she is a fun person and does not want to worry about technical +details. She expects her machine to work. + +Santiago +-------- + +.. image:: /img/Introduction_KDE4_Vision_personas_4_decision.png + :scale: 50% + :alt: Santiago + +Santiago runs a medium-sized business for electric installations. For +him, technology needs to be comfortable and make him feel smart. + +As a manager with engineering background, Santiago's major work is to +negotiate with customers. However, to avoid costs, he administrates the +small network in the company himself, including a file server and +fifteen PCs for his office clerks. + +He loves comfort and does not like to dive into manuals or use the +command line to set up the small network. The system has to be reliable +and easy to use, so his employees get along with it. + +Philip +------ + +.. image:: /img/Introduction_KDE4_Vision_personas_5_geek.png + :scale: 50% + :alt: Philip + +Philip is a high-school student in his last grade. Later, he wants to go +to university to study computer science. He loves the challenge of +making technology do what he wants it to do. + +When he was 14, he started to probe different programming languages, and +since then has implemented various different applications he published +under free licenses. He is convinced of Linux and the benefits of free +software. + +Philip is fancy about technology and is never discouraged if something +does not work as expected. + + +KDE Personas: Background +------------------------ + +The question "Why should people switch to KDE?" was an important factor +in the creation of our Personas – a crucial aspect if we want to extend +the current user base. The "Technology Adoption Lifecycle" by Rogers +(1962) deals with this question by splitting the overall user base in +groups along a bell curve according to their willingness to adopt new +technology. + +Looking at the "Technology Adoption Lifecycle", you'll find the +following user groups: + +.. image:: /img/Introduction_KDE4_Vision_tal.png + :scale: 50% + :alt: Technology Adoption Lifecycle + +We suggest to move away from the *KDE is for everybody* approach to *KDE +is for the more sophisticated 50% of computer users out there, who +choose it because it perfectly suits their work and that they "want to +have it".* + +Concentrating on this user base rather than everybody has both pragmatic +and motivational reasons: Pragmatically, it will be hard to make KDE a +favourite product for *laggards* and even the *late majority* within the +next five years. Neither cutting away functionality nor hiding all the +complexity behind *Advanced* buttons is an acceptable solution. Second, +creating a desktop for ambitious users better fits the current +motivation in the KDE development base. We don't want to be *simple and +stupid*, we want to develop a smart desktop with rich functionality! + +To avoid misunderstandings: KDE will still be an option for educational, +governmental or large enterprise usage – but it won't be the main focus +when developing the default desktop. KDE as a configurable framework can +still be adjusted to meet the needs of any other user base. diff --git a/source/introduction/research.rst b/source/introduction/research.rst new file mode 100644 index 0000000..c3b250c --- /dev/null +++ b/source/introduction/research.rst @@ -0,0 +1,88 @@ +Project User Research Profile +============================= + +Short summary description of the purpose of the application, who it is +for, and what those people can do with it. + +Purpose +======= + +**About the Project User Research Template:** The purpose of this +template is to provide a place to document an application's user +research information for reference during development. Top level items +are information everyone in the project should be aware of. Some of the +details in the lower sections may take some work and discussion within +the project to complete. + +Who is the application for? +--------------------------- + +- List of types (groups) of users +- User groups can be organized based on any type of dimension +- Some groups may be broken down in to sub groups + +(Who is the application *not* for) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Sometimes it is easy to identify who the application is **not** for +- This can help keep the scope of the project under control + +Sample User Profiles +~~~~~~~~~~~~~~~~~~~~ + +User Profile 1: For each group of users identified (or primary groups, +or particularly special groups if many groups are defined), write a +description of that user's characteristics based on a real user you +know. + +What kinds of tasks will they complete +-------------------------------------- + +- List of common tasks users will complete +- This does not have to be a complete functional specification, but + major tasks and specialty tasks should be listed +- Include functionality that is planned but not yet implemented to help + keep the future in focus + +(What kinds of functionality will the application *not* support) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- List tasks or functionality the application will not address +- Sometimes it is useful to list this unintended functionality to help + keep the scope of the application +- For example, a certain functionality may not be implemented because + it is out of scope with the primary goals of the project, another + application with a different focus does it better, or it is an + extreme edge case for a user type which is not primary + +Sample Use Scenarios and Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Use Scenario 1: For each task identified (or major tasks, or +particularly special tasks if many tasks are defined), write a +description of how that user would accomplish the task *independent* of +how they would complete it within the application. + +Use Case 1: If a use scenario has been implemented, include a matching +use case which describes how the task use scenario can be completed in +the application. There may be branching or multiple ways to complete the +task, and this is a good way to document it. + +Environment Conditions & Requirements +------------------------------------- + +- List of environmental conditions for the user or the application to + consider +- For example, an Internet-capable application would require an + Internet connection + +More Information +---------------- + +`Short introduction to user personas on Usability.gov`_ + +`In-depth discussion about creating personas on Boxes and Arrows`_ + +.. _Short introduction to user personas on Usability.gov: http://www.usability.gov/analyze/personas.html +.. _In-depth discussion about creating personas on Boxes and Arrows: http://www.boxesandarrows.com/view/making_personas_more_powerful_details_to_drive_strategic_and_tactical_design +