Boxes and Arrows

Prototyping with XHTML

Anders Ramsay, Leah Buley — Fri, 31 Oct 2008 07:50:01 GMT

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: | |^. |^. … <div id="header"><h1><a id="product-name" href="#">XYZ Application</a></h1></div> <h1 id="page-title">My Account</h1> <div id="account-options"><h2>Account options</h2></div> <div id="account-details"><h2>Account details</h2></div> <div id="account-help"><h2>Account Help</h2></div> <div id="footer">[footer]</div> … (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): | |^. |^. … <div id="account-help"> <h2>Account Help</h2> <ul> <li><a href="#" rel="help">How do I lorem ipsum?</a></li> <li><a href="#" rel="help"> How do I dolet amet?</a></li> <li><a <a href="#" rel="help"> How do I lorem ipsum?</a></li> <li><a href="#" rel="help" class="more">More help…</a></li> </ul> </div> … |

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
^. `<div id="header">`	“This is the start of the header content block.”

^. `<a id="product-name" href="/home/">XYZ Application</a>`	“display the product name, which should link to the homepage”

^. `<div id="user-info">Signed in as Jane Smith (<span class="role">Editor</span>)</div>` ;	^. “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 htmldog.com or w3schools.com) 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.

IDEA 2008

Jeff Parks — Fri, 17 Oct 2008 05:10:49 GMT

The “IDEA Conference”:http://ideaconference.org/index.html took place in Chicago on October 7-9 at the Harold Washington Library Center.

The speakers pushed the boundaries of what it means to design complex information spaces of all kinds. We can all expand our practice by absorbing their experiences and ideas. In cooperation with the “IA Institute”:http://www.iainstitute.org/, we’re happy to bring you recordings of most conference talks. We hope you enjoy listening to nearly the entire conference via these recordings.

This conference addressed issues of design for an always-on, always-connected world. Where “cyberspace” is a meaningless term because the online and offline worlds cannot be made distinct. Where physical spaces are so complex that detailed wayfinding is necessary to navigate them. Where work processes have become so involved, and so digitized, that we need new processes to manage those processes. —from the “IDEA Vision Statement”:http://ideaconference.org/index.html

Subscribe to the Boxes and Arrows Podcast in iTunes or add this page to your Del.icio.us account:

iTunes Del.icio.us IDEA Conference theme music generously provided by Sonic Blue

Micro-Interactions in a 2.0 World – David Armano
We live in a world where the little things really do matter. Each encounter no matter how brief is a micro-interaction that makes a deposit or withdrawal from our rational and emotional subconscious. The sum of these interactions and encounters adds up to how we feel about a particular product, brand, or service. Little things. Feelings. They influence our everyday behaviors more than we realize.

Vice-President of Interaction Design at Critical Mass, David Armano shares what organizations are doing this and how we’ll all need to re-think how brands are built and sustained in an ever-changing 2.0 world.

Download

Micro-Interactions in a 2.0 World (v2)

View SlideShare presentation or Upload your own. (tags: web 2.0)

CmapTools: From Meaningful Learning to a Network of Knowledge Builders – Alberto Cañas
Based on theories of meaningful learning and education, Co-Founder and Associate Director at the Institute for Human and Machine Cognition (IHMC), Alberto Canas presents a software tool that allows users to collaborate in the construction of shared knowledge models based on concept maps, which are used worldwide by users of all disciplines and ages, from elementary school students to NASA scientists.

Download

Linguistic User Interfaces – Chris Crawford
Wouldn’t it be nice if, instead of digging through nested menus buried inside subpanes of dialogs, we could just talk to our computers in plain language? Sure it would, but computer scientists have long since proven that such “natural language processing” can’t be done.

Storyton Author and Inventor Chris Crawford describes a Linguistic User Interface, outlining how it’s impossible to create a LUI seperately from the digtial reality it reflects: the language and reality must be built up in a parallel process.

Chris illustrates this with Deikto, the LUI system he created for his interactive storytelling technology.

Download

The Language of Interaction – Bill DeRouchey
We are interacting with technology in an exploding number of forms. “Traditional” computers, cell phones, pocket PDAs, game systems, gesture-based input, store kiosks and checkouts, and much more. How do people learn new technology? By subconsciously learning the language of interaction and applying that language when learning something new.

Bill DeRouchey, Sr. Interaction Designer at Ziba Design surveys everyday objects out there now to spot patterns and trends in what people are learning from devices and products.

Download

The Language of Interaction

View SlideShare presentation or Upload your own. (tags: ixd ixda)

Getting Real – Jason Fried
Jason Fried is the co-founder and President of 37signals, a privately-held Chicago-based company committed to building the best web-based tools possible with the least number of features necessary. 37signals’ products include Basecamp, Highrise, Backpack, Campfire, Ta-da List, and Writeboard.

37signals also developed and open-sourced the Ruby on Rails programming framework. 37signals’ products do less than the competition—intentionally. Jason believes there’s real value and beauty in the basics. Elegance, respect for people’s desire to simply get stuff done, and honest ease of use are the hallmarks of 37signals products.

Download

Aurora: Envisioning the Future of the Web – Jesse James Garrett
Co-founder and President of Adaptive Path Jesse James Garrett provides an inside look at the process of creating Aurora, a concept video depicting one possible future user experience for the Web.

Jesse talks about the technology trends that will shape the future Web, outlines the challenges of designing a future product, and takes the audience for a behind the scenes look at the creation of the Aurora concept video.

Download

Aurora (Part 1) from Adaptive Path on Vimeo

