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.
