Back to Blog

Transcript: Design Patterns

Author

This is the transcript for The Dirt episode: Design Patterns

Tim Wright: Hello everybody. Welcome to episode two of The Dirt. I am your
host Tim Wright, and I’m here with dog lover, avid runner, golf pro Steve
Hickey.

Steve Hickey: Very little of that is true, but I will not confirm which
parts.

Tim: Excellent. So this week we’re going to get wild. We’re going to get
violent. We’re going to get a little tired, I think. So last week we kicked
off the show, and we talked about responsive images, and we got some pretty
good feedback.

Pretty much across the board people thought we were too nice to each other.
That is the first time anyone has called me too nice in my entire life. We
don’t argue enough, Steve.

Steve: I have no idea how that’s true, but okay. We’ll try to kick it up a
notch.

Tim: Off the air, we basically just are at each other’s throats. But we’ll
try and get it on the air because God forbid we don’t entertain, right?

Steve: Yeah.

Tim: So, with that in mind, I’d like to take a moment to talk about Steve’s
mother.

Steve: Dorothy Mantooth is a saint.

Tim: I’m sure she is a saint, but if you could just, real quick. Because I
don’t know Steve’s mother that well. I mean, we hang out, but you know.
Steve, if you could just give me the top ten negative things about your
mother. I’ll pick one. We’ll really drive it home. Then we can move on and
start educating the masses.

Steve: Well, I know I’m not supposed to speak ill of my parents, but my mom
likes some really bad design patterns.

Tim: [laughs] Design patterns? Excellent. Well, that is a beautiful segue
into this week’s topic, and a way to skate talking bad about your mother in
front of both of our listeners.

Steve: Ding.

Tim: So this week we’re going to talk about design patterns and argue a
little bit more, and hopefully educate and expand on our massive listening
audience, and have a good time. So, design patterns. I think Steve would
like to introduce design patterns to the world.

Steve: Alright so design patterns are just common visual ways of creating
and introducing common elements to a user. So, things like navigation tends
to follow some well-established patterns when it’s horizontal or vertical.
The general layout of blog articles tends to follow a fairly common pattern
where you have like a title, author, post, and then some links and sharing
stuff towards the bottom maybe.

Websites in general tend to have a header, a footer, a content area. It’s
just a well-established way of making sure that your users are going to
understand what they’re getting into, and not feel like they’re lost

Tim: Right, and design patterns are not something you want to get confused
with design principles, right? They’re not grid layouts or color theory or
anything. They’re specific, more like interface elements.

Steve: Exactly

Tim: We want to talk about some of the good things about them, some of the
bad things about them. Get into some ones we like and dislike, and then
talk about new patterns that we see emerging. Some of them are really cool,
but you’re going to have to wait for that.

So, some of the good things, I think, about design patterns are they’re all
proven solutions. They are things that people recognize in an interface.
They know how to use it. They’re not going to stumble. They’re going to
immediately jump in, and be able to do it. I think there’s a lot of value
in something like that.

Steve: Yeah, I mean there’s no point in reinventing the wheel when you know
something already works. To a lot of visual designers that might seem sort
of the antithesis of what we do. We’re supposed to be out there making
something new and innovative and interesting every day.

But it’s really not so much limiting you from being able to do that as much
as it is giving you a good framework to start with. As much as we enjoy
creating interesting, new things, it doesn’t always aid usability to create
something completely from scratch.

In reality what we should be doing is the best thing possible for our users
and not the best thing possible for stretching our creative muscles.

Tim: Yeah. I think there’s a difference between innovating for innovation’s
sake and innovating when something is legitimately better, and you want to
kind of diverge from one of these design patterns. There’s some value in
using a common language with your clients and on the team when you talk
about a drop down menu or an accordion.

Maybe clients may not know what an accordion was out of the box, but people
on your team will know what you’re talking about, and you don’t have to
waste all the time discussing it. Especially when you know accordion is
going to be the best. Just an example. I don’t actually much care for
accordion menus.

Steve: It’s very important to have that common language on the team and
also with the client. Like Tim said, the client might not be familiar with
the language to begin with. You can’t really expect them to.

That’s the reason they’ve come to us, but if you have a common language you
already understand and are agreed upon with your team, it’s really easy to
transfer that common language to the client as well.

