Full Transcript

Jared Spool: Welcome, everyone to another episode of the SpoolCast. I am very happy, because today I have one of my favoritest people in the entire wide world of the UX space, Ms. Hagan Rivers, who is going to be speaking at the User Interface 16 Conference, which is going to be in Boston November 7th through 9th, and she's doing a full day workshop on the 9th called "Simplifying Complex Applications." And I'm very excited that we get a chance to talk to her today about just this topic. Welcome, Hagan.

Hagan Rivers: Thank you, Jared. It's good to be here.

Jared: So, I have a question for you which are why we're doing this, because I have a bunch of questions for you. Lately I've been working with these teams that have these designs that have been going on six, seven, eight years, right? So they've been around for a while, and they've got dozens of designers and developers who are working on this.

And just a few weeks ago, we're watching actually a training video, so it's a video of a customer being trained. And it's a beautiful way to watch people use a design, because you see what the trainer is doing. They're walking the user through the various aspects of the design, and you get to see the screens. You get to see how the new user is responding to all these things.

And one of the things I'm noticing is that as every part of the interface pops up as the trainer is walking through it. Each one has sort of a different signature look. They're all maintenance screens, right? So, you know, one's a customer screen - these are places where you have classes, so one's a class setup screen, one's an instructor screen, and each one has a capability to make changes and save, but the way you make changes and save in one screen is a "save" button, let's say, and it's at the top of the screen.

On the next screen, it was an "update" link that was at the bottom of the screen, and each one was different, and as we went through these, I began to realize that I could actually start to pick out which developer had probably developed which set of screens. I didn't know the developer by name, but I knew that screens one, seven and nine were all probably developed by the same guy, because they had the same basic look to them, but screens two, five and six were done by somebody else.

And, of course, all this made the trainer's job that much more crazy, because every time they had to sort of explain a different way of doing it. And so I'm realizing that entropy takes over and these designs become this giant hairball of complexity, and I was wondering, do you have any suggestions? What could you tell teams to do that would sort of prevent this hairball from growing as nattily as it does?

Hagan: To make it never happen in the first place?

Jared: Well, maybe, but at least to start to identify that it's happening and maybe prevent it. I don't know.

Hagan: Yeah. I mean, I see these apps all the time. When I meet with new clients, they demo their apps, and I see the same thing. I can tell which screens which parts of the development team did. I can tell you how many different developers there are working on the GUIs, you know?

Jared: Exactly, exactly, yeah.

Hagan: And each one has their little pet peeve about they don't like to call it the "OK" button. They think "save" is clearer, so they always say "save," or whatever. They all have their thing going.

And as new features get added, especially as you talked about in the preferences and stuff like that, that's where the developers tend to do a lot of design work. They just sort of throw whatever they think works onto those screens.

So, actually, it's interesting you talk about the training, because I did some work with a client last year, and I went and took their training. I acted as a customer and I just said, "I want to attend your training classes." And I got so much great material there, because as we went through screens, there were all these places where the trainer had to stop and tell us what was weird about that screen, and I would take notes. I'd go, "OK. We need to fix that."

And we'd go to the next, and they'd say, "Well, on this screen, you have to be sure to click this button first." And I'd go, "OK. Well, we got to fix that," you know?

Jared: Yeah, so one of the things we've been doing with clients is when we take these video tapes and we actually start dividing up the tape into pieces, and any place where the trainer is in essence helping the customer get value - so, in other words, that particular thing, like the customer setting up their first account or their first class or putting in their first instructor, right? They're getting value from that, and so we call that "goal time."

But the places where the trainer is sort of explaining - like there was one option that took about - we counted it - it was about six minutes to explain that you should always keep this number set to one. Whatever you do, don't change it, but then went on to explain why it was there and why it might not be one for people who weren't you, but you should always have it as one.

Hagan: Yeah, don't touch it.

Jared: Exactly. And so we call that "tool time," right? So that's the time that you have to just sort of deal with the tool. And you can actually measure how good your UI is doing by the ratio of tool time to goal time, right?

And if you keep reducing tool time and increasing goal time during the training session, you're getting real value, because there is value to hand-holding a customer through their first experience for some of these high end products. But that hand-holding is different than mine field avoidance lessons.

