Modular User Interfaces
Hey, I am thinking about modular user interfaces.
Note, I didn’t say “modular user interface components”. The difference is that modular components allow developers to build things easily… but a modular user interface allows the user interface to be recombined, not necessarily by developers.
One thing that gets fairly far along this road is drupal. You could build many sites just configuring modules with drupal. You could probably build loomio, and you could build something that did basically what patchwork does, it wouldn’t be decentralized.
But, modularity is another kind of decentralized. Because a user interface system like patchwork does have a very real sort of centralization in it. there is only one version. Sure, you can run your own fork, but then you are out in the wilderness, not a first class citizen of the polis.
i’ve been on a journey experimenting with modular app “frameworks”, i’ll see what i can share about my learnings.
what big did well:
- uniform descriptions for domain models and business logic
- never write CRUD again
- you describe your services (“resources”) as typed properties and methods
- you “reflect” these services over interfaces: HTTP, WebSocket, HTML forms, Markdown documentation, etc
- automatic admin interface (like Rails admin)
- if this, then that
- each service has before and after hooks
- each service is an event emitter (you can do
some other experiments:
- the Open App Ecosystem, as a collaborative ecosystem of social apps that play well together, now the Collaborative Technology Alliance.
- @bhaugen’s experiment with a user interface as a visual programming language, similar to MaxMSP / PureData for music but for socio-economic systems. described as a visual explorer for networks of objects of different types: start with any object, arms appear for possible connections, click on a hand to surface the object on that connection, keep going.
- holodex, where Simon and i experimented with a natural language interfaces based directly on tabular data.
- linked data browser, where i experimented with a “follow-your-nose” interface to the web of RDF-style Linked Open Data. the idea is similar to Holodex but tried to do it in a generic way, you click on an object, it becomes the center and any outward links are fetched, any queries (filters) become a natural language sentence, every piece of data has a respective type (with sub / super type relationships).
- nocms, where i experimented with a new architecture for content management. the idea is just how you edit your content as data, you edit your interface as data, then connect your interface with your content, and everything change is an action in an append-only log for easy time travel (sometimes clients won’t edit things for fear of breaking something). here’s a more popular attempt in maybe the same direction: relax.
from the above, i’ve learned:
- social interfaces are often more important than technical interfaces
- interfaces should render live data
- interfaces should be based on activity
- interfaces should be link data across sources
- interfaces should be fractal, both in terms of “zoom” (amount of detail you see) as well as “modularity” (i can write an interface that you can compose into your interface)
- … probably some other things, i’m just writing this stream-of-consciousness style
lately, i like the common idea found in yo-yo, tom, Elm, and more.
a user interface view is a render function that receives data and a dispatch function (to call with any action objects) and returns user interface elements.
in this way, user interfaces can be composed together into a single app render function and are then only called once to pass in data from the top and any actions are sent up, which updates the data and so forth.
i reckon composable unidirectional data flow (data down, actions up) with a single state object (as in a redux store) is preferred to any two-way data-binding or fancy sub render loops and such. it’s far easier to debug, implement time-travel, write tests, compose modules, etc.
lately i’ve been using some of these ideas as a philosophy behind
in my latest obsession with types, i’m experimenting with tcomb-view, where i describe states and actions as types, and attach “views” (generic interfaces as a virtual dom render function) to these types. for example, t-color is a type and respective interface for colors. my plan is to build up an ecosystem of these types (domain models) and views (generic interfaces), so we can then easily piece together user-facing interfaces and generate any backend services from the types.
anyways, super keen for modular user interfaces! i wonder where the journey will go next. :fireworks: