You will learn to develop sophisticated user interfaces for iOS, with a focus on user interface design best practices, UI animations, and responsive design. You will learn about the key UI widgets, mapping interfaces and view restoration.

DJ

Very Good content, clear and challenging. But the most important part is that the material is very applicable to real app development

OL

Mar 30, 2016

Filled StarFilled StarFilled StarFilled StarFilled Star

Excellent course. Very detailed round tour of User Interface concepts and recommandations for the best user experience.

De la lección

Getting to know iOS Design Concepts

Welcome to Best Practices for iOS User Interface Design! This week, we will take a deep dive into getting to know iOS design concepts. We will cover iOS, HCI, and HIG plus complete a peer review assignment called Layout with Dynamic Constraints that, as the name suggests, uses the auto-layout engine to make dynamic user interfaces.

Impartido por:

Don Patterson

Associate Professor

Sam Kaufman

Partner at Gradient

Transcripción

[MUSIC] One of the challenges of working in mobile user interface development, and quite frankly, in user interface development on almost any platform nowadays, is just the fragmentation of the number of ways that people can experience your app or your website, if you're designing for the Web. Across many different kinds of devices, many different sizes, and in many different orientations. So in this lecture, I wanna introduce you to the idea of device adaptivity. And this is gonna be very important for how we start to work with our apps when we want to design a user interface that works well in different contexts for different devices, different peoples, and different situations. The reality of designing for mobile applications is that these apps are not used when people have just full attention to give to them. Of course they are sometimes, but a lot of times when people are using apps it's when they're on the go, it's when they're in different environments, it's when the app is actually a secondary focus to what they're primarily doing. Whether it's walking, or listening to someone speaking, whether they're waiting in line for a restaurant or a bus. All the different things that they might be doing, people will often pull out the phone in order to multi task and get a little bit something, little bit of productivity, little bit of extra work done. Have a little fun, play a game, communicate with someone in the midst of many other things that they're doing. And the phone is actually kind of a secondary focus in many situations. It's used in many different orientations whether you are trying to read top to bottom, you can turn the device sideways. And, in fact, one app may be used on many different devices. Someone may have the opportunity to use your app on an iPhone platform, an iPad platform. Another person might be using it on those devices as well, but a different version, a different generation. Or maybe on a generation of iPhone or iPad that is yet to be released. All of these different platforms and environments mean that your app has to be very clear, has to work in many different situations, and it has to be well designed. There was a time, this is my nostalgia moment, there was a time when you could devise, you could design one user interface that just kinda worked everywhere. It what, there is one screen aspect orientation for the iPod, iTouch, iPhone platform. There was one landscape mode, there was one portrait mode, and the only difference was how much it was scaled on different devices, and it didn't require a different layout. That just is not true anymore. The fact is that the iOS 9 platform runs on all of these different devices. The iPad 2, the iPad 3, the iPad 4, the iPad Air, the Air 2, the iPad mini, the mini 2, the iPad mini 3, the iPhone 4s, 5, 5c, 5s, 6, 6 Plus, 6s, the fifth generation iPod touch, plus whatever the heck the iPhone is gonna be. That's no gonna be too much longer before that comes out. In fact, you might be watching this after it's already come out. Oh, not only do we have the different devices and the different orientations, but now we also have the introduction of split-screen views, which enables some platforms to view multiple apps side by side. Not just in one half-screen orientations, but one-third and two-third orientations too, portrait and landscape. All of these different situations require different attention to layout details. Depending on your specific app, but certainly they need to be reviewed before you release your application to the wild. Getting it right, I mean the bottom line is getting it right requires a lot of work and a lot of attention to detail. The general strategy is to start with your basic interface. You kind of design, the typical design pattern is to design for an iPad then to adjust your interface for the different phones and orientations. Then you just iterate. You try your design on all devices and all orientations. And if you're designing a multilingual application, an application that supports multiple languages, you also have to design and view your designs in all the different languages as well. Because the translations of your text for buttons or your instructions may require more space than you expected. And you don't want the text to be cut off because a long word was used in one language and maybe a short word or short set of characters was used in another language. If on top of that, you're using a language that doesn't read left to right but reads right to left then you'll also have to worry about your device design, you UI design for different ways that people read languages takes a lot of work. A lot of attention to detail. So, once you do all that, you need to test it, test, test, test. Not just test the code functionality itself, but test the UI and the layouts. The first place that you can test is within Xcode. In a future lecture in this course, we'll show you how to do that. You can also test it in a simulator. In this specialization, in previous courses, we've shown examples of viewing it in a simulator. And then, ultimately, you'll also have to test it on real devices to the degree that your budget supports you being able to have access to all the different kinds of devices that are available. Rarely anymore is there a difference between the simulator and the device itself, but sometimes, the experience of holding your application in a physical device can reveal aspects of your design that just didn't occur to you because you were working in a simulated environment. Maybe the position of your fingers, maybe the way in which it just feels when you've got it on a real physical device causes you to want to use a different kind of a layout approach. You won't figure that out unless you actually test it on real devices. Finally, your only going to get, for the most part, you're only going to get one chance for a user, in order to capture their attention, in order to use your app. If you're lucky enough to get the user's attention just to install your application. If you're lucky enough to have more than five seconds of your user's attention in order to explore your application, then you've gotta make sure that you get it right. That one chance you've gotta make it count. Cuz if the user doesn't have a good experience after they've downloaded your app, after they've tried it out on their device and their platform and whatever orientation they're looking at in their language. If it doesn't look good, if it isn't responding to what they expect to be able to see. Their just gonna get rid of it. And that was it. That was your chance to communicate your idea, and your app to that person. So when you lay it out, when you layout your user interface design, you can basically leverage two different strategies or a combination of those strategies within Xcode. There's one strategy is called Size Classes. We're gonna talk about that in a second. And the other strategy is called Auto Layout, and this is a strategy that entails constraints. Most high quality production applications use both of these. Up 'til now in the specialization, we've been focusing on just using constraints as the way that we do our layouts. Because it's a simple, straightforward way to make an application that's pretty straight and simple that work on all different devices. To make a really high quality user interface however, you have to acknowledge that there are different, there's some significantly different aspect ratios on the devices in which your app may end up being used. And for that, you need to use size classes and constraint and auto layout together. So, what I'd like to do is just talk briefly about size classes. What they enable is they enable your app to have different layouts, meaning you're allowed to put your UI elements in different places according to classes of screens, classes of orientation, and classes of devices. So rather than laying out specific layouts for every single device and the orientation of every single device, what Apple has done is broken their devices into classes which you can design for. Usually you'll design for, like I said, the iPad environment. And then you'll create exceptions or special cases to deal with the other kinds of constraints, and those other classes are called size classes. When we look at size classes, we're talking about different widths and different heights of the device that you're gonna be working with. Size classes for both widths and heights can be described as having regular width or compact width. Heights can be defined as having regular or compact heights. And if you don't wanna specify a difference between the two, you can design for any width or any height. In the case of an iPad, the current generations of iPads render as follows. In the upper left you can see an example of an iPad in which it's in portrait orientation. In portrait orientation your interface will draw its instructions from the size class regular width and regular height. So within Xcode, you will design a interface that applies to a regular width and a regular height. If you turn an iPad sideways, although the screen size changes, it will also use the size class of regular width and regular height. But because the screen size has changed, the interface engine, the UIKit, is going to rely on the constraints that you have given, within the size class of regular by regular, in order to rerender your interface within this same size class, regular by regular, but new size of window. If you decide to use a split screen view or if the user decides to render your app in a split screen view, depending on which pane the user puts your app into, your app will be given the signal that it is being rendered in a new size class. So if you look in the bottom left, that iPad had been split, it's in a portrait orientation, and it's split into a two-third, one-third multitask view. So the app that's one the left will be rendered in a compact width and a regular height size class. And so that means within Xcode, you will have to define how you want your app laid out when it's in a compact width, regular height condition. You'll notice that in the bottomleft iPad layout condition, when it's split two-third and one-third, that same size class is used for the one-third pane view also. And so although it is the same size class of a constrained width and a regular height, different screen's real estate, in both of those cases, will cause the constraint engine to relay out the components, given the input that you've provided for that size class differently. In the case of the iPad in the middle on the bottom, we can see that a landscape view has been split in to a two-third, one-third view. Because of the relative amount of screen real estate here, if your app is rendered on the two-third view in landscape orientation, you will draw on the definitions that you provide in your regular, regular sized class and then the constraints will be applied within the screen real state and the rules that you've provided for regular regular. If in a landscape iPad view, you're in the one-third view, whatever layout you've given for the compact width and the regular height will be applied and then the constraints within that size class will be further applied to decide where are your buttons and where your content views and where your toolbars should be placed. And finally, if you're in a 50-50 view, the bottom right iPad, where your iPad is in a landscape orientation and you have a half and half multitask view, if your app is on the left or the right, You will use the definitions that you have provided in Xcode for how you want your layout laid out in a compact width and a regular height, and then the layouts within that size class will be applied. Now this is just a situation with an iPad. If you then use a different kind of device, you'll use size classes as well, but the screen real estate will be managed differently. So in the current generation of iPhone, the large screen size, I believe this is an iPhone 6s and 6 Plus, when a app is rendered, it uses the size class regular height and compact width for portrait orientation. On that same device, if instead it's turned landscape, the size class that's used is a regular width and a compact height. So notably, this is the same, if I go back one, you can see that, let's look at the bottom left iPad, we have the size class of constrained width and regular height for the two-third, one-third split. So that size class that's used for the iPad split view is gonna be the same size class that's used on the portrait orientation of the current generation of iPhone, regular height and compact width. So that size class is gonna be applied in both of those cases, and then your interface will be laid out within that using constraints. In the current generation of phone, we use a compact height and regular width when we're in landscape mode. But on previous generations of phones, we used compact compact size class because there's just not enough screen real estate to justify using a regular width or a regular height, of course. So, how are we gonna go about doing this? Well first of all, we have to learn where the size classes are found in our interface builder, and how to adjust for different interfaces within each of those different cases. The general rule of thumb is that you design for the common case first, that being an any case view, regardless of whether it's regular compact or regular compact, you use the any by any and design a basic interface. And you wanna focus on the content in your view, make sure that your content looks good, it comes to the forefront, the user interface elements are more of the background of your design. You wanna make sure that as you then look at different size classes, you keep basically the same content in view, so that the experience that the user has, is that as they turn their device, or as they go to a split screen view, or as they view your app in a different device, it's not a radically different presentation of what your app is showing in each of those different situations. You wanna try and keep the layout as consistent as possible. Moving from that common case into the specific variations which are usually the compact views from that common case. Now if you wanna simplify your UI design, it's possible to not cover all of these. It's possible to limit the number of ways in which a user can experience your app. For example, within the info.plist file that's associated with your app, You can restrict your application to only be enabled to be viewed in a landscape or portrait view. So that if your user rotates the device, the user interface will not rotate, it will just turn sideways. You'll have to turn your head sideways in order to see it. That's one way to simplify your design. And perhaps a good way to release an app is to first design a well crafted app in a particular landscape or portrait view, not allowed the user to rotate. And then in subsequent updates of your application, in future cases, do a good job of designing for rotation. Now be aware that this comes at the cost of user experience. Because generally, users expect high quality applications to have different consistent views, whether you rotate or whether it's in landscape or portrait view. And you also have to be careful with various kinds of icons that you might use that encourage the user to rotate the device in order to get a different experience. A second way that you can simplify your UI design is to just use one size class or disable size classes entirely and to just make your user interface layout on the basis of constraints. Now this is what we have been doing up until this point in this specialization. We've always just laid out our user interface using constraint based layouts and not worried about size classes. This again is a way to simplify your UI design, at the expense of making your user interface kind of look good in all situations. And then finally the last thing that you can do is you can focus on just designing for a single debvice at a time. And if you do that, in the process of releasing it through the iTunes Connect interface and through the iTunes Store, you can specify that you don't want your device to be able to be loaded under different classes of devices, in general. All right. At a high level, when you design your layout, you should be aware of a couple of concepts that are present in design. And that is something called a quadrant design. It goes by a couple different names. But you can think of your interfaces been laid out to four quadrants that get a user's attention based on basically reading pattern. So again this applies only to cultures in which you read left to right but in those cultures there's a strong tendency for primary attention to focus in the upper left. We call this quadrant the primary focal area. A user will look up there, kind of focus their attention up there, and then will quickly move to a strong secondary focal area on the upper right. As they proceed through the experience of looking at your app, and I'm talking about like a very biological level, as your eyes scan over an app, the third place that they'll go is to the bottom left. Kind of a weak tertiary focal area. And then the last place that the eye ends up is over on the terminal focal area generally speaking on the bottom right. This kinda reflects a reading pattern, but it also suggests that the way that you might want to design your user interface with buttons and the labels is with the assumption that the first place that the user is going to look is in the upper left. So you might want very quick description, explanation of where you are and what you're doing in the upper left. And then some kind of concluding action like a Submit button or a More button or a Next Page button down at the bottom right. Now, this general pattern of moving from upper left to upper right to bottom left to bottom right can be altered with strong graphic design, with strong button elements, with larger fonts, with bold or color. You can change this general pattern. And this isn't for sure in all cases. But as a general rule of thumb, this is a good way to think about how users are going to experience your application. If you're interested in seeing some examples of this, you can see and go to Google. You can Google for the term eye tracking heat map. And you can get a bunch of examples of studies that have been done in which eye-tracking hardware has been used to see where people look on different kinds of interfaces. And from that, you can get a sense of both this pattern of moving upper left, upper right, bottom left, bottom right. But you can also see the way in which different kinds of graphical elements can alter that pattern so that you get a sense of where you should put your most important elements. And how you can adjust your user interface to make sure that your user can comprehend what the task is that they want to achieve how you can lead them through that task by doing a well designed user interface. All right. Ways to alter that pattern is to use a different font size. You use font size in order to communicate importance. Both just the point size as well as whether it's bold or regular. You can also use alignment in order to alter the way people view a given interface. Alignment can be used both to organize content so that people can get a bigger picture sense of how the data is structured, and can also be used to communicate hierarchy if you have certain elements all lined up on the road. It give them a sense of equivalence and if you have items indented, it gives them a sense of hierarchy. You also wanted, going back to this high level design concepts, you wanna make sure that you allow your user interface to have enough white space so it doesn't feel cluttered. You want there to be negative space so that the user can experience some sense of structure and can orient themselves to the content that is present. So make sure that the buttons don't get too small. The rule of thumb in the Interface Guidelines is that a 44 pixel by 44 pixel button is about as small as you want it to be. Let's make sure it doesn't get too small for our user's finger. And then, so, in summary, what we are leading into, is an explanation of how you can deal with device adaptivity. How you can deal with devices that are used in a wide range of context where screen real estate is different because of the way the user is using your application on different devices and different orientations and different split-screen modes. An important aspect of that, perhaps the most important aspect of that is the screen size. We're going to start to talk about how we manipulate our design to reflect those different screen sizes. Supporting all those screen sizes is a lot of work and so there are different strategies that you can use to reduce that. Then finally you can use good graphic design to help you mitigate some of the effects of these changing screen sizes on your application. All right, thank you very much. [MUSIC]