Adam Churchill: Welcome everyone to another episode of The SpoolCast. Just around the corner from our offices is a fantastic design consulting firm called Two Rivers Consulting. The Two Rivers refers to two of our favorite people in David and Hagen Rivers.

Now much of David's experience happens to be with large and complex web applications that are trying to accomplish a whole lot of things for a bunch of people during much of their working hours. Back in November, David gave a great presentation on the visual design of web applications for our UIE Virtual Seminar Series.

As is often the case with our extraordinary presenters and the topics they shed light on, we had our audience thinking. That generated a lot of questions. Many of which Dave tackled in the seminar. Some we couldn't get to, but now David has come back and he's going to help us explore a bit more on the world of visual design for web applications.

Hi, Dave. Welcome back.

David Rivers: Hi, Adam. Thanks for having me.
Adam: Thrilled to have you. Now folks who didn't listen to the particular virtual seminar can get at it in UIE's user experience training library, which has over 50 recorded seminars at this point, from experts just like David Rivers.

Dave, for those listening who weren't with us for your presentation, can you give us an overview?

David: Sure. In my virtual seminar I talk about several different points which I think are touchstones you can use as guidelines when you're doing your own design work. The first one I talk about is, using what I've come to know as the stage.

Brenda Laurel, about 20 or 30 years ago, wrote a book called "Computers as Theatre." She referred to something called the stage. It's the area where you get your work done in an application. I try to give it as much room as possible to the stage, where I think the data really is the star of the application.

I also talk about attention grabbers. I visually emphasize the things that tell users at a glance what a screen can do. I also talk about consistency. I purposefully make things that are the same type look similar, but not equal, because it's actually important to let things be recognizable and not have to put the burden on users to tell the difference between things that otherwise look the same.

I also talk about interaction planes, where I pay close attention to what plane or layer of things live on, and I minimize the number of planes that are used in an application. I also talk about borders, boxes, and alignment. And this goes for the whole screen as well as using tables or grids. I generally use few borders and boxes, and I align the edges of the screen to keep a clean look. Sometimes I'll even use a grid to help align things.

I also talk about fonts, where I work with the system fonts, and I vary the size, the weight and color instead of looking for new fonts to use. I also give lots of tips for working with fonts. Then I talk about color, lighting and branding. Because I always keep in mind where my light source is, and I let the design help define the brand.

Then I talked about affordances, where I only make clickable things look clickable. And I talked about mocking up with real data and implementation in mind. I test my design with real data to hone the implementation details.

So those are the points I talk about, and I think we've got some more questions based on my talk, Adam.

Adam: We do, we have some very good questions. Just to circle back on the overview of your presentation. You did mention Brenda Laurel, and that book is called "Computers as Theatre." And what we'll do is in the post for this podcast, we'll make sure that we put a link in there so folks can get at that valuable resource that you referred to.

One of the questions that we had that we did talk about on the virtual seminar -- but I think you and I agree that it was a great kick-off for this series of questions -- it was asked that you reiterate the difference between the goals of a website, and the goals of an application.

David: Sure. I think this is an important distinction, because it really changes your mindset when you're designing. I sort of consider that a website is basically for conveying information. Websites are trying to keep your attention; they're trying to keep you there. And all of the design revolves around the concept of keeping you on the site and not losing you.

In fact one of the important things about websites is that users have a choice. You've got competing websites that do similar things, and so you're trying to keep users there, keep their attention. And it's all about grabbing attention and looking pretty, but not necessarily being easy to use.

Web apps are used entirely for accomplishing work. People live and breathe in their web apps. They often don't have a choice, because their work requires them to work in an app, and they're working in it all day long. And it needs to be comfortable; it needs to really support their tasks. Which is accomplishing work, getting things done. It's not necessarily trying to simply be a consumer of information.

Adam: Alright, so let's get to some of these other fantastic questions. Marta wants to know how she can handle attention when she's competing with banners.
David: That's a great question. Often a web app is embedded in a website in such a way that you really can't avoid having banners and even ads surrounding your web app. Things that inherently are trying to grab for your attention -- really in strong ways. So, I prefer for the web app to sort of provide a sanctuary from all that busyness, and all that noise -- that visual noise.

I think that if the app is sort of a clean, relaxing respite from those busy surroundings. Then your eyes actually want to retreat, to get away from the noise and the clutter of the banners and the ads, and pay attention to your work. Now I achieve that with white space, or negative space. That is, provide a nice space around your app so that there's a clearer barrier of Zen cleanness, if you will, between the app and the banners.

But I also like to use contrasting and comfortable colors, things that your eyes find soothing rather than jarring. So if the banners are bright flashing orange, I might choose a nice relaxing green or a light gray palette that will put your eyes and your mind at ease.

