Prototyping with XHTML

Illustrations by Leah Buley

If you design user experiences for standards-based websites and applications (i.e. those built with XHTML, CSS, and JavaScript), there are several great reasons for adding XHTML prototyping to your UX tool kit. Perhaps you’ve found that traditional wireframes just aren’t sufficient and are looking for more powerful ways to explore and communicate design solutions. Perhaps your current practice is based on the traditional waterfall model (i.e. first creating wireframes, which are handed off to creative, who hand off comps to tech, and so forth), and you want to explore more contemporary methodologies, such as agile and iterative development. Regardless, a great way to embark on that journey is to start prototyping with XHTML.

So what does it mean to prototype with XHTML? Essentially, it’s the process of using the XHTML itself, and related technologies, to evolve and define your design solution. And what does an XHTML prototype look like? While, as we’ll see, that depends on where you are in your prototyping process, an XHTML prototype generally looks like any other web page built with XHTML, with some links or features perhaps being non-functional. In other words, anything you can build with XHTML, from consumer websites to enterprise applications, you can also prototype with XHTML. As we’ll see, there are numerous advantages to this approach compared to designing with wireframes or other prototyping tools.

An Iterative Process

While prototyping with XHTML isn’t tied to a specific design process, iterative development seems to effectively leverage its strengths. There are many reasons for this, but perhaps the most significant is that in both cases the prototype, and later the application itself, doubles as a specification. We’ll explore what that means in a bit, but first let’s walk through a suggested process for prototyping with XHTML.Let us start with an overview of the larger design process:

In this (iterative) methodology, rather than design the entire application before starting to build it, one designs and builds a unit of the application and then uses what has been built to inform and serve as a starting point for other application units. As with other design methods, the design work begins with sketching, which plays a particularly important role relative to prototyping.

Sketching: A Freeform Question

The term ‘sketching’ refers here to any freeform exploration unconstrained by a specific technology. This includes production of wireframes, which in this model are reframed, as it were, from specification artifact to refined sketch. When thought of, and presented to stakeholders, as sketches, its more natural to discard your wireframes once the design has evolved beyond them. This is usually after a prototype equivalent has been produced. With the design team I work with, we’ve found that when prototyping with XHTML, wireframes often became superfluous, and it’s more effective to go directly from sketch to prototype.

Prototyping: A Concrete Response

Prototyping has a counterpoint relationship to sketching. To paraphrase Bill Buxton, while sketches ask a question—“Is this a good design idea?”— prototypes provide a response. By making the idea manifest, prototypes force upon it the concrete realities and user experience idiosyncrasies of the actual production technology and offer a crisp verdict on the quality of what you dreamed up in drawings.

The Prototype/Build Relationship

When prototyping with XHTML, especially in an iterative model, the build and prototype become very intertwined. If you’re prototyping a new application or product, the XHTML prototype is essentially a rough draft of the actual application. However, when updating the design of an existing application, the production version can serve as the starting point for the prototype of the new solution.

Three Integrated Layers: Structure, Behavior, Foundation

The model for XHTML prototyping is based on the best practices model for actual site production: start by setting the foundation with XHTML, add a presentation layer with CSS, follow it by a behavioral layer using JavaScript then iterate.

Let’s start by looking at the structural layer.

Structure: Set the Page Foundation

The first step in production of the XHTML prototype is to create a structural foundation. Similar to how we create a wireframe, we start by representing the main content areas on the page, except we do so with text-based XHTML markup.

| If our sketch or wireframe looks like this | …our XHTML might look like this: |
|^. |^.

My Account

Account options

Account details

Account Help

(We’re only displaying the relevant snippet of the XHTML here.)

Next, we add detailed content elements that have been defined, using the XHTML structure appropriate for the corresponding content.

| For example, if our detailed sketch looks like this | …we’d represent the list of account help topics as an unordered list (i.e. use the ul tag): |
|^. |^.