Tim: Yeah, and I remember a few years ago I was dealing with a client, and,
not to hammer home on accordion menus, but because it’s what I think about
immediately with design patterns. I was trying to explain an expand and
collapse feature on a website that we wanted to put in.

It was an alumni website for University of Southern California. I just
could not explain it. We sat down for an hour trying to make this client
understand what an accordion menu was, but at the end of the day I just
went back, and I built one, and showed it to them, and they’re like, “Oh.
Cool. Do it.”

Steve: That actually brings up an interesting point. Something I’ve been
encountering lately. It’s a bit of a tangent, but there’s only so much you
can show somebody with Photoshop mock-up. Sometimes it really is helpful to
get as quickly as possible into building an actual thing. Because
regardless of whether or not it looks the same as the Photoshop mock-up,
the way it behaves is a lot of the times what sells the client on it.

Tim: Yeah. We’re building a lot more interaction into these designs. Like,
back in the mid nineties or 2000 when we were building really flat designs,
and when they were more print oriented, you could just say, “This is my
website. This is what it’s going to look like. There’s really no behavior
involved.”

I think there’s a lot of value in prototyping at this point. I like it
because I like to code as fast as I can, and so it gets me into that,
and… Oh I had something really good, and I totally lost it during that
sentence.

Steve: That’s okay. If you really like prototyping to get something out
there as fast as possible, a good thing to fall back on is something like a
foundation from ZURB or Bootstrap from Twitter because not only does that
allow you to prototype something really quickly, but they’re two different
libraries built on very common UI patterns, so that you can very easily
build something that’s understandable to most users.

Tim: Yeah. I really like building out some prototypes. So there’s some…

Steve: …Some common complaints about design patterns. The bad stuff would
be that they’re boring or it’s hard to break away from them, and I think
that’s sort of a cop out criticism honestly. They’re a framework for
starting out something. They’re a good way to know what you’re supposed to
include to make something understandable to a user, but they’re only as
limiting as you allow them to be.

Tim: I think they can be difficult to break out of at times. I’m trying to
think of one. We’re going to talk about date pickers later, but I think a
date picker is extremely difficult to break out of. You know, you’re
choosing a date. I think you can break out of it if you keep the goals of
choosing a date in mind, but they’re just so automatic that when you want
to pick a date, just throw in one of those JavaScript heavy calendars and
then paginate it.

I think that that can be very difficult to break out of. There’s a couple
emerging ones that we’re really tying ourselves to, that are going to be
difficult to break out of in the future. I have the outline in front of me
so I’m jumping ahead in my head, and I’m going to try not to do that.

I think there’s some validity in having them be difficult to break out of
because when you’re trying to do something new, and people just don’t get
it, it can take some time. I guess really good ones will break out easily.

Steve: I mean, sure, sometimes they are hard to to break out of, but one of
the things I try to remember is that design is very much about the
constraints and the creativity within those constraints. I try to use
common interface elements and not modify the user interface of the browser
as much as possible.

So we’re talking about things like not building custom scroll bars, not
going too far beyond the common select menus. Those are common UI elements
that anybody who is used to Google Chrome is used to the way Google Chrome
renders them. Anyone who uses Firefox is used to the way Firefox renders
them. So you don’t want play around with those too much.

Some people think that can limit a design or make it boring, but again,
we’re here to aid the user. That’s the number one goal above all. So
sticking to those patterns is very helpful for them.

Tim: Yeah. I think you start to get in trouble when you overwrite default
browser behaviors. Like when we start rewriting the scroll bar like you
mentioned or the back button, or some other default behavior. I don’t
really like overriding select menus even though it’s getting to more and
more common practice to design select menus, but you get into a lot of
trouble when you get into those form elements.

I remember back when Eric Meyer came out with the CSS reset file, he
deliberately had nothing in there for forms. Because forms are just so bad
cross browser, and they’re so tied in to each other. Like the way Safari
treats some forms, and the way Chrome treats them, and the way IE treats
them. All the margins, the padding, the gradients, they’re all very
different, and to zero all that out, it’s just a mess.