Hagan: That's right. That's right. Yeah, I mean, a lot of the apps I work on are really complicated. They're not apps that you can typically just hunt through the web and find them. They're the kinds of apps that are installed in enterprises, so apps for managing purchase orders or patients at a hospital or ticket systems for managing help desks - stuff like that. I mean, big, big apps, and they're complicated, and they do often have training.

And you're right - there's this tool time is like just spent trying to dig through what is quirky about this app. And there are always a lot of internal inconsistencies, and I always tell folks, like, "Just pick one." I mean, in a way, it doesn't even matter which pattern you pick for your forms - just pick one and use that one again and again. Like, yes, they obviously can make improvements later, but the inconsistencies just throw everybody for a loop.

It hits you in training, but it hits them in QA. It hits them in documentation. It hits them all the time when they are being inconsistent.

Jared: Yeah. I think there is something to that, right, because you can have something that is illogical but consistent and it works, right? The old start button on Windows XP, right? It didn't make sense that to shut down your machine, you press the start button except that once you learned it, it just work. It just always worked.

Hagan: That's right. And so, if your app has, the OK button as a link on the upper right hand corner, you know that's not how most folks do it. That's not the standard pattern. But if you do it in every one of your screen, people will learn it and will just do it. It will be fine. But if you change it every single form, you are creating much more work. And the other thing is you are creating more engineering work. I mean if you have to recreate how you deform submission for every single form, that's a ton of effort that's wasted.

Jared: Well, one thing that gets me is on the American Airline site. I can go on for hours about the American Airlines. I mean but on the American Airlines site; they have this convention where the OK button is a red button. How do you like that?

Hagan: I love that.

Jared: In the lower right hand corner, it's the farthest most right button, except occasionally, the start over button is that button.

Hagan: I'm sure the ramifications of clicking that are a lot of fun.

Jared: Yeah. If you are like me and you are trying to make a reservation quickly and you do it 20 times a year, it drives you nuts when you hit start over and you didn't mean to. It's like, "UGH!"

Hagan: Yeah. To answer your first question like the hair ball of complexity. I think if you do what I do. When I first meet with a client, I go around and I talk to the folks in their sales team. I talk to the folks in the support engineering. I talk to the folks that helped us. I talk to trainers and as I talked to them, they'll tell you about these inconsistencies and they know them because they are working directly with the customer trying to deal with them.

They spend a lot of their time dealing with them every day. And you know, I see those and that's why I know why the products got the hair ball of complexity in addition to looking at it myself. One of the first things we tackle is these patterns. They are trying to create very standardize ways to do things that you use throughout your application. The one way to do a form, one way to do a chooser, one general way to present a toolbar over a table, so that you don't have to reinvent that all the time.

You don't have to retrain people all the time. These complicated Apps, it's hard enough just to understand how to work the App and do the real tasks. Much less have to wade through a complicated, difficult to use UI.

Jared: Yeah, I think they are creating a library of patterns. It's really a good idea. People ask me this. There are now a handful of sort of general purpose patterns that people put together. Jennifer Tedwill put one together. There's a guy in Germany who's got a really extensive site. I don't remember how to pronounce it. It's German so everything I know about German I learned from Hogan's Heroes. Which is probably not the best way to model an entire culture.

Hagan: I think that was all deliberately mispronounced.

Jared: You're probably right. There are all these third party pattern libraries that are emerging. But I still feel like there's a lot of value in sort of crafting your own library as a team, because you have a lot of really useful discussion about what is a pattern and what do we call that, and it creates a language, which I think is really important.

Hagan: Yeah. I find the same thing. If you just kind of hand an organization a pattern and say, "Here's your pattern library," they don't use it. They just shelve it. It's not their pattern. It is a pattern library, but it doesn't always apply to their apps and it doesn't make sense and they haven't even agreed to use it. So you know, we try to do a conversation with the development team, and I'll go through and I'll find the six different ways they do a chooser screen.

And we'll put them all up on a screen and we'll look at them together and we'll say, "Well, which of these do we think is the best and why?" And I'll tell them why I think which one's the best, and we'll pick one and then we'll get it recorded down in a pattern and we'll start migrating to using that for everybody.

Jared: Do you do an exercise when you do that, because I've done this with teams? Do you do an exercise where you actually say, "OK. Let's just make a list of what's different - let's not assign good or bad here. Let's just make a list of what's different between these different variations so that we can make a catalog of why each one of these things sort of existed?"

