Adapting UI's for Mobile Touch

Forget "Write once, run everywhere". Rethink your mobile development strategy in this exclusive E-Learning Session presented by Infragistics Principal Design Technologist, Ambrose Little.

TRANSCRIPT:

Hello and welcome to this talk on Adapting UIs for Mobile Touch. My name is Ambrose Little. I'm  a principal design technologist here at Infragistics. We make lots of UI design and developer tools as well as some enterprise mobility solutions. Today we'll be talking about this topic [Adapting UI’s for Mobile Touch].

This first picture you're seeing here is the dream. It's the one ring. That's what all developers want. They want to write the ultimate program that will solve all possible cases and usages and contexts and things like that but the reality is even for mobile this can't be the case. The problem with mobile in particular especially if you're starting from a desktop and you want to move to a mobile solution is you often run into this problem. That's from Tommy Boy. That's him saying saying "I'm a fat guy in a little coat." That's the reality is that you're trying to stuff something that just doesn't fit into the mobile if you start from a desktop and just try to squish it in there.

What you have to think about is not only the literal the size of the screens but also the contexts. Now contexts may or may not differ very much in terms of what people actually want to achieve but the contexts in which apps are being used is greatly different for mobile devices than it is for your average desktop or laptop. There are going to be some exceptions but by and large that's a truism.

This is a nice quote from a Senior Research Scientist, Rachel Hinman. "Applying PC context assumptions to mobile experiences all too often results in a marginalized experience for users." That's going to be true if you take this approach of trying to fit your standard desktop design approach into the mobile environment. Today we want to talk about some of the important design considerations. Talking about reducing, in and out, eye on the ball, touchy feely, and Moore's Law. This is what we're going to cover at a higher level in this talk.

First of all reduce, so here you're seeing a screenshot of AT&T's wireless account overview page and then you see something similar here in their wireless app. Now these they were taken before you watch this so they could definitely have changed in the meantime but it introduces you to the concept. You can see on the left side there is a ton of things. You see one, two, three at least, four possibly, levels of navigation all within this one page and then you see tons and tons of links and you see sidebars and you see other stuff. That probably was never really a great idea from a user perspective to take this approach to begin with but it's even more crazy if you start trying to do something similar on the mobile situation. Now you can see on the mobile case it's pretty straightforward and simple. It gives you an overview of where you stand and a few top level tasks or context oriented navigations. It's very flat.

Now in terms of in and out this is important to keep in mind for mobile apps because unlike a lot of desktop contexts you don't have the luxury of assuming that you have their complete attention. You don't have the luxury of assuming they're going to want to spend a lot of time or that they even will spend a lot of time with your interface. You have to think much more about how can you get the people to what they want as quickly as possible and not require them to dig through, like you saw on the last screen, a ton of navigation potentially in order to find what they need. You really have to go back and reexamine your basic assumptions in terms of what you want to enable people to do on mobile.

Now glanceability is actually a specialized version of this which is when you want to be able to get them the information they need at a glance and we'll see a little bit more on that soon. Now, this example you see here is from Foursquare and the reason I call it out here is it's a subtle but it's an effective way to bring to the front what you want people to do. Not so much what you want them to do but what they would want to do with your app. You got to think about there's a pattern, clear entry points. What are the few things that people are definitely going to want to do and even of those what is maybe the most common or the most primary and you make that the most obvious thing. Here the subtle thing is to just make that button stand out a little bit from the task bar and put it in the center so it's easily tappable whether you're holding it with your left or your right hand.

Glanceability is a related thing and that's pretty straightforward in terms of the word itself. You just have to think about what information should I surface that someone could literally just glance at the screen and know what they need to know. That doesn't work obviously for all usage scenarios but there are quite a few especially in the mobile context because you end up being one of many apps on someone's device and you want to be able to get them that quick in and out view of probably the most common thing they're going to want so that they don't even really have to do any extra navigation. They just open it. It's there and they can move on with life. Of course on some platforms you can take it to another level by leveraging the integration with notification centers and overview centers like that. It's definitely something to think about if your target platform supports it.