Aurora (Part 2) from Adaptive Path on Vimeo.

Aurora (Part 3) from Adaptive Path on Vimeo.

Aurora (Part 4) from Adaptive Path on Vimeo.

Emerging trends | Design thinking | Service innovation – Aradhana Goel
When we look through the lenses of society (how we connect), mobility (how to move) and sustainability (how we consume), we realize that the world has changed dramatically in the last couple of years. Aradhana Goel, the Service Design Strategist at IDEO, discusses connections between these emerging trends, design thinking, and service innovation.
Download Aradhana’s presentation

Download

Books and Browsers – Dave Gray
The book as a form factor has been around for about 2,000 years, since Julius Caesar first decided to fold up a scroll, accordion-style, and mark the pages for later reference. In 1455, Aldus Manutius was the first to publish the portable paperback, and it has remained relatively unchanged since.

In an interactive format, XPLANE Founder and Chairman Dave Gray explores several questions about the future of the book and the web browser.

Download

You are (Mostly) Here: Digital Space and the Context Problem – Andrew Hinton
Context. It’s everywhere. No, really, you can’t move without bumping into the stuff. But it used to be that we at least had a grasp of what context we were in at any given time. We were either here, or there. But technology has radically changed what it means to be “here” or “there,” and has brought some challenging design problems along with it.

Andrew Hinton, Lead Information Architect at Vanguard, discusses What does architecture even mean, when the walls are made of vapor? How do we map places that don’t behave like places anymore? And if you don’t know whether you’re here or there, then how do you know which version of yourself to be?
Download Andrew’s presentation

Download

Digital Context Clues – Jason Kunesh
Experience design is evolving in both discipline and practice as more people communicate and engage with media. In this presentation Independent Design Professional Jason Kunesh examines working with patterns, diagramming and prototyping tools, code frameworks like Rails and Drupal and usability testing 8 year olds.

Jason also looks at the lessons learned and where he draws the boundaries between a firm’s design principles and the tenets of a particular.

Download

Jdkunesh Idea2008

View SlideShare presentation or Upload your own. (tags: idea2008 ia)

Information in Space – Elliott Malkin
Artists and Information Architect Elliott Malkin discusses his new media projects installed in public space.

He covers several projects in this presentation including Eruv, a symbolic boundary erected around Jewish neighborhoods as part of the observation of the Sabbath completed in Lower Manhattan and New York city.

Elliott also talks about the research into the life of his great-grandfather, which led to his concept for Cemetery 2.0, an electronic device that connects gravestones to online genealogical databases.

Elliot also shares his most recent work, Graffiti for Butterflies, a technique for using ultraviolet light and street art to direct Monarch butterflies to food sources in urban areas.

Many thanks to Elliott for adding the audio from his presentation to the videos below. You can find the original source of these videos along with greater detail about each of these projects, on his web site.

Download

The Eruv Projects, IDEA Talk, Part I from Elliott on Vimeo.

Cemetery 2.0, IDEA Talk, Part II from Elliott on Vimeo.

Graffiti for Butterflies, IDEA Talk, Part III from Elliott on Vimeo.

Mixing Messages – Edwina von Gal
The design of a park around a museum of biodiversity in Panama (designed by Frank Gehry) has inspired a number of collaborations and connections throughout Panama and, now the United States. The Park will be a living extension of the museum’s exhibits and the first step in an educational trail that will encourage visitors to explore Panama’s rich natural resources.

In this presentation, author and landscape designer, Edwina von Gal, discusses how this project has inspired her to become involved in other educational and applied projects in Panama, working with scientists, students, and local populations to explore sustainable alternatives in agriculture, architecture, and tourism.

Download

Quick Turnaround Usability Testing

Paul Nuschke — Thu, 18 Sep 2008 10:42:59 GMT

It starts with any number of scenarios: Design and development have taken too long to produce a prototype, you need to release in three weeks, and you suspect there may be design flaws. You are trying to incorporate usability testing into an Agile development process. Or maybe you simply want to pare down your process to make it shorter and less expensive.

Completing usability testing quickly is a challenge anywhere but especially in consultancies, which have to overcome additional challenges, such as learning a new application. To assure success on these projects, I’ve developed a quick turnaround usability testing methodology (QTUT) that minimizes the time needed to complete testing. In Part I of this article, I discuss how to make the first three steps of QTUT—Sales & Kickoff, Recruitment, and Preparation—as short and efficient as possible. In Part II, I will discuss the final two steps: Testing and Analysis & Reporting.

Steps in the QTUT Process

Step 1: Sales & Kickoff
Step 2: Recruitment
Step 3: Preparation
Step 4: Testing
Step 5: Analysis & Reporting

Sales & Kickoff

A new client or a group within your company has approached you about doing usability testing. They need the results next week, which works out to six business days from today. What should you do?

Before a project kicks off, we typically have a number of discussions with the client to understand their goals and deadlines for our engagement. However, in QTUT, each day spent in the sales and kickoff process takes a day away from testing and analysis. To help our sales team conduct initial discussions efficiently, we’ve prepared a one-page guide outlining the do’s and don’ts of QTUT.

One critical “do” for our sales team is that they should discuss the method with the client and immediately set deadlines for our testing results. Starting with the final due date, an experienced tester can work backwards to determine the dates for testing, beginning recruitment, and finishing the test plan.

It’s also important to review expectations with the client. For example, current clients typically expect a certain level of quality in our deliverables. When we compress a week of work into one day, delivering a perfect document or presentation is impossible, so simply reviewing the timeline and discussing how we plan to shorten the process is extremely helpful.

