In was the fall of 1994, and I was but a lowly intern at Salem, MA-based record label Rykodisc. Specifically, I was the “online” intern, primarily responsible for maintaining the label’s forum on the Delphi ISP1. Commercial online services like Delphi were essentially separate from the then-nascent web, and only the largest services had fancy, proprietary graphical interfaces. So Delphi’s forums were text-only, though ours had downloadable cover art, plus a few rudimentary sound clips. And since I had interned for Delphi that summer, I was already pretty comfortable with my forum management duties and was looking for a new challenge.
So while my boss Lars frantically tried to get us a spot on the then hip-and-happening online place2, I decided to attempt creating a page on this new thing called “The World Wide Web.” A Delphi co-worker3 had shown me a bit of the web a few months earlier, and I, like many others who stopped by his computer to take a peek, were immediately seduced. It wasn’t just that there were pictures, though that was indisputably cool. It was the whole, hyperlinked way of interacting with information, the self-published free-flowing-ness of it, which left the green-text-on-a-black-screen, press-a-number-to-select, BBS-style interface and walled-garden paradigm we were used to in the dust.
Armed with a SLIP connection4 to a local ISP and a 14.4k Modem, I fumbled my way around creating my first page, starting by viewing the source HTML code behind the web pages I visited, and pasting the contents into my text editor to mess around with and preview in my Mosaic browser.5 Then I bought a book, one of the first on HTML6, which helped me build upon the fragments of knowledge I’d picked up by trial-and-error.
And since creating a web page was free7, my boss was all for it, even if, as I warned, I wasn’t sure how many people would be able to view this page. It might only be visited by students and academics, the only large demographic groups likely to have Internet access. The vast majority of the online population then, including anyone using the major ISPs — AOL, Prodigy, CompuServe — still did not have access to the web.
What I did have: a collection of links to web pages for Rykodisc artists I’d gathered via web searches, digital album artwork scavenged from the art department’s file server (including that nifty Dan Clowes piece from a Ryko sampler CD), and witty, brand-appropriate copy written by Lars. That’s right, early web pages were all about the content, if only because there was precious little design one could apply.
But I did my best with the design, as well as the code. And it all came together in the page you see below, with historically-appropriate gray background added in via CSS prior to taking this screenshot. While I didn’t save the exact first iteration of that page, this one, from the very beginning of 1995, is essentially the same design and content. (You can also view a full-size version.)
It may not be a pretty web page, but it served its purpose and started me off on a path I continue to this day. Figuring out how to build something from nothing, even when I hadn’t a clue… that was heady stuff. And it’s one of the reasons why I continue to preach the power of prototyping to other UX and design folk. That is to say: I did it, and so can you.
1. Delphi’s two main claims to fame in the footnotes of Internet history: a) Edging onto the list of Top 5 nationwide Internet Service Providers, and b) Getting purchased around that same time by Newscorp, in one of their first in a string of ill-fated online forays.
2. AOL, of course.
3. Renowned writer Jimmy Guterman, who I also recall assisting in what would now be called his “liveblogging” of the Rolling Stones’ “Voodoo Lounge” tour kickoff for Delphi.
4. Serial Line Internet Protocal. Pre-PPP, yo!
5. This was just before the first Netscape beta was released.
6. Laura Lemay’s Teach Yourself Web Publishing with HTML in a Week (Sams Publishing, 1994)
7. Even — believe it or not — the domain registration at that time. Also free.
photo: P Hansen
My father took a lot of pictures. Photography was a hobby and, for a short while, part of his professional life while an engineer at Polaroid. I grew up loving the click-whoosh of an instant photo being taken, slip of murky proto-photo being ejected into waiting hands. Pulling to expand, then snapping flat the brushed metal and leather-paneled slabâ€¦ just getting to handle the camera was almost as fun as staring at that inky square, waiting for the image to appear.
Photos would get pinned to the fridge by magnets or to the cork board in the entryway with pushpins. Most of those would eventually make their way into one of the large, three-ring photo binders that collectively served as our multi-volume Family Album. And there each photo would sit, layered in plastic against an adhesive-backed, card-stock page, waiting patiently for that holiday visit by relatives. Not long after their arrival, binders would be taken down off the shelf and rifled through for collective reminiscing and occasional moments of embarrassment. (Plaid bell-bottoms!)
Of course nowadays, I can snap a funny photo, upload it to Flickr or Twitter or MLKSHK, and quickly get comments (or “likes”) from my friends. Or I could go a step further and toss it up on a different kind of site, like Canvas, where my photo would serve as raw material for a cycle of remixes and captioning that ends only when all the lulz have been wrung out of that particular creative sponge.
Now, some people might dismiss the purveyors of silly photo mashups as nothing more than juvenile mouth-breathers killing time between flamewars. And many people want nothing less than to have their personal photos subjected to (often ridiculous) manipulation by strangers. But somewhere between that static photo album and the photo-free-for-all is the space in which most of us probably play. We want to share our pictures, and solicit comments, approval, acknowledgment. We’re willing to release them out into the world to be viewed and experienced in many different ways.
The web is not a photo album. It can’t be. It shouldn’t be. I put up content, you read it, view it, share it using a phone, a computer, a tablet, a PC. Then you might print it out, repost it somewhere else or make it your computer desktop image. You might even decide to make a CafePress t-shirt from it. (Though let’s hope in that instance I’ve released that image to the public domain or used a liberal Creative Commons or similar license.)
As part of sharing my content with you, I implicitly agree to your, at minimum, experiencing it in a different context than I might. After all, you might use the Flickr Android app to view a 320-pixel-wide version of my image, even though I might blanch at the thought of browsing my own photo library in anything less than full-screen mode using iPhoto on my 22″ widescreen monitor.
But as soon as I release that image onto the web, that’s my problem, not yours. I’ve relinquished a certain degree of control.
And such is the case for any content I, you or anyone might choose to put on the public web. Yet so many web designers seem to, if not actively fight against this notion, be made uncomfortable by the fact that you might choose to browse their shiny new web site using a netbook, or a phone, or just a smaller-than-fullscreen web browser on a computer. We need less “my design is meant to be viewed” and more “our content is meant to be enjoyed.”
So how to begin changing the conversation? While many of the ideas will be familiar to those who followed the aims of the Web Standards Project (“simple, affordable access to web technologies for all”), established in the early part of the past decade, the web thinkers, designers and developers rallying under the current banner of “Future Friendly” have summed things up quite succintly in three basic points. The first one, in particular, makes a rather nice manifesto in and of itself:
Acknowledge and embrace unpredictability.
In other words, get comfortable with being uncomfortable. Accept there will always be a new device, a new technology, and entirely different way of experiencing content. And step two is, naturally, to carefully consider and prepare anything you might unleash onto the web accordingly.
Perhaps unsurprisingly, most of the people behind Future Friendly are largely approaching this from having done a lot of work in the mobile space. Quite frankly, the explosion of mobile has been a much-needed kick in the pants to further dissemination and adoption of these broadly-applicable ideals. When mobile Internet usage is growing at such a fast pace that, by current estimations, its volume will exceed that of desktop Internet usage by 2015 (if not sooner), it becomes impossible to deny that web sites unfriendly to mobile use are simply unfriendly. Period.
Things that may be a minor annoyance when experienced in a desktop browsing context — minimum browser window widths, plug-in downloads and long page-load times — often become intolerable in a mobile one. Attempts by designers and developers to shape the experience by elevating form over function only serve to drive users away.
Sites like Media Queries strive to highlight some of these newer, adaptive designs that change to suit your screen size in the same way CSS Zen Garden did for site using web standards almost ten years ago. And there’s movement away from plug-ins towards web-native experiences, as evidenced both in an announcement by SlideShare this week that they were ditching Flash in favor of HTML5, and a report last month that more top web sites are now using web-native-technology-leveraging jQuery than Flash. And mobile web pioneers like Yiibu (Bryan Rieger and Stephanie Rieger) continue to not only evangelize for better context-appropriate web experiences overall, but share actionable insights in amazing presentations like this one about some of the ongoing issues with serving that right experience, at the right time, in the fastest possible way.
In these ways, we’re still figuring out the mechanics of how to harness certain technologies and approaches, and when to discard others, all in the service of removing barriers to truly delightful experiences.
And it truly was a delight, using that Polaroid camera. I may not longer own it (and getting more film for it would be a challenge in and of itself), but that kind of connection is something that I’ll always seek out, in experiences both tangible and digital. Designers and developers who strive to be future friendly should end up being user friendly, which gives them that much more of a chance of wowing me. And that’s a challenge I’d love for more of us web professionals to take on.
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!
Twice in the past month, I’ve found myself responding to developer colleagues of mine who have been encountering difficulties working with UX folks as part of Agile project teams. The development teams want to jump right in and start building and collaborating, but the UX designer prefers working separately, handing off requirements once they are largely defined, implementation detail and all.
Having worked as part of Agile project teams in the UX lead role at a couple of different companies, I’m familiar with that situation. So I’m always eager to share my experiences from the “design side” and help explain some of what might be going through that UX designer’s mind. Because, in many ways, I was that stubborn, documentation-happy designer. (And alas, in a client-services scenario, the road to project completion is covered in virtual paper…)
My first exposure to the Agile project process was at a technology product company I worked for a little over five years ago. And, from the start, I hated it.
Having honed my project skills at an agency where a spec document of 100+ pages was a source of pride (See how comprehensively we documented the system?), I was loathe to discard what I viewed as an essential skill. Shorter documentation, in theory, was not necessarily a bad thing, as my idea of a good time definitely does not include wrestling with Format Painter in Word, or cutting and pasting boilerplate language about recurring functional elements. But the idea of no documentation, as communicated to the project team by our SCRUM master, was something that seemed completely unworkable.
And it didn’t work, at least not at first. Our project was a chaotic mess! All of us were new to Agile and unsure how to proceed. The SCRUM master dealt with uncertainty by attempting to order us to do things in a very prescribed manner, which further alienated him from the rest of the team. I dealt with the uncertainty by doing a little prototyping and a little documentation (Agile be damned!), both because it was what I was comfortable with and was what the developers were, ironically, seeking. The developers and I ended up working together very collaboratively, bonding over our mutual distaste for our methodology-obsessed project lead, who couldn’t see that we were following the spirit — if not the letter — of a quick build-and-release process.
Now, it took me quite awhile to figure out the unpleasant parts of that experience had very little to do with Agile. Inexperience, clashing personalities, different expectations about work style and product… these were far more powerful forces.
But the positive parts were also there: I discussed implementation approaches with developers, created quick prototypes in code, and helped QA my own work and that of others. These were things I’d always loved doing. But it was only later, on a second go-round with Agile that I learned that they — along with an experienced, good-humored project lead — were in fact all valued as elements key to a successful Agile project.
Ah, but what about that damned documentation? And other things, like pixel-perfect wireframes and comps, that I still clung to as some measure of familiarity and control?
Well, those things were hard to (mostly) give up. It helped that my prototyping skills improved to the point where I could demonstrate more complex interactions. And I became more comfortable with group technical and UI design sessions, once I’d had time to chew on some of the bigger problems and develop a high-level understanding of what was needed. (I still shudder at the idea of design-over-my-shoulder, as epitomized in this terrifyingly cheerful 37signals blog post.)
Even so, what ultimately made things work was both gaining the trust of the developers on my team and learning to trust them. And that takes time, as we silently size each other up — Does this person know what the hell they’re talking about? Will my design be mangled? Will this person design something that can’t be built? — and are able to eventually dismiss fears as we see how we work together and what we actually create.
Once you’re able to see ideas take shape in ways beyond what you imagined, all due to the input of a strong team, it becomes much easier to present work without having figured out all the details in advance, and to be open to criticism and feedback from anyone, not just other designers. And, hardest of all, it even gets easier (if never completely comfortable) to admit when you don’t necessarily know the best way of doing something.
In fact, it ends up being lot more fun when you let demonstrably awesome designers and developers surprise you with how much more they can do.
This past weekend, I learned that the proposal for my presentation on mobile UX design was accepted for inclusion in the program for the Midwest UX Conference, happening April 9-10 in Columbus, OH.Â Huzzah!Â I am honored and excited at the opportunity to talk about some of the specific technologies and techniques used to create great mobile user experiences.Â And I’m looking forward to meeting other UX peeps and learning a whole hell of a lot in the span of just two days.
While the Midwest UX web site has the complete and detailed program, below is the description for my talk, one of four mobile-themed presentations happening as part of the same afternoon session.
Saturday, April 9
Afternoon Session A 2:10 pm – 4:00 pm
Adaptive Mobile UX Design / 2:30pm 2:50pm
Whether putting pen to paper or mouse pointer to blank canvas in your wireframing program of choice, most of us still pick an unconscious 1024 x 768 pixel resolution, landscape-orientation starting point for our designs. And if we need to design for mobile, it’s often on a completely separate track that uses a limited subset of the content and functionality we plan for in the “main web site”.
But with smartphones now projected to be in the hands of half of all Americans by the end of this year (citation) it’s vital that user experience architects understand some of the mobile-centric techniques and technologies that developers are already experimenting with.
In this presentation, UX professionals will see specific examples of HTML5 and CSS3 that have greatest impact on the user experience, including:
- HTML5 form types used to create smart soft keyboard UIs
- CSS media queries that serve up custom versions of the same page, making them truly responsive to any screen size and resolution
- Device-orientation and location-awareness technologies that add a context layer to the experience of using a site or application
- Semantic HTML5 tags that bring our wireframes closer to the code that developers use to create finished web sites
Any user experience professional, even those not yet working in mobile, can benefit by viewing these new techniques and being aware of how they can be used today and involving designers and developers in that conversation.ï»¿