Steve: I think that reaches a point, actually, where being able to fall
back on common patterns is helpful for redefining something without going
too far. So I think you have some common elements across form inputs. For
example, there’s a focused state, which is generally indicated with either
a changing in the background color or some sort of gradient appearing or
soft glow or shadow around it.

It might not be the same from browser to browser, but generally users
understand that that change is what indicates a focused input. Or you have
select menus, which, I generally prefer to leave them alone, but you can
redefine them stylistically as long as you stick to a couple things that
are pretty standard about them. They usually appear to be coming out of the
page slightly, as much as I generally hate using gradients.

They’ve got the little arrow symbols on the right hand side that very
clearly indicate to a user, “This is a select menu.” So as long as you
provide the correct degree of contrast from its surroundings, I think even
if you restyle it slightly, keeping in mind the patterns that make it a
select menu will continue to help the user to recognize that it’s a select
menu.

Tim: Yeah, and I think it needs to act as a select menu as well.

Steve: Exactly.

Tim: We use a jQuery plug-in called Chosen a lot when we need to redefine
our select menus, and what it does is it parses through each option and
dumps it into a list item, and then saves the data and maps it to the
actual select. The problems with that is we came into an issue where we
were tabbing through an interface, and in Firefox it wouldn’t activate the
menu, but in Chrome and in IE it would.

So we had to hack something together to get it working correctly. I think
that’s a big deal. You can even make it look completely different, but as
long as it acts the same, or acts somewhere close to the same, I think
you’ll be okay.

You can put in auto complete instead of having a drop down or just
targeting the behavior towards the user, I think. Yeah, I think we’re
starting to break out of some of those, but it’s a long road. It’s
difficult, but it is cool.

Steve: So why don’t we talk about a couple of design patterns that we like?

Tim: Right. We don’t want to be super negative even though we haven’t
disagreed, other than about Steve’s mom. Because I think she’s great, and
Steve doesn’t like her.

Steve: No comment.

Tim: So this morning we actually got into a debate about loading graphics.
I think they’re good. When do I think they’re good? When you need to show
something loading. Obviously. That was a dumb statement. Maybe we’ll edit
that out. Maybe we won’t. We don’t really know how to edit this stuff so
it’ll probably stay in there.

Steve: A loading graphic is really an affordance. It’s telling the user
about the current state of the application so that their expectations are
enforced. It’s certainly much better than leaving them hanging while you’re
performing some sort of complex operation, making them wonder what’s going
on. There’s some interesting patterns and psychology around using loading
graphics.

So, I’ve seen applications before where loading graphics are deliberately
designed to appear for longer on the page than it actually takes to load
something, and what people who develop these applications have found
through user testing is that a user expects the application to be working
and doing something.

If they don’t have that expectation reinforced by a loading graphic
onscreen for a couple seconds, it seems too easy to them to the point where
it might actually impair usability.

Tim: Yeah, that’s really strange. I have encountered that in the past, that
when you do something on a page and it changes, no one notices. Or it’s
suspect, or something, because it happened so quickly, but I think that’s
interesting.

I was actually on a project recently where we had a loading problem, where
the Ajax or the server was too slow, and it would just hang and hang and
hang, and we wanted to put a loading graphic in there or blackout the
screen with a loading graphic, and I’m making hand gestures again, and I
realize that’s not helpful with audio.

We talked about it, and I’m like, “I think we should put a loading graphic
in here,” and some people thought that the perception with a loading
graphic was that your interface was slow. I counter argued with, “True, but
without it, it looks broken.”

Steve: [laughs] That’s a very good point.

Tim: Because you would click that, I’m going to say, “submit” button to
sign in, and it would just sit there. Unless you had the console open, and
you could see that the request was going, you would just sit there and keep
clicking.

Steve: I really hate it when people make arguments like that. It seems
pretty clear to me that slow is better than broken. It sort of raises an
interesting point in how you handle the appearance of a loading bar. You
can actually increase the perception of speed in an application by using an
animation within it.

I think a couple years ago… God, I can’t remember what company it was,
but somebody did a study that they published where they used several
different loading graphics. They had one where it was just that the bar
would move, but the bar was static blue or something like that.

They used a second graphic where there were diagonal lines within the
graphic that were animating to the left in the opposite direction of the
bar, and then they used a version where they were animating to the right in
the direction of movement of the bar.

