wgc blog

One of the biggest problems inherent in working in a new field is that it often becomes very difficult to communicate concepts and ideas because the vocabulary around the domain has yet to evolve.

This has also caused several head scratching moments on the development side too, especially as we come to design user interfacing constructs. Up until now we have been largely able to side step these issues, as when building the proof of concept applications we always have the excuse that we are 'testing' the interfacing concepts as much as the technology.

As we move from prototype engineering into developing our first deployable product however, we need to really get to grips with the problem. Or do we? Maybe this is thinking about the problem in the wrong way.
The overriding philosophy of WGC is to simplify technology to the point that the end user doesn't have to acquire new skills or develop an understanding of the workings. This notion too should extend to the language around our user interfacing. So instead of trying to develop a vocabulary around the technical processes we have, for now at least, decided to base the interfacing around the end user's mental model of what they are doing and the everyday language around that. So 'authorization' becomes 'sharing with', 'remote resource orchestration' becomes some thing task specific such as 'record' etc.
In all likelihood we will find that our predicted mental models don't match exactly with the reality of useage, but this is what is so exciting about the beta testing process.

Now this may all sound pretty obvious, and indeed had we emerged from the lab a little earlier we may be somewhat further down the road, but in fact it is a lot more complex than that.
The flexible, extensible, evolving landscape of the ad-hoc grid means that the hard coding of these interfacing constructs become very difficult the moment we orient around a usage pattern which is context and not process related. Simplifying for the user means more complexity for us! In effect we have had to abstract the interfacing a further notional level from that of a traditional architecture - the interface is a living, evolving entity - not an ever changing sub set of some pre-ordained system parameter matrix. And, we finally have a grasp on it!

Most interfaces 'ask' users what they want to do by presenting various options to them through icons, buttons, menu items etc. This doesn't really work in our domain, instead we have to get to a situation where the user can tell us in their own way what they want to do with the collection of resources currently available to them, and that collection of resources is something we can not know about at build time.
The realization of this approach will be somewhat limited in our first product of course, but we are thinking long term here.

It's the interest in problems like this that keeps the team together through all the stresses of living in a startup.