Hagan: That's right. You'll learn things, like some chooser that someone did is really good for that particular situation, because he's choosing between maybe hundreds of thousands of items, whereas another one might only for choosing amongst 50 items or a 100 items, and they do different things. And so you say, "Well, OK. When you identify these, it's not that they're good or bad. It's that they're solving different problems."

You start to build your pattern library, say, "Well, whenever we need a chooser for more than 5,000 items, we'll use the giant one, and whenever it's less than that, we'll use this one. And so if you do an exercise, you get them to think about what's making that work? Why did they choose to design it that way? And what's the purpose? What problem is it solving? How does it help the user? Then they understand why they would reuse the pattern. I think that's much stronger way to start building a pattern library than to just grab a book off the shelf.

Jared: I'm thinking this doesn't have to be a difficult thing, right? You could take, like, 15 minutes of a weekly staff meeting and just put up a chooser one week and a form next week, the way you do login authentication the week after that, and just do one a week for 15 weeks and all of a sudden you've got the start of a library.

Hagan: Yeah, it doesn't have to be super hard. I think what happens is a lot of folks get very married to the patterns that they've created and they really feel they've got the best solutions. So sometimes you do need to go out and talk with users and talk with the support folks and see what's really working for people. But most of the time when you ask people to sit down and really look at the design, and compare it to other designs solving similar problems - they're pretty quick to pick up on what needs to be done.

Jared: I have this friend who was a real film buff, and he went and studied all these film classes and would watch every DVD extra where they talked about how they made the thing. And he always wanted to go off and be a filmmaker himself. And I would go to the movies with him, and we'd be sitting in the movie theater, and this exciting thing would be happening on the screen and he'd hit me on the shoulder and he goes, "Did you see that tracking shot? That was like an awesome tracking shot!"

Or we'd be watching a video at home and he would make us go back and rewind something because the zoom was particularly good. And, it's like, "Dude, I just want to watch the guy get the girl." You know?

Hagan: What guy? What girl?

Jared: Yeah, exactly. He had stopped paying attention to any of that. He was looking at what the cameramen was doing the whole time. And so, "I figured out how they did that." And like, we'd have to watch the same scene 15 times.

Hagan: He was interested in the craft, not the product.

Jared: Exactly. Exactly. And I'm wondering if, in fact, that's what we're trying to do here with developers. They can't log into, you know, PayPal without noticing exactly how PayPal does their authentication screen, now, because they're going to pay attention to that level of detail, because we've dissected it.

Hagan: That's right. Yeah, I mean, I think, you need to be able to, kind of, step back. Like, I always think it would be fun to take a piece of software and replace all the English in it with gobbledygook. And see how much of it you could drive.

You know, there are certain expectations we have about, like, where buttons should be. You know, the "OK" button is the one that's bigger and brighter and more clickable, and the "Cancel" button is less so and they're in a certain position. And toolbars go above tables. And the first thing is usually, like, new or something like that. Like, if you didn't have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs and stuff. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They're very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. And so, they're just like, "Well, it's obvious, it says in the help text right there." Yeah, but, OK, don't read the text, just look at it and see what you can learn.

Jared: That's interesting. I actually found myself in a Dutch police station once in Amsterdam and watched the cop fill out a theft report, a friend of mine had had her purse stolen. And so, we're watching him fill out the theft report, and of course, the screen was entirely in Dutch. And yet I had no trouble following along with what he was doing, because it did follow those sorts of conventions that we're used to.

Hagan: That's right. And I have a theory that if a pattern is working well, the labels are irrelevant. They add supporting information, but you should be able to figure out how to use it without being able to read them.

Jared: Yeah, I think that makes an awful lot of sense. It is really interesting that this idea of being able to use the design independent of the language that's there. And can you drive it that way, basically, through just convention. Makes a lot of sense.

But at the same time, a trap that I see teams falling into, I don't know if you've seen this, is when they try and come up with generic designs and they use "Lorem ipsum" style text. And then, when they plug the real design in.

Hagan: It's just too generic.

Jared: It's too generic. And it doesn't handle the special cases, which is why you need the patterns for the 50,000 item selection, or is this the 3,000 item selection?

Hagan: Right. We'd worked on an app last spring. It had a bunch of wizard based forms for editing. There were a whole bunch of different objects in the system. So, they had, like, 20 different tabbed wizards for editing these 20 different objects.

