drossbucket

[This was originally part of the previous post, but is separate enough of an idea that I spun it out into its own short post. As with the previous one, this is in no way my area of expertise and what I have to say here may be very obvious to others.]

‘Inkscape GUI plus raw XML editor’ turns out to be a really interesting combination, and I wish I had access to this general style of working more often. Normally I find I have a choice between the following two annoying options:

• write code, no inbuilt way to visualise what it does
• use a visual tool that autogenerates code that you have no control over

Visual tools give you lots of opportunity for solving problems ‘by doing’, moving things around the screen and playing with their properties. I find this style of problem solving intrinsically enjoyable, and finding a clever solution ‘by doing’ is extremely satisfying. (I gave a couple of examples in the previous post.)

Visual tools also tend to ‘offer up more of the world to you’, in some sense. They make it easy to enter a state of just messing around with whatever affordances the program gives you, without having to think about whatever symbolic representation is currently instantiating it. So you get a more open style of thinking without being tied to the representation.

On the other hand, of course, visual tools that don’t do what you want are the most frustrating thing. You have no idea what the underlying model is, so you just have to do things and guess, and the tool is normally too stupid to do anything sensible with your guesses. Moving an image in Microsoft Word and watching it trigger a cascade of other idiotic changes would be a particularly irritating example.

You also miss out on the good parts of symbolic tools. Precision is easier with symbolic tools, for example. The UI normally has some concessions to precision, letting you snap a rotation to exactly 45 degrees or 90 degrees, for example. But sometimes you just want exactly 123 degrees, and not 122 degrees or 124 degrees, and the UI is no help with that.

Most importantly, symbolic tools are much better for anything you’re going to automate or compose with other tools. (I don’t really understand how much this is inherent in the problem, and how much it’s just a defect of our current tools.) I knew that I was eventually going to move to coding up something that would dynamically generate random shapes, so I needed to understand the handles that the program would be manipulating. Pure visual mucking around was not an option.

Unusually, though, I didn’t have to choose between visual immersion and symbolic manipulation, at least at the prototyping stage. This was a rare example of a domain where I could use a mix of both. On the symbolic side, I understood the underlying model (paths and transformations for scalable vector graphics) reasonably well, and wasn’t trying to do anything outlandish that it would struggle to cope with. At the same time, it was also an inherently visual problem involving a load of shapes that could be moved and edited and transformed with a GUI tool. So I could switch between open-ended playing and structural manipulation whenever I wanted. I wish I got to do this more often!