Full Transcript

Adam Churchill: Hello everyone. Welcome to another episode of the SpoolCast. Earlier this fall Richard Rutter joined us for a virtual seminar titled, "JQuery for UX Designers." There were lots of good questions and comments. And we decided to have a followup conversation that we could make available as a podcast for you. Richard's seminar spoke to how JQuery facilitates the vital steps of designing and testing interactive wireframes. Specifically, the complex interactions of today's modern websites and web applications.
In the seminar Richard got folks started with JQuery. He offered lots of examples, hints and tricks. And he's graciously offered to come back and tackle some of the questions that we didn't get to address in the seminar. Now, if you didn't get the chance to listen to this particular seminar, you can get access to the recording in UIE's growing User Experience Training Library. There's presently 80 seminars there that have wonderful topic experts just like Richard giving you the tips and techniques that you need to create great design. Hello Richard, welcome back.

Richard Rutter: Thank you. Thanks for inviting me back. Hello.

Adam: Happy to have you. For the folks that couldn't join us for that seminar, could you give us an overview of what you talked about?

Richard: Sure. What I wanted to do in this seminar was really give a very practical introduction to UX designers about what JQuery is and how to get started using it. Right from the very beginning assuming kind of no knowledge. Because, really that was a seminar that I could have done with when I first started using JQuery as a UX designer to help me design. That was the real focus I wanted to get over, that JQuery can be a design tool. If you're using HTML and CSS as your method of defining wireframes. And helping design more rich kind of interactions that most websites have now a days. Most things go a bit beyond just being texts and links and images. There's Ajax and all sorts of stuff that starts to get in the way. Which is pretty difficult to design with static wireframes in things like Viseo.
We find at Clearleft that JQuery is a really good tool for helping us do that. We like to hand code our wireframes. JQuery fits into that nicely. It gives us, as designers, the flexibility to really work out some ideas very, very quickly. Which is the whole sort of idea of JQuery. So in the seminar, yeah, it went from sort of first principles, how to get JQuery working, and then showing some more detailed examples about faking Ajax interactions. Simple show and hide. How to get plugins working so you can straight away get things like popup calendars and light boxes. And all these other tools that you might want to include in your designs. It makes it easier to get that stuff together quickly so you don't have to spend your time and your thinking energy coding. You can spend that vital thinking energy designing instead. Which is really important.
Crucially, actually, I finished off with a bunch of the best documentation and tutorials and places online where you can go and get more information. One of the great things about JQuery is that it's hugely well documented. There's lots and lots of people all over the place have written tutorials and so on. So that in itself makes it a good tool. If getting your hands dirty with code is not too scary for you. For me, I quite like doing that as part of my designing. It helps, I think, to get your hands dirty in the medium for which you're designing. I think that's quite important. That's why I put this together.

Adam: Cool. Well, let's get back to some of those questions. So the folks at Lokion Interactive wonder, why use JQuery and the tools that you offered up versus interactive wireframe tools like iRise, Axure or Balsamiq.

Richard: Mm-hmm. What JQuery does, by its very nature because your coding with it, it gives you, sort of, ultimate flexibility about what you want to do with your designs. Things you want to try out. Effects that you might want to do. Bespoke interactions that you want to map out. Because even the most simplest sounding things, like say, adding a tag. That's actually got a bunch of states in there, which you may or may not want to specify in some detail.
That said, I think the other aspect to those other pieces of software is that like any piece of software, there's a certain amount of time ramping up learning how to use it. Learning how to use it well. And, if you already know how to code a little bit... Now remember, we're not producing production quality code, just enough stuff to get your ideas over, then adding JQuery on top of that tool set you already know, perhaps, is no more onerous, for example, then learning how to use Balsamiq or any of the others.
But obviously, if you already know those pieces of software well, then sticking with that might be to your advantage. Although you are hamstrung to a degree by what the software can do. And there is occasionally a danger that the software can drive the interactions that you specify rather than the other way around.
Plus, to Clearleft, we do have the advantage of being a relatively small company. Which means that the UX designers that we have are surrounded by visual designers and, crucially, the front end developers as well. Who are more than happy to chip in and give us a hand every now and then if we want to, you know, have to do something a little bit tricky. We can just go to them and say, "hey, Andy. Can you help me with this bit." And they'll be more than happy to do so.
So, it works well in our environment now which is very open and collaborative. Like I said, that suits us well. And so JQuery just fits into our work flow nicely.

Adam: Phil asks if there is a particular reason to use the Hover JQuery function rather than the Hover CSS pseudo-class.