And so, they all looked the same. I mean, once you opened one up, it was really hard to distinguish them. You know, I told the engineers, we need to put labels at the top, we need to repeat these labels. Like, instead of just saying, "Name," we would say, "User's name." So, it was very clear what name we meant. Or "System's name" or whatever name we were asking for. And they said, "Well, they should know by the context they're in."

And I said, "Well, the language is what gives them the context." We saw regularly, people would open up a screen in our usability study and they would forget what screen they were on. The language is the thing that gives you those cues, oh, I'm working on this. Oh, it needs to know this. And being repetitive, like, there's this real tendency to be really lean in language on some of these apps. And sometimes it's confusing.

Jared: Every pixel costs, right? So, you want to save on those characters.

Hagan: You've got to save, I know, because it might, burns out your monitor. I don't know. But yeah, it's like, there's this appreciation for brevity that doesn't really help users at all. I mean, obviously, you can swing the other way and have full sentences all the time, and that's too much. But there's this desire to be really, really concise in the language, and I think it's disorienting, sometimes.

So, yeah, I don't mean to say, if you use the pattern without seeing words that it would be perfect. But the sort of placement and arrangement of things can be very suggestive. And then, the language kind of adds to the whole context and the behavior layer on top of that. To, sort of, tell you what is this thing? How does it work? What's its relationship to other things in the system? What can you do with it? And that's what the language layer kind of gives you. Of course, the language is really critical.

Jared: Yeah, I think that the more we understand about interfaces, the more we realize that we're basically creating a language that is both visual and verbal with our users. And that the combination of the two is really important.

We saw this early on with icons, where there was this big push to have visual symbols for everything and no words. And we were working on this tool for software developers. The team had come up with this hatchet dripping blood. Which was the "Execute" program icon?

Hagan: Yeah. That'll translate well.

Jared: Yeah, exactly, yeah. A visual pun that just does not work. The funny thing was that we'd have these usability tests and all the male developers that we had come through went, "Oh, that's really cool." And all the female developers go, "Ew. Why?"

Hagan: Ew. [laughs]

Jared: So, that one really split down gender lines. But what we found early on was that when you just had pictures, often people didn't know what the picture meant. And when you had just words, it wasn't as good. But the picture and the word together, actually seemed to really work best.

Hagan: Yeah, the pictures give you a differentiator, so when you're using your kind of positional memory of the toolbar in your head, you remember it's kind of the fourth or fifth one in, the picture kind of gives you a reference point for your eye to grab onto. At least that's my theory.

Jared: Well, you know, what was really interesting was we experimented with that. We started moving the icons around, and we found that the position wasn't as prominent as we thought. In the early Microsoft Office apps, for example, the first icon was open and the second one was save, and the third one was print, or something like that.

But we found that if we moved them around a bit... I mean, if you completely reversed it, if you put open and close on the far right instead of the far left, people would have trouble with it. But if two icons appeared before open and close, nobody was freaked by that. It didn't have to be the very first icon.

Hagan: Yes, I don't think positional memory's that absolute. I think it's just sort of like, "it comes first-ish neighborhood" memory. But it helps. It's an important piece of finding stuff again and again, especially in an app you use all day long.

Jared: So what's your take on dashboards? We have a lot of clients that are doing this sort of dashboard thing, and it sort of starts with some executive declaration of, "I just want one screen that tells me exactly what my business is doing." And the next thing you know...

Hagan: Wouldn't that be nice?

Jared: Yes. You've got odometers, and speedometers, and temperature gauges. Every physical skeuomorphic gauge that man has ever come up with is now a visual element on this opening screen that nobody understands.

Hagan: Yeah, they're trying to really create the pilot's dashboard, which works great for pilots, but not so much for most other folks.

Jared: Except that pilots are intensely trained on those dashboards.

Hagan: That's correct. That's why it works for them. They need to know where things are and what to click and what to look at, whereas we present someone with something just as complicated as a pilot's dashboard and say, here, this helps you know what your whole business is doing! And they scream and run out of the room.

So, dashboards. I can usually tell if a client knows who their users are and what they do just by looking at the dashboard. To me, I think of the dashboard as like an extra layer of navigation, actually. Like, a whole screen devoted to navigating to key parts of the application and bubbling up information from key parts of the application.

Jared: That's interesting.

Hagan: Yes, so if you know your users, your dashboard, it reflects it. I'll give you an example, because this is this new idea that I've been working on for the last year or two.

