GUI

Roadmap

1. Create the "Portal" page and drafted webdesign
2. Setup the workspace mechanics
3. Create a basic "Account Home" block
4. Create a raw Table block with basic viewing/editing/creation functionality
   1. viewing Tables
   2. editing Tables
   3. creating a new Table
5. Create a Map block
6. Create a View block for viewing/editing/creating Views

Philosophy

The philosophy for the interface is as follows

• conceptually separate objects (tables, views, maps, searches ...) get visually separate representations, for sakes of clear communication, called "blocks"
• 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
• the interface either visually or textually guides the user toward his own goal without intterrupting the workflow or visually distracting the user
• Every block can be a starting point for the users work.
• 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
• Limitations of the technology (backend) should be incorporated into the gui in a suggestive manner, in order to not create false expectations or misunderstandings

Until now, it seems the best approach to meet all these requirements is this:

• 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.
• The home environment should be a block on its own.
• The whole workspace consists of a stack of blocks, compiled by the user during his work
• blocks can be added to the stack, closed, minimized (hidden), manually arranged; the stacks should be persistent, even savable
• 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).
  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)
• 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.

Concept

The main document is either the home- or workspace template.

Both these templates have a container object with the id "moduleslot" where the Blocks are appended on creation.

All div.block objects in this "moduleslot" can be dragged and dropped for manual arrangement.

The Blocks consist of a titlebar (used for minimizing, closing and drag&drop) which should contain information about the content of the block, a menu bar and a content area.

There are separate kinds of blocks for Tables, Views, Maps, searches etc., and they all should have an icon in the left corner of the title bar that identifies their content type.

Blocks are added to the moduleslot with the JS function "addBlock(url,id)" (blocks.js).

Technology

Most functionality of the GUI is implemented using jQuery (v1.4), and to this point, the following plugins are also used: ​ClickMenu, ​Facebox.