I think it was the animation that moved to the right increased the
perception of the load speed to the user, even though in fact they were all
moving at the exact same rate. So, when you’re designing an interface, you
might not be able to actually speed it up, but there are little tricks you
can employ to improve the perception of speed in the interface. That aids
the user experience.

Tim: Did you just make that up?

Steve: No. I promise. [laughs]

Tim: So, I’d like to talk about things that we don’t like because I am very
negative by nature. I feel like you should be more negative because we’re
on the same podcast.

Steve: Generally am.

Tim: We disagree on basically everything. Would you agree with that?

Steve: No.

Tim: Excellent. So one thing that I really don’t like in design patterns is
modal windows. Well, I don’t dislike them across the board, but I think
they’re very grossly misused. The reason you would use a modal window is
when you need to block interaction with the page. I can’t think of an
instance when you need to block interaction with a page, but…

Steve: I’ve got one, actually.

Tim: We were just on Hulu, and I think Hulu used to have a great user
experience for their sign in process, and they recently switched over to a
modal. I don’t think you need to block out the page with a sign in box.
There’s no reason. There’s no reason you can’t sign in while you’re
watching a movie or something.

That’s what really bothers me, that people just default to this behavior of
“let’s black out the screen and a modal there.” That’s just a thing that
you do now because it’s a design pattern.

Steve: There’s a couple places where I agree with you. I think I agree with
it in more cases than Tim. Probably a lot more. I can also see his point
about where you wouldn’t use it.

To give you an example of blocking the interaction, I’m designing an
application right now where a user has to configure a whole bunch of
filters to display data in specific ways, and the filtration can get really
complex to the point where you’d spend five, ten minutes configuring
filters to get it exactly the way you want, but you need to be able to
unset those filters really quickly.

So we have a reset button in the interface. I don’t want a user to hit that
reset button, and accidentally undo everything, and we really don’t have
anything established as an undo pattern in there. So instead what we do is
we just put up a modal asking the user if they’re sure they want to go
through that action.

So we temporarily block them, give them an extra click to undo it, but in
the end we save them quite a lot of time and frustration from when they
might accidentally undo something. Another case where I think it’s a good
pattern would be when you really need the user to focus on something.

So, Tim’s example of throwing up a pop for log in which prevents a user
from watching a video, that’s a bad thing. Throwing up a pop because you
want a user to sign up for something, that may be a good way to keep them
focused on their task, especially if they weren’t already doing something
that’s going to be completely blocked by that pop, such as watching a
video.

If they were just reading about your product and now you want to get them
into the flow of signing up and possibly paying for it, isolating that
interaction from the rest of the application can be a good thing to do.

Tim: Yeah. I think that’s the good thing about the stuff that we do here.
We’re not blindly using these design patterns. We’re actually saying when
do we need to use them, when do we not need to use them? Another design
pattern that I really dislike are jQuery carousels or slideshows.

It’s so much that I don’t like them, like that they exist, and people use
these gigantic graphics and they put a slideshow through them, but I really
dislike the implementation of them.

The current way that a lot of people are doing them are just lining up
five, six gigantic images, or slides into the dom when they initially load
the page and then just cycling through them. While that’s super easy to
build, it’s terrible for performance.

Steve: Especially if you’re thinking about it from a mobile first
perspective where you want users on the most limited devices to be able to
get the experience to load as quickly as possible. Loading 12 desktop-sized
images in the background where people can’t see them really impairs that.

Tim: Yeah, trying to load these high resolution graphics for Retina, which
we spoke about last week. Just for a little plug. But you can’t load five
super high res images, and have an efficient, responsive design. So we need
to have our data source somewhere where we can pull these images from where
we can not hamper the user experience from a performance perspective.

Steve: I sort of disagree with them from a visual design perspective. I’ll
admit to having used them before because sometimes they feel like the right
solution, and they’re certainly not always the wrong solution, but I think
frequently they’re used to either combat this false notion that a user
won’t scroll, so you need to display everything above the fold, or they’re
used because the organization in question can’t pick a single message to
stick to so they want to put 3, or 4, or 5, or 8, or 12 up ther right above
the fold where everyone can see them. It’s a really bad way of falling back
because you don’t have a focused message.