So, we worked on an app a couple months ago for managing mailing lists, email lists, and stuff like that. And they had a dashboard, and when you logged in you got this screen, and it showed you your user profile. So it showed you your first name and your last name, and a place to change your password, and those things. And then it showed you a list of the mailing lists you were subscribed to.

This dashboard was the dashboard for the administrator of the mailing lists, mind you. Not an end-user, but the administrator, the person who actually sets them up. So, there was nothing on this dashboard that was of any use to this person. And they had little meters and metrics and stuff, but it was useless. They all clicked right through it and went off to doing stuff.

So we went and talked to some of these users, and we talked to them about what do you do the most often? If you talk with them, after a while they said, well, the biggest problem they have to deal with is updating other people's email addresses. That's their number one problem. Like, they send out a message and a bunch of them bounce back as having failed. And they need to know who those people are so they can get it up to date, and they have to look up and manage those users and deal with the failed deliveries.

And then the other thing they do a lot is they send out these mailings. So when we were done, the dashboard now had a quick way to get to a list of users who have disabled email addresses due to delivery failures. So you could just say, 150 people right now, their emails are no good, click here to go straight to them. A quick way to look at users who don't have email or are out of sync however with the system. We even had a little box right there where you could type in an old email address and a new email address and just push a button, and it would just look it up and do the swap.

So that was, again, we were looking, what's the common task? And then we had a place for starting new messages and sending them out. So we went out and said, what's done really commonly, what's really hard to do, what things do you have trouble finding? And those were all the things we bubbled up and put on the dashboard. And we had some reporting stuff too, but it was mostly like, how many mailing lists do you have, how many total users on each mailing list? Just some very simple metrics, and they were not giant dials, they were just some very straightforward numbers.

So the idea is that the dashboard is like storytelling. It tells you the story of what the app does, and the most frequent things you're going to do with it. And it navigates you very quickly to those key places to support those tasks. Most dashboards don't do that.

Jared: Yes, that to me makes a lot of sense. So, you could have it, for instance, if you had items that needed attending, you could have it put the number of items that need your attention in red for those things, much like the way unread messages show up on an iPhone, or something of that sort.

Hagan: Right. For instance, in a lot of apps, you'll have a list of stuff and you can filter that list. So it's possible to go in and set up whatever filters you need to find something out. But on the dashboard, you could put five links to the most important filters that the user's going to need a lot, and it just immediately takes you to that page and applies those filters and gets you up and running. And you don't have to do anything more complicated than that, it just gets them going and gets them started on their work.

Jared: Yeah, because I think a lot of these sort of visual elements, though, they might demo well just from an "Ooh, that's very impressive," the dials and gauges and stuff. I think the amount of information that they communicate for the number of pixels that they use, that sort of data-to-ink ratio is probably pretty low.

Hagan: Yeah, it's very low. We've done a lot of work cleaning those up to try to increase the information density, and it's really low. The other thing is I think, at least I'm finding with our clients' customers, you know, a year or two ago, they would just be really wowed by seeing a dashboard covered in these controls. But now, when I go and sit in on sales meetings, I hear them saying, "Well, what is this for? What is it telling me?"

So, the customers are starting to become more critical of these flashy screens and really asking what they're good for. And I think that's going to be what drives improvement in the design, is that the customer is getting a little jaded about all those bells and whistles.

Jared: So, we have this definition of the word "clutter." Every so often, you'll be sitting in a usability test and a user will tell you, "That screen feels really cluttered to me." And what we've realized is that clutter doesn't mean high information density. Clutter means there's a lot of stuff on the screen that I either don't understand or I don't care about. And there's very little stuff that I care about.

And I've actually seen screens where we did a before and after of a design. And the before, the user told us, was much more cluttered than the after. But the after had more information on it than the before did. And what made it less cluttered was that all the information we had designed to be relevant to something that user needed.

And so, I think what I'm hearing you say is that these dashboards that don't do well, that the users are now saying that maybe that's that clutter effect, right? They're looking at this dashboard that has a lot of stuff on it, but it's not stuff that they are interested in in running their business or doing their job or whatever their operation is. And if you replaced it with stuff that was actually, really important.

So, one of the things is, we have this client who has this application. It's a subscription thing, it's a monthly subscription thing. So, every night it goes and runs a batch of credit cards for the people who are renewing on that day of the month.