Since the project must start very quickly, our sales staff and project team use part of the kickoff as a working session. During this working session, we develop specific goals, learn what types of results will be helpful, develop an initial list of testing tasks, and learn about the users that we need to test the application. We also compile a list of what we need from the client. Depending on the project, we may need:

Information about users for both recruiting and for writing the test script. For example, do people regularly use the application or do they only use it occasionally?
Training materials for the application and a subject matter expert who can answer questions.
Background information, feedback, or previous testing materials that give context to the current design or may help us to write screeners and test scripts.
Access to a stable application, especially when it is under development.

Sales & Kickoff Tips

Create a “Do’s & Don’ts” guide to help team members through the process.
Avoid clients who are rigid, who prefer not to participate in the process, or who want long reports.
Use the kickoff as a working session to learn about the participants and potential tasks.
Have a facilitator available with the domain knowledge needed to quickly learn the application.
Refine your methodology before you have a project.

Recruitment

Before starting the project, you called several of your favorite recruiters to see if they could meet the deadline. You’ve gotten information about participants during the kickoff meeting, and now you simply need to write a screener in less than two hours!

Recruiting quality participants is a big challenge. There are two key components to recruiting: writing the screener and scheduling the participants. The screener is a list of questions used to filter out participants who are not appropriate for your study. Scheduling involves calling potential recruits, asking the questions on the screener, and scheduling participants who qualify and are available.

Because scheduling is time-consuming, it’s critical to write the screener immediately; in fact, we often start and finish the screener immediately after the kickoff meeting. That’s why it’s important to get information about participants during this meeting.

The level of effort required to recruit depends upon whether you’ve recruited similar participants before and whether you handle the scheduling internally or externally. If you’ve recruited similar participants before, you can reuse the same screeners almost verbatim. To facilitate recruitment for new participant types, we’ve built a list of standard questions so that, at worst, we need to write only a few new questions. In addition, we use a screener template that has our facility procedures, location, and contact numbers; the facilitator need only fill in the specific test questions.

External schedulers. We typically use external schedulers, which is particularly helpful for QTUT, because it takes burden off the facilitator. I highly recommend contacting your external recruiters before agreeing to do a study to see if they can meet the timeline that you need. If at least one of your external recruiters cannot meet your timeline, do not hesitate to ask your client for assistance before agreeing to the study.

Internal schedulers. If you do your own scheduling for QTUT, you may have a list of participant leads in house, so writing a screener isn’t always necessary. However, depending on your timeline and your success rate when calling, it’s often necessary to ask your client or a co-worker to make the calls for you.

You might be tempted to schedule testing sessions very closely together in order to complete more sessions per day. However, we find it more efficient to leave time between sessions in order to quickly debrief and begin analyzing what we observed during the previous session (I’ll discuss this analysis method in more detail in Part II). You may also need the extra time to modify the testing script as needed before the next session.

Recruitment Tips

Start recruiting as soon as possible.
Create a screener template so that you only need to write the questions.
Reuse questions from past screeners.
If you do your own recruiting, ask a coworker to make the calls for you.
Budget more money than usual when using third party recruiting firms.
Screen carefully but avoid particularly restrictive screeners.
Schedule backup participants (“floaters”) to cover multiple time-slots in case a participant fails to arrive.
Leave time between participants to summarize results and to change the tasks as needed.

Preparation

You’ve started recruiting. You are familiar with the application type but you need to learn this particular application. You need to write the tasks and questions for your test script and you need to clear them with your client.

With recruiting underway, you can turn your attention to learning the application and writing the test script.

One critical note in our sales guide is to avoid aggressive timelines for applications in unfamiliar domains or those which require extensive training. Even if you’ve followed this advice, you will still likely need to learn certain aspects of the application.

It may seem obvious, but you cannot learn an application if you do not have access to it. Often the clients who come to us are still developing the application, so be sure to schedule adequate access to a stable version.

After you’ve had a chance to learn the application, writing tasks and questions for QTUT is similar to a normal study. We rely on client stakeholders more than usual because they help to prioritize testing needs and to identify key tasks. In QTUT, most clients are releasing soon so they’re more interested in finding easy-fix problems than in statistical data or qualitative feedback. Consequently, we tend to focus our effort on creating tasks vs. writing a lot of questions. You also need to consider what you can realistically summarize quickly. For example, if it takes two hours to compile error rates, then eliminate error tracking from your test plan.

We run pilot tests as early as possible because they help us more rapidly iterate and improve the script. Keep in mind that you probably will not have perfected your script when your first participant arrives, so you may need to modify slightly the tasks and questions between sessions.

Preparation Tips

Avoid gathering data that takes a lot of time to compile and analyze.
Use open-ended questions such as “Tell me about what you did yesterday at work” and allow time for discussion with the participant in order to learn about them during their session.
For tasks that require more information that you currently know about participants, use a series of questions to build more realistic tasks.
Use Likert-style scales to get data if you need it, and rely less on task completion data (as your tasks may often change).

Next time: Part II

In Part II, I will discuss how to facilitate the sessions, and I’ll describe a novel approach to analyzing and reporting the results.

Getting a Form's Structure Right: Designing Usable Online Email Applications

afshan kirmani — Thu, 18 Sep 2008 10:42:52 GMT

I started writing this article with an emphasis on the financial domain. I then realized that I would like to broaden the focus because my findings are also applicable to a general domain like email account registrations, for example. In this article, I would like to take a simple example of how users register for an email account online. For a first timer, is the transition from a real world of letter writing to the online medium easy? And for a frequent user, is he or she motivated enough to create an email account with another service provider?

