I’ve been traveling the conference circuit this summer, talking about New Wave interactions like CSS3 animations and the Web Audio API. One of my favorite things about this experience (aside from finally getting to travel to different countries) is meeting people who have been trying to do the same things and seeing the different ways they’re solving some of the same problems. But some problems keep coming up during the Q and A segment at the end of my talks:
Yes, there are tools like Adobe’s Edge Animate and Sencha’s Animator. And they are certainly useful. But the problem with using a proprietary visual interface while building these interactions if that you will always be limited to the state of the art its developers and maintainers choose to implement. For instance, I’m working on a project where I want to put a little WebGL in, just for funnzies. If I used an animation program that didn’t support webGL features, I would be less likely to imagine working outside its constraints, and even if I did think outside my UI, I would probably be unable to implement something so avant garde and foreign inside that user interface.
User interfaces, while they can free you up to do many things visually, also tie you down to their creators’ methodologies, abilities, and ways of thinking. Right now we have so many exciting ways we can tell stories in the browser. It seems premature to adopt a program that takes away all that magic.
I have a huge interaction I want to build, and I know how to sling code. But managing all these assets gets complicated very quickly. Isn’t there a tool to keep them under control at least?
This is a reasonable complaint, a problem I have encountered on my own. While we do have tools like Sass to help with managing lots of CSS, there are some tools that we don’t have but desparately need:
- A way to convert onion-skinned PSDs to sprite sheets
- A way to scrub through animations to check timing on longer sequences
- A plugin for Sass to handle animation timing (I’m working on this)
- Polyfills for browsers that don’t support animations
(There are more, and please feel free to respond with what would help you out!)
All of these tools could stand alone, working directly in your browser or from the command line. We wouldn’t need to build the entire interaction in one program. Rather, we could build it in the browser with several tools running alongside, depending on what we need for the situation.
I approve of this Tool Belt approach: It’s lightweight, modular, and encourages people to learn more code than they would if it was all being written for them behind the scenes. It might even scale better for production environments with multiple teams! But it’s not an out-of-the-box solution/empowerment for those with no code background.
At first I thought, “Interaction should be like a craft, not something a WYSIWYG program delivers into your lap.” Aren’t we all crazy about “craftsmanship” these days? Craft beer, craft nights, handcrafted goods. Why should code be any different? Get a text editor and put your fingers to work!
And this brings me to one final thought. At Gotham JS’s afterparty, I had a conversation with a young man which left me thinking. Right now, we don’t have many of these Tools. Those that we have leave us “working blind.” That is, we make a change, refresh the browser, wait to see the change, repeat. We have to do a lot of math and calculations by hand to get it right. Math and calculations are what computers are best at. And humans, especially the artists who have those Big Interaction Dreams, are great at visual and audio analysis. Wouldn’t it be best if we could see and hear those interactions while we build them? And that’s where the Tool Belt approach fails.
Crafters of experiences
I do feel there is a place for a special breed of experience designer/developer in the web development ecosphere. I also strongly feel these people will come from unexpected places, places that have a pedigree for delighting people, like animation, cinema, comics. But in order to get their ideas, we have to make some accomodations:
- Better tools for excited creators. It behooves us as a development community to build the tools these creators need to work quickly and efficiently and better understand their code. The alternative is that we let privately owned companies with their own code standards empower these people to create according to a narrow definition of interactions.
- More collaboration. I’d like to see more non-developers being dragged to hackathons. You can get starving artists to come to an event with free beer and pizza. But you have to reach out to them, and you have to know how to talk to them (which is the topic of another post, but the gist is: ask to work on their ideas instead of your own—it’ll be good for both of you).
These are just some ideas I had and some things I’ve observed. I want to know: what do other designers and developers think? Can we come together to build exciting things, or will we always need to look to so-called unicorns? Can and should we train people to work on these things by hand, or is it better to just let the programs do the work for us? Is it better to craft blindly or design visually?