Projects/Plasma/SynoxiDesktopInteractionPrinciples: Difference between revisions
Rememberme (talk | contribs) No edit summary |
Rememberme (talk | contribs) No edit summary |
||
Line 2: | Line 2: | ||
This is a preliminary Version of my Dektop Interaction Principles. These are aimed to provide a high usability and consistency. They're also supposed to reduce the stress of looking for ones files. This is archieved thruogh its non-hierarchic file visualization management. | This is a preliminary Version of my Dektop Interaction Principles. These are aimed to provide a high usability and consistency. They're also supposed to reduce the stress of looking for ones files. This is archieved thruogh its non-hierarchic file visualization management. | ||
1.What you see is what you get: Icons don't represent the file, they are the file | 1.What you see is what you get: Icons don't represent the file, they are the file | ||
Line 52: | Line 52: | ||
Minimized windows can also call for attention with a dialog and an associated action menu. | Minimized windows can also call for attention with a dialog and an associated action menu. | ||
A problem with this kind of application starting behaviour is how to handle big masses of applications (or in sinoxy "tasks"). In Sinoxy this problem is solved by being able to invoke a dialog who displays all tasks available on the system (Partially this is also solved by grouping applications, who have the same purpose, under one "task"). To invoke this dialog, you click on the KDE-icon. Herefrom you can drag tasks to the panel and also start them directly. | |||
[[Image:SinoxyMockup4.png]] | |||
Probably, a search mechanism would be very convenient. |
Revision as of 17:47, 23 February 2009
Synoxi Desktop Interaction Principles:
This is a preliminary Version of my Dektop Interaction Principles. These are aimed to provide a high usability and consistency. They're also supposed to reduce the stress of looking for ones files. This is archieved thruogh its non-hierarchic file visualization management.
1.What you see is what you get: Icons don't represent the file, they are the file
2.No hierarchic Folder Arrangement: All Views a user gets are virtual folders and represent all files who match a certain criteria (e.g. all Pictures / all Files edited last week / all Files sent to me by Peter) This includes semantic information. A user doesn't want to care about WHERE to save his files, he cares about the content. So a file save dialogue would ask for additional metadata rather than a place to save.
3.There are 3 types of objects for the user. These types will be called states further on: “Empty Objects” (create new file of a certain type) represented by an icon, “Closed Objects” (closed files) represented by a preview and “Open Objects” (open windows) represented by the window itself. A minimized Window is treated as a closed object. It is just placed in a special containment (see point 4 for visualization details of objects).
4.“Containers” are virtual views that collect various information about objects and are able to filter them in awareness of these. They are the general way of representing objects. They are aware of the state of an object (empty or new / closed / open). Containers act like a folder view that looks for data that matches filter criteria. It has to be very easy to customize them → reasonable set of filters visible (depending on which filters are already in use). To add or remove a criteria you can drag and drop from a list. This idea of filters is shared among all file views.
5.A user can interact with an object by holding the mouse or finger over the object for a certain amount of time (1-2 s) or by right clicking. Then, a menu appears. It shows contextual actions (delete / duplicate / rate / tag / send to …), semantic information (which can depend on the filters used in the container) and gathers all notifications for an object. Notifications are treated similarly as tags and canhave actions associated with them, as have tags. An object can call for attention by sending a visual and/or audible signal – it can also open parts of its menu (the notification area) by itself, if there is urgent information. By hovering this partial menu, the full menu is shown.
6.No systemtray exclusive notifications. All objects (which to the user are pieces of information with actions associated to them) are treated the same (from a visualization point of view). The information belongs to the object associated with it. Application Notifications are stuck to the objects representation, be it an open or closed object.
7.Containers are no explicit Window switchers. There is the window switcher applet or composite animation for that. Containers are used to look at and change the state of objects. So they can open a closed object or create an empty one. There can still be a window switcher applet.
8.You don't start an application, you start a task. If you have several applications, you can choose between them. The user doesn't care about applications, they just want it to work. The user wants to write a new text document as opposed to opening a certain application that can edit text documents. So applications are started by clicking on a certain task which is represented by an icon. By staying on the icon for a while (1-2 seconds) an action menu is shown (see point 4) Every action a user does is a task. Tasks can be dragged into the application launcher bar. 9.When a new notification arrives from a process, of whom there is no visible object, a new task appears in the task bar.(!English relative clause!?) It has a pop-up that shows the message. By hovering, a full context menu appears. It shows more information and allows for more actions.
10.New Tasks (application sessions) are treated the same way as closed documents or windows (open documents) are, because to the user, they basically represent empty documents or empty sessions of a chat application or an new browser page.
11.Closed Objects, Windows and new Tasks have to be distinguishable. It is important to have useful and intuitive filters.
12.An open file has to have the same contextual menu as a closed one. The problem here are notifications: In this file-centric system a notification would have to be attached to the application itself. This has to be either aggregated in a menu or attached to the bottom / top of the window. The former seems to be more viable.
13.Closing a window NEVER is a destructive task. It has nothing to do with deleting a file. A new file is saved automatically. By closing an application that has unsaved changes, the changes are saved automatically. Change History has to be preserved. Deleting a file is done by using the objects context menu.
Here some Mockups of a possible panel:
The user is hovering over the "new text document" icon. Not much to see here.
This is slightly more intresting: Here a task is calling for attention. Two new mails have arrived and the user is being informed. Hovering the icon or the notification will cause this:
Here the user is presented with options. 1) Open the Mail application 2) ignore the notification (the dialog will disappear).
This behaviour for notifications also applies for tasks who are not in the panel. All notifications for new or closed tasks appear this way.
Minimized windows can also call for attention with a dialog and an associated action menu.
A problem with this kind of application starting behaviour is how to handle big masses of applications (or in sinoxy "tasks"). In Sinoxy this problem is solved by being able to invoke a dialog who displays all tasks available on the system (Partially this is also solved by grouping applications, who have the same purpose, under one "task"). To invoke this dialog, you click on the KDE-icon. Herefrom you can drag tasks to the panel and also start them directly.
Probably, a search mechanism would be very convenient.