Yes, this is for all of you out there—my fellow usability practitioners, information architects, designers, managers, project leads, editors, and people who are looking to develop their UX practice.

In the modern family, where often both parents are working full-time and the children are involved in many after-school activities, people may only have a few minutes to spare on an important task during the day. And it’s the Internet that supposedly helps people achieve this. But do we, as designers and usability practitioners, always help them do it? I say, “No.”

Just the other day, a friend of mine begins to complain of the spam mails that she receives everyday. “I have two separate email ID’s to keep myself away from such mails—one for official purposes and the other for my junk emails. But even my official ID seems to be flooded with these emails. So I found myself moving to another email service provider. Again, I found myself grappling with the registration process.”

There are three people who determine success of a web-based form: the usability practitioner, the designer, and the user (Image 1). Taking a simple everyday example like an email service, I aim to discuss the various aspects that lead to a great forms structure.

Image 1: Success of a web-based form requires involvement of a usability practitioner, designer, and user.

There are a million websites out there. There are a million email service providers out there. How do you ensure that you gain the right audience to join your service? What are those factors that will help users move ahead and become your loyal customer? Part of the answer has to do with the first step: REGISTRATION!

In the first part of this series, I will focus on the basic issues that a usability practitioner must address to create a usable web-based form:

Affordance
Orientation
Chunking

1. Affordance: The Lure

We all know how grueling and tedious a registration process can be. Therefore, we need to ensure that our sites adequately “lure” users into the process. To do this successfully is not just a matter of providing the right cues, but how and where we provide them.

Coming from the real world

Every online form was created keeping the real world in mind. We all once began filling in forms in real life before we began moving to the online medium of getting things done quicker.

Email service providers must allow for a smooth transition from a real world scenario to the internet, for those who are petrified of it. Users should know the advantages of the service provided as compared to the real world scenario of letter writing. Why would users move to your service when they can just write a letter? What are the advantages of sending an email? Is it quick? It is easy? These issues should be addressed upfront to ensure that they are lured forward.

None of the websites that I reviewed follow this practice effectively.

Entry points

An entry point to an application must be clear and appropriate to the specific needs of the user. For example, let’s say a user visits a website to send out an email to a distant relative. He or she has never used a web-based email service before. Not knowing that he/she needs to register, they would look for a direct cue to send out an email. Where do you think this user would look for a cue? This is where you need to perform a quick goal-task analysis. Let’s consider a scenario:

A first timer enters the website to send out an email. This user is hauled because he/she is unsure of their next step.

Let’s have a look at Gmail, our most used email provider. Most websites that I reviewed allow you to register. But users are not lured into it. As a first time user of a website, they need to know the benefits of registering clearly, up front. Gmail does a good job of this (Image 2).

Users often hate to register. Therefore, as usability practitioners, we need to tell them of the benefits of registration when they enter a website for the first time.

Image 2: A good example of enticing users to register online by clearly listing the benefits up front.

Service/Product comparison

Remember, your users are watching your competitors as well. So if you aren’t that big in the market, how exactly would you think big? Compare your features with that of your competitors to formulate your strengths over the others in the market. Let’s see how Bluebottle effectively does this (Image 3).

Image 3: Bluebottle’s website allows users to take a peek at service comparisons. Users also have the freedom to view a detailed comparison.

Online benefits

It is important to inform the user up front of what they will gain after registering. It’s a competitive world out there and users must and should know what the website is selling them. This affirms the brand’s identity and responsibility to gain customers online. A basic cue reassuring users about the benefits helps build trust which encourages them to use your services. As shown in image 2, Gmail clearly provides the online benefits.

Another clever way to entice them is to provide a view of what the service looks like once they have registered or applied. In this case, it would be ideal to show users on the homepage a view of what their personal landing page (the inbox) would look like once they have registered.

None of the websites that I reviewed follow this practice rightly.

Security

It is essential that users know that the information they are entering will be secure. A basic “Lock” or “Key” icon would do the trick. Also, providing them with security information and its benefits improves customer loyalty and trust. With the case of Yahoo, the website uniquely utilizes this feature to grab users towards their secure service (Image 4).

Image 4: Providing a security message increases loyalty which moves users towards registering.

Taking a tour

Before users move ahead to encounter a form, it is necessary to tell them why they need to do it and most importantly how they need to do it. Again, taking the same examples forward, if you look at the example below, you will see how AIM Mail allows users to take a tour (Image 5). This also gives an edge to its competitors as they are showing them of what’s inside even before registering.

Image 5: The website allows users to take a tour before registering.

User’s path forward

This doesn’t just end with the benefits. Users have to be told where to go after they have been guided. All websites do provide a way to move ahead. But I specifically want to use an example that can show improvement in terms of placement of this cue, which is most important while users are making a decision.

We love Gmail. But we sometimes wish it were always right.

Provide users with a clear path forward AFTER you are done enticing them with the meat.

Image 6: The website must provide a clear path forward after enticing users with the benefits.

Consistent design

As users transition from the homepage to the form, it is important that the design of the pages remain consistent. Any small change in the design or layout could affect their performance and decrease the overall experience.

Most websites get this right. But we can still look for improvement. Let’s have a look at the example below (Image 7). Here, as users move from the landing page to the form, we see significant changes in the layout and the visual design.

Image 7: The design of the page is inconsistent with the previous page.

An overview of what’s to come

