SwanKit 2.0

[drernie]

I believe we should implement SSK via a "SwanKit 2.0". That is, we should build it using the next generation of our game engine.

This implies that we should again use Reactive Coffee as our HTML generation layer (though we may not need to use it as our data model).

The key differences are:

• We want to be a true single-page web app
• We need an actual datastore somewhere
• We don't need arbitrary programmability and a full GCI
• We are using a responsive Zurb Foundation layout rather than fixed-size #2

The workflow would be something like:

1. The user enters a URL: kioskme.net/username/sitename
2. The app downloads into a browser window
3. It retrieves the kiosk config file from the datastore using the username/sitename pair
4. It generates the layout and content for the first page
5. When the user makes a selection, it reloads new content (and possibly a new layout)
6. If the app is idle too long, it goes back to step 3.
7. User selections are tracked via local storage
8. There is a 'submit' phase at the end where the local selections are uploaded to the server
9. The server may return a customized response based on those selection, which should be displayed to the user.

In addition, we want to have an 'edit' mode where the owner of the app can update the contents, and perhaps even add new pages and layouts.

The key, it seems to me, is having a rich and extensible library of layouts, and a simple way to map content into them. More precisely, we need a UI description dictionary for laying out panes and fields and a normalized vocabulary for specifying content.

For our proof of concept we would need:

• advertising pane
• home screen layout
• multiple-choice Q&A layout
• multiple-choice rosetta layout for vision testing
• tabbed results panes

This implies a very simple (?) structure of components and bindings.

[drernie]

The primitive components would be something like:

• label / text field
• paragraph / text area
• media / drop zone

The central idea is that each component has both a "display" mode and an 'edit' mode. The bindings are bidirectional, so that it is easy to update the source (perhaps event functionally / copy-on-write a la react, to enable trivial undos).

This seems like it would map very naturally onto Reactive Coffee Components:

http://yang.github.io/reactive-coffee/tutorial.html#components

Components would be configured via a dictionary such as:

{
  kind: 'label'
  tags: ['class1', 'class2']
  source: json_object
  path: ' key1.key2'
  edit: false
  contents: 'placeholder' # if empty
}

There would also be composite 'list' and 'stack' components, whose contents are an array or dictionary of other components, respectively.