Tim: Yeah, I like them from a design standpoint. I don’t think they’re bad.
They’re just very, very poorly implemented. I think we can do a lot better
with that. You really only need to display what you see, and then maybe the
next one, or the previous one, and that’s it.

Steve: Sounds like it’s time to write a plug-in, Tim.

Tim: Yeah, let’s live code that plug-in right now.

Steve: Okay, give me five minutes.

Tim: So there’s some emerging patterns that I think are really interesting
that we wanted to get into as well. Most of them are mobile, I think. Are
they? Yeah, they’re all mobile.

Steve: Yeah, they all seem to have come from mobile and then sort of worked
their way back into the desktop, which is pretty interesting. The first one
we want to talk about is menu icon. So, you’ve probably seen it by now. It
generally is just three horizontal lines stacked right above each other.

That wasn’t really something we saw a lot up until recently, in the last
couple years. I believe Jeremy Keith blogged about this recently as an
emerging pattern. It’s pretty interesting. I think it also sort of goes
hand in hand with the off canvas pattern of using navigation, which is
something Luke Wroblewski talks about.

Tim: I really like that pattern, off canvas.

Steve: Yeah, it’s really good. You don’t lock a user into this idea that
everything needs to be displayed the whole time. You need to scroll to get
to it. Instead you just reveal information when necessary. It became
necessary to convey that there was something that needed to be revealed.

That particular icon is really good at informing the user, “There’s a list
of options that can be exposed.” I’ve seen that in Facebook, Path, a couple
of applications we’ve designed, we’ve fallen back to that pattern. It’s a
pretty good one, pretty solid.

Tim: Yeah. The menu icon itself itself is starting to get on my nerves
because you see it everywhere. I think the first time I saw it was on the
Facebook iPhone app, and then I saw it recently on the E-Trade iPhone app,
and somewhere else. It’s becoming so prevalent. I agree that you know
exactly what it is now.

Steve: Well, I think that’s the point of an icon.

Tim: Yeah, but they’re also designing the menu that slides out exactly the
same too. It’s all…

Steve: You might be able to consider that a pattern.

Tim: …displayed with the indented line underneath it.

Steve: Sure. If you have a different type of menu it certainly would be
better for you to design it in a different way, but sometimes a list of
words is the best way to do something. When I was in design school,
everybody I worked with, we were all designing icons all the time. Because,
designing icons is really fun, but it’s not always the best approach.

There have been studies on users and how they parse icons versus words, and
you parse a word instantly. So if you’ve got a short enough word to
accurately convey what you’re doing and is not going to take up too much
space, it’s almost always better to use that.

Icons are actually a bad secondary option unless they’re so widely
understood that they’re instantly parsed.

Tim: I think this brings up an interesting thing of sometimes on the
desktop, we use an arrow, and we point the arrow one direction. You click
it, interface element slides open, and the arrow flips. I wonder why that
didn’t translate over. Why did the menu icon take precedence instead of
that flipping arrow?

Steve: I think until you’ve clicked the arrow, and actually know what it
does, you might have a perception that it’s sort of like the browser back
and forward buttons. There could be a little bit of user confusion there.

Tim: You’re saying because of the screen size?

Steve: I don’t know. I think it would depend on layout and usage, but I
would shy away from using that immediately because arrows have so many
other connotations. This icon is pretty much reserved for exposing a menu,
which makes it a good option for that.

Tim: I’d like to see someone put it on the right side of the screen.

Steve: What are you mad?

Tim: It’s just always top left, and I’m like, “Come on. Really?”

Steve: This is madness Tim. Madness. I can’t allow you to do something like
that.

Tim: It’s getting to the point where it’s almost as prevalent as pull to
refresh. [laughs]

Steve: I like pull to refresh. It’s a really good example of something that
didn’t exist a few years ago, again. I think Twitter was the first
application we saw using that.

Tim: Yeah.

Steve: Twitter has a long list of tweets which are frequently updated at
this point because so many people are on it, and you don’t want to
automatically load new tweets because that pushes the list down and
prevents the user from continuing to read things. So, when they get back…
I apologize. Mark is telling us that somebody else actually came up with
that pattern. The application Tweetie, and they were acquired by Twitter.

