I clearly didn’t make myself hungry enough putting together the cupcake bakery mini-site for my prototyping talk last month, as I’ve spent the past few weeks polishing that prototype — and staring at chocolate frosting — in order to make that code a proper, release-ready framework. And I’m now happy to say… the 3-Layer-Cake Prototype is now ready for your (ahem) consumption!
The prototype builds on a technique I’ve actually used for many years, one I first read about in late 2004 in this Invasion of the Body Switchers article on A List Apart by Andy Clarke and James Edwards. I remember finding it instantly useful for a project I was doing at Coinstar, where I was tasked with developing an updated kiosk interface that could accommodate touchscreen and keypad interfaces, in either Spanish and English. Using IOTBS, I was able to create an interactive prototype from a single set of HTML pages that effectively simulated the various interfaces and served up different language content.
But it wasn’t until sometime last year, fiddling with WYSIWYG prototyping tool Axure and seeing their in-prototype annotations that I realized… hey, I could do that, too!
First I tried absolutely positioning individual labels over each page, something which was pretty effective, but slightly wonky cross-browser and -platform. Plus, it was incredibly time-consuming having to both position the labels (nudge, nudge – save – refresh x 1000) and create all the additional markup and CSS to support them.
Then I discovered CSS3 Generated Content and realized that it could be used to create an almost identical set of annotations, but in a way that was much simpler and scalable. In a nutshell, here’s how it works:
The Annotation Technique
- Elements bearing a class of “x” in the HTML page will be tagged with a numbered note, to be shown in annotations view.
And if the element has one or more classes already, just add it to the existing one(s), as multiple classes are A-OK.
- In the switch.css file that defines view-specific styles, a counter is defined for all elements tagged with the “x” class when in Annotations view.
- Then the counter is started, its results styled and set to appear as generated content before the start of each “x”-tagged element in Annotations view. From this, the note labels appear onscreen next to each of those elements.
- Finally, the annotations themselves are inserted into the notes panel in the HTML page, written up and formatted as an ordered list, with one list item for every “x”-tagged element on the page, in the order in which they appear in the code.
The notes and the annotations lists aren’t yoked together, so this is the only place where you’ll need to manually match up the count/order of elements to list items.
And that’s the heart of the annotations functionality, explained. You could (and should!) strip out whatever you don’t need, if, say, you want the annotations without the complete 3-Layer-Cake Prototype framework. Non-commercial re-mix and re-use is very much encouraged under the Creative Commons license under which I’m releasing this work. And if you end up using this and posting something online, please let me know, as I’d love to check it out!
If you’re in the Seattle area, are a web design or UX professional, and want to learn more about prototyping in code, come to the June Puget Sound SIGCHI meeting this Thursday, June 23rd. I’ll be speaking about prototyping, and much more — here’s a quick description:
When: Thursday, June 23, 2011 – 6:30pm
Where: Blink Interactive, 1011 Western Ave., Suite 810, Seattle 98104
Designing experiences using native web code instead can help us overcome those limitations and make us better designers. The process of building out our ideas in the same medium in which they will be implemented makes us better able to understand what is possible. In this presentation you’ll learn about creating interactive prototypes that will thrill stakeholders, designers and developers alike. We’ll review some of the ways of organizing information and creating rich interactions that can be done with code. We’ll also walk through specific techniques, tricks and web-based tools, many of which require no prior coding knowledge to start using. Through prototyping, you’ll get closer to both the finished product and to the designers and developers who will be ultimately translating and implementing it.
The event is free, and open to the public, though if you enjoy this event, you should really consider joining PSSIGCHI. (Check out the fringe benefits.) Hope to see you there!
While I’ve always loved learning, my attitude towards school was usually less than positive. My high school was certainly academically rigorous, as it was one of the top five in the state. But in its pursuit of that goal, my school celebrated and promoted a kind of achievement that was heavy on standardized testing and highly-structured classes set to guide young minds along a straight-and-narrow path into hallowed Ivy halls of higher learning.
It was a game, and a rather boring one, I thought. Learning in discrete blocks — French, then History, then Music Theory, then Math — with each subject in its own separate silo, a student’s competence (or lack thereof) in each area helping to nudge that person into a specific collegiate track. But I wanted French AND History, mixed together. The Science of Music. Peanut butter in my goddamn chocolate.
So it’s hardly surprising I was drawn to the early Internet, where a mid-90s web job consisted of a little Perl scripting, a little graphic design, and a whole lot of making-shit-up-as-you-go. Need to promote the new Frank Zappa album with some 30-second song samples? No problem, boss! Teaching myself how to encode, optimize, upload and embed audio files, all long before the era of online tutorials and YouTube video how-tos… well, that was just all in a day’s ]webmastering work. The means were largely irrelevant to the end goal of creating something cool for the user. (And yes, online audio, even in 30-second bursts, was pretty cool back in the Internet Stone Age, circa 1995.)
It took a number of additional years for me to figure out that it was the “creating something cool for the user” part of what I did that interested me most. And so, like a lot of people, I started specializing, concentrating my skill development in the area of user experience accordingly. But I always hung on to the coding know-how, and some of the design theory, always trying to learn more about those disciplines from job to job.
Folding these newfound bits of knowledge into my work, and practicing new techniques, I found that I was:
a) creating even stronger and more fully-realized solutions, and
b) making some people a bit confused, nervous, or both.
Through years of experience, I had specialized myself into a fairly tightly-defined role. And doing something that is not in your job description — something that is, in fact likely part of someone else’s — can prompt a reaction not unlike that of my poor high school guidance counselor upon her being confronted with my proposal for a semi-self-directed course of inter-disciplinary study.
In spite of such hurdles, I’ve been lucky enough to work with a number of other web hybrids: developers with an eye for design, database architects passionate about taxonomy, and visual designers with a flair for information architecture. And you know what? Those extra interests made those people especially engaged and invested in the final product, which benefited greatly as a result. In fact, a few months ago one of the first YouTube developers wrote this great blog post about hiring front-end engineers, in which he highlights the value of potential candidates who possess artistic interests and/or UX and design skills.
So here’s to all the interdisciplinarians, the not-easily-categorized, the hybrid web workers. By connecting our interests together, we’ll always end up creating something cooler for the user than if we’d stayed between the lines of our own roles.