Here's another great example of glanceability where Microsoft really nailed it in bringing that information up onto the tiles themselves. You can see it's more than just a badge that has a number which could be interpreted in any number of ways. You have a lot more flexibility and it's even grown over the years in terms of what you can do with the live tiles and the fact that they're live so that you can push more than one interesting message or image to people and really not even require them to go into the app to begin with maybe to get the information that they need. It's really a home run that they came up with there.

Flat nav is another interesting concept. You won't see that multilayered navigation in mobile apps usually. If you do maybe it's not so great but the point is that you really want to try to keep it within maybe two layers. If you think of it you have your main navigation or activities at the top level. In this case on the iPhone you have that little bar at the bottom, the up bar. I think on the Android it's at the top but point is that you have that layer and then maybe one more layer within your app to get people to doing something useful. You really don't want to go beyond that or it just gets a lot of friction from a user perspective. You definitely cannot usually take a desktop navigation and just use the built in nav in a mobile platform. You have to really rethink that and try to break it down a little bit more.

Keeping your eye on the ball, this is just from a design perspective. You have to think about the fact that again you're not in the PC context. Someone is not going to be sitting in the office. Maybe they are but you don't know. They could be anywhere and then also the fact that they could be moving. They might be driving down the road even though they're not supposed to be. Think about that. Your app could be involved in an accident so if you don't make it glanceable and you could of who knows maybe you're causing an accident.

It's a totally different environment that you get into when you're thinking about mobile versus your stereotypical desktop design. You really have to start thinking about the user context and what people need and getting them to that as fast as they can because it really can even if your app itself is not life or death because they could be using it anywhere. It could turn into a life or death situation so keep that in mind. It's pretty important.

The other thing about mobility is that you're switching from device to device. Maybe you start out on your phone and then you say hey, I'd rather read this on my tablet and then maybe you're like well, I really need to do a lot of writing or something. You don't really want to sit there and tap on your device and you have the option then you could go to a desktop. The reason that's helpful is if you're thinking about those from a design perspective you can help facilitate those transitions. In fact the upcoming iOS 8 at least they've really come up with a slick story for that in terms of being able to start writing something like an email on your iPhone and then literally you go to your desktop and it recognizes that you're working on that and you can pick up right where you left off. That again is another one of those home runs from a user perspective.

The more that platform vendors and applications take advantage of these capabilities that they're coming up with the smoother it is going to be for everyone in terms of the story of moving from device to device. If you can do that I would highly recommend it. Of course it also depends on your uses, contexts, so if maybe you have a status update on a task that someone's working on and then you want to be able to have them pick up that task right away on their desktop because they need to do some work in a desktop app for instance. That's a great story of someone walking down the hall. They get a notification. It's too much of a pain or whatever to do it from the mobile so if you can figure out a way to easily bring that up like you tap a button. Say work on this on my desktop and then as soon as they log in or open their desktop app you bring that case or whatever it is, that task up for them. That's pretty slick so think about opportunities like that.

This is related to those designing for interruptions. You don't want to assume again, that people are just sitting there focused. You've done it yourself. I'm sure you have. You're sitting there. You could be anywhere. In a coffee shop. Someone walks up to you starts talking while you're working on something. You're at home one of your kids comes up and starts talking to you or maybe your significant other. It's just the way things are now that devices are everywhere and it's only going to keep being more and more like this.

The reason this is important is you've got to think about things like you can't just have sessions time out because of inactivity. That's not real great so you've got to think about ways to get beyond that problem. If someone closes the app on their phone by hitting home or whatever you need to save whatever current state was there and most of the platforms provide ways to do that but you need to take advantage of it and actually do it. Make sure you're doing those things because there's nothing more frustrating to be in the middle of something on your phone or your tablet and it goes to sleep or you switch over to something else and the app doesn't properly handle that and you go back and you lost whatever you were working on. You definitely need to be thinking about that and design for interruptions.

Now, this is a given here for most of us. It's definitely the most obvious that's why I say duh on here. A change that came along with mobile devices and especially phones is a built in GPS and location services. If in any way possible that is relevant for your app by all means be thinking about how you can take advantage of that and use it. Don't forget about this but of course there are lots of other different possible new sensor type things that you can think about which I'll get to some of those here in a minute.