As users enter the application, they need to know what to expect, however short it maybe. Therefore, throwing users directly into a form is not the best way to help them achieve their goals. Instead, the website must first provide users with an overview of what’s to come, including the application requirements and the next steps. This can be just a few lines telling them of the benefits, the things that are expected and an instant access to their emails soon after they are done.

Let’s have a look at Yahoo as an example (Image 8). It doesn’t do a perfect job. But it’s nearly there. All the information that the user is expected to provide during the registration process is described up front.

Image 8: The website informs users of what is expected of them while registering.

Lending a helping hand

We all know that people fumble along the way. Heck, sometimes I come across forms that I don’t understand. Therefore, it is essential to provide users with online help whenever needed.

For applications that drive business, a toll free number is essential as this brings in the revenue. But with the case of an email service provider, online help would suffice.

The visibility and location of the help link is equally important. By providing this, you can ensure that users not only find it quickly but also feel safe just by seeing it. This is also useful for first time users who are just transitioning from the real world of letter writing to the web world of emails.

None of the websites that I reviewed follow this practice successfully.

Language aid

There are websites that allow users to view their services in the language they choose. This should also be the case with web forms. Choosing the language of their choice gives them freedom and control. It also helps them move forward and register as they can be assured that the website caters to their needs as well.

Image 9: The website provides a way for users to set their language preferences.

Save and continue

Let’s say that the basic goal is to register online, so why not just save users’ information automatically as they proceed? A basic “Save and Continue” button would not only tell users that their information is automatically saved but it would also allow them to access the information if they need to resume the application later.

Now if your form is just a page long, you would obviously need a button that reads “submit” or “done”.

Most websites only follow the later.

2. Orientation

Form title

Ensuring that the page header follows a clear task flow from the preceding cue helps applicants orient themselves to the page. Most websites do this successfully. Let’s take a look at the example below (Image 10). Gmail follows a clear flow from one page to another, telling the users where they are at each specific point in time.

Image 10: The website provides a clear orientation feedback to the users as they move from one page to another.

Progress indicator

How ever short or long your application form maybe, users need to know their path ahead. A well-positioned progress indicator outlining the entire application process helps users see what lies ahead of them. There’s no use of providing the progress indicator on the left or the right of the form. Users need it up front as they do not tend to look to the left or the right of the form when they are entering information into an application. The best way to grab the user’s attention is to display the progress indicator on the top of every page of the application.

Let’s have a look at an example below (Image 11). This website has got the concept right. Yet, it can further deliver what’s best for users at this point. If you are providing users with a form, make sure that you tell them what each step entails. For example, Step 1: Enter your personal details. The example below does provide a progress indicator by telling users of the number of steps ahead. Yet, it fails to mention the step details.

Image 11: An example of a progress indicator. Though, the website needs to take a further step to provide the step details.

Progress feedback

More than 60% of web-based forms that I’ve encountered add in extra steps along the way, ones not included in the progress indicator. As applicants do not see all the steps up front, they are baffled when additional steps start appearing. When you tell users that the form entails 3 steps, don’t cheat them. Keep it to 3 however tempted you might be. With the example above (Image 11), users are probed into a number of pages, viewing the same orientation feedback for pages to come. Make sure that each step is provided on the same page. Moving them through pages and providing them with the same orientation feedback is only going to cause confusion.

3. Chunking

People perceive information more easily when related parts are grouped. This increases users’ efficiency and reduces reading effort. Chunking information into related parts helps users better understand information to navigate more effectively.

Headers

Ensure that you break the form into logical content groups and provide relevant headers for each information chunk. I have seen more than 90% of web forms that just provide the main header and then continue with about 20 questions on the same page. This can overwhelm a user. A quick way to organize information into groups would be to do a card sort with potential users of the application or even your co-workers. An example of effective chunking is found at Yahoo and My Way (Image 12 and 13).

A clever trick is to number the chunks to allow users to perceive how much is left and also to perceive that they are moving forward. It provides clear direction of a way forward.

Image 12: The form is well-chunked, with clear headers describing the grouped content.

Image 13: The form is well-chunked, with clear headers describing the grouped content.

Labels

Labels on individual pages within the application process must be related to the main header as well as its elements. For example, forms should display a clear and simple header along with related sub-headers. In the example above (Image 12 and 13), the sub-headers (labels) are clearly grouped with their header. You have personal information and password information separated with clear headers that define the structure. This provides clarity and direction.

Summary

As usability practitioners, we need to first and foremost understand the user’s intentions and expectations, in order to provide an online experience that accommodates them. The image below (Image 14) shows the mapping between the user’s intentions and expectations and the ways in which the usability practitioner can help accommodate them in order to ensure the ultimate success of online application forms.

Image 14: The usability practitioner ensures that the form’s structure accommodates the user’s mental model, experience, and expectations.

The journey of creating a successful online application form requires three people working in parallel: the usability practitioner, the designer, and the user. The usability practitioner needs to keep in mind the big picture. The designer needs to have a clear understanding of all the details that will go into the form’s structure. The user helps shape the overall approach to the application form and ensures its ultimate success.

You might agree, partially agree, or even disagree with my thoughts. You might even have something to add to this. Let’s hear your point of view. We are innovating, remember?

Coming up…

The next part of this article will focus on the designer’s role in the process of creating the form’s structure, layout, segmentation, widgets, color schemes, formatting, alignment, and consistency.

References

“GUI Design for Dummies” by Laura Arlov, 1997
“GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers” by Jeff Johnson, 2000

Information Architecture for Audio: Doing It Right

Jens Jacobsen — Fri, 12 Sep 2008 12:02:04 GMT

