I’ve written three pieces now on a fictitious visual programming language. The goal was to tap into years of user experience work to come up with an approach that would significantly reduce the learning curve associated with programming. As I wrote in 2012:
Make this easy enough, and you might tap into an audience of “casual programmers” that use this to assist them in their daily doings. No one’s come up with a successful programming analogue to the likes of Microsoft Access that appeals to the likes of secretaries and payroll officers. There’s room for one.
I’ve come to realize that my approach was flawed because I was getting the audience wrong. I wanted this to be for the everyday consumer, but was building it for programmers. I was conjuring a tool (the programming environment) that then made the tools (programs) that then accomplished a desired task. Only programmers care about making tools that do things. The average person just wants to do things.
So the idea then becomes to provide an environment for the user to automate tasks. To chain tasks. To provide a standard interface to the things the user uses. More along the lines of a graphical bash script. Skip this middle step of building tools. Now the things that a consumer uses on a computer is no longer confined to the hardware of the box on which they type: they store files Google Drive, post pictures on Instagram, make a note on Twitter, etc.
The file and standard input/output are no longer the standard mechanisms of interchange. You now have these web services, with their own authentication schemes and APIs. This has to be accounted for and handled by the programming environment, such that what comes out to be accessible to the user can in fact be chained to other components.
Access to different elements – the device’s GPS and onboard camera, Twitter, a file – would for the consumer be treated the same way. Oh sure they might have to plug in their Tumblr username in the little widget representing access to that service, but what comes out would be in a dictionary format consistent and the user wouldn’t have to worry about implementation specifics. For the consumer, it would be no more complicated to read a post from Tumblr as it would be to read a local file.
In the flow-based programming model, each of these elements would be its own block. Consumers could import blocks to access more services. Perhaps some of these blocks would be available for purchase from third-parties. The block that plays a music file might be part of the free base package, but the one that uploads to SoundCloud might be $0.99. The programming environment would merely serve as the framework to chain these blocks together.
So what kinds of things would you build with this? You could have for instance:
- When it’s 6pm, publish this note to my blog.
- When I’m at this location, send an SMS to my friend.
- When I take a photo, save a copy to my online storage.
- When my work sends me an email, send this automated reply back.
- When I press this button, I want you to do that and do this thing.
I think that’s how you get closer to a product that’s more accessible and bring programming to the masses. It’s also well suited to the low-level of complexity that have defined tablet/mobile interfaces. Is it still programming in this case? I’d contend so.
Adopting this model means foregoing the flexibility and power of a general purpose programming language. That’s okay because we’re minding the audience and building a demand for programming tools where none existed. That’s a good thing. If its limitations are ever an issue, then the user will always be able to jump to something better suited to their expanded needs, like Python.