Now that Apple has officially released the iPad we want to start designing for it. While Apple’s interface builder is great, it doesn’t really allow us to create custom UI elements on the fly. We decided to take a page from our iPhone GUI PSD and create one for the iPad.

The PSD was constructed using vectors, so it’s fully editable and scalable. You’ll notice there are a few new UI elements as compared to the iPhone interface. The workable screen design is formatted to 768×1024 so anything you design in the Photoshop file can easily be brought over to the SDK.

It’s 1.0 so I’m sure we’ll notice missing elements as we begin to use it. We’ll perodically update it to include new elements as we notice them or as they become available through any SDK updates.

If you like it or use it, help us out by retweeting it.

Download The iPad GUI PSD Here (24MB)

(Thanks to Finn O’Hara for the photo)

Last year, I gave a presentation at MeshU that took a behind the scenes look at how we arrive at design decisions. We’ve since taken clients through variations of this presentation, which is always evolving because it corresponds to such a perennial and fundamental question in our field.

I’ve always appreciated it when fellow UXD practitioners talk candidly about what works and doesn’t work for them. Insights and methods pioneered by others have helped us improve our process here at T+L a lot. Maybe our spin on things will be helpful to you and your team.

Here’s the presentation

During a recent pitch, one of our clients asked us to come back and explain how we “bridge art and science” when making design decisions. I think this is an intriguing way to pose the question (and it speaks to how clients are becoming more engaged and sophisticated in what they’re looking for from a design shop).

Let’s start by defining our terms (Slides 1 through 20). Here are a few conventional ways to differentiate between art and science when it comes to user experience design (please note that I’m speaking in stereotypical terms here): In terms of focus, an artistic process is concerned with issues of look-and-feel, whereas a scientific approach focuses on deeper, more systematic issues like underlying architecture. In terms of methodology, art relies on intuition and experience, whereas science depends on rigorous investigation and analysis. In terms of validation, an art-led process often rests on subjective or personal evaluation, whereas a process that’s grounded in science relies on rigorous testing using quantitative metrics.

Although perhaps a helpful starting point, this model doesn’t tell the whole story. In fact, we can flip things around (Slide 8) and take a look at the other side of the coin: over the last 6 years, some of the most influential academic research in HCI has demonstrated the importance of emotional, relational and aesthetic affordances in design; when you factor-in experience, intuition is often an important check on incomplete or distorted data that might otherwise mislead; and there is certainly an “art” to testing in appropriate and productive ways.

In other words, rather than this binary opposition of art vs. science, a better model is perhaps something more like a continuum. There are two extremes we want to avoid. At one end, we have deterministic design—the idea that we can be entirely predictive, almost in a Newtonian physics kind of sense, mapping out causality for everything, no matter how complex or layered. At the other end we have open-ended design—where decisions are more or less arbitrary. The first alternative has turned out to be pretty unrealistic; the second is just a cop-out. We’ve tried to strike a balance between these two extremes and have gravitated towards evidence-based design as our happy medium.

Evidence-based design (EBD) is a term that comes from the medical world. Evidence-based medicine is the “conscientious, explicit and judicious use of current best evidence in making decisions about the care of individual patients.” Transposed into our context, we like the idea of EBD because it acknowledges the fundamental reality that design is about making choices, and that the goal is to do this on an informed basis. We don’t have to maintain the pretence of a magical process that guarantees optimal results, but neither are we given free license to design whatever we want: our decisions become accountable to the best available evidence whenever possible.

EBD is not just about gathering up data at the beginning of a project: it’s about infusing design decisions with data-driven insights throughout the entire process. Slides 16-20 visualize this goal in terms of a typical agency process (actually, our process). In practice, there’s typically a gap between the define (or research or discovery or whatever you want to call it) and design stages. This is a fundamental challenge—you can have the best researchers on the planet, but if their observations and insights don’t carry over to impact and influence design decisions they’ll do you little good.

So how do we bridge the gap? For us, the secret has been to build our process around a rhythm of open exploration and refinement. Slides 22-28 visualize this approach (thanks to Brendan Schauer et al. from Adaptive Path for the inspiration). We oscillate between a ‘go wide’ mode where we investigate, explore and experiment, and a ‘refine down’ mode where we focus and prioritize. When this happens over and over again, we get these critical points of inflection that keep us grounded (evidence-based) and moving forward (design).

