Recently, I've been spending time developing a series of scripts previously created for specific projects, and amending them, and turning them into general tools intended for use by the entire office. This means intended for use by novices and experts to Grasshopper alike. Somewhere along the way, the exercise became a investigation of a design scripting philosophy with the focus being the following questions: how can I write scripts or tools which are easy and intuitive to use by novices, and at the same time satisfactory and conducive to addition and amendment for advanced users? This was the more high level question, while the more direct, practical question was: how do I combine our various tools into a workflow that make sense in the broadest imaginable application. I will discuss the latter question in another post, but let's focus on readability and usability here.

The most common mistakes I see in GH scripts (and that I used to make myself) are a) that the canvas is a mess, b) the canvas isn't a mess but is still overwhelming due to size or complexity or c) the intention, input and output of the script are not clear. Assuming that you are not creating scripts with the explicit intention that you and only you (and possibly not even you in 3 months time) will understand what is going on, it is critical that the you, the creator, are able to distill the script into bitesize, manageable pieces AND that you ensure that the input/output of the script are understandable at a glance. Groups, colors and titles helps with this. Canvas positioning even more so. Just like how most drivers know how to rotate the wheel, change the gears and follow the road infrastructure, but are happy and probably better off leaving the inner workings of the engine to whoever built it, so should the new user of your GH script be able to at a glance identify exactly which parts of the script are worth spending his precious time understanding and controlling, and leave the rest of the script to 'just run'. This can be difficult though, and mixes in the question of how much control to give the user. When I started using GH, the ideal was that the user controlled EVERYTHING. These days, I sit at the opposite end of the spectrum, looking for no more than 3-4 inputs from the user. Anything more leaves the user confused and overwhelmed, like restaurant menus with too many options. If they want more or different, they can either formulate more precise wishes for the script, or if possible, make the necessary adjustments themselves. So, much as in other areas, true knowledge shows in the ability to express complex concepts and ideas in simple terms for the uninitiated. What is actually going on? What is important, and what are details?

Playing with colors, layout and wires can go a long way, but what really pays off is if your code itself lead the user by the hand.