Continuing to add detailed content to the page, we have essentially produced a structured content inventory of the page. This serves as a foundation for the rest of the prototype production. While wireframes force us to represent a page’s information architecture within a specific layout, this is pure structure and hierarchy, and, in my opinion, represents the true information architecture of a web page.

By defining the information architecture directly in the XHTML, we can also easily define accessibility-specific attributes, such as being cognizant of how users traversing the page with a screen reader will experience the page, and order content blocks accordingly. Additionally, we can more easily define elements often overlooked when working with wireframes, such as effective use ofLabel tags in forms.

If one were to view the structural layer in a browser, it would essentially look like an unstyled web page, and would not be interesting to look at. Just as building foundations are not known for their aesthetic qualities, but instead for the impact their quality has on the building they support, so too will the quality of the page structure significantly impact the overall quality of the web page. In fact, that absence of style is a key advantage of working with XHTML.

Evolving the Presentation Layer

With a page structure in place, we are ready to focus on how content will be presented. Looking back at our sketches, we’ve already explored some layout concepts, which we can begin to apply to our content structure. The way that look and feel is developed and applied will vary widely from team to team. While you may choose to do your initial exploration of look and feel with design comps, especially if you are also developing an overall brand, it’s worthwhile to redefine comps similarly to how we previously redefined wireframes. Just like wireframes are great as sketches, design comps are great for initial exploration of look and feel. But the practice of fully developing the presentation layer away from the actual technology, and then cutting it up and applying it wholesale to a web page is like wallpapering a façade onto a building. It’s impossible to be aware of all the dynamic aspects of a web page when working in static illustration software. However, when prototyping with XHTML, you can leverage the power of rendering your design in the same way that it will be seen by users, and incrementally evolve page presentation based on this immediate and rich feedback.

Issues that don’t easily reveal themselves when working in illustration software will often be obvious. This includes issues related to your design and the browser viewport, from the basic question of if the design should center itself in the browser window, to more advanced issues, such as how to design for different window sizes and browser resolutions. For example, for small windows sizes, is it okay if some content disappears out of view, or should the design adapt to the window size? When look and feel is designed solely with illustration software, questions like this are often unexplored to the detriment of user experience.

Adding Behavior: Unreinventing the Wheel

When prototyping with XHTML, you are designing within the larger ecosystem of the web, which effectively becomes your always-up-to-date UI library. Instead of laboring over the design of a detailed piece of functionality, start by letting Google inform you if anyone else has designed and built something similar, and then use that as the starting point for your solution. This can include anything from date-pickers to web widgets to whatever cutting edge UI idea was just created. Additionally, prototyping with XHTML makes it easy to incorporate and simulate Web 2.0 functionality, such as embedded widgets and syndication. If you don’t know JavaScript, or whatever technology is being used, you can collaborate with your developer on integrating the solution. Of course, you’re not going to find a solution for all your design needs online. In those cases, go back to sketching and collaborating with your team.

Iteration: Discovery, Evolution

The true power of prototyping really emerges during iteration This is when users can interact with your prototype. On a recent project, we sketched out a solution in which users could drag videos from a library onto a playlist. Looking at the static illustrations, it seemed a simple and elegant idea. But when users were able to interact with the solution, dragging and dropping video thumbnails, they found that it was a pretty tedious activity, especially for large numbers of videos. In other words, the prototype allowed us to discover a design problem that went unnoticed when looking at a wireframe.

And therein lies a core problem with using static artifacts to communicate interactive solutions; they effectively force the user to prototype the solution in their imagination, where all solutions seem to function in glorious perfection. With XHTML, we minimize the cognitive leap that users need to make, allowing them to instead experience and respond to something nearly identical to the actual solution.

