Downloaded 19 times
More Related Content
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
Mobile-First Design
- 1.
- 2. Why design formobile 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 bigquestion: 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? ⢠Writtenwith 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 bigquestion: Separate mobile page or Responsive Design?
- 10. But how? ⢠User-CenteredDesign â 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 ⢠Thismeans 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 soundshorrible! ⢠Limitations are GOOD
- 13. But that soundshorrible! ⢠Limitations are GOOD ⢠Prioritize content
- 14. vs. Graceful Degradation vs. ProgressiveEnhancement
- 15. Conceptualize First Start byfiguring out what your user wants.
- 16. Student Portal ⢠Quickreference ⢠Mostly on mobile ⢠Used by middle and high school students
- 17. Data from schooldistrict: ⢠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 ⢠Givethem 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 ⢠Givethem 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 ⢠Textmust readable
- 27. Size Limitations ⢠Textmust readable ⢠Buttons must be large enough to press ⢠Condense large text areas
- 28. A Tangent AboutText ⢠Users hate reading ⢠Large chunks of text frighten them
- 30. A Tangent AboutText ⢠Users hate reading ⢠Large chunks of text frighten them ⢠Total lack of text frightens them too
- 31. Size Limitations ⢠Textmust readable ⢠Buttons must be large enough to press ⢠Condense large text areas ⢠Vertical scrolling > horizontal scrolling ⢠Avoid large data tables
- 32.
- 35. So far⌠⢠Chosena 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.
- 38.
- 39. To Summarize⌠⢠Thenumber 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 UsabilityCrusader 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
- #2Â 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.
- #3Â 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?
- #4Â 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.
- #5Â 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.
- #6Â 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.
- #7Â 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.
- #8Â 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.
- #9Â 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:
- #10Â â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.
- #11Â 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*
- #12Â 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?
- #13Â 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.
- #14Â 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.
- #15Â 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.
- #16Â 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:
- #17Â 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.
- #18Â 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?
- #19Â 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.
- #20Â 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.
- #21Â 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.
- #22Â 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.
- #23Â Users, man.
- #24Â 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.
- #25Â 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.
- #26Â 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.
- #27Â *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.
- #28Â 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.
- #29Â 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.
- #30Â 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.
- #31 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.
- #32Â 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.
- #33 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âŚ
- #34Â 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.
- #35Â 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.
- #36Â 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.
- #37Â 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.
- #38Â 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.
- #39Â 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!
- #40Â 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.
- #41Â Iâm going to post my slides up on my website there, along with some links I found helpful when making this presentation.