Site MapUser Experience for a Better World Site MapUser Experience for a Better World 
|
Dr. Susan Weinschenk: Hello! I'm Dr. Susan Weinschenk, Chief of Technical Staff at Human Factors International and welcome to this live webcast presented by HFI's Usability Broadcast Network. Our topic today is "More than just a pretty page - The importance of user interface design patterns" and I'm really excited to have with me here today Dean Barker, Executive Director at HFI and a dear friend of mine, welcome Dean. Dean Barker: Thank you Susan, thank you for having me here. Dr. Susan Weinschenk: Now before we get started in talking about patterns. There are a few reminders I want to make for our audience. First of all, if you haven't downloaded the white paper that is available at the website, we have a white paper on Design Patterns and you can download that now or after the webcast. Also you might want to take a look at our complete schedule of our webcasts. We have a whole bunch of them coming now throughout the rest of the year and those are also listed at our website. And we will have a Q & A session at the end of our discussion after we are done talking about patterns and you can submit questions for us at anytime during the conversation so there's a link down at the bottom of your screen and just go ahead and submit the questions whenever you like and we will save some time at the end for that. So to get started talking about patterns and you know this is really a hot topic. The UPA Conference that just happened in Austin, the theme was patterns so we know that people were very interested in it. But I also know you Dean, and I know that you are a definition kind of guy. Whenever you are talking about anything you always want to define exactly what we're talking about so why don't we start with that. Could you talk about what you think patterns really means? Dean Barker: Sure. Well, in its simplest form, a pattern is basically a model, so it's something that we use for the purpose of making other things including user interfaces. Dr. Susan Weinschenk: Okay, well how did this come about, the use of patterns? I mean, is this, you didn't make this up... Dean Barker: No, no. Dr. Susan Weinschenk: Okay. ;Dean Barker: ; No, this has a long history in the creative fields and in design in general. As a matter of fact, we see patterns in everything. So if take a look at some of the images that you're seeing for films that you may recognize, I guess it depends on the demographics of the audience... Dr. Susan Weinschenk: Of who's out there and which films they are watching, right? Dean Barker: But you might be surprised to find out that these films that you see here are ; some of the ; top 150 films of all time and they indeed follow a pattern. So you've actually been watching the same movie over and over again. Dr. Susan Weinschenk: (Laughs) Dean Barker: It's the same structure, the same storyline, a very well defined pattern. Actually this analysis was done by a fascinating fellow named David Siegel and so we so we see patterns in the films and in the literature that we consume. We see patterns in our roads and highways. We see patterns in basically all manners of architecture. Basically patterns are everywhere. Dr. Susan Weinschenk: Well, one other thing you know I'm always interested in research on the brain and there is a lot of research out there that shows that our brains are really wired for recognizing patterns, interpreting the world through patterns so it doesn't surprise me at all that we kind of infiltrated even movies and everything else with patterns but tell me what this has to do with interface design. How are patterns involved in the process of designing interfaces? Dean Barker: Well it basically started in terms of formal theory with some seminal work by a fellow named Christopher Alexander. Christopher Alexander is a well-known architect who wrote a couple of books called "The Timeless Way of Building" and "A Pattern Language". SW And you talk about this in the white paper right if people are interested, are some of these listed in the white paper? Dean Barker: Yes, absolutely. Dr. Susan Weinschenk: Okay. Dean Barker: There's a good deal of bibliography in the white paper and even now these aren't specifically about interface design... Dr. Susan Weinschenk: Yeah, these are not about software design. Dean Barker: No, it's just in terms of design principles and constructs in general and certainly for formalizing the concepts behind pattern languages. This is very important work but Alexander's work was taken some years ago by the Software Engineering Committee including a book by Gamma and some other folks called "Design Patterns" and that book really codified a system of patterns and a language for patterns for software development. And so what you found in recent years, within the human computer interaction UI design community, we've seen a few resources begin to be published with our realm. And there are only a handful of them and they all have different approaches, use different language so there is a very promising foundation with the literature that exists right now but in terms of UI design, it really is sort of the Wild West and this is - this is a pretty new arena for us to be in. Dr. Susan Weinschenk: In UI design - a little bit more established in the software development world... Dean Barker: Absolutely. Dr. Susan Weinschenk: Okay. Dean Barker: Absolutely. So even though design is a formalized field of study unlike architecture, unlike even software engineering we're not quite as mature in our approach to patterns so you'll see conflicts in terms of how people talk about patterns, how people use patterns, that's also been codified at this point. Dr. Susan Weinschenk: Okay, now this – you refer again to David Siegel here. Are you aware that David Siegel - I was surprised to see you talking about David Siegel and that he is involved in talking about patterns because you know he was back one of the first people having an unusual website so I don't know if you even remember. He had a website with pictures of Marilyn Monroe back at the time when everyone just had brochure ware and before that he was a typographer, he designed font. Dean Barker: Yeah, he's an interesting guy. "Creating Killer Websites" is a great book but now I think he is in the business of doing script consultation and screen processing. Dr. Susan Weinschenk: Oh is really, wow? ;Dean Barker: Yes, a very interesting fellow. Dr. Susan Weinschenk: Okay. Dean Barker: So today, what we want to do is, we want to talk about patterns in the construct of UI design. Dr. Susan Weinschenk: Okay. Dean Barker: Specifically we want to - we want to talk about within software engineering... Dr. Susan Weinschenk: Alright. Dean Barker: Limiting to UI design within software context and limiting to UI design assuming that you have a process for design. Dr. Susan Weinschenk: Okay, maybe a lot of assumption there but we're going to... Dean Barker: We're going to constrain a little. Dr. Susan Weinschenk: Constrain a little bit, so we're going to talk about patterns for use in, when you say software, you mean software applications and websites? Dean Barker: Correct, absolutely. Dr. Susan Weinschenk: Okay. Dean Barker: Absolutely, and so if we think about, if we think about patterns within UI design we also want to further constrain I think, the discussion of patterns to interaction design. So if we think about UI design one way to consider that realm is with 3 dimensions - visual design, information design and interaction design. Certainly there are and could be described patterns within the visual design and information architecture. Most of the literature that exists now and the approach that I have taken to patterns is within interaction design. Dr. Susan Weinschenk: Okay so that's what we're going to talk from here. Dean Barker: Fairly... Dr. Susan Weinschenk: Okay right. Dean Barker: So what is a pattern? A pattern is basically a solution template. So it's a template for design, basically that is intended to be used to create other designs. Dr. Susan Weinschenk: Okay, so it's a template for design used to create other designs but that sounds a lot like standards. I mean we had standards for a long time, right? So how is this any different than the usual standards that somebody might have in place? Dean Barker: Yeah now, that's a good question and again there's a lot of variation in terms of people, how people discuss and use UI patterns. And so, I really distinguish between UI patterns and guidelines. A pattern is a thing. It is a template that you can use to create other designs. It's not a rule so for example, here's something you might find in a pattern library or pattern repository. ; It's as though, the pattern is described as "using a small section of every page show a consistent set of links or buttons that takes the user to the key sections of the site or application." So is it a pattern? Is it a guideline? Is it a rule? Maybe you can think of it as an abstract pattern or pattern of high level. Dr. Susan Weinschenk: Right. Dean Barker: I would tend to call something like that as guideline. Dr. Susan Weinschenk: That's a rule, that's not an actual thing that just tells me what to do. Dean Barker: That's right. It's better to define, physically define a global navigation element like a tab card set... Dr. Susan Weinschenk: Okay. Dean Barker: ; And define and describe that and make that available to use rather than just have a rule. Dr. Susan Weinschenk: So that will be a pattern rather, to actually have tab cards that would be the pattern and not just the rule about when to use tab cards. Dean Barker: Right, physically defined it's more concrete that way. Dr. Susan Weinschenk: Okay, alright. So a pattern is a thing and a guideline would be more a rule. Dean Barker: That's correct. Dr. Susan Weinschenk: Alright. Dean Barker: And so in order to use those patterns and to even construct them, it's necessary to create a pattern language and this is why the Alexander work is so important because he really goes into detail about pattern languages. And so pattern languages are basically these finite combinatory systems that allow you to take these patterns and assemble them into new designs. So the idea is having a catalogue or repository or a library of patterns. You can then take them in a modular fashion and reassemble them into new designs. Dr. Susan Weinschenk: So when we talk about patterns we can't just talk about the actual patterns, we have to talk about this whole system we're going to put in place for creating them, documenting them and using them. Dean Barker: That's right and the system includes, kind of the Meta level, the structure of the pattern itself, the individual patterns and then, and this is something that is fairly complex, the rules for the combination of that. Dr. Susan Weinschenk: So you're back to rules though. Dean Barker: Yeah but a different set of rules. Dr. Susan Weinschenk: But the rules have to do with how you combine them. Dean Barker: That's right. Dr. Susan Weinschenk: Now I've heard you use the phrase, I don't think you used it yet today but I heard you say this before and I wrote it down, you used the ; phrase when we're talking today about the range of scales. What does that mean and how does that come into what we're talking about here? Dean Barker: Yeah, so range of scales basically talking about the level of granularity of pattern and it comes from Alexander's work and it is a very important concept. And so when we use patterns to create things they are not homogenous in terms of how granular they are so if we look, as we will shortly, at a set of UI patterns, it's important to look at them and classify them by their purpose. So for example, what tasks they support, what user tasks they support because that helps you determine what's proper for combining them, right? But then you also need to look at them in terms of the range of scale and analyze them and document them in terms of their range of scale. So for example, on a web user interface you might have a range of scale that goes from a high level of a series of pages to individual page patterns to sub pages or component patterns to all the way down to the rigid patterns which is just you know, your tool kit that you use in radio buttons and drop down... Dr. Susan Weinschenk: Oh, okay. So it's not just different types of patterns but there are actually these different levels? Dean Barker: Yeah and that's usually important so if we look at for example, the diagram that you're seeing now that shows how patterns are combined together. Again, a page series is going to include N number of pages which should be composed of N number of sub pages and a sub page might have other sub pages or widgets. And so any pattern library having this range of scale is really what allows you to create new designs that are based on requirements and that really give you a somewhat customized design but still being based on pre-design, pre-constructed component so that they are usable. Dr. Susan Weinschenk: But you would always use, or you are suggesting to always use these levels always, I mean that we shouldn't be creating our own little range of scale categories? Dean Barker: Yeah that's a great question. You know, I sort of offered this in the white paper and some other work that I've done. It's based on just a handful of actual projects in the real world and I think it is very useful as it is in the web environment. I think in the creation of a pattern library and we'll talk about in detail later, what's important to understand are the organizational needs and document the patterns in whatever level is appropriate. So for example, if feasibility dictates that page level templates are the only patterns that are going to be used by the development organization, fine, get used to that. Dr. Susan Weinschenk: So in a particular organization I might not have all these categories, but these are just the kind of the typical categories that people use? Dean Barker: That's correct. Dr. Susan Weinschenk: Alright, so we have a page series, sub page series is that right? We have the widget and then I'm missing one, what is that? Dean Barker: So it's a page series, a page... Dr. Susan Weinschenk: A page. Dean Barker: Sub-page. Dr. Susan Weinschenk: And then the widget. Dean Barker: The widget. And the sub-page is sort of unfortunate - it is a term that I had used because we used it - in most organizations that I have worked before we were using components and modules and unfortunately in software development projects you've got this larger vocabulary. Dr. Susan Weinschenk: It has a different meaning, yeah. I don't think there is any word we can pick for anything that hasn't been used in any other way, right? Dean Barker: Yes. Dr. Susan Weinschenk: Alright, now I think it will be helpful if you could show us some examples, some actual examples of these rather than being so abstract. Dean Barker: Sure, so let's take a look at a page series. So we'll use, we'll use an example from Amazon.com. It's a design that everyone's probably familiar with, I think most of us probably use that and so if we take a look at the purpose, at the task of searching for a product, you start with these series of pages that, this page series rather that has a number of defined pages within that. Dr. Susan Weinschenk: Now you are showing on these slides, you've got down at the bottom you've highlighted, so this first one that you showed us is a page series that's why the icon at the bottom of the screen is highlighted. Dean Barker: That's right so the level of scales is denoted by the icons. Dr. Susan Weinschenk: Oh that was really a fancy way of saying that icon thing over there is highlighted, but okay you've been exact in terminology. He's really exact in terminology. I have to tell you, I'll tell our audience years ago. I don't want to think how many years ago, Dean and I sat in a room and created that interface design methodology together and it took I don't know, you kept coming back, more trips and it took us months to... Dean Barker: That was a long process, yeah. Dr. Susan Weinschenk: And we would have like a four hour debates about like a term, about one word literally – which word we were going to use so I just had to throw that in. Dean Barker: There was some physical combat involved I think... Dr. Susan Weinschenk: No, no it was just a discussion, okay so keep going. Dean Barker: So within that page series there are a number of individual page types or page level patterns so for example, if you look at the home page that is its own fairly unique type if you look at some of the elements that it contains at the sub page level, you've got this global navigation, this tab card set, within that they embedded this search entry component... Dr. Susan Weinschenk: This is another sub-page... Dean Barker: Another sub-page which is comprised of the text box and the drop down list box. Dr. Susan Weinschenk: And these are the widgets. Dean Barker: These are the widget level patterns. Dr. Susan Weinschenk: Okay. Dean Barker: And again, you know there is some arbitrary nature to the language and so this is just that I have chosen this documented but regardless it is important in an organization, you create a pattern repository that you are thoughtful about the range of scale and exactly how modular you are going to be. Dr. Susan Weinschenk: Okay. Dean Barker: So in this case, these two widgets comprise a larger sub-page and then you've got other sub-pages within these page level templates such as the browse menu and the search results page is the next page in the next series... Dr. Susan Weinschenk: Is the next page in the series, okay alright. Dean Barker: Which go, which is comprised of the result list and the global navigation? Dr. Susan Weinschenk: So you're moving in and out of these different levels you're showing us. Dean Barker: Yeah showing the different levels of scales within this page series and then ultimately it ends up - this purpose or task ends up with the product details page and that contains the product information and again that global navigation and obviously when you look at this - so if our viewers look at this page you know you can take the information that exists in the main work space that has the data about the book, you can consider that a pattern or you can take that to the what's to the ; right of that, that has the buttons on it and consider that another pattern and ; I mean you can be very granular about this right... Dr. Susan Weinschenk: But there are lots of patterns? Dean Barker: Yeah this is simply for the purposes of illustration and goes to a certain level based on creating a reasonable system for re-use and we'll talk more about that later but that's really the goal for all of this. Dr. Susan Weinschenk: Now you're saying though that what an organization would is they would have defined and documented all of these patterns. It sounds like there are just these few pages that we went through. There were a lot of, potentially a lot of patterns in there at all these different levels, it sounds like a lot of documenting goes on and a lot of details that's on. How do you go about you know actually doing this? Dean Barker: Right. Well in terms of the documentation we shall talk about that later. There is an example of the documentation in the white paper and this is what is called the pattern description. So each of those individual patterns we look at from the Amazon example could and should be documented in this pattern description and so that's going to contain some Meta information, some identifying information such as the serial number, name.. Dr. Susan Weinschenk: You mean the serial number of - the pattern itself has a serial number? Dean Barker: Absolutely. Dr. Susan Weinschenk: Wow, now why does a pattern need a serial number? Dean Barker: Your pattern repository may ultimately end up, certainly being dozens and possibly even hundreds of patterns. Dr. Susan Weinschenk: Okay. Dean Barker: So just for managing that level of information it's useful to have a serial number. Dr. Susan Weinschenk: Okay. Dean Barker: What I found, through doing this in the trenches is that you'll even start by naming these patterns of course, but what happens is that'll develop some nickname so for example, one place we had a name, address, phone number form entry, a big very complex data entry form and that was the name, address, phone, data entry pattern which eventually just became the NAP pattern, for name, address, phone. Dr. Susan Weinschenk: But later on if someone wants to look it up won't be able to find it because of that? Dean Barker: Right, all that they need to say is we need the NAP pattern and we need to use that here so that's why for example, here you see aliases or personas when you want to do something like that but in your repository whatever identifying information you need for your organization to be useful, that's what is important. Dr. Susan Weinschenk: Okay. Dean Barker: And so I would start a pattern description with that and then we're sort of going classically through the software engineering literature on patterns. The typical documentation strategy for patterns is to describe the problem and solution. So you know, effectively a design problem that is going to have a solution and that solution is this pattern and so that is basically the high level structure of a pattern description. And I think that you will see that in most people's approach to design patterns, I'm starting to wonder if that's even the best way to document patterns and I taught a tutorial in UPA maybe a month ago or whatever it was and there were about 45 people in the tutorial and we talked about that and I think that there was a pretty good debate about what the actual best structure is but you'll see in most of this literature this problem solutions page, this problems solution strategy documentation. I don't know as designers if we think that way. Do we really think about the problem that I am facing is "user needs to..." or "the system needs to x, y and z" Dr. Susan Weinschenk: Yeah, that's a good point. Dean Barker: Or do we think, "No I just need a form that does this or no I just need this widget that does this..." Dr. Susan Weinschenk: Well you know, and I forgot to mention when I introduced you that you've done your Master's thesis on this topic and I was just going to say if you ever ; want to go back and do another Master's or go in for your PhD you can focus on that question right just if you wanted to. Dean Barker: (Laughs) I'm probably not in a hurry to do that. Dr. Susan Weinschenk: Oh okay. Dean Barker: So the pattern description contains a lot of information and one of the things that's important to include in it is known usage. I would include it if you're doing this on an enterprise level both internal known usage and external known usage. Dr. Susan Weinschenk: What do you mean by internal and external? Dean Barker: So for using it in a company so for example, we've got Amazon as if, we've got this documented as if we're the Amazon design team. Dr. Susan Weinschenk: Okay. Dean Barker: If I am Amazon I want to know how we're using this pattern internally but I also want to know how Barnes & Noble is using this pattern, how are our competitors' sites or similar sites using this pattern? Dr. Susan Weinschenk: Oh really, okay. Dean Barker: Sure because you want to see... Dr. Susan Weinschenk: Whatever the others are, if they're all the same in terms of... Dean Barker: Yeah in terms of web norms, in terms of alternative ideas... Dr. Susan Weinschenk: Okay. Dean Barker: It's that sort of thing. Dr. Susan Weinschenk: And in this pattern description would be an actual picture of an example? Dean Barker: Yeah that's correct and so you've basically got a couple of different pictures there. You've got the diagram of the actual pattern which could be done in wire frame format. You've got maybe some screen shots if it's in production and then some additional screen shots for external resources or external instances of the pattern and again this is something that ; I think became more clear to me in the tutorial that I was teaching as there was a lot of good collaboration with people who participated and I've been coming to this conclusion and I think that everyone seemed to agree that, in terms of pattern documentation more diagrams, more pictures, less prose. Dr. Susan Weinschenk: Well people learn by example and they like examples right? Dean Barker: Absolutely. Dr. Susan Weinschenk: They always do. So this example that we just went through was you know, for a website right? But you can use this in other environments besides just websites? Dean Barker: Yeah definitely and for example, we do a lot of work in the mobile user interface space and so here's an example of a page series pattern for a mobile user interface and one of the things that you get into is, if you are creating a pattern library that supports multiple interfaces or types of interfaces you've got some very difficult decisions to make... Dr. Susan Weinschenk: You mean if you've got something that you can interact with the website or on a desk top as a GUI application or users can access it through a mobile device, is that what you mean? Dean Barker: That's right and so the level of specificity in terms of the type of UI that you are supporting allows you to be more detailed in your pattern construction. If you've only got this one kind of platform, if you're trying to support with a single pattern library - GUI, web, mobile, speech basically you have to take your patterns to a fairly abstract level I mean basically task level patterns or possibly navigation level patterns or possibly some shared branding and tool kits but you can get the high level and very, very low level... Dr. Susan Weinschenk: Right. Dean Barker: But the in-between is kind of fuzzy. So it's pretty tricky and you know it's still a pretty new arena and I don't think a lot of people are doing this but I think that if you are supporting multiple platforms you're probably going to need multiple pattern libraries. Dr. Susan Weinschenk: Okay, alright. Would you be cross referencing on any of that or...? Dean Barker: Yeah possibly, possibly. Dr. Susan Weinschenk: Okay now you keep using this term library, right? So what we were looking at before was a pattern description right? What's a library? Is that just like you know you have a folder on your hard drive and it's got all your patterns in it or are you using that term in a different way? Dean Barker: It's simply your repository. So pattern library is the repository physically of your patterns collection and so that can be just a file folder on a hard drive or shared drive in some place. It can be documentation. I mean you can't probably through the camera here but the stack of books as a pattern library. We tend to - and I would recommend that your pattern library be online and that it be ideally integrated with your UI standards and guidelines. In addition, and I think in the white paper we discussed this or referenced it, you can look at the Yahoo examples of for how they've done this but in addition you want that pattern repository or library to be synchronized with a code repository so that you've got your design patterns and their corresponding development patterns. Dr. Susan Weinschenk: So these things will be linked so if I'm looking t a design pattern. I could then link to for instance, a guideline or guidelines around that and I could link to if I'm a programmer or something to do with the code? Dean Barker: Right so that the development pattern library will have the code components then have the corresponding design patterns associated with that. Dr. Susan Weinschenk: ; But you wouldn't put that all together in a pattern... Dean Barker: Well we might and those are decisions that the enterprise needs to make you know if you've got, so you've got these design issues and these challenges around actually constructing the patterns and so it's then basically a whole separate project, you have then this challenge of creating a pattern library and so if you look at, if our viewers look at the slide that's showing now, this is an example of a high level project plan for creating a pattern library and so just the act of creating a repository like this is a non trivial project. Dr. Susan Weinschenk: Right so can you just go out and buy you know, like a library of pattern or do you have to create your own patterns or can you just go out and buy those patterns in there and use one of those? Dean Barker: You certainly can get some level of benefit from purchased or off the shelf patterns, there's not a lot of them. So we have for example, at HFI, our tool - Usability Central that we sell that has standards and guidelines and best practice information and it includes basically a single range of, or a single level of scale patterns which are these page type that we... Dr. Susan Weinschenk: Page level? Dean Barker: The page templates right. Dr. Susan Weinschenk: Okay. Dean Barker: And embedded in there are the corresponding static codes or components as well, right? And so there's certainly some value to that. There are some online resources that include what I would call generic patterns; a lot of those are listed in the white paper. Certainly the books that exist I think have value and they represent generic patterns but those have a certain degree of re-use and value. But where you are really going to find the value in patterns is if your organization takes the time to tailor and customize these UI patterns for your design and development of organization because ultimately what you want to do is you want to reuse them to assemble the designs so at the end of the day these generic patterns resources are good best practice information but really provide business value they need to be thoughtfully tailored and customized for your organization. Dr. Susan Weinschenk: So talk about that for a minute I mean because it sounds like this whole thing you're describing is a lot of work. Dean Barker: It is (Laughter) it can be... Dr. Susan Weinschenk: It can be, it can be a fair amount of work. So can you walk us through what that process would be like? If an organization said well two questions, one is "So why is it worth it? Why would I invest you know, the time to do this?" and two, "How would I go about starting, I mean I'm not going to go to Amazon...?" Dean Barker: Right. Dr. Susan Weinschenk: "And I look at their patterns and use that I mean I could but I'm not in that space, I mean that's not even worth what our company does..." Dean Barker: Right, right. Dr. Susan Weinschenk: "So how do I get started thinking about doing this and why would I do this?" Dean Barker: Well let's come back in a few minutes to those, to the last question... Dr. Susan Weinschenk: To why, okay. Dean Barker: As to of why we do this. In terms of how you would go about it, you know the previous slide that we showed, where we talked about that formal approach for creating a patterns library that is sort of a proper project - a major initiative where you're probably going to make a business case for, much as you would for a standard projects, right, it's ; very much ; analogous to a UI standards project where you're going to cause testify and then in advance you're going to put the resources into it and you are going to execute a project like that and that is where you basically create your initial patterns library or you develop the guidelines associated with that. You develop the rules system associated with the combinations of the patterns and you provide for the main ends of the patterns and that's also a point of consideration because like any repository of information that sort of captures corporate knowledge, this thing has a life cycle, right? So once you create this initial library, you are not done, you create it and then you need to provide for some level of maintenance, the ongoing care and feeding... Dr. Susan Weinschenk: Right you're not going to just create the library, you put it out there and you're done – you have to change the pattern... Dean Barker: Right and so I've been a part of organizations and design groups that have done sort of the big bang right, in that way... Dr. Susan Weinschenk: Okay major events. Dean Barker: A major patterns project and in other places it took more of a, an incremental approach including the guy that I am working with right now where it's somewhere in between where basically what we're doing, maybe not a big bang but something a little more modest than that with a pilot program and then you know, pending the success of the pilot program there probably might be more incremental work than there might have done in this example. Dr. Susan Weinschenk: So you mean that you're not creating a set of all the possible patterns that they might ever need to create any of the applications that might occur in the next 5 years... Dean Barker: Right, that's right. Dr. Susan Weinschenk: We're just kind of creating a smaller set that they think will be useful in the next year and this one set of applications, don't you think? Dean Barker: Yeah then you really have to define this domain. So what applications or what areas of the business or what are we going to support with this... Dr. Susan Weinschenk: So that's how you start you kind of you know, figure out that scope and then look at what you have now and what you have coming down the pipe? ;Dean Barker: Typically. So it really starts in creating a patterns library, it really starts, usually with a lot of reverse engineering right? And so what you'll find then I think is ; if you go through the process of reverse engineering and de-constructing, your existing body of work of interfaces, you'll find that by documenting those patterns and providing for the life cycle of those products, so re-designs over the future, providing for new products that the company is going to bring online there that are going to be necessarily part of the same family or have similar looking feel to these other products, you know ; you'll find that by doing that you're able to gain a lot of business sponsors but then you also see that, you know, Oh boy, we had two very similar instances or ten very similar instances where we did radically different things and... Dr. Susan Weinschenk: That's how you find out that you have 24 different sorts of ways to search on there within your site applications. Dean Barker: That's absolutely right and so sometimes you want to consolidate those things... Dr. Susan Weinschenk: Okay. Dean Barker: And rectify that. Dr. Susan Weinschenk: Re-design and come up with these search. Dean Barker: The new best thinking on the search box or you may just find just the opposite where you have something that really should have multiple variations that provide for different designs... Dr. Susan Weinschenk: You actually do need that base to search. Dean Barker: That's right. Dr. Susan Weinschenk: Okay right. Now what about research on this? Is there any research about how people are using patterns or how many patterns you need or what kinds of patterns you need? Dean Barker: Not a lot. There's no published research that I'm familiar with which isn't to say there might not be some out there. Dr. Susan Weinschenk: But I haven't, you know Kath – Dr. Kath Straub and Dr. Kath Straub is always looking at research and I look through the research she comes up with and I don't remember seeing any research on this. Dean Barker: It's a pretty new arena and I haven't seen any... Dr. Susan Weinschenk: For interface design. Dean Barker: For UI design that's right, but I can tell you based on some of work that I have done both academically and professionally that if you constrain to web UI and specifically an e-commerce site is where I have done on this work and you think about these classifications of patterns, one important way to classify patterns is as I said, is by purpose, right? You are looking at basically the high level tasks that they are supporting with these patterns. So you can see on the slide that's been shown that 34% of the patterns in a pattern library might be considered foundational which is structural, header, footer is sort of you know, very concrete foundational patterns... Dr. Susan Weinschenk: Okay. Dean Barker: And that 23% are related to the purpose of buying, 13% for searching etc., etc. So looking at these metrics you can kind of get a feel for roughly how a patterns library might breakdown and I'll tell you again, based on a pretty modest amount of work but still interesting to have some numbers, that you could build a pattern or you can build rather an e-commerce system based on about a 100 patterns and those would breakdown if you look at the metrics on scale those would break down to roughly 37% at the sub page level, 36% at the page level, 21% at the widget level and then 6% at page series. Dr. Susan Weinschenk: That's interesting. So maybe over time we can get some more research like this. Dean Barker: Yeah I hope so. I hope that some people will take more of an academic interest in this and certainly I think as it becomes to proliferate or as it proliferates in the field it'll become more of a topic in academic discussion, yeah. Dr. Susan Weinschenk: So we talked about having like a whole you know the whole patterns, can you walk us through an example of okay I have my patterns, I have my library, now how will I use these? What would I do with these? Dean Barker: Well okay, so here we are almost to the end of the broadcast and we haven't talked about the purpose of this. Dr. Susan Weinschenk: Oh, okay. Dean Barker: So creating a pattern library is just the first step and it is a hard piece of work but... Dr. Susan Weinschenk: Okay. Dean Barker: But it's not intended to be documentation for user interfaces right, that's not the reason. Dr. Susan Weinschenk: If that's not why we're doing that, we're going to stop there? Dean Barker: So if we look at an example again taken from Amazon.com, take a look at the home page and think about, okay our purpose for having this library is to assemble designs. Well, let's take a look at the patterns that exist with the current home page. Now, assume that these sub page patterns and many other patterns are documented, we've got our whole pattern library already documented and established. Now imagine a scenario where the company is going from its current version to a major re-design, they want to accommodate some new content, some functionality and yet they still want to retain the same look and feel. So make some usability improvements, we add some things but we still want to make it look, feel and smell basically the same way and location, right? Dr. Susan Weinschenk: Okay. Dean Barker: Now just for the home page about how long would it take to re-design that in a normal design process? Dr. Susan Weinschenk: I have no idea, I can't you know gauge... Dean Barker: It's a piece of work, right? Dr. Susan Weinschenk: Yeah it's a piece of work. Dean Barker: It's not trivial, okay. So let's re-imagine then, the Amazon home page. So this is the Amazon home page we designed and if we then look at the patterns that it is based on which were taken from the pattern library, simply in a different configuration... Dr. Susan Weinschenk: Okay. Dean Barker: Now what we've done is we've re-designed it, we've optimized it, made some usability improvements and what not, now we've gone from four pattern or four compounded sub-page pattern set to a five pattern set... Dr. Susan Weinschenk: Okay. Dean Barker: And this was done in about 2 minutes. Dr. Susan Weinschenk: Oh interesting! Dean Barker: Literally just assembling these designs... Dr. Susan Weinschenk: And then I'm assuming that for instance, if you were Amazon and you now bought another business entirely, right? And you were going to create, you need to create a whole another website that you could take the same patterns and just use it on the new website and put in new logos, I mean you can just kind of keep going like this forever, right? Dean Barker: You can end at many levels so for example, one organization that I was working with, basically the scenario was that they had this flagship application, it's an online application, that was being localized for jurisdictions throughout the world but they wanted to leverage the US application and I had to rebuild things and I had to reinvent the wheel. Also needed a mechanism for discussing with the local product developers basically the functionality, the estimate for how big of a development effort it was... Dr. Susan Weinschenk: Okay. Dean Barker: Some sort of strongman structure to talk about, their content and so the pattern library basically served all those functions. Dr. Susan Weinschenk: Allowed them to do that kind of localization, interesting. So that means that you can put this together, you can put together new applications for faster that's that ROI part. Dean Barker: Right, right and so if you look at the comparative designs and the related patterns for the Amazon example imagine that you had this pattern library and you wanted to mock up a number of different examples well, using the library, quickly assemble them... Dr. Susan Weinschenk: You have to do the usability testing and you could come up with two or three alternatives, as you said in a matter of minutes rather than in days or months. So that's how we get our ROI. Dean Barker: Yeah and so you know the business proposition is basically based on having this set of core assets and so the SEI, Carnegie Mellon has some good work now on core assets and software product development that I would recommend people take a look at and that concept is falling around out there for sure. But the idea is to create these re-usable models that ultimately poured into more of a software factory. So it's taking a rather laborious process of design and development, you know I think of those as very tightly coupled and basically making that more of a manufacturing based paragon. Dr. Susan Weinschenk: Okay. Dean Barker: So the business proposition of patterns is more efficient design and development and basically based fundamentally on the concept of re-use, I will say re-use, re-use, re-use. It's like location, location, location. Right? Dr. Susan Weinschenk: Now I think I know how you're going to answer this question. But does using patterns mean that if I use patterns and I create the interface, will I have a more usable interface when I'm done? Dean Barker: No, no it doesn't mean that at all and I know that some colleagues will argue, argue with me. Dr. Susan Weinschenk: Yeah because you know I don't want to create interfaces that aren't usable. Dean Barker: Well reusability does not equal usability. You can have a bunch of junk patterns that are usable but they're reusable and they provide for more efficient design and development. Good usable patterns is this key with well constructed rules systems for assembly and combinations, those will help provide for greater usability which is important because really think about how much design is done by full time designers? Dr. Susan Weinschenk: You mean full time interface design usability people? Dean Barker: That's right. Dr. Susan Weinschenk: Yeah, I don't know. Dean Barker: I mean some fractional per cent, try... Dr. Susan Weinschenk: 10%, 20%. Dean Barker: So most of the design work that's being done at user interface is, is really being done by people whose job, it is to be business analysts, or programmers or something else. Dr. Susan Weinschenk: They're doing something else besides just designing interfaces. Dean Barker: So let's give them tools, right, let's give those tools to these people so they can do their job more efficiently. So they can have usable components. So that they create more usable designs and then also have tools like this for people like us, who do specialize in this area, so that we can do the routine mundane and ordinary things that much quicker and focus our time which is at a premium on the challenging harder parts of design and aspects of design and have greater business value. Dr. Susan Weinschenk: Okay, alright so you've set the record straight. You would suggest that we do reusability and usability together? Dean Barker: Absolutely. Dr. Susan Weinschenk: Okay I just wanted to make sure that he was going to say that. So we are ready to go to the questions and answers I think. Just wrapping up here, we talked about a lot of stuff. We talked about patterns, and we talked about libraries of patterns and anything that you want to add before we - because you know I actually have questions already. Dean Barker: The cards and letters are pouring in. Dr. Susan Weinschenk: They are, they are. So are you ready to go? Dean Barker: Let's go. Dr. Susan Weinschenk: Alright so let's see what you guys, I'm just reminding everyone, if you want to submit questions, you have a link on your screen there and you can submit the questions. We have a bunch here and let's see how many of these we can get through. So here's the first one. ; ; QUESTIONS & ANSWERS:- Dr. Susan Weinschenk: Within your definition of patterns and using the example of a website, would every single element in the website be defined by a pattern or would some elements always be "one off?" Dean Barker: Yeah that's a good question. Certainly things are going to be one off. So one concept that I didn't bring up earlier was the notion of instantiation right. You have a pattern, so take the cookie cutter example and I don't mean with apprehension. People often talk about cookie cutters and they go, "Oh that's a cookie cutter." No, it's not a negative thing at all especially if you see me trying to make Christmas cookies around the holidays. But if you take that cookie cutter and you make a bunch of Christmas cookies, we are going to decorate each one differently, right? Not to say that UI design is all strictly decoration but there are these instantiations. So as you instantiate the patterns, there's certainly going to be idiosyncratic elements, idiosyncratic elements that you didn't accommodate and the other thing is that also as you do this the whole notion of the maintenance of the pattern library right, you will find "Oh we really need a pattern for 'x' that came out of you know some of that work or variations" certainly on the whole idea of variations. Dr. Susan Weinschenk: So you can create new patterns or you can create variations so a given pattern can have multiple variations. Dean Barker: Yes and I would recommend that. So for example you might find using the search example we've used, you might find for example I think, just based on the Amazon example, they had I think four different search templates types... Dr. Susan Weinschenk: Okay. Dean Barker: And there was one that I think that Barnes & Noble used, there was a fielded search that Amazon didn't use that really I think is a very useful pattern, those are all variations. They have the same function but they're used... Dr. Susan Weinschenk: Okay and they might even have some things that are similar but they are slightly different. Dean Barker: Right and based on your design requirements in specific instance you are going to choose a different variation or based on your different needs. Dr. Susan Weinschenk: A different variation right. Here's the next one. To create a pattern, is data collection of any kind required? Dean Barker: Well it's interesting; I'm not sure what they mean by data collection in terms of... Dr. Susan Weinschenk: I think they meant and this came in pretty early so I might know just a little bit so I think they mean, I'm going to guess what they mean that can you just go create a pattern or do you kind of analyze some data beforehand before you start to create the pattern? Dean Barker: You know in the process of creating a pattern library it typically begins with this reverse engineering at an enterprise level that we have... Dr. Susan Weinschenk: Okay. Dean Barker: So if that's the type of data we're talking about absolutely, that's a very, it's a pretty robust process that's necessary. If you're talking about user data... Dr. Susan Weinschenk: Yeah what about you know user requirements and do we have to do that before we create a pattern? Dean Barker: Well so, okay that's interesting right? Who are the users? What users are we talking about? Dr. Susan Weinschenk: You mean I'll be talking about the end users who're using the application or are we talking about users of the pattern library? Dean Barker: Of the pattern library...you're right, and both ought to receive some level of consideration. Dr. Susan Weinschenk: Okay, so we actually, we collect some data from both of those user groups? Dean Barker: No, I would like to recommend that honestly the organizations that I worked with who have done these pattern library projects. I hate to say but the focus has been primarily on the users of the library and this notion of institutional re-use rather than necessarily its impact on the end users. Although to be fair, that's part of the consideration that you are establishing the patterns because you want to make usable patterns. You want to create greater consistency. You know so there is consideration given but I haven't yet seen anybody do a lot of research in that. Dr. Susan Weinschenk: So I kind of get the feeling that when you are doing this work and when you're creating these patterns, I mean, am I right in saying, you would say you know jump in, figure out how you are going to do it, get started and do it rather than it being you know this is the way – this is the methodology for creating a pattern library, you must go out and collect data from all of your end users and you must, because we talked about you know deciding on scope? Dean Barker: Yeah, well I mean I have a process and I think that it's described in the white paper that you tried to do a UPA as well as that it's a process for creating a pattern library... Dr. Susan Weinschenk: But you're pragmatic at the same time. Dean Barker: Oh totally pragmatic and I would say you know, kind of the "some is better than none" idea that if an organization can do some level of developing a pattern library, just like standards and guidelines. Dr. Susan Weinschenk: Yeah. Dean Barker: I would cultivate that and grow it over the time and that's preferred to not having any, it depends on who your audience is, getting back to the user track, who's the audience for the pattern library? So I know a lot of our viewers are going to be members of design groups right, user experience group, usability groups, well you've got some level of control over that group and it may not have the control over a large IT organization, over a whole ; enterprise right? Dr. Susan Weinschenk: Right. Dean Barker: So creating a tool kit just for those people. Dr. Susan Weinschenk: Just for you is different but if you creating a tool kit larger than that the process may be a little more complicated. Dean Barker: It's going to be more formal, it's going to require more funding, greater integration with the development teams, those sorts of things. Dr. Susan Weinschenk: Alright. Here's the next one. I notice you refer to "design patterns" instead of using the word "templates". Is there a reason you don't use the term templates? ; Why are we calling it patterns, why not just call this you know as sub-page, templates or use just template? Dean Barker: Yeah you know the vocabulary is a mess, right, and I've sort of standardized my vocabulary. If you look at the literature, you know including the Alexander literature, the software engineering literature, you know the ten or twelve research that existed in the HCI UI realm, the language is kind of all over the place and so templates is perfectly the suitable word if that is something useful for a given organization, I don't have any problem with it. Dr. Susan Weinschenk: Although the term pattern is starting to be used more. ;Dean Barker: Yeah. Dr. Susan Weinschenk: You see to me templates, this is just my opinion but templates seems to be a looser word you know, people can use templates, may be they're talking about patterns, may be they're talking about page level patterns? Dean Barker: Well exactly that's it, right. Dr. Susan Weinschenk: May be talking about patterns but not library patterns you know... Dean Barker: Right, right. Dr. Susan Weinschenk: So at first, when you at first were talking to me about patterns, that was my reaction. It was "Well, this is just templates" but then when you walked with me through all this stuff, the pattern library etc., I thought. "Oh, alright it's a little bit different." So you kind of convinced me that it will be better to start talking about patterns just because we could kind of, get away with all of our old assumptions or looseness about templates. So... Dean Barker: Yeah and I think there are two issues with that. One is this in sort of our sphere at HFI that the tools that we use and what we've been doing for years, templates has a connotation of these page levels... Dr. Susan Weinschenk: Page level, yeah, okay. Dean Barker: And the range of scale again, not to put the hammer on it, it's a huge thing important for providing modular design. But then also as you mentioned it, the whole notion of patterns is sort of proliferated and it is more mature in the software development and software engineering community so there's a great opportunity to piggy back on that and part of being able to do it effectively is using the same language. Dr. Susan Weinschenk: Right. Okay. Which teams or roles are typically responsible for identifying which patterns should be created? Dean Barker: That's a... Dr. Susan Weinschenk: But who's doing it? Dean Barker: That's a great question; you know somebody's got to do it, right? Dr. Susan Weinschenk: (Laughs) Dean Barker: So whatever resources are available, I think you know obviously the idea of having user experience professionals leading the charge, when we are talking about user interface patterns, that's important. But in most product development environments you're going to find a strong role in the site of work for business analysts and especially depending on how tightly coupled the UI patterns are going to be with the development organization, you're going to need to work more closely and even primarily with the developers so... Dr. Susan Weinschenk: Is it the famous "it depends" thing? (Laughs) Dean Barker: Sure, I've always said it depends but I'll say this the more you can be joined at the hip with development, the greater your level of re-use throughout the organization is going to be, so I strongly recommend as much as a company can, tying the UI patterns to development constructs so that you can get the re-use, both from the design and from the code. Dr. Susan Weinschenk: Okay. What type of governance committee or group do you suggest to (1) make sure that people are following the patterns and (2) make sure that you are properly maintaining and enhancing your patterns based upon future products and needs of the company etc? Dean Barker: Well that's a great question and it's always difficult and again it depends, in terms of making sure that people are following the patterns, you know that the patterns are similar to the issue we have with UI standards and guidelines, right? You know each organization needs to decide, what's going to be compulsory, what's going to be optional... Dr. Susan Weinschenk: Give suggestions, can they release applications that don't use these patterns etc. Dean Barker: Yes, so it's very much up to the company, I think, the big thing is that for that purpose and for the second part of the question, making sure that the patterns can always be properly maintained the big thing is whoever is creating the business case for this... Dr. Susan Weinschenk: The business case for having patterns and ... Dean Barker: For patterns and initiatives. Dr. Susan Weinschenk: Yeah. Dean Barker: Needs to provide for ongoing resources. So for example, a few organizations I've worked with basically have sort of settled on approximately half on FTE for the purpose of ongoing maintenance and governance... Dr. Susan Weinschenk: After the patterns are in place, okay. Dean Barker: Of the UI patterns catalogue. Dr. Susan Weinschenk: Okay do you think that's a good estimate of...? Dean Barker: You know that's the best I've got for now. I think it's probably a little wide and it depends on how broadly they're being used and what the design environment is but some level of ongoing commitment of resources is hugely important. Dr. Susan Weinschenk: With that person, would you say that it would be or should be the same person who'll be responsible for you know talking with people about patterns and continuing with the new developers, new interface designs come in the group. Dean Barker: Right. Dr. Susan Weinschenk: And recycle patterns with a resource person? Dean Barker: You know that's a great point, Susan, you know and the one thing that we didn't talk about is the process of creating a patterns library and evolving it out, right is communication and training. So there needs to be some level of communication and it needs to be ongoing, some level of training probably stepping down after an initial launch right? Dr. Susan Weinschenk: Right. Dean Barker: But absolutely that will be part of that person's role. Dr. Susan Weinschenk: Yeah, yeah there are some ideas as to what we are used to dealing with when we've done standards and passed same kind of governance issues and may be issues in training and maintenance... Dean Barker: Yeah and ideally they're a bundled right, like you have one as we show with HFI's Usability Central, you have one repository... Dr. Susan Weinschenk: That has talent. Dean Barker: That includes both. Dr. Susan Weinschenk: Well and I have to actually and the next question is right into that. Dean Barker: You didn't do that? Dr. Susan Weinschenk: Yeah right you know I didn't do that on purpose. (Laughter) Dr. Susan Weinschenk: If we try to introduce patterns in our organization, is it a prerequisite to have guidelines or standards in place first, or does it not really matter? Dean Barker: Yeah another great question. You can put the cart before the horse or the horse before the cart. Dr. Susan Weinschenk: So it doesn't matter? Dean Barker: Well what matters is where you're starting from, right? So if you have standards and guidelines in place, do the patterns work, provide for in the projects plan reconciliation and integration of the standards with the guidelines that you have in place or if you don't have guidelines in place and you have the bandwidth and the capacity for developing those in parallel of that is a part of standards initiatives, absolutely do that. Dr. Susan Weinschenk: Okay. Alright. How do Web analytics tie into patterns, since data should drive design as well? (Laughs) I think I'm trying more into extracting. So would you take your web analytic data that you're getting and you know, revise any of your patterns base somewhere? Dean Barker: Well it depends. Dr. Susan Weinschenk: (Laughs) Dean Barker: Well I don't know may be, so, well I think it's an interesting question, it's a good question, and it's hard to answer. So the one thing that always scares me about web analytics and usability is people tend to look at usage right and you look at something and say "Oh that's getting, that's not getting used therefore it's not good" right? Dr. Susan Weinschenk: Just get away with that right. Dean Barker: Well indeed it may be the exact opposite problem. Well that's not getting used yeah because it's buried in the design but ultimately it's a terribly important part of the user interface right. And so I'm usually a little cautious about that. Dr. Susan Weinschenk: Okay. But I would think though that you could, well may be this should, may be you could use this when you are creating your pattern library just to figure out... Dean Barker: As a starting point, for sure. Dr. Susan Weinschenk: Yeah which patterns or which parts of applications and websites are being used the most, right? Dean Barker: Yeah and that's fair and so in your initial blast through the construction of a patterns catalogue, you'll start with an analysis activity that basically includes identifying candidate patterns, right, and so web analytics could have a great role to play in the identification of candidate patterns. ;Dr. Susan Weinschenk: Okay, okay. What is the best approach for a one person UI team - we get this question for any topic... (Laughter) Dr. Susan Weinschenk: Because I know there are lot of one person UI teams out there. Dean Barker: The lone ranger crisis. Dr. Susan Weinschenk: So just to let you know, lone rangers, we're with you. What is the best approach for a one person UI team in a large and diverse international company (web apps, desktop apps, etc.) to start building a pattern library? Should they even do this or could there be other low-lying fruit that they should be going after instead of doing the patterns? Dean Barker: Well, no maybe it depends on the organization, maybe metrics are more important, maybe patterns are the right way to go, I think the big thing, and we've all been there, most of us have been there, this lone ranger... Dr. Susan Weinschenk: Right, at one or another right. Dean Barker: Because you are the evangelist, you are the voice of reason in these large development organizations, I think the big thing is to think about, how can you get leverage of the function of usability, user experience whatever we call ourselves these days? How can you leverage that function and get more of that being done in the organization? So if you limit it to only one person... Dr. Susan Weinschenk: Yeah. Dean Barker: Or even a small team, things like a patterns library, things like standards and guidelines, things like creating types of evaluation activities that business analysts or developers can do for the purposes of usability audits and inspections, you know those things we've got other bodies doing usability work and using tools that are more effective and more efficient those give you leverage in an organization and so when you are looking back at the question, I'd say the best approach for a one person team would probably be, just start with some generic patterns right, start with something like our Usability Central or start by just introducing some of the patterns libraries that exist out in the public web sphere to larger entities or larger communities within your company that are doing design, right? So if you are just one person, you're not doing all the design work, there are business analysts, programmers, project managers, vice presidents, who knows who is doing design. Plant the seed, have them use some of these tools and possibly start developing your own tools to roll out over time. Dr. Susan Weinschenk: And I think it really does depend on what your strategy is for growing usability in a company, right? Dean Barker: We're getting back to the whole institutionalization concept. Dr. Susan Weinschenk: Yeah, so where you are with institutionalization, what's your strategy going to be and you may at some point fall in there but it might not be one of the hot priorities for you at that time. When you talk about patterns, are you talking about coded templates that developers can take and drop into an application, or visual representations (screenshots) of what developers will need to reproduce in code? Dean Barker: Right, it's a good question. So specifically what we were talking about is the latter, these visual representations and the textual descriptions that accompany them for UI design. Ideally you would have mature enough patterns and initiative patterns library that would map those to their corresponding code components and it might be a one-to-many relationship, it might be a many-to-many relationship or you might even need two levels of code so for example, in Usability Central we have our page level templates and that tool includes static HTML code, which I don't know what the metrics are... Dr. Susan Weinschenk: We have the visual representation first... Dean Barker: Oh yeah the visual representation and then we have the static code Dr. Susan Weinschenk: Right. Dean Barker: Well what most of our clients do is take that static code and incorporate them into their development environment. That's not the code that ultimately gets put into the actual application so you've actually got two levels of code. Dr. Susan Weinschenk: Okay. Based on your experience, who in a typical organization would use the pattern repository? Dean Barker: Primarily two types of people with maybe a third for certain organizations. The primary users of the pattern library are going to be designers and I would first think of, again these full time practitioners - people who specialize in UI designs, user experience design. Secondarily would be sort of part time designers - people who are business analysts and developers, whoever and who as part of their job, are doing live design but that's not what they do fulltime. And then the third would be the product developers and by product developers I mean that from a business sense, not from a coding sense, right? So a product manager, and IT manager, a CIO even ; who basically vetting the business rationale for developing his products and thinking about what functions are we going to have? How big of a design and development effort is this? That kind of things. A patterns repository, because it embodies, it is patterns embody; you know they can embody your content, they can embody your business rules, they can embody your functionality, you can use them to discuss and describe the requirements, right? They have use and utility at the higher level of organization to talk about new product development and product development in general. Dr. Susan Weinschenk: Okay. If I have a library of patterns and I want to make them more usable, at what level of granularity should I focus? Dean Barker: Yeah, so that's an interesting question. So I'm going to look back here and we are going to stay on the same slide. I might repeat my metrics here, I think, alright. So if you look at the granularity, you're talking about the range of scale, roughly a third of the patterns in a pattern catalogue would be at a page level. Dr. Susan Weinschenk: Okay. Dean Barker: Roughly a third would be at the sub-page level, 25%-20% at the widget level and only approximately 6% would be at the page series. Dr. Susan Weinschenk: Okay. (Laughs) ;Dean Barker: So I think it's an interesting question. The easiest that the path of least resistances is probably at the page level but that's roughly a third of the patterns that you should have, right. The greatest re-use, in my opinion, in most development organizations is going to be at the component level, the sub-page level. But some organizations unfortunately are focused on the very low level due to widget level. Dr. Susan Weinschenk: Due to widget level? Dean Barker: So I have a client that I am working with now, who, and this is fine, this is their business need, you know their developers are very focused on the widgets because they are using a new tool kit and they really need to understand how they should use those widgets. Even though the page series is only 6%... Dr. Susan Weinschenk: Yeah? Dean Barker: Think about the importance of a page series in terms of usability, your high level navigation... Dr. Susan Weinschenk: Yeah, I was going to say, I mean right that's it. Dean Barker: That's your task, right. Dr. Susan Weinschenk: So then what are you going to say? You just gave me the final A, B, C, and D. (Laughter) Dean Barker: Well I've been consulting for a long time right? Dr. Susan Weinschenk: So you're saying that the page level and the sub-page level are the most, you know you're probably going to have more of this. The programmers may care more about the widgets... Dean Barker: Right. Dr. Susan Weinschenk: But in terms of the impact on usability, are you saying, focus on the page series? Dean Barker: Well you know, altruistically, I would say only focus on the page series even though that is the smallest part because it does have, I think - this is just an opinion, but I think it has the greatest impact on usability in as much as you're talking about navigation and passport and you can tie that, there's some great work by a fellow named Len Bass, of the Software Engineering Institute on the relationship for example, between usability and software architecture. So you can tie that into the whole architectural level and software development as well. But pragmatically speaking probably the page level is... Dr. Susan Weinschenk: Is what everybody is... Dean Barker: Is going to be the path of least resistance. Dr. Susan Weinschenk: Thinks about, looks at and cares about the most, okay. Dean Barker: And it is very tangible, very concrete as well. Dr. Susan Weinschenk: Okay. How can you evaluate, these are great questions too aren't they, that we're getting? I love getting these questions. How do you evaluate when an idea is worthy of a pattern and when it's more appropriate as just a one-off implementation of some piece of functionality? Are more patterns better, or do you start to risk pattern overload? A new term - pattern overload. Dean Barker: Wait, wait, and let me take that. Dr. Susan Weinschenk: (Laughs) I think he is appropriating the term "pattern overload". Dean Barker: Overload, whoever sent this, probably will earn a nickel every time I use that moving forward. Dr. Susan Weinschenk: (Laughs) Dean Barker: Oh, let's work backwards, so are more patterns better or do you risk pattern overload? Absolutely, you can start to risk pattern overload. The first organization that I worked in that did a major patterns initiative, a great big huge effort. We had I think on order for single application and we had an order for 350 patterns something like that. You know it was simply unwieldy. It was simply too much and it was also too granular. I can't even remember how many widget patterns we had, it was very low level and as a result it didn't get used. So I think that that's definitely a risk. In terms of how to evaluate when an idea is worthy of a pattern, you know again it depends, it's a good question. One thing that you want to look at and it depends on your circumstances but look at the recurrence, when you do this analysis, this is reverse engineering of you know, your whole portfolio of applications where do you see these recurring instances of the thing that is a candidate pattern? You know, because the idea is re-use, right? So I would again, tell people that the value proposition is based on reusability. So if you're doing this incrementally, focus on those things and a small number of those things that are going to get the most traction in terms of being able to reuse, but then the other thing to consider is the notion of the pattern language. You want to complete a set of something; you want something to kind of hang this together Dr. Susan Weinschenk: ; Put together. Dean Barker: So you may really constrain to I don't know, within an application or within a certain level of application, like we do with just the page types. Dr. Susan Weinschenk: This reminds me of the slide here you had of the dishes. Dean Barker: Yeah. Dr. Susan Weinschenk: You want a complete set of dishes so if your pattern library contains only, you know mugs... Dean Barker: Right. Dr. Susan Weinschenk: Then really how many things are you going to be able to piece together? Dean Barker: Well you know, unless you're running a coffee shop, right? Dr. Susan Weinschenk: (Laughs) Dean Barker: No, I mean seriously. Dr. Susan Weinschenk: Yeah but all you have is mugs, right? Dean Barker: Or you might have a small place setting. This is not going to work for everyone so we want we might have a small place setting... Dr. Susan Weinschenk: (Laughs) I want a gravy boat. Dean Barker: Well that's what I'm saying. Like my wife, well I shouldn't say this, she's not watching this. Dr. Susan Weinschenk: Oh I'm going to call her and tell that you are talking about her. Dean Barker: You see you have all these and at one point after 10 years of marriage or something like that we got this turkey plate, for Thanksgiving right? Dr. Susan Weinschenk: (Laughs) Dean Barker: And I swear it was as big as this table, so we didn't need that you know, so whatever you need? Dr. Susan Weinschenk: So don't pick the things you don't need. Dean Barker: So you see, you don't need the gravy boat; you don't need the turkey platter? Dr. Susan Weinschenk: We don't need the turkey platter, okay that's all I have to say. Alright. Typically who or what team owns the pattern library and the responsibility of documentation of the pattern library? And I think we talked about that before a little bit but here's the second part, how much say should the end-users have in the definition and documentation of the patterns? Dean Barker: I mean that so contextual, it depends and it's really hard to say. I think the – I'm going to save this one. Dr. Susan Weinschenk: Yeah, save that one. Dean Barker: You know, I don't know if the end-users should have a say necessarily, what's important is, this is largely an internal view, right? The users of the pattern library are going to be your designers, your developers, and your people who are doing designs done for an internal audience and you have to obviously cater to the needs of the audience. The end result of the product that they create with this thing impacts the end-users right, and so not to say the end-user should have a say in the definition of patterns but there should be, as we discussed this before, a place for you know, providing for greater usability including, hopefully some level of research to consider behind this. Dr. Susan Weinschenk: And you could, can you test here? Patterns? Dean Barker: Sure, I mean when instantiated. Dr. Susan Weinschenk: So you could use your patterns, and I mean I'm just making this up here but could you actually have a testing, usability testing plan in which you take some of the patterns you are creating and use them in an application, maybe not on a real application, just a pretend simulated application so that you can get feedback on some of these patterns that you are creating before they actually go out and use on real applications? Dean Barker: Yeah, you know it's a great idea... Dr. Susan Weinschenk: Did I just invent something? Dean Barker: Yeah I think you did, let's, let's write it up. Dr. Susan Weinschenk: Okay. Dean Barker: Yeah I mean, so if you take these patterns, these candidate patterns you've identified and you take some sort of a system and you do a quick mock up based on that you can do, you can do some raw design and prototype and test it. Dr. Susan Weinschenk: And then revise the pattern if you need to before it even goes out there, right? Okay you know, I think we have time for one more question according to the clock here. Dean Barker: Okay. Dr. Susan Weinschenk: And of course I would pick a complicated question. Dean Barker: (Laughs) You would, wouldn't you? Dr. Susan Weinschenk: It was the next one in line. How do you align the flexible idea of patterns with the more prescribed approach of a specification? For example, if you have a Search box widget which solves a particular problem, how do you ensure that widget is built the same throughout the system? How do you marry flexibility and specifying things through you know to a level detail? Dean Barker: Right, right. Dr. Susan Weinschenk: In your pattern. Dean Barker: Well it's kind of back to the governance issue for one thing, let me take a look at this. So the patterns are not necessarily a prescription... Dr. Susan Weinschenk: Yeah are they really specific? Dean Barker: Well they should be concrete but they are not specific, so if you use the tab card set idea because everybody knows the you know the notion of the set of tab cards right, it's one level of pattern like we talked about early on to say, you should provide for a high level of navigation, that's fairly abstract right, because that's a very high level, that's more of a guideline or a rule, it's another thing to say use the tab card set. Dr. Susan Weinschenk: Okay. Dean Barker: It's another thing to say here is XYZ company.com's tab card set and the rule is, it shall have no more than 8 tabs and that regardless of whatever tab you are designing or information under that, it shall always have the home tab. Or whatever you know, rules are around that right and so there's some concrete level that's still pretty flexible. Dr. Susan Weinschenk: So how far will the pattern of tab cards go? Dean Barker: That would be the pattern, when you instantiate that and design your application, then it is specified and then depending on how formal a UI documentation you are using, you know that, then you would document it in a UI specification. But that's different because you work for it. Dr. Susan Weinschenk: Okay, that's good, okay. We have the pattern library then you have the instantiation of that in the UI specification. Okay. Dean Barker: That's right Dr. Susan Weinschenk: Well we are out of time, we as Click and Clack say, "withered away another hour somehow"... Dean Barker: (Laughs) Dr. Susan Weinschenk: Dean, which you and I can do pretty well, can't we? Let me remind everyone please that you can access the white paper at the website. That this particular webcast is going to be archived, it will be up and available at the HFI website and that's www.humanfactors.com in about 2 to 3 weeks and I also want to invite everyone to come join us at our next webcast which is August 23rd, the topic for that is "Top 10 Usability: How to create a user experience strategy that works" and that's going to be with Jerome Nadel and Jay More and I want to thank you, Dean Dean Barker: Thank you, Susan. Dr. Susan Weinschenk: For joining us today and thank everyone for joining us. We've really enjoyed it. Thank you. |
| © 1996-2012 Human Factors International, Inc. All rights reserved | Privacy Policy | Follow us: |
|
