● Simple “workflows” or “platforms” that can be invoked like parts, such as: presentation, browser/navigator with visualization, sketching, programming.
● Time-managed components consisting of morphic views with model state stored in a time-stamped database.
● Build-your-own database allowing the construction of and extensions to simple personal databases. A first run at this using tagging as the key semantic component appears in http://lively-web.org/users/Dan/BYO.html
● A graph database of people, projects, scrum notes, etc. for viewing CDG or similar organizations, with specific added leverage from Stanbol and context enhancement from web-savvy agents.
● Fabrik-like pin connections for dataflow-like applications. Of particular interest here is synergy with a spreadsheet-like view of connections that allows for simple management of interstitial calculations. A proof-of-concept appears here: http://lively-web.org/users/Dan/Fabrik.html
● Build-you-own browser/navigator, featuring an architecture for facilitating widget-panel connections that could possibly extend into actual widget design. For example: http://lively-web.org/users/Dan/PanedWindowDemo.html
● Simple sketching environment for freehand drawings. The goal here is simplicity and ease of integration with the outer environment, including touch support and gesture recognition.
● Simple programming-by-example, using morphic actions as an onramp to programming, as suggested in Astrid’s screencast: https://www.dropbox.com/s/epf5xa0v2da2mp3/ProgrammingByExample.mov?dl=0
● Everything is a part, meaning that the basic morphic worlds in which you program, give presentations, or sketch, are all parts. If we push on this a bit it may lead to a cleaner view of what is Lively underneath, and how can all the other “workflows” be made simple and more modular.
● Can it all be smaller and faster? It is hoped that some of these small experiments may suggest how much of Lively might be simpler, smaller, and faster.