Once users provide feedback and the team begins work on the next iteration, another measure of the quality of the prototyping methodology comes into play: how rapidly are you able to iterate? The longer an iteration takes, the less valuable your prototype. When prototyping with XHTML, iterations can be incredibly fast, first because the prototype can be easily presented to users, since it’s usually just a question of posting your files and sending out a URL. Second, because XHTML is text-based, iterations such as text changes or basic functional updates can often be completed in just a few minutes. More advanced design updates usually don’t take more than a few hours of actual production time.

How XHTML Can Double as a Specification

One of the most powerful aspects of XHTML is that it is self-describing. The same XHTML markup that tells a browser what to display can also double as a specification for a developer. For example…



This markup Would be read as

“This is the start of the header content block.”
^. XYZ Application “display the product name, which should link to the homepage”

Signed in as Jane Smith (Editor)


^. “display user information, including the user’s role (or set of application permissions”

In buzzword-speak, the practice we are applying here is writing semantically meaningful markup, which means we are selecting tags and naming our IDs and Classes such that they communicate the meaning and function of the content they enclose.

Annotations Visible Only to Those Who Care About Them

Another advantage of using XHTML as a specification is that IDs and Class names can double as annotation references. In other words, the annotations for the content block with the ID “account-options” would appear under the heading “Account Options” in your specification.

Rather than obscure and clutter a page design by placing annotation callouts on top of it, a common practice when using wireframes, that may confuse and distract non-technical viewers, references are only in the markup view for developers who are interested in seeing them. And since the XHTML file itself is so richly informative, the actual annotations written tend to only be short bullet points.

More Standards, Less Noise

One of the biggest problems with wireframes is the lack of a standardized notation. In other words, my wireframes certainly don’t look anything like your wireframes. This means that visual designers and developers who use wireframes are continually relearning how to interpret our work, leading to noise between author and reader. To compensate for the lack of a standard, we have to create highly detailed wireframes, with often lengthy annotations that explain what our wireframes mean and how elements in them work. These, in turn, are collected in large specification documents that usually are so labor-intensive they become impossible to maintain. When they are no longer kept up-to-date, the team stops trusting and relying on them as the design specification, which leads to all kinds of bad things happening.

In contrast to wireframes, XHTML is a standardized notation, anyone who knows XHTML can read your document. More importantly, it is a language spoken fluently by a key target audience of your design documents, the developers. And those who don’t know or care about XHTML can view the part they do care about, the page design, by opening the document in a browser.

Using a standardized notation also means you are not confined to specialized wireframing or prototyping software, but can use anything from a simple text editor to the range of tools available for editing XHTML files. Also the compact syntax of XHTML, particularly compared to verbose wireframe annotations, combined with the fact that you are just typing in a text file, leaving it to a browser to deal with the visuals, allows you to work rapidly and efficiently.

A Small Amount of Knowledge Goes a Long Way

If you’re new to XHTML, you’ll discover that a small amount of knowledge goes a long way. Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time. (Two great places to start are or Better yet, rather than invest time learning the UX tool du jour, you deepen your understanding of the technology that realizes your design.

Dividing and Conquering

The redefining of a wireframe from a blueprint to a sketch has a domino effect on who does what and when in evolving the page or application design. After a rough page design has been sketched out, rather than have one team member toil away in isolation, wireframing detailed representations of each page design, this model takes a divide-and-conquer approach. On the team I work with, I might produce an initial cut of the XHTML and some of the CSS, while other team members build on that, updating the XHTML, adding more advanced CSS, as well as JavaScript. If the team as a whole conceives of a solution, why not also have the team as a whole design it? In other words, rather than creating one person’s vision of a team’s solution, why not have the entire team contribute their particular expertise? When working with XHTML, we can use the tight integration of CSS and JavaScript to allow team members to contribute their dimension of the design via a set of integrated artifacts.

Where To Go From Here

This has, of course, been a mere whetting of the appetite for anyone interested in prototyping with XHTML. If you are interested in exploring the methodology further, particularly if you currently follow a traditional waterfall-oriented process, I recommend a many-small-steps approach. In other words, prototype the methodology itself, working with your team on a small project, and then building on that. If your experience is anything like mine, you’ll find it an incredibly powerful addition to your UX toolbox — a more effective way to straddle that proverbial divide between user experience and technology.

An Open-Source Conference: BarCamp

“Think of BarCamp as the open-source equivalent to a traditional conference, in which top-down planning is replaced with bottom-up self-organizational models.”

It seemed to be an average technology conference. A hundred some web geeks gathering for a weekend of presentations and discussion at a loft-like office space in lower Manhattan. And yet, BarCamp NYC (New York City), a recent incarnation of the BarCamp “un-conferences,” was about as far as you could get from a traditional conference.

The BarCamp venue was a tangle of laptops, sleeping bags, food containers, stacks of Red Bull, and notes taped to wall space not already occupied by screen projections. The constant crisscross of discussions and presentations (of which it often was hard to tell one from the other) would likely be jarring to the uninitiated, like an orchestra musician encountering a jazz improv session for the first time.

Think of BarCamp as the open-source equivalent to a traditional conference, in which top-down planning is replaced with bottom-up self-organizational models. Instead of having committees planning the event, selecting presentations, and then charging attendance fees, the only price for attending a BarCamp is participation. Attendees have to either give a presentation or help out with one. That simple rule lends momentum to an overall sense of ownership on the part of each who attend, which in turn, fuels a desire to participate far beyond doing presentations.


At the same time, even BarCamps need an initial seed effort. At the NYC event, Amit Gupta headed up a group of volunteers who did the initial heavy lifting to provide the core ingredients of a BarCamp: a space to hang out, a decent Wi-Fi connection, and some food. In the spirit of making the event as low-cost as possible, the daytime space doubled as accommodations for out-of-towners. Describing group-effort auto-pilot in action, Amit writes that organizers “didn’t give any instructions on what to do or where to go. Everyone just figured it out on their own, found a space when they got tired, and bedded down. In the morning, people got up, showered, and were ready by 10 or 11. Again, no direction, no alarms, people took care of themselves and each other.”


Similarly, the un-conference approach to scheduling presentations was also a community effort. Attendees were encouraged to arrive early to “get a slot on the wall,” which is BarCamp-speak for the self-organizing event scheduler. At the NYC event, this took the form a Day/Time/Room grid taped up on a wall, onto which people slapped sheets of paper with their (sometimes barely legible) presentation names in whatever slots remained open. Presentations ranged from down-and-dirty coding discussions about new or on-the-horizon tools, such as FeedPile and ideaShrub, to more activist-leaning talks with titles such as “Build your own TiVo (Myth TV) to beat the evil broadcast flag” or the more light-hearted, like “Getting your girlfriend the ‘best present ever!’ using OSS.” Below a presentation titled “Social Networks,” someone had added the presentation “Subverting Social Networks.” Very BarCamp indeed.

Chris Messina, open-source evangelist, and a co-organizer of the original BarCamp (held in Palo Alto in the fall of 2005) describes the BarCamp experience as being “emergent… in totality. The events happen in communities — and are organized by the community members *for* the community.” His presentation, “Flock, Micro formats, and Open source world domination,” was representative of the tenor of the event, intermingling intricately detailed technical discussion with larger social themes, such as the win-win proposition of sharing as much of your work as possible with as many people as possible.

Chris used his work on the Flock browser as a springboard for discussing how users can more easily create web content and engage with other users. Describing the traditional bookmarking model for maintaining a personal web history as “stupid and unintuitive,” he presented the Flock model, which takes a Gmail-like approach, indexing every page the users visits. Then, rather than having to dig through long lists of bookmarks to find the URL of that cool page you looked at last month, you can instead just search your web history to find it.

“Below a presentation titled ‘Social Networks,’ someone had added the presentation ‘Subverting Social Networks.’ Very BarCamp indeed.”

Exemplifying the playfully rebellious undertone of several presentations were Brandon Stafford and Mike Goelzer, in their presentation “Making the entire web as unreliable as Wikipedia.” They talked about a very-much-in-progress model for allowing visitors of a web page to view an alternate version of the page—written not by the original author but by someone who is part of your “micro culture,” and whose opinion you’ve defined as preferable to that of the original author. Admitting the concept definitely needed some work, they described it as an attempt to “take back the web” by allowing users to, at least in a limited way, turn the entire web into a wiki.

Other great presentations included a talk by Nick Gray on empowering individuals to get their development projects implemented on the cheap using offshoring. Generally associated with how big corporations lower labor costs, Nick described a peer-to-peer version of offshoring, made possible by services such as RentACoder, from which one can find a programmer in, say, Ghana, to build an entire application for under $1,500, or even get small jobs done for as little as $10. Many of those attending initially responded with disbelief at the idea of getting even a single line of code written for $10, until we realized that this amount may in fact be a lot more money in other parts of the world.

Some presentations took on more of a sideshow-attraction feel, such as Matt Pelettier’s lunch-time challenge for anyone in the audience to pick an application for him to build in 15 minutes using the Ruby on Rails programming language. “What do you want me to build?” he asked defiantly. “Build something that searches craigslist for New York City apartments,” someone in the crowd proposed. Sure enough, fifteen-ish minutes later lists of outrageously priced Manhattan apartments from craigslist appeared on his laptop.


Saying that BarCamp NYC was a huge success is an understatement. Interest in the event was so high that the organizers had to keep the location of the event secret, only doling it out to the first 100 or so that signed up. The event buzz was in part thanks to a self-perpetuating marketing strategy similar to how the event itself was run: plant a small seed and then let community forces take over. It involved asking a few respected bloggers to write about the event, and then let news spread via word-of-blog. At the same time, a lot of free BarCamp buzz also came by way of its predecessor, Foo Camp.

Created by O’Reilly Books founder Tim O’Reilly, Foo Camp originated the unstructured event concept on which BarCamp is based, with a key difference being that Foo Camp is invitation-only. Due to an “in-hindsight-fortuitous miscommunication,” web-standards evangelist Tantek Celik thought he hadn’t been invited back to Foo Camp 2005, which led him to create an alternate open-to-all event, setting in motion what led to the first BarCamp. (By the time he learned he in fact had been invited, BarCamp planning was well underway.)

More than just an alternative model for facilitating a rich exchange of ideas, BarCamp seems to represent a generational break from conventional professional gatherings. They usually take a year or so to plan, cost tens of thousands of dollars to execute, often have some corporate backing, and are mostly planned over email. In contrast, the first BarCamp was put together in about six days, mostly via instant messaging, SMS, and ad-hoc wikis, for a cost of about $1,500, which is less than the price of a single ticket to some of the more high-end tech conferences. Stripped away are the constructs adopted by major conferences from academia, such as keynotes, posters, formal calls for papers, and peer reviews. Gone too is the presenter/attendee divide, where those not giving talks too often are passive spectators, except maybe for the occasional end-of-talk Q&A.

That model certainly has its place. Some people just want to go to a conference and listen to leaders in their field speak (and maybe get their two cents in during a 5-minute madness session.) But the detrimental side effect of this is one of virtually the same A-listers disseminating to the flock year after year. And this where BarCamp provides a democratizing alternative, where talking is just as important as listening.

The informal feel of the event also makes people less concerned about presenting fully developed ideas, instead, increasing the comfort-level of throwing out off-the-wall ideas just to see what the response is. And by the same virtue, an audience who, in a more formal setting, might politely listen quietly to a not-so-great presentation, is more comfortable speaking up, maybe even turning the presentation into a workshop to see how a bad idea can be turned into a good one.


As of this writing, at least three more BarCamps are being planned. In addition, several spin-offs are in the works, including WineCamp, in which developers mingle with non-profits at a vineyard to explore how one can support the other. As with BarCamp NYC, the events have been mostly technology-centric. But there is of course no reason why this low-cost, yet amazingly fruitful, event model can’t be applied toward IA and UX-oriented events. In fact, because the work of user experience professionals is so much about listening to and communicating with technology and business groups, an event where everyone presents and participates seems tailor-made for this field. At least one such event already is being planned, with Dave Heller heading up the planning of UXCampNYC, expected to take place sometime in May.

New Challenges Retreat: ideas, discussion, and a call to action

“On a global scale, there are only a handful of us, and yet our work affects millions every day.”

“We’ve got a lot of questions and not so many answers,” according to opening session speaker Peter Van Dijck as he and Jorge Arango addressed the issue of global information architecture (IA). As the IA field grows, conferences and retreats provide IAs with the opportunity to ask questions and discuss the possibilities.

This year’s IA Retreat, “New Challenges in Information Architecture,” took place at the Edith Macy Conference Center, just north of New York City, October 7-9, 2005. Of the many themes discussed at the retreat, those that stood out revolved around the challenges of enterprise information architecture (as in very large enterprises, such as government agencies, and Fortune 100’s), cross-cultural IA issues, and designing user experiences for evermore complex, and increasingly less, web-centric systems.

Peter and Jorge gave a “broad-strokes” perspective on the daunting challenges faced by cross-cultural multi-language sites, where even something as seemingly innocuous as how country/language is selected can set off a firestorm among users. In one great example, they explained that Flemish users protested loudly when a product site chose to set French as the default option if users selected Belgium as their country. The design was changed to accommodate the users.

Language and culture challenges in IA were also very much at the center of Mairi Willis’ session on designing intranets in large, distributed organizations. She described her task of deploying intranets across some 50 countries, each of which incorporated the country’s own language and cultural idiosyncrasies, all while remaining consistent with the overarching enterprise framework. Mairi told of having to mix diplomacy with sprinkles of dictatorship to provide countries as culturally and geographically disparate as Kazakhstan and Indonesia with enough freedom to ensure that locally specific needs were met without compromising enterprise-level objectives. An example of one specific issue was deploying information from headquarters to individual countries.

Dan Brown and James Melzer each took stabs at addressing enterprise-level challenges. Dan led a workshop that proposed leveraging the work of George Lakoff and the thinking behind prototype theory toward designing content management systems-which too often are more expensive than useful. He guided us through several group exercises, where workflow, roles, and content were used as the core building blocks of a CMS. Some of us felt that “context” deserved being a separate building block.

James’ session, which was based on his work for large government agencies, started with a nutshell description of Enterprise Architecture and how (surprise, surprise) user experience had mostly been left out. He presented a great diagram, which placed user experience at the center of the enterprise architecture. A discussion that simmered throughout these presentations was the absence of a formal IA theory, and how we instead find ourselves cobbling together theories from other disciplines.

Is there a need for a Ph.D. in information architecture? Is information architecture just an umbrella for other disciplines, making the need for a theory of its own moot? As Peter said, a lot of questions, not so many answers.

Marcelo Marer, Mary-Lynne Williams and Victor Lombardi took more of a strategic focus in their sessions. Marcelo and Mary-Lynne described navigating design concepts through their client’s various acquisitions of other companies, in which much of the heavy lifting in the design work, conventionally associated with the user-visible interface, took place in back-room strategy sessions with executives. They also provided a great example of high-level design “from the hip;” when, in the twelfth hour of this enterprise-wide effort they decided to discard the strategy they’d worked so hard to sell to stakeholders and instead adopt the infrastructure already in place at a newly acquired company. It was a gutsy, but ultimately, successful decision, and a great testament to the power of being open to change course, even after a fundamental design choice has been made.

Victor talked about how advertising space and value on a page-level basis can affect page design. He showed methods for calculating the value of an ad, and discussed how size and placement of the ad on the page are key factors. This led to a discussion of the trade-offs between choosing content quantity on a page and how difficult choices need to be made by stakeholders regarding usability versus income. The focus of IA is often on the structure of the content, while the big swatches of ad space, which have a direct impact on usability and usefulness (and in some cases the ads turn out to be more useful than the content), are easily forgotten. Todd Warfel pointed out that navigation and orientation are also critical factors when incorporating ad space, describing how users sometimes click on an ad link and are not aware until several pages deep in the advertiser’s site that they no longer are in the originally visited site.

As part of his presentation, Todd outlined methods for improving IA deliverables, including how to leverage grid systems. Using two different newspaper layouts with similar amounts of content as a discussion springboard, Todd showed how the one that made better use of a grid had a cleaner and more relaxed look. He explained that it improved usability during page transitions, since only content that is unique to the new page moves or changes.

Todd also showed how pattern libraries can increase productivity both for IAs as well as developers, who are keen to leverage the same code base across multiple solutions. Reminiscent of the Yahoo! pattern library presentation at this year’s IA Summit (March 2005), Todd showed several examples of solution reuse across multiple designs. As with wireframes, the ins and outs of sitemaps are a matter of continual discussion among IAs. Into that contentious mix, Todd added his hub-based model, which he described as more closely matching the user’s mental model of the site. In contrast to the tree-based approach, page clusters with user persona information associated with them radiate from a central homepage. Todd showed how the model works for content-heavy as well as interactive sites, and that many of the clients he had shown it to understood the model without need for introduction. He noted that the hub-model may be more work to maintain than other models. A lot of discussion emerged surrounding Todd’s concepts, such as questions about the role of IAs in defining page layout, or the usefulness of sitemaps. At the same time, there was agreement that there is a dire need for more innovative ideas, such as Todd’s work, and Adam Greenfield certainly brought that message home with his “Everyware” presentation.

“From the complexities of designing across cultures and languages to managing information in massive organizations, the challenges facing information architects seem to be growing more daunting every time we look around to assess them.”Due to scheduling conflicts, Adam was only able to join the retreat at very end, but as it turned out this was the perfect closing session for the retreat. Adam’s presentation was both a detailed depiction of a ubicomped world in which we’ll find ourselves in an impossibly near future, as well as a call to action for IAs to apply their skills to the mind-boggling challenges of designing user experiences for that future (which, to paraphrase William Gibson, is already here, just not evenly distributed.)

Very methodically and with sometimes frightening detail, Adam described a technological eco-system in which the web as we know it vanishes into the pervasive ether, in which privacy and ethics become paramount factors, and systems become so complex that attempting to design them at the atomic level may simply not be feasible. Instead, we may find ourselves functioning like gardeners tending plants, guiding and overseeing but not controlling detailed behavior.

As the leader of the committee organizing this event, I can say that a major motivating factor for making the retreat happen was the sense of a need for more events and opportunities for IAs to come together and discuss our work. Peter Merholz, president of the IA Institute, has raised similar sentiments about the need for more events. Too many IAs work in isolation from other IAs. On a global scale, there are only a handful of us, and yet our work affects millions every day. I know that efforts are underway to organize a retreat in the Chilean Andes sometime next year, and I hope to learn about other similar efforts. The catalyst that set me off on the path to make this event happen was Christina Wodtke’s call to attendees of last year’s amazing “Future of IA” retreat to make retreats happen in our local areas.

I can only hope that this year’s retreat will serve as an inspiration for others to create similar opportunities for IAs to come together, share and vet ideas, and continue evolving as we take on the challenges that lie ahead.

More retreat resourcesRetreat event page
Retreat wiki (where Chiara Fox and others added session notes, links to presentations, and more)
Flickr stream
Podcasts of the sessions will be posted soon…

Anders Ramsay organized this year’s IA Retreat. He is an information architect in New York City, as well as founder of New York City IA Meetups. His personal site can be found at: