Yahoo! Mail: Simplicity Holds Up Over Time

by:   |  Posted on

Email was one of the first applications to move to the web, and the first to find widespread popularity among users.

In many respects, email is the ideal web application: it’s an application that people often need access to when they’re away from their “home” environment, and the core user tasks (reading and writing) are easily accommodated with standard HTML interface elements.

As a result, it should come as little surprise that the basic flow of Yahoo! Mail has hardly changed at all since the portal first acquired the RocketMail service in 1997. But rather than offering an outdated solution to the web-based email problem, Yahoo! Mail demonstrates the lasting effectiveness of a simple approach.

The application is extremely conservative with page designs. Almost all user interaction takes place across only three pages: the “message list” folder view, the “message display” page, and the “compose” page.

Another demonstration of this conservative approach is in the site’s error handling. The entire application contains only one standalone error page (the “no account found” page in the login flow), and this seems more likely to be the result of a back-end limitation than a deliberate design choice.

A few awkward spots do appear in the flow. An empty search result set returns a search result page with a “no messages found” message, rather than bringing the user directly back to the query interface to retry the search.

Downloading attachments is a two-step process, which seems like one step too many. The dichotomy between viewing and editing contact information in the address book seems like an artificial distinction whose purpose is unclear. But these are really minor quibbles; overall, Yahoo! Mail is a model of streamlined interaction design.

Yahoo! Mail diagram
Poster-sized diagram ( PDF, 37K) | Letter-sized diagram ( PDF, 100K)

Note: The date on the diagram indicates when the snapshot of the system was taken. Yahoo! Mail may be substantially different now.

Jesse James Garrett has been working in the Internet industry since 1995. In the information architecture community, Jesse is recognized as a leading contributor to the development of this rapidly evolving discipline.

When the Show Must Go On, It’s Time to Collaborate Or Die

by:   |  Posted on

It was a tense meeting. Forty-eight hours before launch and a key multimedia effect was still not ready. The developers were trying to catch up on a long punch list of bugs; the designers wanted last-minute changes to things that were already on the “done” list. No one knew what to do. But there was a deadline, and the reviewers were coming. As a team, we walked through the schedule again and again until we had a plan. The next day, the video was edited, the shop finished the screens, and the production crew walked through the critical paths. Two nights later, the cannon fired, the song began, the screen dropped into place, the film played just as we’d envisioned it, and the cast members of “A Man’s A Man” took their bows before an appreciative live audience. Another show had opened.

Photo from "A Man’s A Man"
“A Man’s A Man” by Bertold Brecht Hyde Park Festival Theater, 1986. Directed by Tim Mayer. Lighting by Whitney Quesenbery. With Bill Murray, Stockard Channing, Gerrit Graham, Mark Metcalf, Brian Doyle-Murray, Bob Halley, Jr.

I became a lighting designer because I was in love with live theater, where lighting only exists in real time as part of the performance. Certainly, it has a utilitarian role: to put enough light on the stage so that the audience can see the actors. But the lighting also helps shape the performance by providing the color and overtones that add meaning and layers and depth. The same mix of art and technology, craft and discipline exists in user interface design.

Fast forward a few years, and it’s another tense meeting. Our demo was part of a presentation to the board of directors who were voting on whether to fund a new multimedia news service, but the video encoding was taking longer than we expected, and we weren’t sure if the bookmark feature would be intuitive enough. More late nights and it all came together. Another project launched.

As different as my two careers may seem from the outside, I never thought they were so different. Switching from theater design to interface design, I traded a forty-foot wide proscenium for one that was just seventeen inches across, and the big gestures of the stage for the more subtle movement of a hand on a mouse.

Are we all on the same team?
One thing that software and theater have in common is how many different skills are required. There are individual performance artists who pretty much do it all — write, direct, design, perform — creating perfect gems of performances, just like there are personal websites conceived and created by a single person. But most productions are the results of work by dozens of different people. At the center is the director, surrounded by the production team: designers, choreographer, and musical directors. Each of them has a team of people to create the design. It takes a lot of collaboration to keep everyone’s work in sync. We used to ask, “Are we all designing the same show?”

Sometimes we weren’t. When there was no shared vision–no overall design concept — I would end up in a situation like trying to light a musical comedy with a brown set and dark, brown wool costumes. Brown wool soaks up all the light and dulls the production’s sparkle. The lights may be bright and the actors perky, but the whole effect doesn’t hang together, and the audience can always tell.

But when all the elements work together, the effect is profound.

On the opening night of a new opera that I lit, the curtain opened on a scene that looked just like the pencil sketches from our design brainstorming sessions. Everything had come together to bring that vision to life. It wasn’t just that the stage looked like the picture. A performer told me that it felt like the only place where that opera could possibly take place, that it just “felt right” to be singing that story on that stage.

Original sketch for Tomorrow and Tomorrow   Actual scene from for Tomorrow and Tomorrow
Original sketches and the actual scene for “Tomorrow and Tomorrow” by Timothy Sullivan Center for Contemporary Opera, 1987. This one-act opera is an interior monologue, recounting an unhappy and lonely life. Directed by Stephen Jarrett. Scenery by Robert Edmonds. Lighting by Whitney Quesenbery. With Suzan Hanson.

A theatrical production includes several teams of people. Just in the physical production alone, there are scenery, lighting, costume and sound designers, supported by carpenters, electricians, drapers and a whole raft of craft shops to build and install the sets, props, effects and lights. As many as 50 craftspeople may be working in a theater just a day before opening night. That’s a lot of people, especially for the speed with which shows are produced. The collaboration works only because the roles and responsibilities are well defined and respected.

Despite all my years away from theater, I could still draw a competent light plot. It would not reflect all the new equipment and the design would probably look out of style, but an electrician would still understand it. The design artifacts communicate not only within a single craft, but between disciplines, and they are the language of the collaboration.

We are just beginning to understand all of the roles in designing the user experience. From the brand design that expresses the promise to the user interface that communicates it to the code that supports the functionality and interaction, all of the designers need to be speaking with one voice and a language that lets them work together.

Light plot Cue sheet
There is a standard set of paper work, or design artifacts, that includes the light plot, hookup, cue sheets and, to help the designer, a magic sheet.

If you can’t find it… it might as well not be there.
A lot of the work of putting on a play is simple craft. In lighting design, that means putting all the pieces together in a technically competent way so circuits don’t blow, lights don’t fall, and fire laws are followed. You need to have the lights placed so the entire stage can be lit, effects can be created… and the budget met. Finally, after all the planning and preparation, you go into the theater and create the cues — the looks, timing, and changes in the lighting — and coordinate them with the work of the actors and the other designers. And here, you get a few moments for inspiration and art.

When those moments come, it’s easy to forget that it’s not all about the lighting. The audience comes to see the play, and your work is just one part of the whole thing. Pursue gorgeous chiaroscuro at the expense of illumination and you get lighting that creates an effect of dark shapes. “The ones at the top that don’t move… those are the scenery. The shapes moving at the bottom… those are the actors.” When that happens, the designer has forgotten that, as important as the design is, the audience doesn’t come for the lighting or leave “singing the scenery.” Worse, instead of being wowed, they may just be baffled. It’s hard to hear when you can’t see the actors’ faces, and the brilliant nuances of the design are probably lost on an audience that came for the play.

I used to wonder why so many experienced professionals couldn’t get it right on the first try. Why were scripts that seemed so obviously bad on opening night ever produced? Wasn’t the very heart of the profession being able to visualize the results in advance? But what you can’t see in advance is how it will all fit together. You are supposed to be designing not only the same show, but the one the audience wants to see. That’s why those preview performances are so important: they give the production a chance to add the audience to the collaboration and to knit all the elements together more tightly.

Usability testing… coming to a theater near you
When you’ve worked on a show for several weeks, it’s hard to remember what it’s like to walk in the door and spend two hours seeing the performance unfold. You know all the nuances and characters and turns of plot. But what’s the experience like for an average audience? In software design, the solution to this dilemma is usability testing. In theater, it’s previews. A production used to have out-of-town tryouts. A show would play in smaller cities, testing the production in front of live (and paying) audiences until it was ready for Broadway. Other plays are developed in workshop or regional theater productions. Either way, it gives everyone a chance to see the play “on its feet” and make changes before they face the New York critics. It’s a nightly, elaborate usability test, as audience reaction is scrutinized and the production adjusted (whether minor changes or massive rewrites) until it all works for the audience.