And the first thing every one of these business owners of these customers did is that they would go to the report that told them how that job did, which credit cards got declined, how many got declined. Because that pretty much set their to-do list for the day of who they had to contact and say, "Hey, your card is expired," or "Your bank's not accepting this charge anymore and we need a new card or we're going to have to shut off your service." And that wasn't on the dashboard. Right? Yet it was the most important thing that pretty much every customer we went to visit did.

Or just checking to make sure the job ran at all, because there are random nights where, for whatever reason, things don't go well and nothing was charged, right? And the batch is left hanging, because of some technical error.

And so, having this thing that says, yeah, last night, we ran 23 credit cards and every single one of them cleared, would save, like, A, six clicks, and give something incredibly useful that that person wants to know when they first login in the morning.

Hagan: That's right. And that's what I mean about it being kind of a mechanism for bubbling up key information and giving the user a quick way to get into, maybe, deep places in the application to do tasks that they have.

So, I have this funny exercise I do with clients now where we do a demo of their product very early in the process. And they bring up their dashboard screen. And I say, "OK, let's take a look at this. I'm going to go through this screen, and I'm going to tell you what I think, based on this screen, are the most important things in your app."

And we go through the screen and it's mostly garbage. I mean, it's just sort of like random stuff we're able to tell you, but has no bearing on things you do, or things you care about. And they quickly realize that they really haven't given it much thought. They just sort of threw everything on there that they had, rather than spending any time thinking about how people use the app.

Jared: Your content management system has 47,000 letter E's in it today.

Hagan: Yes, exactly. And those are the kind of stats they'll give you. And it's like, thanks.

Jared: Sixty four percent of words are spelled correctly.

Hagan: Yeah. One million three hundred and twenty two pages. Great. OK. Why isn't it 323? I don't know. Like, it's just data and they're just sort of flooding you with this firehouse of data. And it's not useful.

Jared: So, you really have to get into the head of the user to figure out how to do a dashboard right.

Hagan: You really do. I mean, you can build your app and never put a dashboard on it. The dashboard is a completely separate layer. It doesn't do anything that the app doesn't already do. It doesn't tell you anything that the app already doesn't have in it.

So, the question is, why are you putting it on there? If it's just to be a sales gimmick, yeah, I guess. But I think the clock's running out on how much people are going to love that in sales calls.

You really want to say, we know our app is complicated, we know there's a lot there, and we've really spent some time studying what our users need to know, and what they need to do, and we've incorporated those things here.

Jared: So, one of the things that we've been doing when we go out on customer visits is we say, OK, so what's the first thing you do every day? And we have the person we're visiting actually walk us through those sorts of first steps. So, if we start to see patterns from one visit to the next, of a first thing that everybody does each day, that, to some extent, is telling us what a good dashboard entry might be.

Hagan: That's right. And that's why I say, I can usually tell if my customers know their customers just by looking at their dashboard. If they know what they're users are doing with their app, and they know what information their users need to have, then their dashboard will show it.

Jared: I wonder if this is one of those places where self design, you know, designing an app that you also use yourself on a regular basis, actually really helps, because you know what you want to see. And if your behavior matches your users' behaviors, you know, which doesn't happen that often, but programmers creating tools for other programmers. People who are business owners creating something for other business owners. It does happen.

You can get away with that. But if you're not in that space where you're not a user of this thing, the odds of you coming up with what those dashboard things, without doing serious research is probably very slim.

Hagan: So we worked on a help desk application a couple years ago. This was an app where we had some really different types of users, different personas that we were working with. A help desk tickets come in. End users have problems, they submit tickets, and then there are the people running the help desk.

There are the folks that answer the help tickets, the front line worker. What they do with the app is they go through their list and they work through their tickets, right? I mean, that's their job. Then there's their manager and their manager might manage 20 or 30 of these people and they want to know things like who's doing the fastest job of going through these tickets?

Who's got the longest back log? What do I do when this person's out on Tuesday and I need to redistribute his tickets? And they were using the same dashboard for both of these user types and they had totally different needs, you know? And so we separated it out. We had two different dashboards.

Sometimes the managers did answer tickets so they would use the ticket answerer's dashboard sometimes which was a list of your tickets that you were assigned to and helped you deal with that. What's the highest priority, things like that.