Adam: Merrill asks a question in regards to, I think, a challenge probably a lot of folks face. They have a design where there are a number of things that are equally important, but it's described as configurable. Merrill wrestles with what order to group them in. Any advice?
David: Sure, so in the virtual seminar one of the things I talk about is when you have a lot of things that seem equally important, it's really tempting to make them all look the same because it's logical for things to be consistent. You make all of your headers look the same; make all of your sections or portions of a portal or a dashboard look the same so that everything seems like a unified design.

And there is definitely some merit to making things look like they belong together, look like they're a unified design, but that doesn't necessarily mean that they need to look identical. So I talk about using subtle differences between them so that there's additional cues that help people find the things that they need.

Sometimes it's positional. Sometimes it's color. Sometimes it's use of borders or lack thereof or providing similar amounts of space around things. So in the case where things are incredibly configurable -- I wouldn't be surprised if Merrill's talking about a dashboard here -- it seems like it might be an insurmountable problem. But it really isn't.

Because users can configure it, that's what makes it work. People can still put things where they want them to go. They can still size them the way they want to often. But if you wanted to provide some extra UI for them, you could allow them to pick from a few different visual styles for each configurable thing. And those styles could work together as a family so that some might have borders, some might not. But they work together as components in an overall design that they can cobble together so that things work together as a whole.

But, like I said, the positional placement of things is what really works for them when you're making things configurable. So that really handles the issue of having things that are otherwise equally important but different enough so that people know what to do with them and how to use them.

Adam: Randy wants to know what you recommend for the minimum font size in a web application.
David: That's a good question. It really depends on your user population. If you're designing for younger people, you can usually afford to go lower. For older people or people with poor vision or people in environments where there's a lot of visual clutter -- or if they're working outside for example on a tablet device -- you often need to go to a larger size because the ambient light conditions make it difficult to read things.

But keep in mind if you're designing for web apps, you're looking at these on a web browser, and users can change the font size by just bumping it up or down. So bottom line is don't sweat it too much as long as you think that users know how to find that bonking-the-font-size-up-or-down button to make things readable for themselves.

If you don't think that they'll know how, my general rule of thumb is 12 point and here's why. 12 point is a good, sort of lowest common denominator to work with. Chances are it's going to be readable if they squint or get close enough to the screen if they have problems with their eyesight. That way you don't have to worry about things being so tiny that they won't ever have a chance of reading it.

There are enough cases in their everyday lives where 12 point is the size that they have to work with, so I think that's a good bottom end.

Adam: Eduardo describes an application that requires its users to view and analyze lots of data. So they use a lot of grids, and he wants to know what you recommend to make the grids look and feel better or, at the very least, be more user friendly.
David: Now there is a long topic -- one that I'm sure someday I'll put together a report or even a book on. But let me give you some general guidelines that I think will be pretty helpful for the vast majority of cases. Now Eduardo talks about using grids to view and analyze lots of data, so I'm going to assume that means many rows and many columns as well.

First of all, I'd recommend that you increase the space that you use between rows -- that is, the negative space between rows -- because users are going to have to do lots of scrolling anyway. If they're going to be scrolling anyway, that means you don't need to pack things as tightly unless you're doing comparisons between the rows of data, which you're probably going to handle with sorting those rows by clicking on those column headers.

Chances are, being able to squeeze in an extra two, three, or four rows on a screenful is not going to make the difference between finding something and not. However, it will make a difference in fatigue, and you want to reduce fatigue as much as possible for people that work with this web application all day long.

Also, don't use borders around the grid or on the grid on the whole. Borders are really bad for fatigue, and they make it difficult to scan across columns. So I recommend not using borders inside the grid. Around the perimeter, I think you're always generally better using white space than you are using borders.

Also, for the data itself use more subtle shades. If you're using black text, for example, in general, use lighter shades of gray for less important data and use the darker or black text for the most important. You can have a good range here. If you've got 12 to 20 columns for example, which is not uncommon in a lot of complex web apps, you can use a good five different shades of gray to indicate different levels of importance.

So the thing here is that all data is not equally important, and your text color can really help indicate what is more important and what is less important.

Also, consider using a multi-line format for individual items. Normally, if you have a lot of columns, instead of having one row per item, you can use two or three rows of space per item and format the data in that space. Not in a columnal way necessarily but in a way that clusters useful information with information that belongs with it.

This works really nicely, especially when you have really long column labels, which would normally make a column abnormally wide. And by using a non-grid layout for that row, it allows you to have labels that work nicely with the data in a way that you can't if you're sticking to a rigid grid.