Touchy feely: this is by far another most obvious and crucial difference between desktop and mobile. The most common differences in terms of events I list some of those here. There's going to be more once you get into it. You get usage and you use some usability studies you're going to figure out which ones matter more for your particular context. Just be thinking about the fact that just like you can't bring the navigation in, you can't necessarily just bring in your existing interaction especially hover. That's the most common one that people seem to struggle with so you just have to think about new ways to design your interface so that it doesn't rely on hovering or maybe if you absolutely need that extra on demand interface then you can have that go by pressing and holding or some other means. Maybe there's a swipe and a more or something like that.

Then of course keyboarding, you don't want to be requiring typically a lot of keyboard interactions. If your app involves that and that's core to your domain, fine there's not any way around that. If you can come up with other ways to input information, smarter pickers. If you can do more domain specific pickers to get people to where they have to type as few things as possible that's great. Autocomplete, if they're doing any entry that does require that where you can help them to complete what they're typing. Another huge win so just be thinking about the fact and all the implications of the touch interfaces.

This is definitely something you have to keep in mind. You know as well as I do that your fingers are not as pointy as a mouse cursor. You have to keep that in your head when you're moving to touch interfaces and most mobile devices are touch interfaces of course. Here are some general guidelines. It's always best to actually do testing and make sure that you see where and if people are messing up and hitting things incorrectly but these are pretty good rules of thumb. You can translate these into pixels depending on the mobile device pixel densities. The reason these are in millimeters is because in human factors it's actually more relevant to talk about the actual physical measurements as opposed to pixel measurements because they are so very variable so that's why these are this way.

Now, 9mm square that's rather large quite honestly. If you're used to designing for desktop and you start putting things in the equivalent pixel space of 9mm square it's a big touch target. The thing with that is that it's optimal so when that's really important is when you really don't want people to miss it. That's going to also relate to the particular task that you're asking them to do and how important it is that they don't mess up. Some other suggestions here like 7mm high is okay. You can make it wider if that's the case. That has an interesting proportion that if things are wider then that's good.

Then if you do want to have a smaller visual size like 4.2mm as the minimum then what you can do is actually put invisible buffers. You would put an invisible triangle overlay or something like that. Not triangle. Rectangle overlay around your visual target and that means that when people get near it even if it's smaller visually they'll still be able to touch it and that's perfectly fine. There's some guidelines there in terms of spacing.

Spacing is important especially on not just smaller but when you have things with multiple choices that are next to each other. If you have a menu bar or something like that you need to be thinking not only about the size but also about spacing and you want to do that and make sure that's there. If you go smaller for instance than 9mm square then you might want to start thinking about a little bit more spacing so think about that and as I said before target size is proportional to the consequences of missing. Obviously, you don't want to frustrate people in general so it's good to not make it harder.

If you want an experience of what's not a good way to do it is, is try to load up a standard desktop interface on a device that supports touch like a service tablet or something like that and try to actually use it. You see this today with a lot of the desktop software. I mention Surface specifically because you can still run desktop software easily on it if you've got the non-RT version. Definitely you'll want to test it first of all but these are good rules of thumb.

Now here are some common gestures, the most common gestures. They come from this nifty little resource on Luke Wroblewski's site slash touch, lukew.com/touch. It's out of date but it's still mostly relevant especially for these generic ones like the ones listed here. You're going to want to depending on what your target is consult this specific guidelines for that target platform. If it's web then you can look for some of these more cross platform commonalities or maybe you know that some higher percentage of your users use Android or iOS or whatever in which case you can tilt your interface towards those platforms. Then there are some tools out there that let you do adaptive. Any time you do stuff like that it creates a complexity so you really have to think about if it's worth that trade off.

Often times especially if your app is going to be used across multiple devices, potentially even by the same person, then it's better even across multiple platforms. Let's say they have an iPad but they also have an Android phone. It would actually be better in that case to have a consistent interface for your application across the different platforms than to try to totally customize it for an individual platform but there's a balance there and especially if you're going to be publishing in an app store. You are going to have to follow. Well, I should say if it's a controlled app store like the Windows or iOS you're going to have to follow and get your stuff approved through them so keep that in mind. Just in general I would err toward consistency across the board even to an extent on your actual desktop apps if you end up re-factoring them and making them more touch friendly let's say.