OK, let’s take a look at a real life example. Slides 29-48 provide a glimpse behind the scenes of our work on thestar.com redesign. We start by going wide and essentially scavenge for as many design inputs as possible. These vary project by project, but at a minimum we’ll need to get a handle on demographics, psychographics, behavioural profiles for target users; a concrete understanding of what is and isn’t working on the current site; business goals, needs & requirements; and a comprehensive competitive analysis.

All we have at this point is raw data—we need to turn this stuff into evidence and insights we can actually use. Borrowing from Subject to Change, we believe that inputs become evidence when they are durable (you can kick them around and mash them up), actionable (there are clear implications for design), and impactful (they actually start to change the way designers think about the problem itself). So how do you get there? This is where the art part comes in…

In the beginning, we aggregate stuff in one place, organize loosely and share it among the team. Tools like wikis are good for this exercise. Next we start to look for patterns and find corroborating data—multiple pieces that tell a coherent story. We then construct and test narratives for things we heard from stakeholders. These narratives help us get at the context behind the requirements. We then create focusers—models (visual, conceptual, personal etc.) that help us focus and filter. Two focusers that we often use are personas (architypal users) and design principles (mini mission statements). Focusers are important because they allow us to find the signal in the noise, develop a common language and conceptual framework, and make our assumptions explicit. Because they’re so elemental, they can inform design decisions on a case-by-case basis throughout the entire process.

Sketching has always been central to our process, but we’re starting to formalize this step and make it more collaborative and inclusive. In the case of The Star, we generated about 150 initial sketches (going wide) for 10 key templates (which we refined down in detailed IA). Prototyping is another technique that allows us to explore and test ideas and assumptions. Critical and complex elements in the UI make great candidates here.

Finally, we need to develop a plan of attack for knowledge gaps or areas of uncertainty. For example, with The Star we noticed some anomalies in the analytics data. When we took a look at the competitive set (with a little help from Image Spark), we didn’t see very much alignment in how other media outlets were using certain areas on the page. So, we developed a fairly wide-range of alternative modules for split/multivariate testing.

So there you have it: a relatively geeky look at the case for, and our approach to, evidence-based design. I hope that some of these ideas and examples ring true with you. What do you think? I’d love to hear what others are doing in their design practices and processes.

We wanted to take this opportunity to give everyone an update on Element. What started out as a simple Photoshop mockup has become somewhat of a thorn in our side and an obvious point of frustration for those waiting on it. Before we give the update we’d like to simply apologize for its continued delay. We weren’t trying to overhype it, we just made the mistake of sharing delivery dates given to us by someone outside of our company. We really should have just sat tight until we had an actual release to share.

Some background. We never had any intention of actually building it until Saurik, the creator of Cydia, gave us a call and told us he wanted to build it for us on a new platform he’d created called Cydget. Needless to say we got pretty excited about the fact the lock screen would soon be a reality. He figured it would only take a week or two to actually build. It wasn’t long after that we began to see some pretty serious set-backs. The first of which being that he got very ill and had to put the project aside until he recovered. Thankfully he’s okay but that set us back well over a month.

We eventually got word that he was still developing it but had to tweak the framework to which it was being built on. A few more weeks passed. It was on December 9 when we last officially heard on its status. He had everything working but SMS and weather but wasn’t quite ready to show us a package yet. Since then the only thing we’ve been able to find out is from his twitter account on December 24. It stated that he now had everything functioning except weather and that he was working on optimizing it. That takes us to today.

We aren’t holding back info or trying to mislead people. The simple fact is that everything is in Saurik’s hands and he is working on his own timetable. Saurik will let everyone, including us, know when it’s ready but at this point we have no idea when, or if, that will be.

The Movie Network (Astral Media) hired us to develop an online-focused campaign to launch their new High Definition programming. We created the “More HD” theme that was used across all media. A series of rich IAB ads featured an HD movie carousel that updated dynamically from the Astral server. We also created video ad units (with purpose-built movie trailers) and an HD Movie microsite that featured the entire library of HD Movie Network titles. The microsite makes use of Flash 10 to create a smooth and engaging 3D environment. This site is also deployed as embedded content across affiliate and marketing partner sites.

