| 6 | | |
| 7 | | == Philosophy == |
| 8 | | The philosophy for the interface is as follows |
| 9 | | - conceptually separate objects (tables, views, maps, searches ...) get visually separate representations, for sakes of clear communication, called "'''blocks'''" |
| 10 | | - since it will not suffice to separately work with each "block" on it's own, the user must be able combine blocks in every imaginable way and number |
| 11 | | - the interface either visually or textually guides the user toward his own goal without intterrupting the workflow or visually distracting the user |
| 12 | | - Every block can be a starting point for the users work. |
| 13 | | - visual consistency ensures that the users knows what everything that is visually represented does, (in many cases) before even using it, and things that look the same should do the same thing |
| 14 | | - Limitations of the technology (backend) should be incorporated into the gui in a suggestive manner, in order to not create false expectations or misunderstandings |
| 15 | | [[br]] |
| 16 | | Until now, it seems the best ''approach'' to meet all these requirements is this: |
| 17 | | - The starting point for the user should always be the '''home environment''' - the page that comes up directly after login, from where the user can open and manage the different workspaces, communicate with other users etc. |
| 18 | | - The home environment should be a block on its own. |
| 19 | | - The whole workspace consists of a '''stack''' of blocks, compiled by the user during his work |
| 20 | | - blocks can be added to the stack, closed, minimized (hidden), manually arranged; the stacks should be persistent, even savable |
| 21 | | - Work done in one block - object type e.g. a View - that implies changes to another object - possibly of another object type, e.g. a Table - directs the user directly to its own, separate block (e.g. by opening it and/or scrolling down to it). [[br]] This ensures that the users know what they are doing (if one for example wanted to change data inside a View, the actual changes would have to be done to the Table since the View only assembles data from different Tables; hence it would make sense to open a new block for the affected Table underneath the View-block, and directly jump to the line and column to be changed, then let the user make the changes there, and on confirmation of the changes show what happened to the View) |
| 22 | | - A set of distinct, suggestive icons is used for the different object types and actions; text on buttons should be reduced to a minimum, graphical buttons with tooltip-text cause the least visual "white noise", especially compared to textual buttons. |
| | 24 | |
| | 25 | == Philosophy (old...) == |
| | 26 | The philosophy for the interface is as follows |
| | 27 | - conceptually separate objects (tables, views, maps, searches ...) get visually separate representations, for sakes of clear communication, called "'''blocks'''" |
| | 28 | - since it will not suffice to separately work with each "block" on it's own, the user must be able combine blocks in every imaginable way and number |
| | 29 | - the interface either visually or textually guides the user toward his own goal without intterrupting the workflow or visually distracting the user |
| | 30 | - Every block can be a starting point for the users work. |
| | 31 | - visual consistency ensures that the users knows what everything that is visually represented does, (in many cases) before even using it, and things that look the same should do the same thing |
| | 32 | - Limitations of the technology (backend) should be incorporated into the gui in a suggestive manner, in order to not create false expectations or misunderstandings |
| | 33 | [[br]] |
| | 34 | Until now, it seems the best ''approach'' to meet all these requirements is this: |
| | 35 | - The starting point for the user should always be the '''home environment''' - the page that comes up directly after login, from where the user can open and manage the different workspaces, communicate with other users etc. |
| | 36 | - The home environment should be a block on its own. |
| | 37 | - The whole workspace consists of a '''stack''' of blocks, compiled by the user during his work |
| | 38 | - blocks can be added to the stack, closed, minimized (hidden), manually arranged; the stacks should be persistent, even savable |
| | 39 | - Work done in one block - object type e.g. a View - that implies changes to another object - possibly of another object type, e.g. a Table - directs the user directly to its own, separate block (e.g. by opening it and/or scrolling down to it). [[br]] This ensures that the users know what they are doing (if one for example wanted to change data inside a View, the actual changes would have to be done to the Table since the View only assembles data from different Tables; hence it would make sense to open a new block for the affected Table underneath the View-block, and directly jump to the line and column to be changed, then let the user make the changes there, and on confirmation of the changes show what happened to the View) |
| | 40 | - A set of distinct, suggestive icons is used for the different object types and actions; text on buttons should be reduced to a minimum, graphical buttons with tooltip-text cause the least visual "white noise", especially compared to textual buttons. |
| | 41 | |