Now another interesting thing that those of us who've been in the industry for a while have gotten spoiled in the last few years is thinking about these things. Obviously, most of us didn't even really have to think about battery for the most part but these other ones we can remember back to the earlier days when these were actually a bigger concern and then they gradually became less and less of a concern thanks to Moore's Law but hey, guess what? It's all back again because now we've got these nice new small devices that have limited all of this stuff. You have to actually start thinking about it again and you have to consider the impact that your apps will have on people's devices because if your app hogs a lot of any of these especially battery you're going to be in trouble with your users. Bandwidth, I would say is probably the next most important because the other two have a little bit more built in management in terms of platform stuff.

Some things to think about in terms of performance. Maybe you're used to doing a lot of talky kind of chatty interfaces between your client and your server if you are doing those kinds of apps or maybe you're used to doing web apps that are still more on the server side where they generate and send down basically a whole page of new content for every interaction. Those are really no no's in the brave new world here. It's more of a given actually if you're doing native that you're not going to have that problem. If you are doing web it's something you definitely need to think about and be thinking about first of all how you can reduce the size of your payloads. That's just the total amount of stuff that you send over the wire and the number of the requests that you do. That's especially important if you're on mobile networks because of the latency that's involved in negotiating the back and forth.

There's a great presentation out there I got from Google. I will provide that in the notes that goes into a lot of detail actually about the specifics around this especially with cellular networks. If you are targeting to optimize for those there's some key things you can do and you really do have to get the initial response down to a really rather small size. I can't remember off the top of my head. I think it's 14 kilobytes and that's total. You don't want to have external requests for scripts and other things like that if possible. If you want that really more immediate responsiveness on the initial load for a website then you have to think about stuff like that and then you can piecemeal load in other stuff later. There's all kind of techniques for that and there's a nifty tool called Google Page Speed that you can use to analyze the different factors that can affect this performance.

Thankfully for the web and of course for the native platforms there are more tools these days than there used to be to help you debug problems along these lines. Chrome dev tools, Firefox, IE, they all tend to have pretty decent support for figuring out where your problems are whether it's network requests, whether it's size. Make sure you have things zip enabled. Use zip on your server as a general rule. Minimizing your scripts. Making sure you're not sending out stuff that you don't need. All that stuff is important far more so than it is when you have someone sitting on a LAN in an office. You got to be thinking about this stuff.

The interesting note there at the end, the Dark Themes. Windows Phone 7 came out of the box with that sort of thing. The point there is that mobile devices actually, depends on the technology, but some of them use more energy if they are using lighter colors. The Dark Themes were actually designed specifically to conserve some of the battery usage and it's an interesting consideration. I wouldn't put that at the top of my optimization list but it's something to think about.

Here we're talking about the pixel densities versus the physical measurements for touch screens. Obviously, there's more to it than just touch. You've got to think about images too. That was a big thing when the iPhone came out with their retina display for the first time and you get these high density. Since then more and more devices have high density displays. You need to be thinking about this aspect both in terms of the touch but also images if you have bitmaps. Anything that's not a vector that will not be scaled proportionally you'll want to consider substituting images and stuff. I think I have a little bit more about that later on.

I highly recommend that you search online and find these lists of devices and their relative pixels per inch, but don't get obsessed with specific screen sizes especially if you're doing any web design. Again, I'll touch on that a little bit later. Here just to further illustrate the point the problem with pixels. You can see here that you've got the effects I guess you could say of scaling based on pixel density and it's something to keep in mind. Think about if you do have specific devices and what those densities are. On the web it's a little bit more interesting shall we say.

Orientation that's one of the key factors that changes especially for the native environments but obviously none of that applies to the web but web has again, more potential issues because of the proliferation of screens that it can be run on. If you're dealing with a native platform, I guess now that I think about it it's true more so maybe for Androids then it is for iOS in terms of the potential for varying screen layout issues even on native but anyways so orientation is one thing to keep in mind. It can change somethings pretty significantly.