One year, the Big Apple Circus included a famous clown, a top star of the one-ring European circus, with an act that was completely different from the red-nose physical humor of American clowns. His first night, he bombed. The kids just stared at him with no laughs and hardly even a giggle. We all waited for the tantrum, for the star to blame the audience. Instead, the next morning, while we were working on the lights, he brought his trunk into the ring and quietly rehearsed. That night, he got a few laughs, and over the next days he continued to work, changing some bits, dropping some, adding new ones. By the end of the week, he was getting the big laughs and the applause. He didn’t do it by abandoning his style of clowning, but by listening carefully to the audience and learning how to speak to them.

A play is different to everyone who sees it, just like an interface is different to every user. The interaction between the performers and the audience is part of the magic. Software is like that to me: a dance between person and machine, different in small, subtle ways every time, something that comes to life only in the user experience. It’s not surprising that when I was seduced away from theater by a small beige box, it was to design the user interface. The interface is live in the interaction, taking place in real time.

For more information

Want to know more about theatrical design? The two books I have read and re-read are:

Each was a pioneer, changing our vision of how theater is made.

Whitney Quesenbery designs user interfaces for Cognetics Corporation, a design and usability company dedicated to creating excellent user experiences. She is the manager of the STC Usability SIG and a member of the board of directors for UPA.

The Evolving Homepage: The Growth of Three Booksellers

by:   |  Posted on

Web design is expensive. Web designers earn upwards of $50,000 a year1, information architects earn even more.2 During the heyday of web design—the late 1990s—designing a large commercial website could cost as much as designing a medium-sized building. During this period, commercial websites were created and then often completely replaced with redesigned versions a short time later. Today the redesigning continues, albeit at a slower pace. What is the return on this design investment? A report on online ROI from Forrester finds that many commercial sites fail to even try to measure the effectiveness of design changes.3

What lessons have we learned about how design improves the interface between customers and companies?

The web has been with us for about a decade now. We’ve seen some obvious trends, such as greater use of multimedia, search engines, and increasingly sophisticated markup techniques. But these trends were facilitated by changes in technology. What lessons have we learned about how design improves the interface between customers and companies? Perhaps we can start by asking how websites have actually changed over time, and from that we can learn how websites should change in the future.

To start working toward an answer, I compared three eCommerce sites: Borders.com, BarnesandNoble.com, and Amazon.com. Much of the media’s coverage of these websites, especially coverage of Amazon.com, discusses the business models, corporate cultures, and finances of the companies. Since the medium of interaction with these companies is the website, it’s ironic that the media rarely critiques the site design and its effect on business performance.

Because it is the homepage that carries the most responsibility for guiding customers, I examined the homepages of all three sites from a number of years, using screenshots from the Web Archive4. Presumably these large retailers had a great deal to gain, and lose, with these substantial online ventures. By comparing design decisions over time among the three sites, I hoped to discover lessons from their extensive and expensive design experience.

The companies
Competition is fierce in the online bookselling market, currently erupting in offers of “free shipping.” All three companies have annual revenues in the billions of dollars.

Barnes and Noble, which runs a large chain of stores in the United States, claims the largest audience reach of any bricks-and-mortar company with Internet presence.5 Yet, both they and Borders were put on the defensive when Amazon’s growth rocketed. During December, 2001 BarnesandNoble.com attracted over 10 million unique visitors,6 compared to Amazon’s 40 million visitors.7

Borders is the second largest bricks-and-mortar book chain in the U.S. 8 In April 2001, after operating their own online bookstore for several years, Borders announced an agreement to use Amazon’s eCommerce platform to power a co-branded website.

Amazon claims to be the leading online shopping site, having expanded their selection to music, video, auctions, electronics, housewares, computers and more.9 By February of 2002, Amazon, which had pursued a get-big-quick strategy typical of internet companies in the late 1990s, announced its first profitable quarter.10

Criteria
I first studied these sites quantitatively looking for clear trends over time. I then critiqued them in a more qualitative way based on my own experience as both an in-house website designer and as an information architecture consultant.

There are many criteria that could be examined in such a study. I limited myself to those that would, I hoped, reveal as much as possible about the business intent of the design. I looked at criteria such as the type and size of layout, the type and amount of navigation, the amount of images and text, and functionality specific to the industry. Detailed results can be seen in the attached spreadsheet (PDF, 75k).

Analysis

