Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Web-Native UX Design: Prototyping with HTML, CSS and jQuery

by Jen Matson

2,645 views

New versions of, and extensions to, HTML, CSS and JavaScript are revolutionizing web design, but the tools we UX professionals use to define both structure and behavior are frequently incapable of expressing the full range of web-native interactions. Designing experiences using native web code can help us overcome those limitations and make us better designers. In this presentation you'll learn about creating interactive prototypes that will thrill stakeholders, designers and developers alike.

Video examples from original presentation can be found here: http://jenmatson.com/vid/

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Apple Keynote

Usage Rights

File a copyright complaint

6 Embeds 91

http://lanyrd.com	78
http://paper.li	5
http://zootool.com	3
https://twitter.com	3
http://twitter.com	1
http://www.verious.com	1

Statistics

Likes: 5
Downloads: 39
Comments: 0
Embed Views: 91
Views on SlideShare: 2,554
Total Views: 2,645

Hello. I'm excited to be here to today to talk about some of the ways in which you can start building interactive prototypes in code. I feel strongly that the better we understand the building blocks used to bring our design ideas to life, the more we can use that domain knowledge to create even better designs.\n
The key there is the word "understanding." It's not about learning a specific methodology, or a tool. Methodologies can fail, us and tools can obscure the true nature of what it is we're doing. In a lot of areas of our lives, this is perfectly fine. I don't need to know the details of what's happening to my food, on a molecular level, when I stick in the microwave. But in areas where we do care, and especially where many of us make our living, on the web, failing to understand underlying systems undermines our capacity for learning.\n
But before I get to talking about the web, something I care about, passionately, I'd like to share a little story about me and cars and my total lack of understanding.\n
Cars are something I used to care virtually NOTHING about. As far as I was concerned, you turn the key, move the stick to "D", lift your foot off the brake, put it on the gas pedal, press and go! I never questioned this, or learned anything more than I needed to in order to pass my driver's license test (which, even so, I failed on my first attempt).\n\nSo naturally I learned to drive cars with automatic transmissions only. My parents' cars were automatics, as were the Driver's Ed cars. My first car, which I got at the ripe old age of 21, not long after FINALLY passing my driver's license test, was therefore an automatic. And I really had no interest in making my transition to an auto-driving adult any more complicated than I already thought it was.\n\nThat is, until my boyfriend got a new convertible.\n
Now THIS was a car I wanted to drive, much more so than my '87 Honda Accord hatchback. I was motivated. And, unbelievably, my boyfriend was game to allow me to learn to drive stick using his brand-new, shiny car. And since he wanted to make sure I didn’t end up crashing it, much emphasis was placed on, again, a series of instructions to make it go.\n
And so he gave me a driver's ed-style version of how to make things go, this time involving something called a clutch pedal and a stick with many more labels on it, and a specific order in which I needed to move it. And oh! -- don't forget to look at the tachometer and listen to the engine when you're ready to shift!\n\nNeedless to say, I pretty much sucked at this.\n\nMy mental model for how cars worked was fuzzy, at best, and was definitely not helped by my having only driven cars with automatic transmissions up until that point. The method I learned was a series of rote actions applied in a specific context, knowledge devoid of the understanding I'd need in order to apply it elsewhere.\n
It was only much later, after I stumbled across a picture like this one and learned how transmissions work, that I was able to connect my actions with the specific results, in terms of speed or responsiveness. Or harm -- I also got why I was yelled at for riding the clutch.\n\nWhile I've decided to stick with automatics -- not least in part due to a daily Eastside commute -- I do think that understanding how a car works has helped me become a better driver. However, it's probably a good thing that I'm not responsible for designing cars.\n
But web sites -- those I can do. I'm a Senior User Experience Architect at Ascentium, a web agency in Bellevue. I've been designing experiences for the web since 1994 and have been coding for just as long. You can find me online at jenmatson.com, and on Twitter as nstop.\n\nNow, of course my tech background is immensely helpful for me when creating prototypes for clients. But I've actually had to entirely re-learn how to create web sites at least three times in my career -- first it was tables, then it was no tables and CSS layouts, and now it's HTML5 and CSS3. Add in rich interactivity via JavaScript frameworks like jQuery and technical approaches that enable us to serve up different layouts and content for mobile devices and different screen sizes… that's a lot to learn.\n
Given that, you may be thinking, "Wouldn't it be easier to just learn a prototyping tool like Axure or Balsamiq, or even a WYSIWYG HTML editor? In a word: YES.\n\nBut in the same way that my automatic transmission abstracted away the actual functionality of the car from me, the driver, prototyping tools that hide the inner workings of the code behind our designs and interactions are doing nothing more than creating a convincing simulation of a web site.\n
As designers, our process affects the result. And our tools shape our process and our thinking, often in ways of which we're largely unaware. How do we know that a software program is abstracting functionality, or only showing a limited subset of the actual design possibilities, if we don't already understand the capabilities of the underlying technology? If a software program can't implement a content box that dynamically stretches to fill the screen when I click it, will I even know it's even possible to do that? (And it is. And it's easy!)\n\nSo basically, what I'm saying is, unless you're a vegetarian...\n
You don't want this. You want the real thing.\n
So, let's talk turkey! Which is, in this context, code.\n
These are the three building blocks of the front-end of the web site, the part that that the user sees and interacts directly with, therefore having the largest impact on the user experience. While there is some degree of overlap between the three, in general, each has a distinct role to play.\nHTML provides the structure to the web page using semantic tags meant to define web page content. It's the markup language used for things like page headings, paragraphs, images -- any and all web content. CSS adds styling information to a web page, determining color, size and placement, among other things, for HTML elements on the page. Those HTML elements plus their "class" and "ID" attributes provide hooks for CSS style declarations, ensuring that the right styles are applied to the right parts of the page.\nAnd while you can have a perfectly usable web page -- even an entire web site -- comprised of nothing but HTML and CSS, JavaScript is what brings the magic. It's a programming language that adds the behavior layer to our well-structured and styled pages. While CSS alone can be used for minor behavioral elements (such as mouseovers), JavaScript is what powers an increasing degree of the rich interactions you see online, including many things you previously needed to use proprietary technologies like Flash to do.\n\nAnd help you feel the magic, here's a quick example of what JavaScript can do to ANY web site. Like, say, the Puget Sound SIGCHI site:\n\n
If you're familiar with the videogame Katamari Damacy, what's happening right now should look familiar. And while I'll admit that I added the theme music, it's this JavaScript bookmarklet -- just a little piece of code -- that's taking every single element on this page and rolling it up into a big ball.\n
I hope I won't disappoint you too much by saying that I won't be showing you how to do *that* today. But we will be seeing some animations courtesy of jQuery. That's a JavaScript library. It's open-source, free for anyone to use, and has made it easy to write JavaScript. You can use individual jQuery effects for simple interactions or chain multiple ones together for more complex scenarios.\n\nThe other specifics we'll be going through today are HTML5 and CSS3. These are just the latest versions of -- you guessed it -- HTML and CSS. We'll be focusing on the latest iterations of these for a few reasons:\n
1. They are supported today by modern web browsers. Not all browsers, and not evenly, but for the purposes of prototyping, and not creating production-ready web sites, being able to run your prototype in two or more freely-downloadable, cross-platform browsers is more than sufficient.\n2. They pack in the most features and functionality. What fun is prototyping if you aren't able to demonstrate the widest range of possible interactions? For example, CSS3 enables you to create buttons with gradients, drop-shadows and fancy fonts without you (or your visual designer) ever cracking open a copy of Photoshop. And developers can often use fancy code ninja tricks to get the same, or similar, effects in older browsers, and when they can't you can discuss how to gracefully handle those instances.\n3. You will learn the "right way" to create web pages. There is a lot of bad code out on the web. Some of it is just legacy code, the remnants of old ways of doing things that were born of necessity when browsers often behaved badly. And some of it is being written today, by people holding outdated and strange views, like the notion that every web site needs to look EXACTLY THE SAME in every single browser. We should try to ignore those people, and their code.\nUltimately, the future will become the present. What's new now will be the new standard. Knowing "the old way" of doing something can actually put up a mental roadblock to learning the new way, as I, and anyone else who used to code web pages using nested tables and single-pixel spacer GIFs can attest.\nSo, in order to best see what we can create with a little HTML, CSS and JavaScript, we need an assignment. Something that we might ordinarily wireframe. Here we go...\n
Your Assignment: “You are working with a cupcake bakery to create a new product detail page that best showcases each delectable cupcake.” A product detail page is pretty straightforward. We can start with the structure, using HTML5:\n
\n
This is a fairly traditional wireframe, one that should look pretty familiar. It has a header, a footer, a navigation sidebar and a content area in the middle.\n\nFirst, we want to translate that wireframe into HTML. Eventually, you'll get to where you can skip the wireframing. At least, the wireframing in a software tool part. Sketching is, of course, a tremendously valuable part of the creative process, and it's something I continue to do before I start creating anything new on the computer.\n
Here are the HTML5 tags we'd use for each of these elements in a web page. If you already have some knowledge of HTML, these tags might look kind of funny to you. That's because, up until very recently, you'd actually mark up the page like this:\n
Divs with IDs (or classes) that provided the semantic meaning. In fact, this is still the way most web pages today are built, partly due to backwards-compatibility concerns, and partly just because HTML5 is still so new. But again, we're just building prototypes, not finished web sites, so don't need to worry about that right now.\n
Back to the HTML5-tagged version. You'll see that HTML5 has, as one of its built-in features, semantic tags. We don't need to use IDs or classes to give them meaning. That makes for cleaner, easier-to-read code. But there are two, much bigger benefits:\n\n1. Accessibility. Screen readers can more easily interpret web page content, so that users with visual impairments can have a better experience.\n\n2. Findability. Search engines also love semantic content. In fact, Google recently launched a recipe search feature that relies upon web pages that use semantic markup, like microformats, for recipe content. Web pages that aren't marked up semantically simply won't appear in the Recipe View results.\n
Back to the HTML5-tagged version. You'll see that HTML5 has, as one of its built-in features, semantic tags. We don't need to use IDs or classes to give them meaning. That makes for cleaner, easier-to-read code. But there are two, much bigger benefits:\n\n1. Accessibility. Screen readers can more easily interpret web page content, so that users with visual impairments can have a better experience.\n\n2. Findability. Search engines also love semantic content. In fact, Google recently launched a recipe search feature that relies upon web pages that use semantic markup, like microformats, for recipe content. Web pages that aren't marked up semantically simply won't appear in the Recipe View results.\n
Back to the HTML5-tagged version. You'll see that HTML5 has, as one of its built-in features, semantic tags. We don't need to use IDs or classes to give them meaning. That makes for cleaner, easier-to-read code. But there are two, much bigger benefits:\n\n1. Accessibility. Screen readers can more easily interpret web page content, so that users with visual impairments can have a better experience.\n\n2. Findability. Search engines also love semantic content. In fact, Google recently launched a recipe search feature that relies upon web pages that use semantic markup, like microformats, for recipe content. Web pages that aren't marked up semantically simply won't appear in the Recipe View results.\n
Here's a list of all the new HTML5 tags, with the ones we're using in this wireframe highlighted. You can also nest these tags within each other so that, say, an article has its own sidebar, in addition to the page sidebar.\n\nSo that's some of the structural goodness of HTML5. Another one that can have a big impact on the user experience is new field input types which, again, bring semantic meaning to input fields used in forms. So let's say we wanted to add an email sign-up form where users could get added to the bakery's mailing list.\n
Pretty straightforward, right? A form field where the user enters their email address, with a submit button. But what if the user is viewing this web page in the browser of a smartphone, like an iPhone? (That's right, our web page should look and work well in mobile browsers, too.)\n
The form will still work. However, the soft keyboard that shows up onscreen doesn't know that the form field is for email, so it just shows the default keys. But if we added the new "email" input type to that field…\n\n…with just a tiny bit of extra code, we add meaning to the form field. The phone's browser sees that it's for an email address, and helpfully switches up the keyboard to display an @ symbol and a period so that the user does not have to switch back and forth between the different alpha and numeric keyboards to type in her address.\n
And here is a list of new input types you can use. Email is just one. And while not all browsers will use this additional information in the way that was just demonstrated on a mobile phone, since it's semantic, you're setting yourself up for the accessibility and findability benefits previously mentioned.\n\nThose are just two HTML5 features; there are many more. But those are the two you can and should start using right away when prototyping. At the end of this presentation there will be links to resources with more information about HTML5 if you want to learn more.\n\nNow that we have our structure, let's add a bit of placeholder content. Though, to be fair, content development should be parallel to the UX process, and content plays a huge role in determining the overall design. But that’s a whole other topic...\n
Looking good, if a bit sparse. But before we move on to adding styling, let's take a look at the HTML code behind it all:\n
From top to bottom, first there is a DOCTYPE. This tells the browser to use the document type specification "HTML," which is what's used for HTML5 documents. Older specs include those for HTML4, which preceded HTML5 and XHTML 1.0, which was meant to be the next step in HTML and then kind of never took off.\n\nNext up is the HEAD tag, which indicates the section of the document where we put all of our meta information and resources, prior to the start of the actual page content. You'll see below the head I have a page title, which I've structured in such a way for optimal readability when it appears in search engine results and in my list of bookmarks. Here's where meta tags for things like keywords, content type and description go, but those are strictly optional for our prototype, and -- shh, secret! -- virtually all search engines ignore meta keywords anyway, so don't bother. We'll also be putting references to our CSS and JavaScript files in the HEAD, but we don't need to do that just yet.\n\nFinally, the BODY tag opens our content area, consisting of the content blocks defined in our wireframe, plus our new content, which is likewise marked-up. We're using an unordered list for our sidebar navigation. At the end of the content comes the closing BODY and HTML tags.\n\nOne last thing before we move on to styling:\n
You are doing a great job as an audience so far! Okay no, not that kind of validation. (Though if you created a web page like this on your first try, I would be quite impressed.)\n
Validation, in this context, just means checking the syntax of your code to ensure it is valid markup, free of errors, that follows the rules defined in the spec for your chosen DOCTYPE.\n\nAll you need to do is go to the validator tool provided by the web standards body the W3C at "http://validator.w3.org" and either put in the URL of your web page (if you've uploaded it to a web server) or upload the HTML file itself. And if you've done everything right, you will be blessed with the following message:\n
And if you've done something wrong, you'll get a different kind of message:\n
…but it's one that should have (usually) helpful info on what went wrong and how to fix it. Now, your web page may still look fine in your browser, even if you fail validation. Again, we're not developers here, so that in and of itself is not a problem. BUT… if you run into design problems later on down the road, it will be that much more difficult to troubleshoot if the document is invalid. Make it valid, and that's just one less thing you need to worry about.\n
Now for style.\n
Here’s our wireframe with content again. But first, let me confess -- I've already added a *tiny* bit of styling. I made our content blocks line up using CSS positioning. If I hadn't, the code I showed for our wireframe would have looked like this:\n
Pretty plain, right? But perfectly readable. So I added this CSS to the page -- regular old, CSS, not CSS3, to size and position our elements like so:\n
So, as you can see, CSS is style, but it also affects structure -- at least, visual structure. It is also used to communicate the overall look & feel of a web site. Now, for prototyping, this may be less crucial, especially if your role does not include any visual design duties. But I've observed usability studies where the participants find higher fidelity prototypes to be less distracting, especially when new pages are being blended into an existing web site. So if you can do it, and you have the time, it's worth knowing the small bits of code that can create major visual effects.\n\nAnd because we're not using Photoshop, those effects can be scalable, dynamic and easily reusable, regardless of content or context.\n\nFirst, let's style that cupcake picture.\n
Here I've specified borders for our main content blocks, along with basic padding and margins. I’ve also specified height and width values for specific content blocks. I'm also using CSS positioning, to make the sidebar and the article "float" to the left. Floating takes those elements out of the document flow. Since the header is set to take up 100% of the width of that wrapper, the floats need to line up below that, side by side.\n\nThis is an extremely basic description of floats, and again, you can check out my resources list for more reading on this topic. Thankfully, there are a number of excellent page templates online that already cover a lot of common content layouts.\n
First, we'll round the corners of the photo.\n
Then, we'll add a drop-shadow to the box containing the photo and caption.\n
Finally, we'll style the caption so that its container is slightly opaque, positioned over the cupcake pic.\n
That's a lot of design work with a little bit of code. Here are the CSS3 effects we applied:\n
1. Rounded corners 2. Shadows 3. Opacity\n\nNow's let transform that logo (or lack thereof).\n
We'll pick a fancy font, this case League Gothic, which is free for web use…\n
And then add a slight text stroke.\n
And we're done. CSS3 effects used:\n
We can add in a little bit of interactivity with just CSS3. Say we want to make that cupcake picture just a bit more… playful.\n
That's right, zoom and tilt on mouseover! The effects:\n
And here’s the code for that CSS animation. CSS3 effects used:\n
Now, there are lots of other CSS3 effects. Those are just a handful. If I really wanted to show you ALL the new CSS3 visual effects, I could do that...\n
But your eyes would burn. Comic Sans. Papyrus. Hobo. *shudder* Let's get that back to where it was, maybe with a little additional CSS frosting of its own.\n
Much better. Now for the final pillar in our trio of tech: jQuery.\n
We have a web page, structured and designed. If visual design is not part of your role, your prototype would likely be less styled than this. Or, you'll have grabbed a code-savvy designer to help apply visual style in the prototyping process, if you have time for that.\n\nBut jQuery -- remember, just a JavaScript library for code lightweights like you and me -- can give you the interaction design oomph. Let's take a look at the one obvious interactive component on this page, the email submission form.\n
In order to use jQuery, we first need to add some code to the HEAD of our HTML document. First is the reference to the jQuery file itself, which you can download from jquery.com. Then a reference to our own file with our interactions, global.js. Finally, a bit of code that will initialize our functions on page load so they are ready to go.\n
Now for our interactions: what do we want to happen when the user enters their email address and clicks on the Submit button? Aside from the data itself getting passed to the server and an address getting added to a list somewhere. That's all back-end -- important to document, but not something that we'll actually *see* in a prototype.\n\nLet's start with the simple act of clicking on the form field. Maybe highlight the field?\n
Here is code in our global.js file specifying that, when the field is clicked on, for a special "hilite" class to be applied to the field. We could specify the particular CSS background color and border as part of our jQuery code, but it's much better to keep the style and behavior layers cleanly separated. I also find it's much easier to edit CSS than comb through a bunch of JavaScript when you later decide you want that background color to be blue instead of yellow.\n\nNow, we probably want to let the user know when they've been successfully added to the list.\n
Here we're simply displaying a div with a "success!" message when the button is clicked. In reality, there would be additional JavaScript that would run first, checking to see that the field wasn't blank, the address was formatted correctly (with an @ symbol and a dot-something). And you'd want to create and format the appropriate error messages for those instances, since error states should always be part of your design, too. There would also be additional code needed to dismiss this message after a certain interval, and how to do so: fade out, slide away, and so on.\n\nFinally, what about that sale message?\n
Instead of having it take the user to another page when it's clicked, what if we just expanded it within the page, with a smooth animation that revealed the sale details? And we could close it up again after reading.\n
And this is just a small taste of the kind of interactions you can do. Any element on the page can be manipulated, with animations, hide/show behavior, if/then statements based on user form selections -- you name it. I've done all of those and more in my prototypes… time willing, of course.\n
And skill willing, too. At any point in creating a prototype, you will run up against the limit of your abilities and patience. And if you're me, you'll try the patience of your programmer boyfriend, too, as you ask the umpteenth JavaScript question in the quest to perfect some effect.\n\nWhen that happens (not "if"), you can try a couple of other things:\n
1. Switch to a different medium or tool.\nIf you can't do it with HTML, CSS and JavaScript, that doesn't mean the design or effect you want can't be demonstrated in some other manner. It could be Photoshop, Flash, a WYSIWYG prototyping tool, even paper. Just knowing the capabilities of what can be done natively, even if you can't execute it yourself, will keep you grounded when using another tool.\n2. Ask a developer on your project team for help.\nChances are, you have a tech lead or developer already assigned to your project or team at work. And if you don't, SHAME ON YOUR PROJECT MANAGER. At the very least, that shouldn't be the normal state of affairs. Teams need cross-skill and -idea pollination at every stage of a project, even if you're doing Agile.\nNow, a developer may not have time to help you with your prototype, but I guarantee that he or she will appreciate your having gotten them involved early on. And they may be able to suggest a better way of doing something. Some of the coolest ideas come from your tech folks, as they are (or should be) immersed in all the latest and greatest developments in browsers, languages and techniques.\n\n3. Do what I and every web developer has done since the beginning: find the layout or effect you’re looking for online, view the page source, and copy the elements as a starting point for your own work. (Don’t take anything as-is, of course -- that’s tacky.)\n
So there you have it! A full-fledged web page with structure, style and interaction. You'd almost think we were done, right?\n
Well, for those of us working in an agency environment, in particular, there's one thing that always needs to be added on to wireframes: annotations. And prototypes, while they may be able to reduce the amount of annotating required due to their showing interactions, generally still need some explaining for clients, or anyone else on their end to which they need to show your prototype.\n\nWe could just try to position numbered labels directly on top of our page elements -- and I did try that, initially -- but the alignment is always wonky between browsers, things shift in unexpected ways when you resize the browser, and it's a real pain to manage 20+ unique tags floating over your content. It's especially hard when the tags need to change along with the different page states.\n\nIntroducing… CSS annotations!\n
Each element to be annotated has its own label, dynamically-generated using CSS3. A corresponding numbered list of notes appears in a panel to the right. This page template also has a drop-down control with style-switching JavaScript that turns the annotations on or off, depending on whether you need to focus on the page information or meta information.\n\nHere is the style-switcher in action.\n
I've also added a "sketchy" option to the style switcher, in case you want to start by demoing the basic structure before the high-fidelity design. It styles everything on the page using "sketchy" lines and switches all type to a brush-stroke font.\n\nFinally, while it does take some additional JavaScript know-how, it is possible to change the annotations along with the interactions. Here's an example from my personal web site that shows dynamic annotations in action:\n
So there we have a one-page prototype. If you haven't been discouraged by the amount of work that goes into creating just one page, then next you can hook up multiple pages. You can even use JavaScript to pass variables from page to page, enabling us to create an entire catalog of cupcakes with just a few templates.\n\nIf you want to do that, you can do the visual design piece, *and* you can create clean and valid code, you are probably on your way to becoming the most insanely sought-after designer-slash-developer on the planet. But for most of us, just getting the cross-training itself is a valuable exercise.\n
\n
Here are just a few amazing resources that can help you both learn more about code and give you some tools to create it without having to hand-code everything. That's right, all those crazy shadows and gradients can be done by tweaking sliders on a web page, with a live preview and all. Now that you've sent the hard way, I can show you the easy way. And I’ll be posting a more extensive list of resources on my web site next week, so check jenmatson.com for that soon.\n\nBut whatever you do, please use these tools for good, not evil.\n\n
\n
\n

5 Likes

Iven Lin 3 months ago
a-nasser, Web Developer & Designer 5 months ago
SEIGOSIM at SEIGOSIM 1 year ago
Martin Kopta, Web Site Analyst / User Experience Designer at martinkopta.cz Tags html prototyping annotations jquery 1 year ago
逸飞舒, Software Developer at Home! Tags css3 jquery 1 year ago