Content today is increasingly delivered by audio both online and in the real world. We have radio shows and newscasts, and in recent years, podcasts, audio books and navigation/car assistance systems have been added to the field. Audio is more emotional, as sound effects and acoustic atmosphere enhance content to help deliver its messages. It also affords users the opportunity to interact with content while their hands and eyes are busy (i.e. when doing physical work, driving, walking, etc).

However, the inclusion of audio often results in usability issues that make it difficult for users to access and understand content. That is why we need new tools to organize linear content like audio. Luckily, a wide range of techniques employed in information architecture, journalism, usability engineering and interface design are available. All that’s required is the knowledge to combine them effectively. This article presents a practical framework for designing and implementing audio-based content, such as podcasts.

The Problem with Audio

When using audio today, we face challenges similar to those of written text about a decade ago. During this time, information was being transferred from hand-held documents to the computer screen, without being optimized for the new online medium. Now the same mistakes are being repeated with audio. Existing text is read by a narrator, or worse, the text is speech-synthesized by a computer. Audio doesn’t function the same way as written text, so its execution is often poor. The main difference between printed text, be it on paper or on the computer screen, is that audio is linear. You can only consume it in a linear fashion and you have to listen to it at a given speed.

Figure 1: Part of the “Web Trend Map by Information Architects, Japan

For example, Figure 1 shows part of the famous “Web Trend Map by Information Architects Japan”:http://informationarchitects.jp/web-trend-map-2008-beta/. It’s an excellent example of how information can be displayed in a two-dimensional space. It’s not possible to use one-dimensional spoken text in the same way. When accessing audio, users have no idea how long the segment will last, unless this information is provided by the interface or the narrator states it at the beginning of the segment. Users only have a vague idea of where they are within the narration. If you don’t have any visual hints it’s difficult to determine how much time is left and what topics are going to be discussed. Finding specific content by rewinding or forwarding is difficult. In contrast, finding the next subsection within a text document is very simple. You can easily find a particular word on a page by scanning it or by using your browser’s find function.

Best Practices for Audio

When beginning an audio-related project, ask yourself whether audio is the right medium for your message. In some cases, text is a better choice and in other cases it’s video. Don’t use audio just because you can. If you are certain audio is the best choice, there are several fields to help inform how you implement it. The most important professions we can learn from include:

Information Architecture
Journalism
Educational Psychology
Usability Engineering
Interface Design

Information Architecture for Audio

The principles of information architecture are exactly what you need to create usable audio. Your approach to creating audio should be similar to developing a large website. In both scenarios you don’t want the user to get lost or overwhelmed by content. For any informational audio that is longer than a few minutes, follow these guidelines:

State the Length: Typically the user has no way to assess the length of the audio segment. Sometimes the length is provided by the interface, but not always accessible. For example, if you listen to a podcast with your MP3 player, it might be in your pocket so you don’t see the time and duration displayed on the device.

Give an Overview of the Structure: Informing users how the audio is structured helps them find the content they’re looking for. It also gives them the option to directly locate the information they’re most interested in.

Introduce the Topic: An introduction helps set the mood and prepares the listener for the content to come. In printed text, such an introduction might seem hackneyed, but with audio it’s good practice to describe a situation the listener knows from everyday life. It’s better not to jump right into the topic, but instead provide some information about it.

Provide Orientation from Time to Time: If the audio is longer than a few minutes, help the user form a mental model of the content by repeating its structure from time to time. Tell the user where they are within the content and give an overview of up-coming topics. For longer audio pieces, consider giving users the option to skip sections/chapters via the interface or offer content in segments.

Journalism for Audio

Radio has been around for more than a century, and most of the best practices from radio journalism are ideal for creating usable audio. Here are some of the most important points.

Keep it Short: Ideally, audio narration should be shorter than printed text covering the same subject. If you have three pages of printed text, don’t write three pages of text for the narrator. Since users are unable to easily scan audio content and must listen at the narrator’s speed, concentrate on the most important content.

Moreover, the sentences and the individual words should be kept short. It is much more difficult to comprehend a long, complicated sentence read aloud than to read it in print.

Repeat Often: Repetition is something you usually try to avoid with written text. With audio, however, it helps to get your point across if the most important facts are summarized and repeated. The key is a summary at the end of the audio. It’s also a good idea to repeat the main subjects or themes rather than referring to them by pronouns or synonyms. The text might seem strange when you read it, but as soon as you hear it, you will realize the audio is easier to follow.

Use Mental Pictures: Good journalistic audio sparks the listener’s imagination. It not only makes the piece more entertaining, it also helps the user understand and remember it. Try to create pictures in the listener’s mind. Describe what they might see and feel if they were in your place. For example, let them hear the sounds of the location where your story is set.

Take Advantage of the Possibilities: Different styles of speech, tone, speed and dialects can be used to create memorable audio. When the language is too formal, you lose credibility and narration is more difficult to understand.

Don’t Overuse the Thesaurus: This is another piece of advice from radio journalism. When you use overuse synonyms, you decrease comprehension. The listener has to decipher the synonyms while the narrator continues talking, so he might not understand some of the text. For example, when referencing Japan, avoid using the terms “Nippon” or “Land of the Rising Sun.”

Here is an example of how to structure an audio sequence:

1. Greeting
2. Introduction (i.e. audio length, what subjects/topics will be covered and how the user can interact)
3. First section of content
4. Describe the structure (i.e. summaries, repetition, overview and acoustic bumpers)
5. Repeat Steps 3 and 4 until all content is delivered
6. Conclusion (i.e. summary or what action users can take next)
7. Farewell