The example here you see is showing the impact of the onscreen keyboard on this particular device and you can see it takes up a whole lot more. That actually is something that you tend not to think about if you're not used to designing for mobile. That these touch screen keyboards will take over a lot and they can get a little bit wonky if you don't take that into account with stuff being off the screen. I'm sure you've probably experienced that a few times in your use of mobile apps where you're typing and it's actually under the keyboard or something and then you're trying to move the screen and then it wants to recenter it. It gets a little annoying so you definitely want to take that aspect into consideration as well. It's just the general change in dimensions.

Just another example here. This particular sample app that we did at Infragistics we actually did a different view. This is a little less common I would say but it's not unheard of and it's certainly not a no no in my book but you can see that there's a different layout here. You can even do a different chart if you wanted to. In our case we actually hid the top part of it and spread out the chart so that you can see more. You can do interesting variations on that theme as well.

Now I mentioned earlier that location was the obvious one that everyone thinks about. Here's some of the other device capabilities that you might want to hook into. It depends on your targets and things like that and what you can get access to based on platform that it's running on. I do want to provide a little bit of a caveat, a warning here. Don't get crazy. The interesting thing about Android I'll mention is they have such openness that people can come up with all sorts of interesting variations on theme like tilt to scroll and things like that and eye tracking. It's just a little wonky at least in my experience in trying to use those and the other people I've talked to. It's you think it's going to be cool but then it doesn't really work so I would not go into it thinking that you're going to do something like that unless that’s core or critical. I would definitely deprioritize doing stuff like that.

Now mapping in general is a pretty interesting thing to take advantage of and it really depends. You have to think about if it adds value to your particular situation and your contacts and your domain. A lot of people think it's hard. There's plenty of tools like Infragistics tools out there that have really rich mapping capabilities and they make it relatively easy for you to add rich mapping information into your apps so you can do things like overlay to charts and other information on top of maps in addition to the bare bones out of the box stuff that you can get with a Google mapping widget. Be thinking about those sorts of things.

Proximity, ambient light, these tend to be more specialized. I think of this list probably the most commonly used one would be the push notifications. Another common one that is merged in with some of the other ones is the ability to take audio and/or video or picture I guess would be the more common case. If your app can take advantage of that and benefit from that it's pretty slick to be able to do that and you all probably have the experience of for instance depositing a check even with your mobile phone. I think that's one of the coolest and rather straightforward-est advances that the mobile banking has made in recent years. I certainly use it a lot and find it useful so if you're doing an expense app or something like that it's definitely an obvious win to be able to leverage that.

Maybe your platform offers voice to text so that's again another way to make people safer when they're using their mobile devices but also maybe just to help them out. For instance my mom, she has not the best eyesight so for her using these small devices she actually uses the dictation stuff quite a lot. More than most people I expect and it's a very useful thing to have. If you can take advantage of that maybe your platform has it built in but if you can work that in that can be definitely useful.

Now push notifications again they can be very useful. They can also be very annoying so you have to make sure you're only using them for useful information. Don't use it just because you can. If you're using a platform that supports it you can definitely push stuff to the tile or icon I guess would be the word. To do a badge say on iOS or you can do the live tile on Windows. Things like that. Android of course also has the I forget what they call them off the top of my head but the widgets I think they might be called but you can do and actually embed into people's screens. You can do all kinds of interesting stuff there in terms of sending information.

There's a lot we covered so far but the question might be boiling in your head. Well, yeah it sounds like basically I have to start over and to an extent you need to think about that because of the whole concept of mobile first in terms of reexamining what's actually really important versus what's ancillary and how you surface that in your navigation and things like that. Here's some obvious things that you can adapt without a lot of rethinking. The core activities if you have those primary activities and you do identify them there's probably a chance at least that you can reuse some of that. If nothing else you can reuse your logic, your services, your models. Maybe if it depends on the state of your desktop UI but maybe if it's a web UI and it's contained enough you could try to get it to reflow in a responsive manner. That's really going to depend on your particular circumstances because it can get hairy really quickly if you try to do that.

