blogrium

I remember when programming was a fun thing to do in a silo. You know, building non-networked programs. I remember just sitting down to a BASIC prompt and saying, “What can I make on this thing?” I guess the equivalent of that today is building little desktop applications.

Actually, it really bothers me that I can’t remember what my first program was. I know I started programming young, but I had a fairly complex childhood (parents divorced early, lots of moving, etc) with lots of exposure to computers, so it’s hard for me to even get the timeline straight and remember when it happened.

I know once it did happen, I was hooked. However, just like today, I would rarely write something just for the sake of programming, or even learning to program. It always had to be part of some larger plan or was novel enough to spend my time on. Back then, it would be things like an address book on the Commodore 64 (not very practical), but I vaguely remember some sort of crackpot idea to somehow monetize it.

Slowly, the idea of programming has become more and more profound to me. The concept of virtualized automation has somehow struck a chord in me. So I try and share this idea with others and encourage people to program. The thing that’s been the hardest for me is coming up with inspiring examples of programming use cases that don’t require some sort of bigger picture. Obviously, the simplest examples would involve making the things you already do on the computer easier.

Unfortunately, a lot of effort has been put into making all the common uses of the computer easy enough for most people to use. Most people don’t see an advantage of learning something “scary and complex” like programming just to make it slightly easier to do what’s already easy enough.

Even I ran into a sort of brick wall. Around middle school, I got bored with writing useful desktop applications because most of them had already been written! So I put more energy into games, which was a very different kind of software development and leads us into a whole different topic. But the point is, programming in a silo (desktop applications) gets boring after a while because there’s only so much you can do for yourself with yourself and a computer.

Not surprisingly, I started getting interested in the web around this time. It was just starting to get commercialized, and my dad decided to start a web hosting ISP (but back then little shops like that would do a little of everything). I was exposed to cool stuff and cool people that would teach me things. I don’t think I realized the full potential of the Internet at the time (though I dreamed of building a virtual world MMOG and network based AI before I really understood those things), but I was definitely fascinated and saw something powerful.

Since then I’ve kept on doing some form of web development. My fascination with the idea of programming and software development has taken me all over the place (including all-encompassing systems theory), but combined with my drive to automate automation (making the software developer’s life easier) and to inspire and encourage others to program, I’ve found myself especially drawn to end-user programming, high-level programming, graphical programming environments, etc.

The web is an excellent place for these things. Just like how a fun computer game instantly has immense replay value because of a multiplayer mode, programming has much more potential to get attention when it’s about programming in a networked, social environment. Not just networked, but social– meaning the technical and UI barriers to a good social experience have been removed, which is just about where we are with the web.

So we have things like Ning, DabbleDB, and even Ruby on Rails paving the way to make it easier to build applications. Ning in particular with their focus on social applications. IBM Research is working hard on end-user programming ideas. I especially love the game industry (for many reasons beyond this) because they’re doing great things building tools for users to mod games, augmenting player abilities with generative systems like in Spore, and I believe you can write programs and games within Second Life.

Apple, everybody’s favorite master of user experience, built an application for OS X called Automator that lets you automate tedious tasks that, even with all our progress in making the computer easier to use, are still just too tedious (and they cleverly use a robot metaphor to convey the idea). Essentially it’s a friendlier programming environment on top of AppleScript.

I don’t know if you’ve played with AppleScript, but it’s a very, very useful language. It’s sort of a glue language that you can use to make your existing OS X applications work together, effectively allowing you to build meta applications.

I think Automator and AppleScript are a great effort towards encouraging end-user programming. I think they’ve done a pretty good job with it, but this concept could be so much more.

What if we had an Automator for the web? What if (and it practically already is) JavaScript was the AppleScript of the web?

The idea being, now that we have all these great web services and web-based applications, and we’re starting to open them up a little with APIs, how do we string them together? How do we pipe them togther like you can with programs on the command line?

YubNub was an interesting experiment in this direction, and while it is useful, it’s too true to the command line idea to fully take advantage of the web as a medium. For one, it’s command driven, and the web has the potential for so many more inputs than arguments to a command. The web is also persistent, so it can do things behind the scenes and needs a way to keep on working for you while you’re away.

Picture something that looked like Automator, but instead of desktop applications, you see web applications. You can build web forms for any step of the workflow that you can either go to directly, or be emailed to you when the workflow gets to a step that requires input. But why just you? This is where we take advantage of the Internet. Your workflows could involve other people, maybe strangers.

Of course, this goes hand in hand with web hooks, which is the piping mechanism that the web needs so much.

Anyway, I was hoping my story would build up to something of an epiphany for you, but knowing me, it’s probably still all in my head. I just figured I’d write about it, since it can take me over 6 months to build a prototype sometimes. And I still need to write about the automated technology development idea!

As a last bit that might inspire some more relating to all this, I finished an alpha of Mailhook.org, an interesting use of the web hook pattern to make receiving email in your web applications (or building entirely email based applications) so much more easier and accessible.

This entry was posted on Wednesday, December 27th, 2006 at 3:04 am and is filed under Web, Design, Abstract. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.