Then there was this separate place that managers could go that would show who are your top performers. Who has the greatest back log of high priority tickets, things like that and they could look it up and find that information really quickly. All that information was already in the app. You could have gone and gotten it any way you wanted but the dashboard collected it all together in one place.

Jared: I would think, also, that the dashboard would be an opportunity to plug other things in that may not be part of the app like server up time statistics and things like that, that would be specific to, "what is the current state of a given server right now" so that if all of a sudden a slew of calls comes in, "hey the system's not working", you have this up to date information that says, "oh yeah, we know."

Hagan: Exactly. The router's down, we're dealing with it. Exactly. You can bring in that information. A lot of folks, especially in IT, they like for the dashboard to include information about the app itself. Is the app running properly? Was it able to contact everything it needed to? Sometimes the problem is the app itself is breaking down and so they love to see that information.

Jared: Right. It seems to me that things like dashboards and stuff are going to be moving to mobile platforms, that there's an opportunity to have a way to bring this up. Are you seeing... now that people are using things like iPad and Android and stuff like that are there patterns there that are coming back into the desktop?

You know, Apple just recently with their newest release changed the direction of scrollbars. Are we going to see some of those visual tropes that have been happening with the IOS operating system are we going to see those starting to come back on the desktop and other places?

Hagan: I definitely think so. They didn't just change the way scrollbars work, they now hide the scrollbars when you're not in the scrolling area which is a direct lift off of the IOS platform because they don't have many pixels. They don't want to clutter it up by showing you a scrollbar.

Jared: Yeah, I wonder how long that's going to last because you need some sort of visual clue that there's more.

Hagan: Yeah, I mean I think the number of patterns we have is always increasing. We always have new problems to solve and the patterns are really just an expression of what we commonly do to solve these problems. And as the interactions evolve and we use different preferences, we use touch, we use different things, the patterns adjust and what we consider normal, changes.

One example on the IOS devices is for instance in a list of phone numbers, so I'll have a list of people's names and they'll have a row for the name and then they'll have a little circle on the end on the right. If you click anywhere in the row you make the phone call. If you click on the little circle you go edit the address book card for that person, right?

That's a completely new pattern that was developed on mobile and it would not surprise me if in a year or two we see that coming back to desktop. Stuff like that. So yeah, the pattern space is always increasing. Interestingly, I've been putting this class together and a lot of the patterns from desktop from 30 years ago and from web still apply in the mobile space.

So, there's an enormous amount of overlap between them. I think they're all converging into one big pattern space that just keeps growing.

Jared: Any of those 30 year old patterns that really shocked you like oh my God we still use that?

Hagan: We still use this basic desktop form for tables. A table with a toolbar above it. That has not changed. Mobile has a little trouble with tables because they're wide. And so mobile is using more of what I call a list where you don't really have columns you kind of wrap stuff into thick rows but they still have a toolbar at the top or the bottom. It's the same idea.

Jared: Yeah, OK. Yeah, it's true. That goes back to almost pre-Windows days where, yeah, using DOS and character based displays.

Hagan: Yeah. And honestly you look at the design for tables. You click on the header to sort it. Sometimes you can click on the header, right click, and you open a little menu of other options. I mean, those patterns really haven't changed and they work really well. Why fiddle with them?

Jared: Yup. That makes perfect sense to me. Well, Hagan, it is wonderful talking to you. I'm really excited about the class that's coming up in November. I think it's going to be a lot of fun. I'm really looking forward to learning all sorts of great stuff.

It sounds like the perfect class for folks who really want to get a handle on how to get that stylistic essence of their individualistic design traits for each developer out of the design so it feels like it was written by one person.

Hagan: Yes. We're going to work on consistency but we're also going to work on it being beautiful and elegant and solving people's problems.

Jared: That sounds excellent. I'm looking forward to it a lot. Thanks for taking the time to talk to us today.

Hagan: Thank you.

Jared: So if you want to take Hagan's workshop it's easy. You just go to UIConf.com and you sign up for the three day event and you have to sign up right away because her session's going to fill up. I got to tell you that. It always does. So UIConf.com. That'll be November seven through nine.

Hagan's going to do a full day workshop on the ninth on dealing with complex applications, how you make complex applications so much simpler. So I'm looking forward to that. Thank you Hagan for spending the time with us today and I'd like to thank the audience for once again encouraging our behavior. Take care. We'll talk to you soon.