By working closely with Media Experts we were able to identify media partnerships that were eager to create campaign destinations within their sites, notably, Heavy.com and GorrillaNation. Heavy components included a first-of-its-kind homepage zoom takeover, embedded deployment of the HD Movie microsite inside the HD movie trailers section, TMN sponsorship of various sections within the site, video channel content and Heavy blog editorial content. A branded TMN YouTube channel also features TMN HD movie trailers and exclusive online video content.

Visit the site jointhemovienetwork.ca

At this weekend’s Digital Media Camp one of the most interesting topics was proposed by Justin Kozuch of Refresh Events.

He asked what, as a community, we could do to assemble quality data on the Digital Media industry in Toronto? There is currently no good accounting of how many companies exist in Toronto or how many people work in the field or what value we are adding to the economy.

He cited A List Apart’s survey as an example of the type of information we require.

Why is this important?
So first off why would we bother trying to assemble this data?

For one, we need to understand what impact we have on this city’s and province’s economy. While we may have been a cottage industry in the past we are a legitimate industry now. We create jobs, we support local landlords, local suppliers like ISPs and computer retailers, we need to quantify this.

There is currently no good information on this. StatsCan data is terrible and trying to get the government to collect it will take forever.

If we are able to quantify this, we can begin to have a voice in shaping policy on issues like Net Neutrality, HST and other issues that affect us as an industry.

Once we know how large we are and what we are comprised of we can begin to align together. One of the mandates of Digital Media Camp was to identify “How can we work together to propel Toronto’s technology, content and design communities into the future and make Toronto a globally competitive hub of digital media entrepreneurship and innovation?” Arguably this is impossible without being able to actually identify who the community is.

What are the barriers?
The most obvious barrier to me is how we self identify in this community. For example, is someone at IBM in the same industry as someone at a 3 person open source based dev shop? We may not identify cleanly with each other. I know whenever I have to pick from a list of StatsCan industries I can never figure out where to put us. Are we marketing, are we technology are we content? This is a big issue that needs to be defined.

DigitalMediacamp defines us as…

Digital Media is most simply defined as any information that is created and shared virtually, rather than physically. It has growing applications in all industries, including:

– entertainment – film, TV, games, visual effects
– healthcare – diagnostic imaging, collaborative care, health IT
– education – immersive learning environments
– finance and insurance – modeling complex data sets
– minerals and mining – seismic exploration

Uhm, not sure about this definition as it is extremely broad and our company would not fit cleanly in those examples. Some work definitely needs to be done on this issue.

Next steps
I slipped out before the end of the session on Sat but I’ve heard there is an action item which is to continue this discussion on Jan 18th in Toronto. There will be info forthcoming.

I believe this is an important issue that we need to take care of as a grass roots initiative. It is up to us to stand up and be counted.

I don’t use Facebook much anymore so I just saw the new privacy settings prompt when I logged in today.

Redesigning something as increasingly complex and widely used as Facebook is never going to be easy. People are going to complain. I’ve always felt bad for the slamming Facebook takes on UI design but unfortunately I’m about to pile on.

Here is the default screen for Facebook privacy settings

OK, pretty straightforward except what are my “Old Settings”? I setup my Facebook account a few years ago I have no clue what those settings are.

I looked at this screen for a minute or two and then by accident my mouse hovered over the radio button and it revealed what the old setting was.

[Note: sorry I didn’t grab a screen cap at the time and now I can’t get to this view again. ]

Why would you put a rollover on a selected radio button? I have no reason for my mouse to go near a selected radio button since there is no action I can do on that form widget.

Their account view of Privacy Settings reveals this info quite elegantly. Not sure why they wouldn’t use this for the initial prompt screen?

In the world of marketing and advertising, knowing what interests people have in our client’s brands is somewhat exciting for us. At Teehan+Lax we use social media measuring tools to help monitor our client’s brands, and the competition. What are people saying? Is it good? is it bad? It is ugly…

“What’s particularly interesting is the negative sentiment has jumped to 40% from 15%, while the positive sentiment has dropped to 14% from 49%” @sysomos

The findings can help validate expectations, but they also yield some interesting insights and trends. But what happens when these tools are applied to measuring a person’s reputation?

Sure one could argue that celebrities are often thought of as ‘brands’ in today’s society, but imagine being judged by your peers and the general population and be able to physically see the results?

The folks at Sysomos (who offer a variety of measuring tools that we use) did an interesting experiment along those lines. They recently blogged about Tiger Woods’ reputation pre and post the latest media frenzy surrounding his accident and admitted transgressions. (You know where to find these stories).

