Web App GUI

Table of Contents

  1. GUI Principles
  2. Design and Layout
    1. Graph View
    2. Node View
    3. User View
  3. Node Page Sketches
  4. Node Page Functionality
  5. Queries
    1. For a node, show…
    2. For a behavior, show…
  6. Colors

GUI Principles

Design and Layout

The web app is composed of four pages:

  1. Graph
  2. Node
  3. User
  4. Account

Graph View

Graph view is the user's portal into selecting a node to explore, as well as for adding new nodes and new relationships between nodes.

Components (in priority of implementing):

  1. List of all nodes (should be tree, should be at different scales (zoom?)) 1a. Selection box for viewing some info about what is currently selected.
  2. List of all tags (should be tag cloud) (Is this within the Selection box or within the list of nodes or seperate?
  3. Search box for finding nodes by keywords in label, tag or description

Actions

  1. Add node (must identify parent(s))
  2. Add edge
  3. Remove edge (vote to remove edge)
  4. Weight edges (weighting edges (counts as an action in that requires a feather spent to do more than one.))

Node View

(aka node-centric.html)

Node view presents all information about a node.

Components (and Actions):

  1. Node information
    1. Label
    2. Tags
    3. (Add tag)
    4. Description
    5. More information?
  2. Parents
    1. Each parent
      1. Label
      2. Rating (+#)
      3. #Behaviors
      4. #Arguments
    2. (Sort)
  3. Children
    1. Each Child
      1. Label
      2. Rating (+#)
      3. #Behaviors
      4. #Arguments
    2. (Sort)
  4. Behaviors
    1. Each behavior
      1. Label
      2. User and date of creation
      3. Evaluations (+#)
        1. Relevant/Irrelevant (attachment to node)
        2. More evaluations?
      4. Description
      5. Rating (+#)
      6. (Rate)
      7. (Attach this behavior to a different node => remembers this behavior in the toolbar)
      8. (Write a new argument to this behavior)
    2. (Sort)
    3. (Add behavior to this node)
  5. Arguments
    1. Each argument
      1. Subject
      2. User and date of creation
      3. User's vote on the behavior this argument is attached to
      4. Evaluations (+#)
        1. Logical/Illogical
        2. Biased sources/Objective sources
        3. Well written/Poorly written
        4. More evaluations?
      5. For/against a high rating (or target rating)
      6. Content
      7. (Reply to this argument)
    2. (Sort)
  6. Toolbar
    1. Remembered behavior
    2. Forward/Backward (advanced feature)

User View

(aka user-centric.html)

  1. User info
    1. Points
    2. Level
    3. #Feathers allocated/unallocated
  2. Rated behaviors
  3. Written arguments and responses

Node Page Sketches

The server (dev) website is manually kept up to date with commits. We could add to the post-commit script an svn update for the (dev) website.

Check the server prototype or your local checkout for a general picture of the prototype.

The essential characteristics of the GUI are:

  1. Three primary pages
    1. Node - displays node (company/product/group) information, including parent/child navigation and behavior/arguments
    2. User - displays user preferences (email, phone-number), profile (dimension weights) and impact
    3. Graph - provides a way to navigate/search the node graph. possibly overlaps 'graph view' components with user impact.
  2. Pages are composed of a header, middle and footer. The middle contains some number of blocks
  3. Blocks - view of conceptually similar data (eg, a node's behaviors);
    1. Block positions are stationary. However, blocks can be vertically minimized/maximized and horizontally crushed/uncrushed
  4. There are two forms of data functionality
    1. Data manipulation - sorts (return reordered list), filter (return smaller list)
    2. Data entry - forms and validation

Relevant implementation details:

  1. Modular components reflected in code
    1. Every block has its own html/template file, which may include other html/template files
    2. forms and validation

Node Page Functionality

Block name Description Sorts Filters Forms
Parents
Children
Node info
Behaviors
Arguments
Toolbar

Block movement commands

  1. Toggle top row - minimize or maximize Parents, Children and Node info
  2. Toggle Arguments block - minimize Node info, crush all other blocks so that Arguments fill the space

Queries

(todo: update/cleanup/move/remove)

Queries can be sorted, filtered and categorized. A sort reorders the elements; eg, most popular behaviors. A filter selects elements; eg, the 10 most popular behaviors. A category partitions elements; eg, behaviors by user.

Filters and sorts are often used together. A good example is slashdot's comments technique, which organizes comments by thread, orders comment siblings by date, and filters out unpopular (poorly evaluated) comments.

Slashdot has introduced neat additional features.

  1. Comments can be full, abridged and hidden. Abridged comments show as much comment body text as will fit on one line, which solves the fact that subject lines are rarely over written, thus making the discussion flow faster to browse.
  1. Users can use a slider to toggle the full/abridged, and abridge/hidden boundary. The space is not continuous, but dynamically depends on other factors (depth? popularity?).

Our goal is to allow users the option to customize the way that they view the database. To this end we should allow users to dictate to what extent they'd like things sorted by overall popularity, by transitive trust (ie, I trust what other users that I trust and to a lesser extent the people that they trust have to say), and by biographical and dimensional preference similarities. What computational limits does this create? Would an Endeca app be better than what we could come up with on our own?

For a node, show…

all behaviors
behaviors by user
behaviors by ratings
behaviors by tags
most popular behaviors
most recent behaviors

For a behavior, show…

all arguments
most popular arguments
most recent arguments
arguments by pro/con
arguments from trusted users
arguments by user profession (or some other user property)

Colors

color       R,G,B decimal       #HEX

light blue       219,240,237       #DBF0ED

dark brown       85,79,64       #554F40

dark brown 2       r,g,b       #442200

medium brown       156,146,108       #9C926C

light brown       202,190,140       #CABE8C

light brown 2       r,g,b       #EEEE88

dark green       50,101,54       #326536

faded black       22,22,22       #161616