Now controls that's for us. We do a lot of controls and a lot of them actually do work fairly well because they don't really require the desktop size. We are just a piece of your UI. It's not true for all of them. Our big fancy pants grids that we do that have so much amazing functionality and people find really useful. Those are a little bit more of a challenge and believe me we've worked on that problem to adapt those to mobile devices. You end up having to define for instance different column layouts depending on widths and things like that so that you can have a responsive adaptive interface using something like a data bound grid like we have. It depends but think about that. Maybe there are some controls that we'll just pour it over real nice and we can reuse those.

I just wanted to drill in a little bit more on the things to think about as you're adapting. First and most obvious is form factor adaptation. I've already probably beat this drum a little bit but reduce is key. Reduce, reduce, reduce. Eliminate stuff. Be really really tough about that. You need to work with the people who define your requirements essentially and help them to understand this stuff. It's definitely not a matter of just squishing it in. You have to reduce and reexamine what actually is really important and at least start from there. You can think about maybe later we'll add in other stuff or maybe you can split things into different apps.

That's another interesting approach for these devices especially say on Windows platform where you can use your live tiles. If you had a tile for different concerns in your enterprise apps that would launch into those areas you can actually segment the functionality across the apps instead of trying to do that all in one app with lots of menus and things like that. The benefit there would be that you could also create a dashboard actually on the actual start menu so you can see that high level information and let people drill in from there. It's an interesting pattern to think about and it's a hub and spoke pattern.

Then of course there's the fluidity aspect. I'll talk a little bit more about that next and touch obviously. Events especially the hover. There's other things you can do there. You can layout if that information is important and again this is back to reduce. If you've got something that only shows on hover is it really that important. You're going to have to ask yourself that. If it is that important maybe it shouldn't be in hover. Maybe you should re-layout that part of your UI so that you can supply that information or maybe it can be under a little plus so you can expand and show extra information. That's a key thing if you are relying on hover. That's a key way to adapt is to maybe have a more or a plus or an 'i'. I as in the letter 'i' for info so that you prompt people because they can't hover to know that there's possibly more information to get.

There's the drill in on iOS. Often they'll have that little right arrow to get more information about things in a list. You have to think about those and do those as appropriate and of course the touch target. Don't forget you need to optimize especially for web because it does on every loading I guess you might say of the app. It will send down the UI potentially every page depending on how you designed it which you need to rethink as I mentioned before.

Then the data itself sometimes it's easy to think. I'll just load in everything that they could possibly want and select from that. Again, you have to think about the balance between the number of requests versus the amount of stuff in one request and maybe your initial load is just the minimum to show that first bit of information. Then the next one or maybe in the background you can go ahead and download more information but also don't forget that people pay for bandwidth still in most parts of the world. You don't want to be just sucking up unnecessary bandwidth especially over cellular and even in some areas it's metered on land line so keep that in mind.

Responsive web design, so anyone who's familiar with trends in the last several years will have heard this term in the web areas. It sounds really fancy but it's really just a straightforward concept and it's an extension of the fluid layout pattern. It uses a particular technique. In fact it's less really about design so much because the design pattern is just fluid layout. You adapt based on the container that you're in but the specific sauce that's in responsive web design is this concept of using CSS media queries to adapt your layout and your styling and things like that. Basically anything that you can do with CSS this technique would work with that.

Most queries for these media queries the most common ones are these breakpoints and don't blame me. I did not choose that term. It's overloaded for those who are developers but it's a sensical term you might say because you're just saying once it gets to this variable, whatever that variable is, you have a new set of styles that you're going to apply. Mostly that's based on widths. By far that's the number one thing that people create breakpoints for but another fairly common one is pixel density.

Now there's a new picture element. In fact I think I just read today that the WHAT Working Group is adding picture to their official specifications. What that does among other things is enable you to supply different sources based on these common breakpoints like pixel density so you can load in a higher pixel density image for those devices that have those. Of course that means more bandwidth, etcetera but you want that quality probably instead of having a blurry image.

Whereas on the devices that don't have that you can have the lower pixel density and then also there's the I'm on a desktop which is probably connected to a decent pipe in terms of the bandwidth. Maybe it's okay to have a nice huge beautiful full bleed image on your page but then on the phone if you try to just switch using conventional CSS media queries it will still load that big image even if you specify some other image in that breakpoint. That's the problem that the picture element is being designed to solve is so that you don't have this issue of your still loading in the huge image even though you're not even using it on particular devices.

