The first post this week is an article on webdesignernotebook.com from Yaili, in which she has a little rant on the fact that we, web designers, like to complain about how little recognition our profession has, how everyone likes to think they can make a website, and how clients don’t respect our work. But when it comes to actually doing something that could make us a bit closer to any other “official” profession, we’re bored and dismiss it. It’s so much funnier to complain about IE6!
Yaili has made a point of reading through the W3C specifications for CSSS2.1 and 3, HTML 4.01 and HTML 5. While most of us claim to be familiar with the specifications, how many of us – hand on heart – can honestly say they’ve fully read all of them?
The W3C specs are the closest thing we have to a manual and anyone who works in this field should have read them at least once, we don’t have to know them by heart or be able to quote from them, but we should be familiar with what they contain and be able to use them as a reference like any other professional book, as Yaili says, “After all, those specs lay the foundation of what we work on every day, so we should at least have an overall knowledge of them and of what they address.”
I know personally, this post has acted as an encouragement to print off the specs and read them again on the commute.
Structural Tags in HTML5
If you’ve been inspired by Yaili’s encouragement to read the HTML5 spec’s, then the next post might be of interest to you also. The HTML5 specification has added quite a few interesting and useful tags for structuring your markup and will replace many of our typical DIV entries from our code.
It’s a nice primer for anyone starting to play with HTML5, so give it a read!
Redesigning your own site
And finally we have an article on A List Apart which touches on those times when you have to deal with your most difficult client. Yourself.
Lea Alcantara discusses her experience and thought process of redesigning her personal site. Your personal site has to demonstrate proficiency in the very latest development and trends in the industry while remaining true to the brand which you may have taken years to establish. Cameron Moll’s mantra of “Good designers redesign, great designers realign” features heavily in this thought process.
The article details Lea’s process from start to finish, explaining certain dead ends – like thinking she could jump right into Photoshop and play – to starting with her branding and letting the design evolve from that. She explains how she consulted with some trusted design friends and urged them to provide objective design analysis instead of personal taste.
While the article is focused on a particular site design I think there’s some good tips in here that we can all take away, or at least keep in mind when we decide to work with our most difficult client.
Interview: Dan Rubin making your interface invisible
Ryan: You did a really good talk this afternoon on “making your interface invisible”.
Dan: Thank You
Ryan: What does that mean then? *Laughter*
Dan: Select all…. delete
Ryan: Hiding the interface from your users
Dan: making you interface invisible, doesn’t mean what it sounds like. Thankfully. It’s about the idea of designing for the experience rather than for the visuals or particular features or anything like that. Making those blend so far into the background that users don’t even notice them. That’s what I mean by making the interfaces invisible.
It’s not a new concept if you do a couple of searches on The Google, you will actually find even A-list apart article back in 2000 covering the same kind of stuff. It just hasn’t seemed to sink in and one of the reasons that I’ve kind of thinking lately is that there just aren’t enough designers and developers talking about it. Usually you here about the concept of it an interface disappearing being talked about user experience (UX folk) designers or usability experts and consultants. A lot of the time designers and developer just don’t listen to people who are the same us, those who don’t do exactly what we do. We do listen to them but we just don’t listen in the same way. So if we only hear the same kind of advice from people who aren’t doing what we are doing it’s easier for us to dismiss it. I think it’s more important for people who do the actual design and do the actual development to be talking about it not just thinking about it, but doing it.
Ryan: You mentioned in your talk your talk was targets at not just people who design interfaces but (I can’t remember how you put it), not just designers who push pixels around who do the actual visual design. I’ve always associated interface design with that.
Dan: The thing that I’ve learned from clients (first of all) and then then I realised it applies to all of us. Is that when people hear the word “design” they think that it’s something visual and it’s not. The concept of design is much more basic, its creative problem solving. I mean it can be called a lot of things, but design isn’t just a purely visual task and you can design thing without any visual element. People who design applications aren’t designing the interface to the application; they are designing the interaction, that’s why we have so many. The answer to that the industry has come up with is to come up with a lot of different terms that your experience designer, that your interaction designer. The reason we have to come up with these terms is that people hear design on its own and they think visual. But that’s a visual designer, a graphic designer an interface designer. If were just talking about the process of design, it’s something that everybody is a part of. Whether you’re a developer, an information architect, an interface designer or you’re an amateur, it really doesn’t matter. Your part of the design process. It’s a much bigger concept, that’s why when talking about the idea of designing for the experience, trying to design the experience itself rather than specific parts of it and making sure those parts blend into the background. People just come away having a wonderful experience. That’s why everybody in the team on a given project has to be a member of the design process, otherwise that won’t happen.
Ryan: In your talk you mentioned mimicking physical interfaces and you were kind of talking about trying translate what we do in the real world into your interfaces and those kind of experiences, it’s that right?
Dan: yeh, well there is this concept that we all know, we all talk about look and feel. That’s a common phrase that’s used a lot. But a more specific concept and term that I recently discovered called “affordance” and it’s been around for ages. It’s not new to people who are cognitive psychologists or who are in product design and it really we do the same thing with interface design. Any that’s designed for the screen, especially if it’s designed to be used like applications are. What we are really doing is designing products and software designers again know about this, but for some reason in the web world we’ve got a lot of people who haven’t come up through the traditional lines of education, which includes a lot of that psychology background. Which is fine as long as we are open to learning this stuff and realising we should know it. It all exists and has been around for ages. It’s basically the principal that allows us to interact with objects and interfaces in the real world, outside of the screen, and understanding that we use the size the shape the texture and constancy of things that we interact with in the real world to know how to interact with them before we touch them. And that’s the concept of affordance. That’s what it’s about those aspects of an elements design and construction or what not, that us to know exactly what to do with it and how we can interact with it. There are a lot of great examples of this in Donald Normans book the design of everyday things, which is a product design book essentials but so many of the principals apply to what we do. Not just interface design but again the design of applications and design of interaction. People are using what we build and that’s no different to people using a product that you’ve designed and engineered. We are designing and engineering what ends up being a total experience, it’s not something we can hold in our hands like a physical product but it’s a virtual product.
Ryan: You mentioned that you shouldn’t have to describe your interfaces; they should be intuitive to use.
Dan: I’m very against instructions in interface design.
Ryan: this leads me catching you taking pictures in the men’s toilets earlier.
Dan: Yes, this could be seen as compromising. But …erm… (Ryan has a little giggle fit) I do that all the time.
What I’ve found once is that now that I’ve started looking outward because I didn’t start as a designer in interface design. I started as a graphic designer and doing print. And so I’m always looking at things in the real world for inspiration. For whatever reason in the past year or so I’ve started actually realising how many direct parallels, 1 to 1 parallels there are in the real world with these interfaces that are all around us, they are just 3 dimensional. We just interact with them physically instead of through the intermediary of the mouse or the track-pad and the keyboard. And really they are not that different and so the examples in the restrooms, they are full of them for some reason whether its public restrooms or private stall in a hotel where something clearly hasn’t been designed to be intuitive and thus it needs printed instruction. It doesn’t mean instructions are bad, there are something’s that are so complex that they can’t be simplified beyond a certain point, so they need some sort of instructional text. But far too often we use instructions as an easy out, where we design something that really should be more intuitive, but instead of going back and redesigning it we put a little help icon next to it (or a little bit of help text when someone hovers over it). Or we will just put up a help page, before someone begins a task, and we expect people to read this stuff. The fact is people notice it’s there, they don’t always necessarily read it but they know it’s there and so it’s adding visual clutter that is probably not necessary. If you redesigned that interaction you could get rid of the need for instruction, you make intuitive there is no need for explanation. I think it’s a good marker in the design process that if you find an element of your interfaces requires instructions then you need to redesign it and keep refining and redesigning it. It may not be a refinement it maybe redesigning it from scratch but if you’re always on the lookout for that, like “Is this intuitive? Does this work without someone explaining how it works?” if you keep on doing that you won’t dig yourself into a hole.
Ryan: sorry I’m just chuckling to myself about your toilet reference. Realising that the last person I interview was Elliot J Stocks and I began that interview with “Hi Elliot the last time I saw you were outside a men’s toilet” (fits of laughter) I’m going to be getting myself a reputation.
Dan: it used to be the water cooler and now apparently it’s the restroom.
Ryan: we have to clear up the reason the men’s toilet reference was because you were taking a picture of a diagram of the showing taps and a description.
Dan: the taps that we are all familiar with now that are motion sensitive that don’t have taps anymore to turn them on and off, you just put your hand under it. And that design is not new it’s been around, I’ve never seen one with instructions because it is intuitive. They haven’t broken this one the one in the restroom here just works but even though I knew how to use it, the fact that I saw that descriptive image and text next to it. And its next to every single sink, it was a distraction. So where I would have been able to just go and put my hands under it, for a split second I was distracted by oh what’s this instruction. It made me think that it was something that I didn’t know how to use and that’s where instructions can be bad as well. Maybe you’ve added it in because you mean well, not because you need the instructions but you think that it will help the user by having them there. That that extra bit of information never hurts and that’s actually the wrong thing to do. It has the opposite effect, it adds clutter. If something is intuitive then you’ve spent the time designing it well that people don’t need instructions, by adding them you are actually making it harder to interact with.
Ryan: its weird (repeated… 3 times?) weird occurrence isn’t it. You also mentioned looking at desktop application design and translating that to the web, I found that really interesting. Can you talk about that a little bit?
Dan: yeh, there is a lot we can learn about interface design from the desktop. We can’t do everything on the web and even with things like adobe air and flex we can’t do everything we can do we can when building desktop applications. The thing is that basic interface conventions have been around a lot longer than any of our interface conventions, that we tend to think of being created on the web. The fact is that they haven’t there are very few things that are web specific. One of the things being the silly little Mickey mouse hand icon that we mouse over a link, that’s one of the main examples that I gave. In the desktop we have a much more precise pointer mouse or the default mouse pointer rather (the arrow) whether you’re on a Mac windows or Linux it doesn’t matter. It’s consistent, it has a very specific point, you know at the very tip of that there is one pixel that we use to interact with whatever we are clicking on. It’s much easier to use and target something accurately. Whereas the Mickey Mouse hand is more vague, there isn’t a single point that is clearly defined in the icon and on top of that it only appear once you’ve already began your interaction with something. Developers and designers we tend to work with the web and applications very differently than most users. We’ll mouse over things because we want to see whatever hover effects there are, we appreciate maybe the idea of discoverability in an interface more than the average user. Whereas a regular user (if I can make such a general statement) will look at an interface and without moving their mouse around, they will decide what they want to interact with before they then go and interact with it. So if the only way of knowing something can be clicked on is mousing over it and seeing that hand icon appear it’s not intuitive. Something can easily be missed and so what I suggest is to take a cue from the desktop and only use that hand icon for what it was originally designed and that’s hypertext links. So if you’ve got a link that you’ve underline in your text on a webpage or in a web app, as long it’s an underlined text link in the body of text use it, leave it as the default. Everywhere else if you use that default mouse pointer it’s much more like using a desktop app and it’s much more precise and it forces you to design something that looks like you can interact with it before the mouse ever gets near it.
Ryan: do you think people are just possibly used to the mouse cursor changing to the pointer, and if you took that away, that could possibly have a detrimental effect rather than a positive effect?
Ryan: I think as well how many times have you seen people where they look at a file structure and expect to be able to right click on a folder and have all the options that you normally have. And just because that’s they are familiar with.
Dan: exactly and that’s what I talk about learning from the desktop, that’s the kind of thing that I’m talking about. The desktop has been around and creating these conventions for a lot longer than the web has. Users have been using desktop apps longer than they have the web, maybe you can find younger users who are coming to the web first and barely using desktop apps, it doesn’t mean they don’t use their operating system, they do. They use their web browser too. Those are the first thing they interact with when they start up the computer. Until we get to the point where (and I hope this point doesn’t come) if we had a device that was only a web device and had no other interface than the web then maybe you could make an n argument for it. But I think that would be a bad thing, I would rather see the web and the desktop come together as far as interface conventions and how we work with them in applications. Rather than being web applications, I would rather see them just being applications and when you use them you don’t think about if you’re using something that’s running in a web browser or that’s communicating with a remote server rather than your hard drive. You’re just using an application to do a task, there shouldn’t be a distinction and I don’t think that users have as much of that distinction that we do as developers. We like to think that there is a huge difference between a web app and a desktop app, but the for users it’s likely they don’t think of it in those terms. This is where I complete this task they don’t think that Gmail a web app it’s not a necessarily a web email app it’s their email. It’s their inbox, that’s how they think of it and we have to understand that’s how users perceive what we do. It’s a very very different way to look it.
Ryan: Especially as the barriers are disappearing, things like adobe air for tweet deck and emailing to outlook and mail. And the walls are just fading away.
Dan: Which is a good thing, as those walls fade away we need to as practitioners on the web we need to take as many cues as possible from the desktop and help make that transition more seamless.
Ryan: you mentioned a few resources in your talk, and I bet you can’t remember them…
Dan: Actually I can. I remember…
Jared (I would remember him anyway) – he has uie.com has excellent resources about all sorts of things about usability and that’s ultimately …that’s what this is all about usability. The article I refer to at the end of the talk of Jared’s was one he published the exact same day that I came up with the description for the idea of this talk that I gave today. So it was an odd moment and it’s about the exact same thing that this talk was. Keeping your interface invisible.
Ryan: and your talk previously
Dan: well yes we have been doing work with Jared, we have been very lucky to do a couple of workshops with him. It’s always fun to share the stage with him; it’s even fun to chat with him over dinner because you always learn something. You always come away with a smile on your face even if all you learned was how to laugh and enjoy his magic tricks with the card deck. It’s always enjoyable, so hes a great resource, his site is great resource. And UIE as a company is great resource if you’re looking for information about user testing, usability it’s the place to go. And the article is very recent so look on his site and you will see it on the list of articles a specific lot about invisible interface design and the experience.
I also reference Steve crouges book don’t make me think, which is awesome, excellent, funny, good, and thin. All the things a book should be. Educational, easy to read and short.
Ryan: plane flights worth it isn’t it
Dan: exactly yes, if you don’t have it you will get it and read it and find yourself going back to it again and again and dog ear it and mark it up like crazy and you share it around and sometimes don’t get it back.
And the other book by Donald Norman, the design of everyday things. It’s really a product design book but it’s useful for anyone who deals with designs that are meant to be used by someone else.
Ryan: have you seen thedieline.com product design website.
Dan: no I haven’t
Ryan: it may have been Elliot J Stocks last time he was on I believe it’s just the thedieline.com And it’s looking at product design. They release a series of particular products like an aerosol can or packaging for a toy and look at all different packaging. It’s really interesting.
Dan: I will have to look it up.
Ryan: it’s a really good site
Dan: I eat that stuff up because the more I look outside of the web the more I find that everything that we are doing, that we feel like we are discovering for the first time has already been done. A lot of it has already been done, especially the basic concepts of product design or we talk about information architecture all the time, but we didn’t invent the term. It’s been around for decades and possibly even decades before the web was around. And it comes from architecture and way finding enviromatnetor graphic design, these are concepts that people have been thinking about for a lot longer than we’ve been thinking about them. Possibly for a lot longer than some of us have been alive. I think it puts what we do into perspective; first of all there is a wealth of information and knowledge out there that’s been proven which can help convince us and our clients. If we are going to someone and we are explaining the idea of information architecture to them and we’re not just explaining it as something new in particular for the web. This thing has been around since before the web was even thought of that making it a whole lot easier to gain credibility with clients. It’s not just information architecture it’s so many of these basic principles of interaction, they are all basic psychological principles of human interaction really.
Ryan: what was that word you’ve been using all day again?
Dan: affordance – look it up its good stuff.
Ryan: ok Dan, well thank you very much for taking the time to interview you.
Dan: thanks for letting me ramble on
Ryan: it’s been a pleasure to see you again
Dan: always. Thank you
Much thanks goes to Andy Kinsey for transcribing this interview.
Stories of our failures
Looking from afar, established agencies like yours seem to be almost perfect. However, I’m sure you’ve had to deal with missed deadlines, over-booking, etc. I would like to hear about some of these #fail stories (just to get a “you are not alone” feeling for the rest of us), and also to know how you managed to overcome these common pitfalls.
Hope this question gets a chance of being aired.
Thanks and stay awesome….
Transcript coming soon…
Working on multiple projects
Emil Sundberg writes:
Hi, I’m running a small web agency and I just found your podcast. Great show!
We’re a small team, 4 people, doing web development for clients and use Basecamp/Backpack/Highrise/Campfire (yes we’re 37signals addicts) and I think it would be interesting to hear you talk about how you work with your team in the big picture, not an individual project. How do you plan multiple projects with a limited staff? Who’s deciding what’s most important and what should be done next. Do you use and planning tools or an Excel/Whiteboard?
Transcript coming soon…