The social media measuring results are fun and entertaining when it comes to celebrities – but what happens when your own reputation is on the line? There have been recent reports that the CIA have been investigating ways to watch the social sphere. Beware… one false ‘tweet’ and you may end up on a list!

As a fan of Vimeo’s, I was stoked to hear that Blake Whitman would be giving a talk at FOWD in NY. (You may recognize Blake from that time he had some questions about the homepage...) Blake’s presentation showed that cultivating a vibrant community online is, in no small part, a tractable design problem.

Let me explain what I mean by that.

Vimeo stands out to me because I think they’ve done a great job of embodying simplicity on the web. And it turns out that this is a by-product of thinking about their site in a really focused way. First and foremost, Blake explained that Vimeo is NOT a video site: it’s a community for creative folks who like to make and watch videos. So all of the design decisions are built around this core identity.

I’d argue that understanding the team behind Vimeo’s design decisions can help us bust some popular implicit myths about building online communities:

Myth 1. Online communities are like the wild-west: they work best when uninhibited by constraints.

It’s tempting to think that there’s very little mechanical or social control we can or ought to exert when it comes to building online community. After all, members need to feel like this is their space and we wouldn’t want to stifle engagement–especially early on. Vimeo’s approach challenges this notion.

Blake explained that designing for a specific type of user and imposing key limitations have made their online community flourish, not flounder.

For example, unlike YouTube, Vimeo constrains the type of videos you can upload. Another example: rather than deploying the standard designer’s toolbox for building community around content (e.g. ratings and reviews), Vimeo only lets members formally designate videos they “like.” Blake was pretty adamant: “Vimeo is not a popularity contest.” This makes sense when you think about it since two traits of a strong community—online or otherwise—are 1) shared identity, and 2) a sense of belonging. If other people in the “community” are trash-talking something you’ve created and contributed, both of these traits are strongly diminished.

Myth 2. Successful online communities require strong and deliberate social engineering

This myth swings the pendulum all the way to the other extreme. Clients often default into this line of thinking as a way of hedging their bets. Above all, they want to manage and mitigate potential risks associated with an open online community.

Vimeo demonstrates the promise of a much simpler approach: get involved and lead by example.

Vimeo hires community positions out of their actual community. Their staff are very active on the site: they engage with other members, are supportive where they can be, they make and post their own videos. The upshot of all this is that the team has a vested interest and and embedded perspective—they’re effectively designing their own community space.

To wrap it all up, Blake’s talk encouraged me to think about the cultivation of online community as a a multi-disciplinary undertaking, but assuredly one where design plays an important role.

To keep the conversation going, what are some other design principles that can be applied to these sorts of online environments?

After last week’s announcement of the Kindle coming to Canada I re-kindled (get it) a purchase decision I had started several years ago when I first saw a Sony e-Reader at CES.

Here are my thoughts after spending 24 hours with the Kindle.

Ordering

I bought the Kindle with accompanying leather cover. Total cost: $352.99

Order placed November 23. Order Arrived November 24.

Packaging

The Kindle arrives in a pretty simple brown package.

At first I was underwhelmed but I really like the “Once Upon a Time” on the side.

Here is an unboxing video….

The Amazon Kindle Arrives at Teehan+Lax from Greg Washington on Vimeo.

After opening the box this is what you see.

That text on the screen is not a sticker. That is the screen! It is incredibly sharp and crisp.

You need to charge it fully by connecting the micro USB to the supplied power connector.

I’m not going to cover a full tour of the UI since these shots exist elsewhere online. But here are my initial thoughts.

• Purchasing content is easy. I bought a book on Amazon.com and it appears on the Kindle within 60 seconds. Buying content from the Kindle is as easy. Great experience!

• Reading is effortless and little to no eye strain. I read for about 2 hours last night and had no problems.

• When you hold the Kindle your fingers naturally rest on two buttons.

My natural inclination is that pressing on the left button will go back and the right will go forward but that is not the case.

It’s not a big deal but I miss hit it a few times.

• My biggest issue is something that I would never have thought of until I used the Kindle. When you read a book you make note of where you are spatially in the book. You are always aware of if you are 1/3 of the way through or 1/2 or near the end. The tactile feedback of weight in your left or right hand is an important cognitive clue, it also helps your brain position passages and narrative in a physical space. I can go to a book I read a year ago and know roughly where certain passages or parts are. “I know it was in the first half of the book”.

