Recommended
More Related Content
What's hot
What's hot (20)
Similar to Mobile-First Design
Similar to Mobile-First Design (20)
Recently uploaded
Recently uploaded (20)
Mobile-First Design
- 2. Why design for mobile devices? • There are over 3.2 billion mobile web users worldwide • By the end of 2013, there will be more mobile web devices than people. • In the U.S., 25% of mobile web users are mobile-only (they rarely use a desktop to access the web) http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_ paper_c11-520862.html
- 3. The first big question: Native App or Web App?
- 4. Native Apps • Pros – Works offline – Can generate revenue – Access device’s functionality (Camera, compass, etc.) • Cons – Device specific – Depend on users to install updates
- 5. Web Apps • Pros – Cross-device, cross-browser, cross-everything (means less code to maintain)! – Updates in real time – Found through web search engine (more exposure) – Less expensive to produce • Cons – Slower than native apps – Require internet connection to run
- 6. Hybrid Apps? • Written with web technologies that run inside a native app container. • Pros – Works offline – Accesses phone’s features – Written with HTML5 and JS • Cons – Slower than the web browser – Fairly new technology, difficult to debug – Still have to package for different OS
- 7. The next big question: Separate mobile page or Responsive Design?
- 10. But how? • User-Centered Design – A process in which the needs, wants, and limitations of end users of a product are given extensive attention at each stage of the design process. • Responsive/Reactive Design – Designs laid out using percentage widths, scalable images and text, and media queries to ensure that the content always fits the viewport. • Mobile-First Design – Combining these techniques to create a beautiful and effective user experience across multiple devices by designing for the mobile user first.
- 11. Mobile-First Design • This means plan first for: – Tiny screen – Fat fingers – Slow connection – A user in a hurry • By instituting constraints such as: – 3-Click Rule – One-Thumb Rule – Seconds rather than minutes
- 12. But that sounds horrible! • Limitations are GOOD
- 13. But that sounds horrible! • Limitations are GOOD • Prioritize content
- 14. vs. Graceful Degradation vs. Progressive Enhancement
- 15. Conceptualize First Start by figuring out what your user wants.
- 16. Student Portal • Quick reference • Mostly on mobile • Used by middle and high school students
- 17. Data from school district: • Course request • Documents/Waivers • Attendance • Special programs • Test scores • Grades • Contacts • Health records • Discipline • Transcripts • Class Schedule
- 18. Student User Scenarios • “It’s the first day of school and I want to find my classes.” • “I want to find my semester grade for Algebra.” • “I’m tired, how many more times can I miss 1st period before my grade drops?”
- 19. Navigation Schema • Schedule • Grades • Attendance • Student Info – Contacts – Special Programs • Student Records – Discipline – Health – Test Scores – Transcripts
- 20. Designing with Constraints • Size limitations • Speed limitations • User limitations
- 21. Designing with Constraints • Size limitations • Speed limitations • User limitations
- 23. Speed Limitations • Give them everything quickly, 3 clicks or less – Use menus and sub-menus – Label things logically – Give them more than one way to reach a page
- 24. Speed Limitations • Give them everything quickly, 3 clicks or less – Use menus and sub-menus – Label things logically – Give them more than one way to reach a page • Trick them – Tell them their action was successful right away • Don’t download the world
- 25. Size Limitations • Text must readable
- 27. Size Limitations • Text must readable • Buttons must be large enough to press • Condense large text areas
- 28. A Tangent About Text • Users hate reading • Large chunks of text frighten them
- 30. A Tangent About Text • Users hate reading • Large chunks of text frighten them • Total lack of text frightens them too
- 31. Size Limitations • Text must readable • Buttons must be large enough to press • Condense large text areas • Vertical scrolling > horizontal scrolling • Avoid large data tables
- 32. Grids -> Lists
- 35. So far… • Chosen a platform • Prioritized our content • Found solutions for mobile limitations
- 36. Time to Build • Responsive/Reactive Design – Designs laid out using percentages widths, scalable images and text, and media queries to ensure that the content always fits the viewport.
- 37. Live Example
- 38. Live Example
- 39. To Summarize… • The number of mobile web users is growing • Choose the right platform • Figure out what your USER wants • Prioritize content • Embrace mobile limitations • Use progressive enhancement and responsive design • A good product with a terrible user experience is a terrible product.
- 40. The End Katelyn Sessions Usability Crusader www.katelynsessions.com info@katelynsessions.com
- 41. Links-’n-Things • Live Examples – www.katelynsessions.com/example.html – http://zurb.com/playground/playground/responsive- tables/index.html • Resources – http://mobithinking.com/mobile-marketing- tools/latest-mobile-stats – http://www.cisco.com/en/US/solutions/collateral/ns3 41/ns525/ns537/ns705/ns827/white_paper_c11- 520862.html
Editor's Notes
- Hello, and welcome to my talk on Mobile-First Design! Before we get started, let me tell you a little bit about myself.My name is Katelyn Sessions and I came here all the way from Florida. Is anyone else here from Florida?I got my degree from the University of Central Florida in Digital Media, focusing on Web Design. I’ve done a little freelance, a little web marketing, and now I’m working at Educational Data Resources as the Senior Digital Media Specialist.Right now our company is working on taking our old green-screen COBOL software and redesigning it for the web. It is just an enormous project and has really been a learning experience for the whole team, trying to turn something that used to be pages and pages of green text on black screens into user-friendly applications that can be used for anything from quick reference on a mobile device to extensive data entry on an old Windows 98 machine. This project has really presented a lot of challenges, and responsive design techniques have really been our best friend. So, let’s talk about Mobile-First Design.
- Why design for mobile devices?Short answer: because that’s what people are using!Look around the room: There are tablets and smartphones everywhere. But of course, everybody in this room probably has a big souped up desktop at home with I’m sure no less than 2 monitors. But that’s because we’re a bunch of nerds. But let’s think about your neighbor, or your roommate, or your mom. What are they using to browse the web? More and more frequently they’re using a mobile device.Lemme lay some stats on ya:*read slide*These mobile-only users are most likely people who come from lower income families, and older people. These are households where there’s just one old computer in the living room for dad to pay the bills and for the kids to type up school papers. Everything else; social networking, shopping, reading, searching is done on smartphones.So obviously, it’s important to cater to mobile users. But how?
- The first thing we need to decide is whether we want to build a native application or a web-based application or site.A native app being, of course, one that you download and store locally on the phone or device, and a web app being an app that is accessed via the web.As a mobile web developer, obviously my answer is almost always going to be “WEB SITE!” But often, different projects will be better suited to one or the other.Each platform has it’s own strengths and drawbacks.
- Native apps are great because they work offline, can generate revenue by making people purchase it, and can access device features like the camera, compass and gps.So if your project is a social networking site or a game, a native app might be the way to go.But native apps have problems too, the biggest one being that they are device specific. If you decide to create a native app, in order to reach all of your users, you’ll have to create at LEAST a version of your for Android users, one for IOS users, and one for Windows Phone users.
- Web based apps, on the other hand will run on anything because they’re written for the browser, not the device. This means you’ll need fewer developers with less required knowledge and less code to maintain. Web apps update in real time. You don’t have to worry about whether your user is using an old version of your code, because they simply can’t.Web apps can be found through web search engines, which leads to more exposure, and, because they are faster and easier to create, they are less expensive to produce.The obvious drawbacks of using a website are that they are slower than native apps and require an internet connection to run.
- Now, when I was doing my research putting together these slides, I came across a lot of articles about “Hybrid Apps.” I’m sure some of you have heard of or used these, but this is a totally new concept to me. I haven’t worked with these directly, but they sound really cool so I felt it would be a crime to leave them out.Basically, a hybrid app is an application written with web technologies that runs inside a native app container. It seems like it takes the best parts of native and web apps and combines it into a super-app. Because it runs natively, it works offline and has access to the phones native features. The fact that it is written in HTML5 and JS means shorter production times. However, at this point, these apps tend to run more slowly than a web app would run and can be difficult to debug. Also, it still requires that you package differently for various operating systems and sell them through an app store.So this is a technology I’ll definitely be looking into for the future, but for now, IN MOST CASES, the most cost-efficient and time-efficient option is going to be creating a mobile web site.
- So we’re going to crate a mobile site. Again, we run into a big decision!Do we want a separate mobile page or do we want to use responsive design?In other words, do we want to have two versions of our site, one for desktop and one for mobile, and use browser detection to direct our users to the appropriate page, or do we want to use responsive design to create one page that will serve users across multiple platforms?First, let’s talk about what it takes to use a separate mobile page.
- There are several libraries out there, like jQuery mobile and dojoMobile, that are great for easily creating mobile pages. They imitate the look and feel of a native app on a phone and can be really quite slick.However, when you scale them out to full desktop browser size, they tend to be pretty “meh,” so people who use these libraries often need to create separate pages and use browser detection to direct the user to the appropriate page. This means keeping up with two versions of your site.But here’s what I say:
- “Mo’ code, mo’ problems.” Let’s have ONE code source serve EVERY user, no matter what device or browser they are using. If we do it right, we only need to maintain one site, and it will serve everyone, and it will serve them beautifully.
- So how DO we give a great experience to users on all devices?We start by doing some really great user-centered design, then we build that design responsively.Here’s a few important terms to know:*read first* In other words, design for the user. The user is king.*read second* In other words, designs that scale.*read third*
- This means that when you start your project, you plan FIRST for how it is going to look and act on a mobile phone.The first designs you make are going to be for a 3 or 4 inch screen, for fat fingers, on a slow connection, with a user who probably doesn’t want to spend a lot of time on your page.You also want to add to these inherent constraints by instituting constraints such as:Can a user find what they are looking for in 3 clicks or less?Can someone accomplish a task with only one thumb?andCan the task be completed in seconds rather than minutes?
- That’s so many constraints!Many people initially balk at the idea of mobile first design because of the limitations of the mobile platforms.When beginning a project, people tend to picture their future site as this wonderful cornucopia of webby goodness, overflowing with functionality and glorious design, and they don’t want to try to shoehorn their dreams into a tiny mobile browser.But I say that limitations are GOOD! We’re going to run into them sooner or later, so the best way to get through them without ending up with a crummy, second-rate mobile experience, is to face them up front.I’ve had the opportunity to work on a team that is creating a product that is extremely data-heavy. And while it’s often a nightmare, it’s taught me a lot about prioritizing content.
- I’ve often noticed that you back-end guys especially need limitations. A lot of programmers have this mentality of “here’s all these cool things I can do and show, now go figure out how to fit them on the page.” This is wrong, wrong, wrong! We need to think, “here’s all of these cool things the USER wants to do, how are WE going to help them do that?”Designing for mobile first helps us to set limitations that keep us from being sloppy and prevent things from being added just because they are “kinda cool” or “I read about this thing and I want to try it”It’s important to prioritize your content by deciding what elements are most important to your user, so that you can present them with the information and functionality they want without inundating them with extra fluff.But that doesn’t necessarily mean that we can’t have fluff and fun extras, that just means it’s going to take a little extra effort on our part to make sure the fun stuff is presented in a useful way.
- When responsive design for mobile devices was first becoming a trend, the idea was graceful degradation, or starting with a fully functional site on the desktop, then slowly removing content and functionality as it stopped working on smaller and less capable platforms. For example, removing flash content when the page is viewed from an iPhone. This was a great idea, but often times it can leave the mobile experience feeling unfinished or lackluster.Out of this idea, came the idea of progressive enhancement. In this frame of thinking, you start out with the leanest, fastest version of your site with only the most essential content. Once that has been made available on all platforms, then you can start phasing in extra content as the platform allows, enhancing the user experience on a desktop without taking anything away from the mobile user.So instead of going from a good site on a desktop to an OK site on mobile, you’re going from a good site on mobile to a GREAT site on a desktop.A good way to visualize these two ideas is by looking at these two pictures of Susan Lucci and George Clooney. Both started out as extremely attractive people. On one hand, Ms. Lucci has aged fairly gracefully, looking way better at 66 than we can hope to look at 46. On the other hand, HOLY COW LOOK AT GEORGE CLOONY. He just keeps getting better and better looking.The take away message from this is: While your website would be fine as a Susan Lucci, it would be better as a George Clooney.
- So if we’re looking at our potential site from a “progressive enhancement” state of mind, the absolute first thing we need to do is figure out what parts of our site or product are going to be most important for our users.Let’s look at an example of this:
- One of the projects I’m working on currently is creating a student portal. It’s basically a platform for school districts to provide students with their relevant information such as grades, attendance records, health records, schedules and important dates, etc.This is something that will be most often viewed by students on their smart phones in between classes, as just a quick way to reference their school records. Because the screen size is so small, we can’t just print all this data out willy-nilly. We need to prioritize our content and figure out what information is the most important, and present that information first.
- So here’s a list of all the data that the district has on it’s students that could be available through the new student portal.That’s a lot of good, juicy data, but right off the bat I can see things that might not be relevant to an every-day user. The first two, “course request” and “documents and waivers” are things that are only referenced before the school year starts and during their enrollment period. So, right away, I know that those pages can be outside of my navigation schema, and only appear as big flashy links on the homepage on the few days a year in which they are relevant.To decide what should be done with the rest of this data, I begin by creating user scenarios for a student who would be using my application. If I were a student, what information would be most important to me?
- I came up with scenarios like :*read scenarios* and so on and so forth. From these user scenarios, I could surmise that things like “Schedule,” “Attendance,” and “Grades” would be very important to my users, while information such as “Disciplinary Records,” and “Special Programs” while still relevant to the user, were of secondary importance, and I could arrange my navigation to reflect this importance.
- Armed with this information, I decided on a menu of 5 items, the maximum amount that I felt could comfortably fit across a mobile screen. My menu items being, “Schedule, Grades, Attendance, Student Info, and Student Records” with “Student Info” and “Student Records” being pages with sub-menus to data items that I determined were of secondary importance.
- So now that we’ve decided what our user wants and how our basic navigation through the site is going to be structured, we can begin wireframing and designing our layouts. And of course, since this is mobile-first design, we start by addressing our limitations.Our limitations when designing for mobile devices really fall into three broad categories: size limitations, speed limitations, and user limitations.Actually, make that 2 broad categories.
- Users don’t really need their own bullet point, because they are pretty much the root of all problems.Every site works perfectly until a user gets ahold of it.
- Users, man.
- So lets look at limitations imposed by device and connection speeds.For some reason, users in general expect mobile interactions to be faster than a desktop interactions. Something about how tiny and convenient the device is makes them feel like it is going to be faster than that huge machine on the desk with all the processing power and wired internet connection.Obviously, they’re wrong, but that need for speed is still an expectation that we need to meet. A great way to do this is to make sure all of your site’s content is able to be found in no more than 3 clicks, even by a first-time user. You can do this by using very logically labeled menus and sub-menus, or having multiple ways to reach the same page. For example, think of a Human Resources application where the user is trying to find a certain employee’s payroll information. You can help the user by giving them the option to either find the information by searching through a list of employees, then clicking to go to that employee’s payroll data, or by going straight to the payroll page, and entering the employee’s name or ID.
- Another, sneaky way of keeping up with users’ expectations for speed is through straight up lying to them. I just read about this idea recently and I love it. The idea is, when the user does an action that requires something lengthy or time-consuming on your end, give them the “success” message right away, instead of actually waiting for success from the server. If an error happens, just deal with it later. Apparently, Instagram does this. When you submit a photo, it immediately says, “DONE” but it actually takes a few seconds for your image to pop up in the stream. Tricky, right? Using the time spent reading the success message, to distract from the actual load time.Relating to load times, don’t download the world. Don’t load things onto the page until the user actually wants to see it. For example, if you’re using huge javascript libraries, only load them on the pages that you need them. Or, if you’re loading a long list of data, use pagination and only load maybe 10 records at a time. They less you give them, the faster the page is going to load, and you can give them more as they request it.
- Now let’s talk about size limitations.Size limitations are the most obvious limitations of mobile web sites. But once you’ve prioritized your content and decided what needs to be shown where, the actual putting it on the screen in a readable, usable fashion is a piece of cake. There’s just a few things you need to keep in mind.Text must be big enough to read. This one is obvious. Set your text size in ems and percentages instead of straight pixel heights so that on mobile, it will still be large enough to be read, even by old folks with bad eyes. Also, it’s a good idea to avoid low-contrast text.
- *attitude* Dark grey text on a light grey background with some sweet whitish-grey drop shadow looks cool and modern, but on a mobile phone in bright sunlight, it’s pretty much unreadable. Stick to high-contrast combinations; dark text on light background or light text on a dark background. You can see here high-contrast text on top, and low-contrast text on the bottom. Everything is easy enough to read on this huge projector screen, but on a mobile phone, the bottom two will be really hard to make out.
- Buttons must be large enough to press. Another easy one. You gotta plan for clumsy fat-fingered users. A good example of this done poorly is the mobile safari browser. Nothing infuriates me more than when I am surfing the web on my iPhone and try to hit “back” and accidentally close out my browser tab. It makes me want to scream! Sometimes I do scream, and it freaks people out. Moral of the story: make your buttons at least the size as the average person’s fingertip, somewhere between 30 and 50 pixels. If you use small buttons, you’re gonna have a bad time.Condense large text areas. Since mobile screens are so small, even a small paragraph can take up the whole screen, pushing other important content below the fold and out of view of the users. The solution to this problem is as simple as just displaying the first sentence or two of your text, and putting a little “read more” button that the user can click to expand any text they might want to view.Now, in regards to text, there’s a few more things I have to say that aren’t really related to size limitations. They are an important part of user interface design though, so allow me to make a tangent.
- Users, as a rule, hate reading. They just don’t want to do it. This can be a real problem for user interface designers.Users are notorious for failing to read or sometimes even notice instructional text. Pages with large chunks of text tend to look more confusing and users get flustered. Even I, who pride myself on being a smart user, have been guilty of this. I’ve gone to pages trying to file insurance claims, taken one look at those lines and lines of grey text and said, “Forget it, I’ll guess I’m never seeing that money again.”Users just do not read, so as designers, we have to figure out how to tell them what to do without the use of too much text.
- For example, a while back, we were testing an Employee Portal at a nearby county school district. We had spend a lot of time writing and re-writing our instructional text to make it as clear and concise as possible, and were really optimistic about how it was going to be received by the test users. But as soon as we deployed it, we started getting all these complaints and calls about one particular page. *click*They finally sent me down to the district school building to talk to them, and for every user that had a problem, I’d say, “Well did you read the instructions?” And they’d say, “What instructions?” “There, at the top of the page” “Ohhhhhhhhhh”This happened so many times that eventually I just went back to my computer, took out the instructional text, and put a big 1, 2, 3, and 4 next the form fields. Boom. No more problems. That was all it took! People just see a bunch of text and assume that the page is confusing before they even read it. Even educators!And I know, the second version is a little clunky, but pretty isn’t pretty if it doesn’t work.
- Which brings me to my next point: you don’t want to make your site so minimalistic that users can’t find anything. It’s important that you don’t sacrifice usability for beauty. For example, you don’t want to cut down on text by replacing it with dozens of cryptic icons.By all means, replace the word “search” with a magnifying glass, but don’t try replacing “book a flight” with a little airplane or something. Only use icons that have an inherent, instantly recognizable meaning. For example, everybody knows that “save” is represented by that little square thingy…. Just kidding! I’m not THAT young. I know what a floppy disc is. Anyways, you have to find a happy medium between too much text and too little text.Also, in any of these minimalizing scenarios, it’s always a good idea to give the user a place where they can go for more instructions if they need them. In our Employee Portal, for example, we’re putting field level help available through an F1 keypress or a little question mark icon. Most people won’t use this sort of help, so we don’t need to display it all the time, but it’s there just in case it’s needed.
- Now back to size limitations. We’ve established that text needs to be readable, buttons need to be big, and large text areas should be carefully considered and collapsible. The next rule of thumb is that vertical scrolling is almost always preferable to horizontal scrolling. Unless it is to go to a new page or reveal a hidden menu, a horizontal swipe shouldn’t be required to view more data. You can overflow as much content as you want vertically, but keep it within the viewport bounds horizontally. Unfortunately, when your site or application needs to display large amounts of tabular data, this can be impossible. The solution to that is replacing your horrible, ugly tables with beautiful streamlined lists!Allow me to demonstrate.
- Here is a table of some sample data of a students health records. This is way too big to fit across a mobile screen, even in landscape mode. If we were to put it on a mobile page, the user would need to scroll back and forth horizontally to see all of the data.The solution is to pull out the most important data, which in this example would be the type of health screening, the date it was given, and the outcome…
- And display it in a list like so.The rest of the data can be viewed on-click, in a little drop-down expanded area.The dojo dgrid has a plugin that will do this for you, and I think jQuery has a version of this too, but honestly, I’ve had the most luck with just building my own.
- In rare circumstances, sometimes a list just won’t cut it and you need to put your data in a grid, and it’s going to overflow horizontally. When this is the case, an elegant solution is simply locking the key column in place so that when the user scrolls to the right to see the rest of the hidden data, they can still tell what they’re looking at.Sort of like this sad power point illustration I made. If you google around you can find better, live examples. A company called Zurb makes one that I like a lot.
- So, everything I’ve talked about so far, choosing a platform, prioritizing our content and navigation schema, and coming up with solutions for how our data is going to work within the limitations of the mobile browser, are steps that need to be taken BEFORE we ever start building pages.Once you’ve done all these things, you can start wireframing and making design mockups, being sure to carefully consider everything you learned during the planning stages.And now that all the planning is done, we’re ready for the fun part.
- It’s time to build!This is where responsive design comes in. To refresh your memories, *read slide*Since responsive design is something best explained outside the rigid bounds of a powerpoint slide, let’s switch over to a few example pages.
- If you want to follow along on your own device there, I’m going to www.katelynsessions.com, which is my portfolio site. Please excuse my shameless self-promotion.This here, is my super simple example of percentage widths. As you can see, I simply made a container div with 100% width and 100% height, and put four divs inside of it, each with 50% width and height, and floated them all left. No matter how I squish this browser window, they’re going keep the same arrangement.Now, if you’re looking at this on phone, it will look a little different. You’ll see all of the divs have stacked up on top of each other and the center image went up to the top. This is done entirely with CSS media queries. The markup is completely unchanged, I just changed these 4 divs to have 100% width and 20% height when the width of the browser window is less than 765px.Also, take a look at this top image. You can see if I squeeze it in real tight, it scales down, but if I expand the window out, it doesn’t scale up too large. This is done by giving the image a width of 100%, but setting a max-width to some pixel width so that it doesn’t expand and fill up it’s entire container.So this is the whole point of responsive design. Multiple layouts on the same page using the same code source. If we go back to my porfolio site we can see more practical uses of responsive design.
- You can see how I used media queries to split my text into two columns when it’s on a large browser window, and to turn my navigation into a dropdown menu when it’s on a small browser window. Again, none of the markup is changing, just the css.As a recap, let’s look over that Student portal that I was talking about earlier. We started be deciding what our user wants to do, in this case the user most importantly wanted to view their schedule, grades, and attendance. We then presented it in a way that would be easy for them to find and navigate through. For this particular application, we put our navigation in a large menu at the bottom. By easily clicking these huge buttons with one thumb, the user can quickly go through and find any of their important information in just one click.To find secondary information, the user navigates through sub-menus. For example, let’s look for Discipline Records. We go to records, choose “Discipline,” and immediately see a clear list of all of our discipline records, and we can click to reveal details on each infraction. Holy cow, this girl is a trouble maker.Now, once we expand for the desktop, you can see how the page takes on a more typical desktop-style layout. Using media queries, we resized and rearranged as the screen got bigger.And there you have it! Mobile-First Design in action!
- To summarize, mobile first design is important because mobile web users are a rapidly growing population. There are many ways to serve these users and it's important to carefully plan your project to make sure you create an experience that is both efficient and functional. You need to take into account both the pros and cons of native apps, hybrid apps and web apps and choose the platform that serves you and your users best. You need to figure out what your USER wants so that you can prioritize your content accordingly, and display page elements in a logical manner. You need to work within the limitations of the mobile device, and utilize progressive enhancement techniques and responsive design to maintain a uniform quality across all devices. But most of all, you need to create a great user experience. Remember, what it all boils down to is, a good product with a terrible user experience is a terrible product.
- I’m going to post my slides up on my website there, along with some links I found helpful when making this presentation.