Chart showing growth in length of homepages over time
Click to enlarge.
Note: Missing data due to imperfect records at the Web Archive.

All three sites use very long screens to display content on their homepages.
Using a browser window with a constant width, we can compare the vertical size of each site (all screen references assume an 800 by 600 pixel monitor). The Borders.com homepage grew from a vertical size of about 917 pixels in 1996 to over 3,000 pixels in 1999. Barnes and Noble’s homepage has hovered around 1,500 pixels for the last several years. Amazon’s homepage, which began at only 626 vertical pixels in 1995, stands at roughly 2,156 pixels today. In a web browser, that equals five scrolling screens of information.

Borders.com homepage above the fold, 1999
Borders.com above the fold (1999) Click to enlarge.
Barnes and Noble homepage above the fold, 1999
Barnes and Noble above the fold (1999) Click to enlarge.
Amazon homepage above the fold, 1999
Amazon above the fold (1999) Click to enlarge.

Note: Incomplete web pages are due to imperfect records at the Web Archive.

All three sites evolved to use three-column layouts.
In 1995 and 1996 respectively, Amazon and Borders.com used single-column layouts. By 1999, both of these sites as well as Barnes and Noble used three column layouts.

Amazon has consistently placed more links above the fold.
In 1999, the Borders site displayed only about eight links “above the fold” (the top portion of the screen that is viewable without scrolling). Both Barnes and Noble and Amazon had significantly more links above the fold in 1999, 30 and 48 respectively. Amazon averaged 43 links above the fold between 1999 and 2002 versus only 27 links for Barnes and Noble during the same period.

Through the years, the density of links on Borders.com was half of that on Barnes and Noble or Amazon.
The density of links has varied over time, but as of 2002 both Barnes and Noble and Amazon stood at about one link for every 15 vertical pixels of screen real estate. Historically, the highest link density at Borders.com was one link for every 28 vertical pixels.

Amazon communicates using images and links rather than text descriptions.
From 1999 through 2001, Amazon used more images and fewer text descriptions than Barnes and Noble. In 2002, both sites used about 560 words per page, yet the density of words was 33 percent lower on Amazon; Amazon distributes the words across the page as links rather than bunching them together in paragraphs. Over time, Barnes and Noble is becoming more like Amazon in this respect.

All sites eventually included navigation targeted at specific audiences.
Audience-based navigation—navigation labeled for a particular audience—appeared on Borders.com in 1998, on Barnes and Noble in 2000, and on Amazon as early as 1999.

Invitations to subscribe to an email newsletter were offered inconsistently.
Borders.com didn’t include this feature until 1998. Barnes and Noble included it only in 1998 and 2001. Only Amazon consistently included this feature from 1995 to 2002.

Online and offline design
So what lessons can we learn about how these sites changed over time? How has design contributed to Amazon’s high growth and significant lead over the others? In general, Amazon found a winning formula and applied it consistently over time. In my mind, the successful design elements emulated offline shopping experiences in many ways.

Personally, I was surprised at how long these homepages had grown. Combined with the three-column layout, each page contains a great deal of information. This is quite like the perceptual experience of browsing in a physical store. When you walk down an aisle in a bricks-and-mortar store you can visually scan the shelves quite quickly. On these websites, the long, scrolling pages are analogous to aisles (major groupings of items) and the columns are analogous to shelves (more specific groupings of items). With a similarly natural, efficient motion, a visitor can scroll down the page and visually scan the three columns of product listings.

Amazon homepage
Amazon homepage
(January, 2002)
Click to enlarge.
Barnes and Noble homepage
Barnes and Noble homepage
(January, 2002)
Click to enlarge.

Amazon’s higher number and density of links, and placement of those links above the fold, also reminds me of the aggressive product positioning in a physical store. It’s like walking into a food market and immediately being overwhelmed with rows and rows of colorful fresh fruit, stimulating our eyes and engaging our appetites.

The prominent use of images and sparse use of text on Amazon again harks back to physical objects with simple labeling.

The arrival of navigation intended for specific audiences seemed inevitable. Especially for the book market, a children’s section was developed surprisingly late on these sites given the disproportionately high revenues that come from children’s books in traditional shopping venues.

