This was my first week dedicated mostly to working on Unison. Before getting to my update, I’ll give a bit of background on the Unison architecture. There are two pieces:
This week (and likely this entire month, if not longer), I’m focused on building out the Unison editor. In terms of the actual coding work, I built out the explorer UI component which will be used to provide type-directed autocomplete when a cell is selected for editing. There are a few libraries out there for doing this sort of thing (like Twitter typeahead), but writing custom UI components is pretty easy in Elm and gives me exactly what I want, so that’s what I did. Writing a component in a purely functional way forces you to be extremely explicit about what your state is and how it gets updated. For instance:
"Ali", then we deleted the
"Alice"should still be selected even if
"Albert"is now the first element of the list of possibilities.
In any case, I finished an initial version of a component that does all these things and am presently in the process of integrating that into the editor. I’d have loved to be able to show a demo, but that will have to wait until next week.
I’ve also been thinking through some details of the editor UX. Although I want the Unison editor to be usable by non-expert programmers, first and foremost I want it to be something I would want to use. I currently do all my programming in Vim, which gives me a wonderful sense of directness and control and which is extremely efficient for program entry and editing assuming you know how to use it well. Although a semantic editor has very different constraints, I want to preserve the overall feeling I get when coding in Vim and if possible improve upon it.
I’d like to write more about this in a later post, but my current thinking is that a semantic editor with a well-designed UX can actually be much more efficient than plain text entry. Simply put, the editor has much more information at its disposal, and can therefore disambiguate actions in ways that plain text editors can’t. Plain text editors are forced to have much larger command sets, since it has no information (namely type information and information about the language being edited) that it could otherwise use to disambiguate the user intent. Thus, the Unison editor has a very small, simple set of core commands, which is easier for beginners, while retaining the power and expressiveness of raw text editing. Of course, there is some serious work to come up with a thoughtful set of interactions to make the semantic editing experience just as fluid!
I say all this, but another one of my longer-term goals with the Unison editor is for it to be usable to do serious programming on a tablet. I have this dream of sitting under a tree with an iPad, doing real programming on a warm summer day. Doesn’t that sound nice? Again, because the editor has much more information, the user has less to specify, and we can avoid having to pop out the keyboard in many cases. This use case isn’t a focus for me right now, but I’m keeping it in the back of my head.
That’s my update for now, stay tuned until next week!comments powered by Disqus