Tim: I remember that.

Steve: So, correction there. If you have a list, you don’t want to auto
update the list because you’re going to change what the user is reading.
You’re going to change the position of it. So you need to give them a clear
way of actually defining that that’s what they want to do, and so when you
go back up to the top of this chronological list, and pull down, creating
empty space for more things at the top, the application responds by filling
that empty space.

It’s a really good interaction method which had been previously unheard of,
and a lot of people wanted to pick up on that. I think Apple Mail uses that
now, and it’s really good. Users are coming to understand that. It’s very
much a mobile thing because in mobile you are actually grabbing the
interface and literally flinging it around, which is not something that is
as prevalent on desktop.

Tim: I have fingerprints all over my screen because I’ve been trying to
pull to refresh. It doesn’t work.

Steve: I’m not surprised. That sort of brings up another point though. The
reason you don’t see it used more often is because I believe Twitter has a
patent on it.

Tim: Yes.

Steve: Which, frankly, is just bullshit to me. I really don’t like that
they were able to patent something like that. It just doesn’t feel patent-
worthy to me. I know that somebody is going to say, “We created this
method. We deserve to be able to preserve our intellectual property, and
whatever.” I don’t think it goes as far as being intellectual property.

It was a designer who recognized a good way to do something, a good way to
visually enforce how something should happen to the user, and they
implemented it. That’s great. Why do right to license just a small bit of
visual fluff, basically, to everyone else who might want to use it?

Tim: You’re asking me?

Steve: Sure.

Tim: We could get into a whole thing about intellectual property.

Steve: Respond.

Tim: I think it’s an invention, basically, but it just happens to be a code
invention versus a light bulb. I don’t have a problem with them patenting
it. I personally would not have patented it because I give away all my
stuff for free, and I live in a shoe box. But it doesn’t bother me that
they did that because it’s just how things happen now.

Steve: Just because everyone else is doing it, doesn’t mean it’s a good
thing to do. I don’t see it as a code invention. There’s, I’m sure, a lot
of ways to code that. I see it as a interaction design method.

Tim: It’s intellectual property.

Steve: Eh…

Tim: I would put it under the same category as a really popular jQuery plug-
in. It’s something somebody built. It just happens that we give some things
away for free, and Twitter is a corporation that needs to make money. I
don’t have a problem with it. It doesn’t keep me up at night.

Steve: Yeah. It doesn’t keep me up at night either. I just wouldn’t do it
myself, that’s all.

Tim: What does keep me up at night is the new pull to refresh that Apple’s
using where they have the dot and it stretches the dot. I stayed up all
night pulling to refresh my email, and nobody emails me. It wasn’t pulling
anything in.

Steve: Tim’s trying to poke the tiger because he knows I hate that.

Tim: I’m baiting Steve.

Steve: It really bothers me, and I’m just really being picky here. There’s
no intellectual reason for it to bother me. There’s nothing logical going
on here. There’s no really good reason it should bother me, but I just
think it looks stupid. I think a visual designer just decided, “Hey. I’ve
got this method to use that’s awesome, but everybody uses an arrow, so I’m
going to do something different.”

Tim: There are a lot of cool, different things. There’s the Fitocracy guys
use a spaceship. We were talking about a monkey, and I know we said I’m
going to get right in there. [laughs] It’s something that evokes emotion. I
think the little stretchy ball evokes emotion in you.

Steve: [laughs] And I think that Tim is full of shit. But we’ll agree to
disagree.

Tim: The mouth on this boy. I think we’re running out of time, and we got
to the bottom of our list, more or less. We didn’t talk about everything,
but I think that’s a good point to break for next week.

Steve: Yeah, sounds good.

Tim: Maybe we’ll get into intellectual property after this, and maybe we’ll
record it. We’ll also put the fistfight up on Youtube.

Steve: [laughs] It’s not going to be long. Don’t worry.

Tim: So, thanks for listening. We’ll get you out of here on a high note.
Next week we’ll try to do better.

Steve: Thanks.

Tim: Thanks, guys.

Author Tim Wright

More posts from this author

How we work Process

Product Hero Talin Wadsworth