In general, many of the functions of these pages have become commodities: search engines, shopping carts, authentication and store locators. But Amazon’s extensive personalization sets this site apart functionally. Personalization mimics a personal shopper or a local store employee who knows you. While the online recommendations aren’t always right on, neither is a human assistant.

Rate of change
Many studies have found that our performance using a software application improves over time as we become familiar with its interface. Gerald Lohse and his associates translated this finding into the realm of eCommerce websites using statistical analysis.11 They also found that website visitors learn to use a site more efficiently over time and that this increases their purchase rate. In simpler terms, it means familiar sites are easier for people to use, so familiar sites are where visitors will make purchases.

It follows that sites that can be learned more quickly will more quickly become familiar, increasing the amount of purchases. So a faster learning rate equals a higher purchase rate.

Furthermore, Lohse found that familiarity with a particular website makes visitors less likely to switch to a competitive site because of the effort and time needed to become familiar with another site. He refers to this behavior as “cognitive lock-in.” Essentially, we are creatures of habit. He applied this analysis to several eCommerce websites by measuring the number of visits per person, length of sessions, and timing and frequency of purchases. He found the learning rate significantly faster at Amazon than at Barnes and Noble.

The rate of design change supports this finding. Amazon had no major redesigns from 1999 to 2002, only adapting their design gradually to changing needs. Barnes and Noble significantly altered their navigation in 2000 and 2001. Borders.com implemented major homepage changes in 1998 and 2000. Fewer redesigns make it easier for visitors to remain familiar with the site.

Conclusion
Many design elements on these websites are reminiscent of physical store layout, an approach to web design we should investigate further. Like physical stores, those designs should only change gradually to keep visitors buying. Continued analysis of other sites will hopefully help confirm or deny these findings.

It may be a fallacy to state, “Amazon is a successful business, therefore their website design is successful,” since many factors have contributed to their business success. And yet it’s hard to imagine them having such great success with a mediocre site. A similar eCommerce site launching today could do worse than examine and emulate the design elements that Amazon utilizes.

View all End Notes
Victor Lombardi writes, designs, and counsels, usually in New York City. His personal website is http://www.noisebetweenstations.com.

Getting into Government Consulting

by:   |  Posted on

From Washington, D.C. to Olympia, Washington, there’s a rich potential for user experience (UX) consultants of all flavors to provide services to government. In this article I’ll share some thoughts directed toward you, the independent consultant or small firm that would like to work with government. I’ve tried to imagine what I’d tell you if we sat down for a drink together and you wanted to get into government consulting. Here it is.

On safari in deepest, darkest bureaucracy: Understanding government culture is crucial for ongoing engagement.

Developing a consulting relationship with government can be quite different from your previous experience consulting for business. To help you get started, I’ll outline some lessons I’ve learned in my work with government, in three key areas:

  • Appreciating the differences
  • Understanding the culture
  • Finding your niche

These strategies promote a customer-centric consulting practice—after all, your clients are your customers, and many of the same user-centric principles used in design apply to your business operations. That’s not too different than consulting anywhere else. But your niche in government culture is likely to be something other than what you’re used to in business.

Dorothy, we’re not in Silicon Valley anymore
Assuming that government works just like business will cost you the contract. Appreciating the differences allows you to target your efforts effectively.

For consultants engaging government, focusing on the different levels of jurisdiction is a critical first step in targeting your potential clients. Do you want to work with local, state or federal government? While the federal government makes headlines with “$700 million in new IT spending,” local and state governments are often more accessible and can provide valuable opportunities.

Deciding which segment to serve is largely a factor of access—state and local governments often prefer “hometown” consultants who are sensitive to local issues. Federal contract opportunities exist across the country, but may be too large for independents to tackle alone.

Political ROI trumps all
Once you’ve decided where to focus your attention, someone has to buy in to what you’re offering. In business, return on investment (ROI) drives those kinds of decisions, and the same goes for government. But ROI is so much more than money. In government (and often in business), financial ROI is secondary to political ROI. What do I mean by political ROI? Just that the cost-benefit ratio measures risks and rewards in political terms: how does any given action fit with the current elected policy? What are the ramifications for re-election? Negative media coverage? Public perception? How does it benefit the government, the department, a politician or senior executive? Does it make the job easier? What’s the worst-case scenario?

In the end, you may have a brilliant proposal with significant financial benefits that gets torpedoed because of politics. Selling your services requires you to position yourself as a political solution first—your services need to acknowledge the party line and make bureaucrats, politicians, internal teams and departments look good.