Also, I think another good idea is to use pale horizontal lines between rows instead of using alternating row colors. I find this works really nicely, especially when you can select rows on the grid, because for a selection color often you use still a fairly subtle color. And if you have subtle selection colors and subtle alternating row colors, it becomes difficult to tell the difference between an alternating row color and a select color, and it gets kind of visually busy, especially when you are looking at lots of stripes across lots of long rows and many columns. And I find that horizontal lines give it a cleaner look, especially when you don't have borders around the edges of your grid.

Adam: Alright. We're all now waiting for you to finish that book.
David: Yes, we'll have to wait longer than I'd like.
Adam: In your virtual seminar, you showed some great examples and Christine makes a comment that you make very subtle design changes. And she asks if you use AB testing with users or are a lot of those design changes based on your knowledge, instincts, experience? How do you make those decisions?
David: That's a good question. I think that question came in during the virtual seminar at a point where I was showing some subtle changes. I think, I later showed so much more radical changes, so I don't want folks to think that my work is all subtle. One of the things I wanted to show in the seminar was that I'm showing changes that anyone can make to make a big difference, and sometimes those are subtle changes. And what's nice about a lot of the subtle changes are things that are easy to implement.

So you can make those changes right away with very little effort and still make a big difference, as opposed to ripping everything apart and starting from scratch, which is the sort of thing you do on the next release, whenever that may be. But I also wanted to provide good examples for that next release, if you will, so that people have sort of a new standard that they can reach toward when they're working on a holistic design like that.

So, in my experience, though, AB testing doesn't really teach generalities like it's always good to use alternating row colors or it's always good to use white space, because every design has strengths and weaknesses in the way it's presented and in the environment in which it's presented will have a huge difference on the usability and the results of your AB testing. What I find that AB testing does do, however, is teach about specific designs. So, if you do have two different designs and you need to look at a subtle difference and be able to find out which one performs better, then AB testing works really well. So, my experience is don't use AB testing to decide on a generality. Use it on a screen by screen basis and I think you'll end up much better off.

Adam: The group at Paychex wanted to know your preference in web applications for fluid design or a fixed design. They make a comment that monitors are getting so big that sometimes the fluid design can hurt readability. How do you tackle the problem?
David: Another good question. I think I pretty much always design for fluid layouts. I mean, let's face it, users are trying to accomplish work here. They resize their windows all the time and move them around on their screens when they're trying to get work done. And your design should reflow as they do this. If users are lucky enough to have a big screen, then they'll resize the window to make things work for themselves. Your job, when you're doing design work, is to make sure that at both low and high resolutions you're not wasting space, that you're making good use of the space that you have. Now, this doesn't mean that you have to make things cramped, but it should be easy to parse the things on the screen and to make sense of.
Adam: David, there were also a couple of comments that came in from the Twitter stream that you and I thought might make some sense to discuss a little further. What about distinguishing visited links, what do you recommend to folks there?
David: Sure. So, in websites, you can use a different color to indicate links that you've already followed. And for a website where you're visiting it infrequently or, maybe, just once, that makes perfect sense because when you're looking for things, you need to see what trails you've taken already and visited link colors make complete sense. In a web app, though, I think they make almost no sense at all because you've probably visited all of the links because you're using this to get your work done. This is the web app that you use through your life at work. And it really becomes meaningless once you visited links because the whole idea is "yes, I've been there" and it really makes no sense to keep that visited link different for the rest of your work life.
Adam: So, in your virtual seminar, one of the things we promised is that folks would learn to incorporate brand into their design, and that was something that certainly resonated with people following us on Twitter in regards to the brand experience. What do you have to say about that?
David: So, in the virtual seminar I talk about something that John Sculley, who was the former CEO of Pepsi, he recently described the way that he turned Pepsi's marketing around. Apparently, before his reign, Pepsi's battle with Coke was all about the drink, about the taste. And he said that he changed the goal of Pepsi marketing to always focus on the user of the drink and their perception of the experience instead of the drink itself.

Interestingly enough, that's the same tactic that Coke successfully used to lure customers to their drink in the first place. I think the same thing goes for visual design of web apps. Users don't care to be predominantly reminded whose app they're using. They only care about getting their job done as easily as possible. So, I think that if you focus on the experience being the brand, then it doesn't matter how you express the brand as far as a logo is concerned or as far as colors are concerned. It will matter in a bad way if all of your branding makes those things harder to use.

Adam: Well, David, thanks for joining us. Again, I'm thrilled that you're a part of our virtual seminar program and I really appreciate you coming back. To circle back on some of these questions, we'd love to have you back at some point.
David: Great, Adam. Thanks so much for having me.
Adam:That's it for this edition of the SpoolCast. Good bye for now.