This structure is derived from the typical sequence of a radio show and has been successfully adopted by many podcasters.

Educational Psychology for Audio

Much research has been conducted on reader comprehension and written text, notably the work of Norbert Groeben from 1972 onward. Most of the results show that the techniques from information architecture and radio journalism cited above are also valuable for creating accessible content to be used in an academic setting.

Keep Short-term Memory In Mind: It is important to write short sentences and to repeat words rather than using synonyms.
Design Audio Content for Different Reading Speeds: Research shows that reading speed varies by individual, depending on age, familiarity with the subject, education and other factors, so it’s important to adapt the complexity and the reading speed of the narrator to your intended audience.

Usability Engineering for Audio

Because audio differs, some of the established techniques used in web development cannot be applied audio. Wireframes, card sorting exercises or eye tracking can be used to evaluate information architecture or interface design, but these techniques do not work for developing and testing audio content. Still, we can borrow from usability engineering when including audio:

Design for the Target Audience: It’s still uncommon to apply the techniques of user-centered design to audio, but do convince your design team to produce content for the users, not its creators.

Create Personas: Personas are the perfect method for representing your target audience, so use them.

Create Scenarios: Usage scenarios are a technique you can successfully apply when creating audio content. It is crucial to understand the user’s:
- Environment (i.e. quiet or noisy)
- Access Possibilities (i.e. Do users need to rely on their eyesight or hands right now? When driving or working out eyes and hands are mostly occupied.)
- Mood (i.e. passive/reclined or active/leaning forward)
- Expectations (i.e. entertainment or information)
- Experience (with interface as well as with content)
Test With Users: If possible, test early versions with selected users from the target audience. Usability testing in a research lab is best, but informal tests are a good start.

Conduct Log File Analysis: Do your statistics. Look at which files are most frequently downloaded (and the least). Correlate the files with their content and then produce more of the successful content types.

Consider Users’ Goals & Tasks: Figure 2 shows that audio delivered over the web has a different level of interactivity than, say, just listening to the radio. Apart from listening on demand, users can forward or skip through audio. They may also be looking and interacting with other materials at the same time they are listening.

Figure 2: Depending on the context, the amount of interactivity varies.

What’s more, knowing user’s expectations is crucial to creating the appropriate content (Figure 2). With audio this is more important because it is difficult to skip irrelevant information.

Interface Design for Audio

Finally, give careful consideration to the interface that provides access to and control of audio content. Again, the well-known principles of interface design apply. In general, give the user as many hints as possible about what to expect from the audio—before he even starts listening.

Provide a concise description of the content.
When linking, make it clear that an audio file is linked.
Explain how to locate content within the audio piece, if possible.
Include metadata (i.e. ID3 tags in MP3 files that are shown within the playback software, as well as on portable devices).

Figure 3: Podcast page of “The New Yorker website”:http://www.newyorker.com/online/2008/08/11/080811on_audio_grann?xrail

Figure 3 shows the podcast page of the The New Yorker magazine. Much of the information on how to subscribe to the podcast and how to download the audio file is in text. Some short links at the end of the paragraph might work better.

Figure 4: Metadata in iTunes

Above is a good example of metadata displayed via iTunes (Figure 4). Note the long description; it’s concise but not suitable for scanning.

Conclusion

Creating usable audio is not difficult when you follow a few simple rules. These mostly stem from the creation of usable content in the form of text. Information architecture, journalism, educational psychology, usability engineering and interface design provide plentiful tips for doing so. Most of the methods used in these fields can be applied to the creation of audio. To summarize, the main guidelines for usable audio are:

Write with your audience in mind.
Structure your content by providing an overview at the beginning and giving an introduction to longer audio pieces. Be sure to include a summary at the end.
Follow the rules of radio journalism for creating easily understandable narratives.
Rely on a familiar interface or put your design in front of users if you digress from a familiar practice.

If you follow these tips you will be able to create audio that is easily accessible, engaging and helps to communicate your message, not only intellectually but also emotionally. After all, emotional quality is one audio’s main advantages over text.

IDEA 2008: An Interview with Elliott Malkin

Liz Danzico — Fri, 12 Sep 2008 12:01:51 GMT

Even if you’re trying to find one, the connections among Elliott Malkin’s body of work are hard to see. Part family history, part science project, part home-movie, his projects span genres that, initially, seem incidental. Yet many of his web-based projects—whether they investigate “butterfly vision” or install digital graffiti throughout lower Manhattan—are connected in one simple way: they all explore unofficial signals in public space. Taking on the invisible and the imagined, his projects invite viewers to imagine things that operate beyond their perception.

His latest project, Graffiti for Butterflies, is even further afield from his typical subjects as it deals with natural science. By directing Monarch butterflies to urban food sources it “is the equivalent of a fast-food sign on a highway, advertising rest stops (waystations) to monarchs traveling through the area.”

At the upcoming IDEA conference, Malkin will discuss some of his more renowned projects, as well as some material not yet seen online. I recently got some of his time to find out more about it.

Liz Danzico: As an artist, your work investigates the overlap between memory, information, and physical space. How did you begin investigating memory as a key part of your subject matter?

Elliott Malkin: I’m actually not that interested in memory in the abstract. I’m more interested in what’s stored there, namely, the memories. For a time I was obsessed with reconstructing the life of someone I had never met, my great-grandfather Hyman Victor. I enjoyed the process—excavating memories from those who knew him. But I was probably more interested in the traces of him that remained in the physical record, first at his gravestone, then on microfilm inside government archives.

