Most programs tend to follow two schools of philosophy in their design, one that I’m going to call ‘scriptable’, the other, ‘visual’. Those in the ‘scriptable’ camp tend to come from a unix background where being able to use pipes to direct input and output into different programs provides a simple, yet very powerful paradigm. Those found in the ‘visual’ camp tend to come from a windows background where almost everything has a GUI, and people mostly use a mouse to execute the functions.
Of coures there are different advantages and disadvantages to both approaches.
For example, discovering functionality in a ‘scriptable’ program is often not obvious simply by executing it. Without the program providing well written, detailed documentation and addtional examples, an end user can spend considerable time discovering how to do something trivial, rather than simply do it. Remembering special codes or parmaters, or the order it expects them in can be considered especially tediuous. Of course, the benefits of the having this interface allows the program to be automated as part of a larger job. The power of this approach is particularly useful for system administrators who may need to do something as part of a common job, or for developers who don’t want to reinvent the wheel.
The ‘visual’ approach, on the other hand, requires less documentation as long as the interface is easy to use and intuitive to the user (although this is often not the case). For people from a less technical background, using a ‘visual’ manner for discovering behaviour is a powerful paradigm and sometimes the user’s only option given their individual set of knowledge. Unfortunately, using this approach in isolation also means excluding the possibility of automating any functionality provided (or at least making it significantly more difficult).
I see people unconsciously make the choice between these two modes all the time. If I was to generalise, Java and Rubyists tend to gravitate towards the ‘scriptable’ interfaces (providing libraries, jars) while a lot of .Net people tend to gravitate towards the ‘visual’ (providing exes).
My preference for writing applications obviously leans towards a mixed approach where I would always want to prioritise the ‘scriptable’ interface above the ‘visual’ one. My thinking here is that the ‘scriptable’ interface should give enough separation between the functionality and the way an end user interacts with it that the ‘visual’ interface should be easy to drive out. In my experience, doing it the other way around leaves people coupling a lot more of their functionality into the graphical user interface, often making the ‘scriptable’ interface more difficult to extract.
Don’t get me wrong, as an end user, I almost always want a user interface for things that I’m going to do very infrequently. The developer in me also wants assurance that, in case that infrequent becomes frequent, I have the easy option of automating it later.
I also think that those two approaches are actually not mutually exclusive. It has more to do with the way we do UI. Essentially I think the UI should be a very thin wrapper around the application layer (or presentation model, if you prefer that expression). Time and again I see people calling from their presentation model into the view layer.
Watch out for the typical excuses: “I just have to set the initial value”, “My presentation layer doesn’t know about the actual UI, there is an interface in between”.
This of course is killing scriptability and testability at the same time.
Hi Felix – I also agree that these approaches aren’t mutually exclusive. Rather, most people seem to prioritise the visual over the scriptable without any conscious decision, and the result is a useful application but only accessible with a mouse!