This Is (Web) DIY

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.

It was in this atmosphere of “what the heck?” that I created my first professional web site, in fact my first web page ever, for Rykodisc. My toolbox was limited, as there was no CSS and no JavaScript. The first iteration of HTML didn’t even allow for using different fonts, any page background color (beyond the default gray), or tables, which, in the pre-CSS era, would be used (and abused) in the service of visual design.

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.

Rykodisc Home Page - January 4, 1995

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.


Doing (or Not Doing) Agile UX


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.