• With the Kindle I was aware that I would need to mark passages I may want to remember. There is a very robust notes and bookmarking feature in the Kindle. You can highlight passages, makes notes or simple bookmarks. The problem is to do this, you need to enter a menu, navigate a 5 way controller and then select the passage. It takes not only 10 or 15 seconds of time but more importantly you consciously need to stop reading and do this action. It is disruptive to the experience.

• The keyboard is ass. The buttons are really tough to type on. Maybe in the future I will type more notes and use it more, for now it’s just in the way.

• The Kindle arrives with your name and Amazon account programmed. This means there is zero setup when you turn it on.

• You get a Kindle.com email address. Sending PDFs to that address will add them to your Kindle.

I will try to cover more about the Kindle Store, newspaper and magazine reading in another post.

While attending FOWD last week in New York an overarching theme of Progressive Enhancement started to develop as more and more presentations preached it’s benefits. So what exactly is Progressive Enhancement? and how can we realistically use it and ensure our users and clients are happy with the end result?

Progressive Enhancement is all about delivering structured content to browsers and devices regardless of their capabilities, then adding layers of style and behavior that are progressively more complex. If you’re using a modern browser it will be able to render those complex styles and behaviors and deliver a beautiful rich experience. However, if you’re using a legacy browser or device, the content will be rendered to the best of browser’s ability with less complex styles and interactivity. The key here is that nothing breaks, it simply doesn’t look or behave the same in older browsers.

This probably sounds very similar to something web designers and developers have been preaching for years, Graceful Degradation. While they are similar, they have completely different objectives. Graceful Degradation has you building what the most modern browser can handle, and then ensuring that it degrades (or breaks) gracefully in older browsers. Progressive Enhancement on the other hand has you building for the lowest common denominator and then adding extra polish and functionality for browsers that can render it. Graceful Degradation has you looking backward, and Progressive Enhancement has you looking forward.

Why would you want to Progressively Enhance your website? Quite simply, you want to ensure that anybody who wants to consume the content you’re delivering can do so without getting slapped in the face with a broken unusable site. It will also lead to cleaner, semantic code which is easier to maintain and easier to upgrade (or enhance) at a later date.

Lets a take a look at a quick example. Here we have a pretty really basic nav with rounded corners, shadows, and a custom font. Normally we would build this using something like:

You can see we have code in there just to support the design, a div for the bottom corners, a class on the last list item to get rid of the last underline, and a container div to keep it all together. We would also have about 8 different image files for the corners, background, shadow and custom fonts. Don’t forget the PNG hacks to get everything looking properly in legacy browsers. All of that just to support a pretty basic design.

Ideally we would use something more like this:

Here we have clean semantic code with nothing but a class name (maybe) for the styling of this basic nav. No images are required for this navigation, we’ll let CSS take care of all the styling. Rounded corners, shadow, gradient background, custom fonts, and removing the underline on the last list item can all be taken care of with the latest CSS styles. I won’t dig into the CSS code for this today, but we’ll take a look at how this would look in different browsers.

As you can see, nothing would break and everything is still usable no matter which browser you’re using. If you’re using a newer browser you’ll see a little more polish than users with an older browser, and your experience will be a little bit better. Dan Cederholm used television as an excellent analogy for Progressive Enhancement. You can watch the latest episode of 30 Rock in glorious HD and surround sound if your home theater has an HD TV and a surround sound system. However, you can watch the exact same show on a 15” black and white TV with mono sound. You’ll get the same content, and be able to talk about the same jokes around the water cooler regardless of what your home theater looks like. If you’ve invested in the latest and greatest TV and Audio gear you’ll be rewarded with a better experience. If you have a 15” black and white TV, chances are you don’t care about that better experience, or at least understand why you’re not getting the best experience.

We need to use this type of analogy to explain Progressive Enhancement to our clients. Websites absolutely do not need to look the same in every browser. You can deliver an enhanced experience to users with the latest technology and not alienate users with legacy technology. The tricky part comes when you present a design with all the sparkle and polish to a client, and they can only see the basic lacklustre version of the final product because they’re using a browser that’s 10 years old. Finding a way to present the lo-fi and hi-fi versions in tandem will be key in selling Progressive Enhancement to clients, and moving web design forward.