Beware the Ides of November
Even when you’ve covered your political bases, in an election year, all bets are off. This is true at any level of government, not just in presidential elections. A new administration can (and will) extinguish initiatives started by the ousted party. And even in the case of re-election, the focus isn’t on your precious UX proposal—it’s on the election aftermath. Budget announcements, major policy initiatives, departmental shuffles and other shifts in government will interrupt projects, too.

The bottom line is that you need to be patient during upheaval, and even more than being patient, you need to understand the culture of the departments you’re approaching.

On safari in deepest, darkest bureaucracy: Understanding government culture is crucial for ongoing engagement.

Learn the language
Like any foreign land, government has its own language. When traveling abroad abroad, knowing the local lingo—even a bit—goes a long way in building relationships. Without some advance effort on your part, departmental acronyms, official program names, building locations, internal traditions and initiatives can create a maze of jargon that keeps you from making the connections you need to sell your services.

Alongside this idiosyncratic vocabulary that defines your clients’ “national borders,” there is an additional set of buzzwords that can be aligned with UX goals and objectives. The language of eGovernment is full of things like “citizen-centric,” “G2C” (government to citizen), “C2G” (citizen to government), “service-centric,” etc. The actual selection “eGov” buzzwords will vary, but knowing what they mean can let you frame UX issues in terms that mesh well with existing eGovernment projects.

Know the people—top down and bottom up
While you’re learning the language, get to know the people. Consulting relationships are largely about people relationships—assuming you do good work, the difference between business success and failure is often who you know. In government there are two kinds of people who you’ll get to know: “top down” people are the people in charge. While this includes elected politicians, senior civil servants endure between elections and have more to do with strategic policy than many “backbench” politicians.

“Bottom up” people are people in the trenches actually doing the work—the internal web teams, the middle managers. If you can start talking right away with senior people, that’s great; but the grassroots civil servants will sink or float a project with their acceptance (or lack thereof). Use your personal network to make both kinds of contacts when you’re looking for government work. Even if the people you meet don’t have work for you immediately, you will learn more about government culture, establish longer-term relationships, and find leads on work in other departments.

Big picture, little picture
Even if you’re perfectly fluent in local jargon and know heaps of people, you still need to understand the political landscape. Two flavors of politics inform that landscape: the “big picture” of government initiatives and policy (particularly eGovernment or citizen-centric initiatives) and the “little picture” daily reality of how your client fits into those initiatives.

The “big picture” is usually public—take the time to get to know more than the sound bites from the 6 o’clock news by reading policy documents, studying up on current initiatives, and talking with your contacts to get the word on the street. Those same contacts can help you see the “little picture,” which is no less important. Understanding how your clients fit into the big picture—and where they’d like to fit into the big picture—goes a long way to in tailoring your offering.

Symbiosis is reality: Finding your niche means working with others
So you’ve learned the language, know the people and the landscape, understand the power of political ROI… now what?

While there may be small projects you can tackle on your own, many of the contracts considered in government are beyond the means of an independent or small consulting firm, particularly since the contracts are often package deals (there is the expectation that you will scope the project, create the spec and design, and then build it, maintain it and support it).

Think about working with existing development teams—this routes around the limitations of a smaller shop. This approach can take the form of supporting in-house efforts or working alongside a larger contractor (right now I’m working with an in-house government team; over the summer I did the UI design for a $1.2 million government extranet application that a large contractor is building). Since you can’t compete with larger firms, cooperate with them or change the field on which you compete by doing things they don’t do.

Go get ’em, Tiger 😉
That’s all there is to it. Well, not really. There’s more to consulting with government than this article can cover. But if you appreciate the differences, build connections and cultural understanding and pursue good partnerships, things are off to a good start. Drop me a line and let me know how it goes. Maybe we can go out for a drink.

For more information:

  • California eGovernment Plan
    http://www.ss.ca.gov/executive/bj_tech_plan.htm
    Most governments have a similar public policy document that you can find on their website. It’s required reading before any pitch.
  • Six Ways eGovernment Can Alienate Citizens
    http://infocentre.frontend.com/servlet/Infocentre?access=no&page=article&rows=5&id=265
    Sometimes good ideas get taken too far—in usability testing with over 40 participants, the life events model didn’t scale well to meet a wide variety of information needs.
  • Building Better eGovernment: Tools for Transformation
    http://www.nga.org/center/egovernment/
    Knowing current trends in eGovernment means that you’re being customer-centric in developing your own practice—after all we should practice what we preach.