You don't have to worry about using sprites to select a smaller part of a larger image and things like that if that was something you were doing. Although sprites by far are still a good technique to use in terms of minimizing the number of requests. I don't want to give the wrong impression there. I'm just talking about big images that you might have previously just selected some to show like through cropping as opposed to using smaller images or something like that.

Now I think I touched on this before but it's early on in the trends here where responsive web design is very common and even today because it's easy to think about quite honestly you'll see breakpoints like tablet and phone. In some ways those are okay because those are definitely the most common devices or classes if you will but the challenge there is that if you're thinking about specific pixels like what does that actually map to, it's pretty fluid. Then you also have portrait layout versus landscape layout.

If you're dealing with those ways of thinking about it and creating your breakpoints based on that you're still going to have to pick and think about okay, is this for an iPad. You'll just go crazy especially on Android when you start looking at the ridiculous number of sizes and stuff that they have. It just doesn't work if you're really trying to address that particular problem.

The solution is to find your natural breakpoints in the content. Now that may not sound sensical initially but let me try to explain it with my hand waving since I can't draw it really. Basically the idea is that your content itself, let's say you can start with either a mobile or a tablet or whatever. Whatever you think your primary target is. I'm not super you have to always start from phone kind of thing because maybe phone isn't even something you want people or expect them to use it on and maybe you have no intention of supporting that. In my opinion that's fine if that's your environment. If you're totally open on the web that's not a safe assumption but if you're doing an enterprise app and you know that everyone who is going to be hitting this is using a company issued iPad or Android or something like that. It's totally fine in my opinion to go ahead say yeah, we're going to start with that particular form factor or class of device and then you can optionally add scaling up or down from there.

Now, I mention that because whatever you start with you are going to get to a point like let's say you're looking in your web browser and you start re-sizing it. Either you're making it smaller or you're making it bigger. You're going to start seeing once it gets to a certain point it freaks out and it doesn't look right and it doesn't look broken. That's your natural breakpoint. That's where you go okay, obviously right here we need to change the layout or we need to change the font size or use a different image size or whatever. That's where this approach really is targeted at.

You need to look for those and just define them based on that. Don't even worry about the fact that it may be on a tablet in portrait mode versus landscape or it may be on desktop that has been shrunk down because they only wanted to use half their screen. Who knows. The point is that if you're doing it based on content you're going to hit all the important cases without having to worry about the fact that it may be viewed on 300 different actual devices. It's a much better way to do it and I highly recommend it especially if you don't mandate essentially what devices your content is viewed on.

Now, the last point here and I don't know if you can see it very well in the background but that one ring has started to bleed through again here. That's because that's what responsive web design is to some extent. It's back to this idea of hey, I just want to create it once and have it magically run everywhere. Unfortunately as we said at the beginning and as you probably well know that is a pipe dream. It's not going to work even with responsive web design.

The place that this particular technique was born out of was more out of those people who mostly do content oriented websites where you're mostly dealing with text and images and just breaking down how those flow a little differently. Probably the most complex thing that they have to deal with is changing the menu structure and then of course you get into things like the thing like on Facebook for instance where they came up with where it slides over and you tap the hamburger icon and the little three lines. That's great and fine but that level of complexity it's manageable. It's doable with responsive web design. Even that can get a little hairy depending on the number of page templates you have and the different content and images and things like that but if you have a more complex line of business application that has more complex controls it starts getting hairy pretty quick. You really have to do an analysis of is this actually worth it. Are the layouts and the interactions similar enough that you can take an approach like this where you have one app that literally adapts?

There are people out there and some of them I very much respect because they've done a lot of work in the web world. They're huge advocates of responsive web design. It is the one ring. It solves all things and of course then they get into it and they'll talk about all the problems with it and of course there are ways to address those problems but ultimately you're just shifting where your complexity is. You can't get away from the complexity. The fact that it exists so it does boil down to the way I look at and I've written a couple blog posts about it which I will try to supply in the notes.