Ultimately, I found much of the information about Hyman on genealogical websites. While the memories continued to disintegrate everywhere else, on the Internet they seemed fairly well preserved (though even these will fade.) I compiled the results of this investigation at Everything I Know About Hyman Victor. I also created a device called Cemetery 2.0 that attempts to address the limitations I saw in the way that information about people is preserved.

LD: What kinds of limitations were you seeing, and how did Cemetery 2.0 intend to remedy them?

EM: Mainly that gravestones tend to provide little information about the life of a person beyond their name, date of birth, and date of death. Almost all other information about the person’s life is decaying in public archives, dispersed in fragments across the Internet, and, sadly, fading away in survivors’ minds. My idea for Cemetery 2.0 was to bundle all surviving information with their actual grave. I did this by establishing a wireless connection to the world’s most comprehensive online genealogical database, where amateur genealogists are constantly uploading and revising records about their forebears.

LD: How has an investigation of your family helped you explore information and memory? Do they mind being the public subject of your art?

EM: I suspect Hyman Victor would have appreciated his great-grandson taking an interest in him. But I take it you’re asking me about my video projects, such as Family Movie, in which I have my parents reconstruct scenes from our trove of Super 8 home movies from the 1970s. They’ve seen themselves on the big screen and on my website, and seem to get a kick out of it. As for my interest in my family, it’s probably an expression of self-absorption. That said, I tend to widen my definition of self to encompass broader categories, such as American Jew. But not all of my work deals so directly with myself or my family. I have a feeling that when I finish Mother’s History of Birds, my autobiographical streak will be satisfied.

LD: Your latest project, Graffiti for Butterflies, seems to deviate from your previous work in that it deals with natural science. How does this project fit within the larger evolution of your work, if at all?

EM: Well, it uses graffiti, which are unofficial signals in public space, something I’ve dealt with numerous times in my previous work. In eRuv I put semacode stickers on various street corners to reconstruct a sacred space that once existed on the Lower East Side of Manhattan. In Modern Orthodox I took it a step further, using graffiti to demarcate conceptual boundaries directly onto the surface of the city. In both of these cases, my audience was human. In Graffiti for Butterflies, my audience included butterflies. And there is a further connection to my other work dealing with the invisible or the imagined, in that the ultraviolet aspect of the graffiti operates beyond our perception.

LD: What are the differences between designing for humans versus designing for, well, non-humans? How can you understand your audience when there’s no empathy, or possibility for empathy, between you and them?

EM: It can be argued that I don’t have much empathy with my human audience, but that’s a separate question. When designing for butterflies, I make assumptions about butterfly behavior based on my 7th grade-level understanding of Monarch butterflies. I know that they can see ultraviolet light and that they migrate through massive swathes of North America on their way down to Mexico each winter. So I created Graffiti for Butterflies to instigate some thinking about forms of interspecies communication that are, so to speak, symbiotic: aesthetically stimulating to humans, nutritionally beneficial to butterflies.

LD: What will you be talking about at IDEA?

I’m going to discuss my projects that deal with information and public space. I’ll start with some of the work I alluded to above pertaining to the eruv, a symbolic boundary erected around Jewish neighborhoods as part of the observation of the Sabbath, including eRuv and Modern Orthodox. I’ll also discuss Cemetery 2.0 and Graffiti for Butterflies, with plenty of material not seen on my website.

LD: By day, you work as an information architect for NYTimes.com. How does your work as an artist influence your work as an information architect?

EM: It’s not clear how they might influence one another in any explicit sense. At The Times I work within a set of organizational requirements. In my personal work, I define my own requirements. At The Times I iterate on established design patterns to help produce a consistent, quality user experience (and help invent entirely new patterns when necessary).

In my own work I think I see patterns, though I am able to control or distort these patterns in ways that would be absurd and unproductive in a professional context. And to me this draws an essential distinction between design and art. Design has a functional purpose. Designers have clients and external requirements. Art has any or none of the above. It has distortion for the sake of distortion, if I want it to. Or it can solve real-world problems. It’s up to me.

About Elliott Malkin

Elliott Malkin is an artist and information architect whose work explores the intersection of memory, information, and physical space. His work has focused on the eruv, a symbolic boundary erected around Jewish neighborhoods as part of the observation of the Sabbath. This includes eRuv, a virtual reconstruction of an eruv that once existed in lower Manhattan, and Modern Orthodox, a next-generation eruv constructed with lasers and surveillance cameras. Many of Elliott’s other projects concern the use of new media as a proxy for memory. His short film Family Movie is a reconstruction of scenes from his family’s collection of home movies from the 1970’s. He is also the creator of Cemetery 2.0, a device that connects gravestones to the genealogical database of the Mormon Church. His most recent work is Graffiti for Butterflies, a project designed to facilitate interspecies communication between humans and monarch butterflies in urban areas. Elliott is originally from Chicago and currently lives in New York City, where he works as an Information Architect for The New York Times. His work has been featured at Eyebeam, the International Documentary Festival, and The Contemporary Artists’ Center.

About IDEA (Information Design Experience Access)

This conference addresses issues of design for an always-on, always-connected world. Where “cyberspace” is a meaningless term because the online and offline worlds cannot be made distinct. Where physical spaces are so complex that detailed wayfinding is necessary to navigate them. Where work processes have become so involved, and so digitized, that we need new processes to manage those processes.

This conference brings together people who are addressing these challenges head on. Speakers from a variety of backgrounds will discuss designing complex information spaces in the physical and virtual worlds.