Jess McMullin is active in the online UX community. He is on the CHI-WEB moderation team, is a User Experience Architect and serves on the info-arch.org advisory board. In his spare time he’s a family man. His personal site is www.interactionary.com

Welcome to Boxes and Arrows

by:   |  Posted on

Many months ago, an information architect named David Bloxsom came over for lunch. We both faced an idle post-crash afternoon, so a bottle of Trader Joe’s three-dollar pinot grigio was cracked. We talked about information architecture and trying to get the field to mature. We talked about how the ASIS journal was too academic, too complex for most folks to penetrate. We talked about Web Review, Site Point, and A List Apart and how they were just too basic for most IAs we knew. By the time the bottle was empty we had sunburns and a vision for a magazine. A magazine that would be plainspoken and smart, that would tackle the thorny issues that trying to design structure in new information spaces such as the web, software and wireless created. A journal for practitioners, for those everyday folks just trying to make their product better while ducking the layoff ax.

I hope this ’zine will make us all a bit smarter when we are through. And that is bigger than any tagline, bigger than our semantic antics, bigger than the politics and cross-company infighting.

Next (after a nap) I emailed around to create my dream team… all IAs, but all from different backgrounds. Former designers, programmers, writers and usability wonks that had stepped up and said, “This thing needs an architecture,” and proceeded to design something better. I wanted a journal that was by IAs for IAs.

But I suppose this was a foolhardy assumption on my part—I considered them purely IAs because they did what I did and I was an IA. But they also considered themselves interaction designers, experience designers, user experience designers…well, you get the picture. Over the last several weeks, all the issues we’ve seen again and again on listservs and blogs rose up again among my carefully chosen staff. The best laid plans of mice and me…

But it wasn’t a waste of time. Through all these arguments, we hit upon a shared struggle we all were engaged in—the fight to bring thoughtful design to the new digital medium.

From all of this, we wrote our mission statement:

Boxes and Arrows is the definitive source for the complex task of bringing architecture and design to the digital landscape. There are various titles and professions associated with this undertaking—information architecture, information design, interaction design, interface design—but when we looked at the work that we were actually doing, we found a “community of practice” with similarities in outlook and approach that far outweighed our differences.

Boxes and Arrows is a peer-written journal dedicated to discussing, improving and promoting the work of this community, through the sharing of exemplary technique, innovation and informed opinion.

Boxes and Arrows strives to provoke thinking among our peers, to push the limits of the accepted boundaries of these practices and to challenge the status quo by teaching new or better techniques that translate into results for our companies, our clients and our comrades.

I’m not sure what I can tell you beyond that mission statement.

It’s time for the web (and software, and portable apps) to grow up.
It’s time for us to come to terms with our terms.
It’s time to discover our best practices, our most effective techniques and tools.
It’s time to learn from others in the field and stop navel gazing.

And we need a place to do that.

It is my very great hope that Boxes and Arrows can be that place. A place for designers—who think design is more than pretty font colors—to exchange ideas. A place for programmers—who realize the elegance of code means nothing if people can’t use your application—to learn to make their interface just as elegant. A place for marketers—who know that click-throughs are no good if people click away a second later—to sort out what really creates brand loyalty. A place for information architects, interaction designers, information designers and interface designers to come together with the UXs and EDs and HCIs and build a discipline that will make a difference.

This is a place free of jargon.

We aren’t messing around here: we want answers. That means we won’t hide our ignorance behind terminology. If we know it, we’ll say it. If we don’t get it, we hope you folks will use the comment feature to straighten us out, or better yet, submit an article or case study of your own. This is our journal—yours and ours, audience and authors and staff together. We’re tearing down the fences we so hastily built between our crafts, and we hope to build something better.

I hope this ’zine will make us all a bit smarter when we are through. And that is bigger than any tagline, bigger than our semantic antics, bigger than the politics and cross-company infighting.

It’s ambitious, I know.

Welcome to Boxes and Arrows…

Christina Wodtke
Publisher, Producer and Fool
Boxes and Arrows
“architecting the damn thing”