Richard: There isn't really. It might depend slightly on what you're doing with that hover state. If that hover state is merely changing the style of something then it's fine to just do CSS instead. Assuming that you haven't got any kind of cross browser issues. I mean, when we put wireframes together, they're designed to show to the clients, obviously. And because they're just wireFrames, we can say to the client, "you'll need the latest version of to just do CSS instead, assuming that you haven't got any kind of cross-browser issues.
When we've got wireframes together, they're designed to show to the clients, obviously, and because they're just wireframes we can say to the client, "You'll need the latest version of Firefox or Chrome or Safari or something other than Internet Explorer 6," essentially. Then you're OK with things like hover state in CSS for something other than just links.
But if you're trying to do something more complicated then you want a JavaScript event to do something with, then that's where you'll be finding jQuery, in this instance, as the thing to go with anyway.

Adam: So Richard, we need to address this. Phil also took a poke at you in Twitter. There was an example in your presentation that talked about Phantom Menace as a favorite film. And there was something about a loss of respect for the presenter. I know you wanted to address that.

Richard: Yes, Phil was under the misapprehension that the fictional user we were showing in our wireframe, a user called Amidactio, was me. Our user Amidactio was down as having Phantom Menace as his favorite film, but also such musicians as Bon Jovi as a favorite musician.
Now, I'm not saying there's anything necessarily wrong with Bon Jovi, although Phantom Menace, that's a different question. So it wasn't me who has Phantom Menace as a favorite film. It was our fictional user. So I need to make that clear. Thanks for giving me the opportunity.

Adam: Absolutely. Understood. We talked a bit about production code and folks were wondering about that transition from these kind of interactive wireframes that you were showing them how to make and how they may or may not end up as production code.
The folks at Expeditors International wanted to follow up on that and they want to know, "How do you avoid having a developer look at a rather sophisticated looking interaction and then just saying, "Well, this works. Why wouldn't we just reuse the code?""

Richard: The flippant answer is, "Hire good developers." That's kind of the only answer in a way. I mean, the code that you as a UX designer put together using JQuery might be suitable for production or it might not. It shouldn't be our job to make that decision. It's just our job to get the design working or tested with users.
If that ends up in production code, as far as I'm concerned that's kind of none of our business in a way, apart from our job as a user experience designer to have some say in the user experience. There is some degree of, I think, responsibility a UX designer might have as wanting the performance to be good, certainly wanting it to be good in terms of actually making the performance good. That goes to people who are experts at that.
So really the answer is that a good front-end developer should be able to make that decision as to whether the code is suitable or not. It is, of course, easier, in some cases, just to nick a function and use that in the production code. But the chances of it really being bulletproof, I would say, unless you're a particularly good coder in the first place, are fairly slim, certainly in my case.

Adam: So there was a question about PolyPage, wondering if, in your experience, UX designers typically find that easier to use than jQuery templates or just vanilla, if else, in JavaScript.

Richard: In our experience yes, people who use PolyPage - and that includes us at Clearleft - find it easier because you can just put a piece of logic in there by simply adding a class. It strikes me as being a lot easier to just add a class to a DIV and have the logic just work for you.
So the typical example that we're talking about there is - the way PolyPage works is if you add a class of "pp_notes" then you get a toggle magically appear at the top of the page called Notes and you can use that to show and hide anything which has that class. Basically, in this case, you're probably showing and hiding notes. Or just simply by adding one class to each DIV or paragraph or whatever you want to call your notes.
So it makes it very easy for us, rather than writing functions, to do that. It's already been done for you.

Adam: OK. Cristobelle asks a question. She wants to know if changes set by a jQuery, if they persist upon page reload.

Richard: The simple answer is no. If jQuery has added or changed the state of something it's shown when previous it was hidden or it has paragraphs or lists or changed the mark up in any way and then you hit reload, it goes back to whatever the state was before. Unless that piece of jQuery is also doing things like setting a cookie for that state at the time, in which case you're introducing state by jQuery. But it doesn't happen automatically, you have to get it to do that.
It leads me onto a point that I wanted to make. In the seminar I was keeping things nice and simple when I was talking about event handlers, adding a click event handlers to, say, a link so that when that link is clicked you can get it to do something other than go to a new page. You can get it to hijack that link and get it to fake a piece of Ajax.
If, for some reason, you're getting jQuery to add in more links automatically, then those new links that you're adding, they won't actually get that click event handler click on its own. The click method just applies to everything that's there already on page load.
However, there's, with jQuery 1.7 - didn't really intend to go in lots of code in this podcast, but it's quite an important thing. So jQuery 1.7 introduces the on method, which is basically the new way of doing all event handlers. So it would be along the lines of instead of click open set brackets, you got on open brackets with click inside saying that's the event I want to use.
It's all there in the documentation on jquery.com and jqapi.com which is an alternative source of the documentation. But it's the on method that you want to look for then. And you can just replace where you had click before. It's just something they introduced fairly recently to deal with that situation where event handlers can be added on the fly rather than just on page load, which was the situation that used to be.

Adam: Well, OK Richard, thanks for circling back with us, certainly appreciate it.

Richard: You're welcome.

Adam: And to our listeners, thanks for joining us. Goodbye for now.