The user interface will be central to the success of the Thingk.com site. We’ve gone through several iterations of user interface in an attempt to simplify how our users will persist their Thingks. After several iterations, I believe we have reached a concept that will achieve all the goals we set out to accomplish – I am codenaming it “Polymeric” – a nod to combinatorial chemistry (more on this later). This label may or may not make it beyond the source code and this blog/design meetings, but it usefully describes what is going on: I want the user interface to not only assist those who have a Thingk ready to persist without getting in their way, but also those who are searching for a solution in a combinatorial manner (where the site becomes a source of information, components, and inspiration as well as a persistence mechanism).
Polymeric finally admits that the user interface should get out of the way of the user – that the best expression comes out of the user if they are guided and prompted along but in a non-intrusive way. At the core of Polymeric is the ContextProvider – the context is used to provide suggested components, prompted questions, and directions for exploration. The ContextProvider works at three levels : what the user has done before (what Thin(g)(k)s* they have created, what Thin(g)(k)s have inspired them, as well as the components of each), what they are doing right now (the current word they may be trying to type, what question they are answering), and where the engine can infer they are going (via pattern matching of current text we can infer related directions for exploration).
*: Thin(g)(k)s means Things, Thinks, and/or Thingks (or any combination thereof).
At the center is the Polyermic edit box – a text editor (with optional rich editing functionality but this is hidden away and only appears under certain circumstances) which is fed by and feeds the ContextProvider. At the moment, we are planning to have users use WikiWord format to denote Thin(g)(k)s across the entire site – it is just a format that works well. The ContextProvider loads several layers of information, but the first layer of information is a static list of WikiWords (that is, pointers to Thin(g)(k)s) which the user has had contact with (either by creating, being inspired by, or using as components in their other creations), primed for usage in this context. Let’s look at the post I am writing currently on this blog – four WikiWords are at play and only three are Thin(g)(k)s. The Thin(g)(k) WikiWords are : “ContextProvider”, “Polymeric”, and “Thin(g)(k)”. I’ve repeatedly typed all three manually throughout this post, but if I was editing this post in Polymeric in the actual Thingk.com web site, these words would have been suggested to me. This due to the first and second layers of information: “Polymeric” and “Thin(g)(k)” would have been loaded in context in the first layer (as my creations and/or creations I collaborated with others on), but the moment “Polymeric” was suggested to me and I picked it, the ContextProvider would have loaded all the components of the Thingk “Polyermic” into context, including (but not limited to) the “ContextProvider”. And one of the other Thin(g)(k)s that would have been loaded is a reference to a project which inspired context suggestions and must be payed homage to: GoogleSuggest. GoogleSuggest inspired many people as an autocomplete mechanism to use Ajax to give suggestions based on user inputs, but this is in the context of one singular input, whereas we will suggest individual parts of a larger body of text – this is of course nothing revolutionary – you can see the same feature on your cell phone. The difference here is that a Thingk, behind the scenes, will be a RDF resource that follows the ontology defined for Thin(g)(k)s at the PatternSmithing Alliance, including linkages between Thin(g)(k)s at the RDF level. Like most semantic web applications, we would never dream of having our users manually hand-type RDF; however, by choosing one of these WikiWords, the text of the Thin(g)(k) is not the only persisted but also the relationship/link to the Thin(g)(k) itself. This was the crucial problem to solve – to give the user an intuitive mechanism for forging these relationships.
The Polymeric user interface has an additional set of features which are fed by the ContextProvider. Several of these are based off the usage of WikiWords – for instance, it is possible to use a WikiWord for a Thin(g)(k) not currently on the site (for instance, my mention of GoogleSuggest would have started the process of creating an authorative reference on the site to Google’s project, pending Google’s permission to create such a thing) as well as suggestions to the user to turn a repeated pattern of text into a WikiWord and therefore a Thin(g)(k) on the site. Additionally, the outer borders of the user interface will have bits of context floating in based on what is going on inside the editing area: a cloud of moving WikiWords that can be grabbed and dragged onto the editing surface that changes over time, and prompting questions that fade in and fade out to guide the user to starting or evolving their work.
Once we open up the private beta, we will be soliciting feedback from some of you, so please contact me at http://xri.net/=joel.kotarski if interested.