You can start thinking about it in terms of classes especially from a prototyping point of view and when you're trying to figure out the right thing. You can start from that idea of we're just going to figure out what works best with someone who's using a tablet in whatever your target context are. You know they're going to be used outside of those but at least you have a goal and a target and you create the optimal design for that and then if you do want to target phone you do the same thing. You create an optimized version for a phone interface and then maybe who knows Google apps, whatever. Whatever your targets are. Whatever classes of devices that you're thinking about. Maybe it's a TV. Probably at some point you're going to have desktop/laptop on there.

You do what makes the most sense from a user interaction point of view and then after you've done that work from a design perspective then you go okay, are these similar enough that we can manage having one app that serves all of them. That's the ideal way to approach it in my opinion. You can just start from assuming a responsive web design. I think that's sub-optimal but maybe you already know you don't have the design time. You don’t have the design resources and you just need to get something out quick. Hey, this is good if you're going to start from some basic approach by all means start from responsive web design if that's your situation that you find yourself in but just know going into it that it's not going to be simple. You're going to have things that are challenging and you're probably going to end up having to do some blend of responsive and what they call adaptive.

The difference there is that you have to augment the CSS media query approach with some amount of detection maybe on the server side and serving up for instance maybe different images or completely different shells for instance. If you want to have a totally different navigation shell or maybe you're trying to target a different look and feel. Caveat, you've been warned. Responsive web design is very useful especially in simpler contexts, especially when it's similar enough but that's something you have to figure out.

Briefly I wanted to mention here this case study that we did. We had customers come in as we do every once in a while for a little summit. The problem we gave them here was hey, here's this desktop app and it was a stereotypical line of business thing where you have your two pane navigation and then there's a detailed view and you dig into maybe even a hierarchical grid for instance. How would you take this and adapt it to a mobile phone? I think that's the target that we started from.

Interestingly enough and I don't mean this disparagingly at all but even though they were developers and not designers. They were architects like most of our customers are. They immediately did the right thing in my opinion. They went to optimizing it for that particular target and this is what I was just talking about. They didn't start from how can I switch this hierarchical grid into a phone. They said how can I reimagine this that makes sense for a phone and that again is the better way to do it. It doesn't mean it always the most practical way to do it. If you can take that approach it's probably going to get you to a better end.

I just wanted to illustrate that we all know this I think to an extent intuitively. It's not the right thing but sometimes we're quick to make compromises because it's easier as developers. We think it's going to be less work or whatever. It's just you're asking for trouble if you take the approach of squishing things in because you're probably not going to make your users happy. You'll probably have to do something new in the end or maybe you'll have more bugs because of that. Who knows. There's all kinds of consequences. I hope I have sufficiently scared you away from doing that but anyways.

If you want to think about reuse, you got to think about it in the terms of context. This goes back to some extent that classes of devices because those are part of the context whether or not they're moving about freely versus sitting in an office. Things like that. The lines of reuse are going to be along those lines from a user's perspective. If you start from there you're going to win better than if you start from hey, how can I reuse this technology that I already have. Just reiterating some of that and I'd say at the end, forget about it. Forget about this write once, run everywhere. It is largely a pipe dream. Again, there are some contexts where you can get away with that but it's not the ideal way to do it.

Mobile First is a thing that this guy, I mentioned him earlier [Luke Wroblewski] came up with years ago and it's a good approach especially if you know you're going to have to start your phone because the phone imposes the most restrictions on you from all these different aspects that we've talked about. If you are going to tackle this problem again, reimagine starting from Mobile First and then you can expand out from there but also as I mentioned before Mobile First doesn't necessarily mean phone. It could be a tablet if that's what your target it so do what's right for you.

Thank you again for listening to this talk. I will supply the information that I mentioned. A couple links and stuff that aren't in this particular deck and you can always reach out to me. I'm on Twitter. I'm on LinkedIn and you can get to me through the Infragistics.com website if you want to do that. I'm also ambrose@infragistics.com so it's kind of a tricky thing there. The trickiest part being Infragistics as a long word to write in but anyways. Hopefully you can remember that if you do want to email me and have a great day and I hope you found this useful. Thanks.