Starting and Stopping

Loading...

Do curso por University of California, Irvine

Best Practices for iOS User Interface Design

179 classificações

University of California, Irvine

Best Practices for iOS User Interface Design

179 classificações

Curso 3 de 6 em Specialization Desenvolvimento móvel em iOS para Empreendedores Criativos

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.

Na lição

The Design Solutions that come with iOS

In week 2, we will discuss the design solutions that come with iOS. We will cover HIG and HCI principles plus learn how to achieve the design. We will wrap up this week with a quiz to test your knowledge on what you have learned this week.

Starting and Stopping26:07

Navigation Styles15:39

Gestures and Touch13:06

Leveraging iOS23:32

Some HCI Principles22:24

Conheça os instrutores

Don Patterson
Associate Professor
Informatics and Computer Science
Sam Kaufman
Partner at Gradient

[MUSIC]

As we talk about design concepts, as we try and

move from high level design considerations that are very aesthetic and

design-oriented and experience-oriented, and we move down into the code.

Along the way we get into some principles about how Apple wants iOS

apps to be realized, to try and

give a consistent feel to all of the apps that run on their platform.

And this consists not just in the experience around the graphics that

are displayed on the app, but also in how the app functions, how the behavior works,

how it works through the lifecycle of the user working with the app.

So what I'd like to talk about is some principles

drawn largely from the Apple Human Interface Guidelines,

that document that sits as an intermediary between the high level design goals and

X code, that talk about the starting and stopping of an application and

the different things that are associated with it.

The things that as an app designer,

you should be thinking about, to create a good user experience.

These are best practices for starting and stopping for an iOS app.

So I'd like to talk about them in four bits.

I'd like to talk about the idea of starting instantly,

launching your app, restarting the app and then stopping the app.

So how do you do these things in a way that this consistent and

professional with the rest of the platform?

So first, starting instantly.

One of the things that's just a reality about the world that we live in,

is that if you want to get your app used, you have a very short amount of time to

convince a user that what you are offering them is something of value,

that they should even engage with your app, among the sea of

other information that's flooding them, and opportunities to install other apps.

And users are gonna judge your apps instantly.

When they load up your app, they're gonna look at it, and

they're gonna quickly gonna decide is this something I wanna spend any more time on

or I'm done with this?

So presenting something that has a professional looking feel immediately is

really important.

We've talked about that in terms of making sure that your device,

that your app works on all kinds of different devices.

It's an adaptive app that works in different orientations and

the different devices.

Because, for example, you don't know if a user is gonna open your app in a landscape

mode, and if they do,

you want it to look good in a landscape mode, so that it'll looks like hey,

this is the way its supposed to be used, the user's time is worth it.

So, in that very short amount of time, there's five seconds to one minute that

you've got with that user for the first time, you wanna make

sure that your app gets as far into its value proposition as possible.

And so the first thing we wanna do is we want that app to start instantly when

the user first brings it up.

That entails a bunch of different things.

So for starters, you don't wanna waste time on a splash screen.

A splash screen, if you're not familiar with that term,

is a screen that has just branding, or marketing.

It's like a title page to a movie, or the cover of a book.

You might not realize it, but that makes the user feel like they're waiting for

something, it makes them feel like they're being advertised to,

and it slows them down.

So, the general guidelines that Apple puts forward, is to not use a splash screen.

Don't put something up before the user can begin.

So, what would be a bad example of this?

A bad example of this, would be a calculator app, like the official

Mac Calculator app, that says something like welcome to calculator,

and then you have to hit start in order to begin the application.

This just doesn't add any value to the user experience.

And it slows them down, and

it makes it just that additional burden of getting the user into using the app.

Some of the guidelines from web applications and

people who study things like shopping cart abandonment and checkout processes,

say that up to 50% of your customers are lost for

every time they have to hit another button in order to get out of a checkout process.

That's just a rule of thumb and that kind of a fact you would assume would also be

relevant for someone evaluating an app.

So rather than having a splash screen like this,

just immediately drop in to the functionality of the calculator.

There's no reason why you shouldn't do that.

And that provides less wasting of time, a start instantly experience.

In addition to that, you wanna move directly in to functionality, so

you wanna start instantly, no splash screen,

and when you do drop into, you wanna drop into the active page,

as opposed to some sort of page, an about page, or some other kind of page

that you might have that's not related to the central idea of what your app is for.

You don't want to require the user to ever restart after loading your app for

the first time.

This would be, maybe because you're app uses a lot of resources.

It has a memory leak.

It is allocating objects and it's not releasing them, and so

over time it becomes more and more of a sluggish program.

You certainly don't want to do something like recognize this in your app, and

then suggest that the user restart your app, in order to get better performance.

If you are experiencing that as a developer, if you know that that's

happening, the way to solve that problem is to go and look through your code,

and study it, and to understand why you are increasingly having more and

more sluggish behavior, as your app goes on.

Rather than expecting your user to reload the app

in order to get performance back to their phone.

You also, another thing that could happen,

before a user goes into their functionality, is you might,

with best of intentions, want the user to set some parameters,

set some settings, give some feedback about how they want the app to operate.

Maybe how long of a delay for something.

Or what colors they might wanna see.

Or how big a font they want.

One great way to get your users to start instantly

is to give good default settings out of the box.

Think about what 80% of your customers are gonna wanna do with your content and

then set the defaults for those people.

Now of course, if you have the ability to add features that adjust that

functionality, you can do that through your own settings or

through the settings provided through the Apple iOS interface.

But what you don't want to do is have the user have to fill out settings before

they're able to get into the process of using your application.

In addition to that, in addition to not blocking them from your app with

a settings page, if there are settings that you can get from the app itself, for

example, a single sign-on process or

some of the other features that are associated with the user experience

of using the phone that are available through the operating system.

Don't ask the user to provide that information again.

Just slows them, makes it look like they're doubling entering information and

gives your app a bad, low quality feel.

So, don't ask for

information if it's available already in other places from the phone.

Establish good defaults so that they don't have to adjust settings,

so the majority of the users don't have to adjust settings at least initially.

And also don't require the users to visit the settings page,

the official Apple settings app,

that may have a place for

your app to set preferences outside of the body of your app.

If you know what I mean.

There's a settings app within the Apple operating system that has some settings

for applications that you can only get to by going through the settings page.

Requiring users to go there, is a really bad idea,

because a lot of users don't know that it exists, don't have a good mental model for

how that works with the rest of your application.

So as much as possible, get those defaults right, right out of the box.

Although, it is very common in many applications to present EULA,

or End User License Agreements.

Or other kinds of disclaimer pages, or warnings or

legal indemnification's of all kinds.

If you cannot all avoid it, just don't include those,

in the process of a user, using your application.

They scare users, they're really annoying, they make your app feels sketchy like it's

doing something that you might not want it to do, but it's gonna be able to do it

without regard for your considerations because you've agreed to this.

Long text.

Users aren't gonna read long amounts of text, especially in E U L A agreement.

What you can do, if you needed to have someone agree to terms of service,

is you can have that be part of the process of downloading the app from

the app store, so that when they download the app,

the app store presents the end user license agreement.

It feels like it's coming from the app store.

Although it pertains to your application,

it doesn't feel like it's stuck in the application itself.

Getting between your user and the functionality of your App,

as quickly as possible.

When as quickly as possible, deliver the value proposition to your user,

without presenting them with all kinds of barriers to get in there.

We've seen, in previous courses, places where we needed to request permission from

the user, for various kinds of things.

For example, when we were doing our social sharing,

we needed to request the user to connect with Twitter, if they hadn't already.

A really good practice is,

in any case when you end up asking for permission for the user.

Maybe permission to get location data, permission to get in login credentials.

What is a really good practice, is to wait as long as possible to ask for

that information.

Allow your users to uses as much of an app as they can,

without having to agreed to those things.

Without having to login.

And then,

when they undertake some action that requires them to provide that information,

for example log in information and password or permission to access photos.

It's much more clear to the user, why you're asking for that information.

Because it's at the moment, which that information is clearly needed.

For example, sharing a photo.

At that moment, it'll be very clear that you need permission for

a social media site, an access to photos on your phone.

It makes your user, able to get as much functionality as possible and

also relieves them of some concern, if you ask them for

some information at the beginning of your app launch.

You know, the user may not even understand what your app does and

it makes it look like you're gonna steal private information.

Without EN, these are the usual not user app anymore and you aren't

gonna get a chance to convince them that you have a great thing for them to use.

If you do have to present them permissions or need permission to do stuff or

if you are asking for permissions that are not immediately obvious,

make sure you explain why it's needed and do it in a friendly conversational tone.

So that users get a sense, get comfort level for what you're asking them to do.

A lot of times, when an app first starts,

it's tempting to want to have some kind of an app tour.

For example, you might wanna have a video that shows your users, how to use the app.

Or you might wanna use one of these sort of translucent overlays,

that walks them through each of the buttons that's available on your app.

And gives them a description of what those buttons do.

Before you do that, before you offer that app tour.

So, an app tour just for grounding is a walk through of the features.

It can be done with embedded video, or with tooltips, or

with translucent popups that cover your app.

Before you do that though, consider if you really need it.

If you really need an App Tour, you need to ask yourself,

is it possible that your design isn't very good?

Is it possible, that what you're presenting to the user is too complicated?

In fact it's so complicated, that you have to give them a special tour,

before they can understand what it's doing?

Now presumably, they have some sense of what it's supposed to do,

because they download it already, or they were looking for it.

And so, why can't they figure that out,

from the icons that you're providing them, or the views that you're showing them?

Is it that, it's too complicated as it stands?

Is it that your icons are unclear?

Or is it that maybe the purpose of your application is not obvious?

If those are the cases, before you jump into writing an App Tour,

consider going back and redesigning your interface.

It may be an app or maybe a reflection of design flaws,

rather than simply users who don't know what they're doing.

So, think about redesign as an alternative to an app tour.

If you do decide to do an app tour,

you do decide you need it, make sure you keep it simple.

Only cover the very basics that the user needs to know,

in order to start using the functionality of your application.

Just enough, that they can get in and get going.

Make sure you make it skippable, because you never know,

if a user has already used your app in another device or another persons phone or

someone sitting with them walking them through it in person.

Certainly, don't expect readers to read long passages of text.

Licence agreements's, elaborate descriptions of how things work.

They don't have patience for it.

Once you've delivered the App Tour, get out of the way.

Let them use your app.

Let them explore it and

hopefully if you have done a good job with designing the interface.

It would be obvious how to use it.

You'll find a temptation, in making an app that has broad distribution.

I'm sure you've seen it, in apps you've used.

You'll find the temptation to ask a user provide a rating to your app.

This is good because it provides some feedback to the App Store, so

that when people look at your application and know whether or not people liked it,

you can see that people have used it, so that it's a fairly popular app.

But, you have to be careful not to ask people for their opinion too soon,

because of all, as very simply.

They might just not have formed an opinion yet.

Maybe they're still exploring your application.

And they don't really have enough grounding, to be able to give it

a reasonable description of what your application is like.

What it feels like to use it, what the user experience is like, or

certainly how many stars.

And if you ask them to rate it too soon,

rather than having a well-considered response,

they may just be annoyed by that and that annoyance is gonna lead to a bad rating.

You want to wait, until they understand the value of your app before you ask them

to rate your application and maybe one way that you could do that is you can

keep track within your application, of how many tasks a user has taken.

Maybe, have they explored the breadth of the things, that your application offers?

Or maybe have they done enough of a single task that your application enables?

And once they have,

once you've kept track of how many times a user has used a feature,

maybe then, that would be a good time to ask them, to provide a rating.

Okay. So, that's launching.

But starting instantly,

let's talk a little about that launching process in a little bit more detail.

We first launch up, we said don't provide a splash screen or

some type of interstitial, where you hit a start button.

Well, IOS also enables you to have a specific launch image, or

a specific launch interface.

The next course after this, next lecture after this,

will show you how to put together a simple launch interface, launch image.

But it's really good to do that, and to have one that looks like the interface for

the rest of your application, It improves the user interface,

because it makes your app appear faster.

That launch image can be very quick to render, and it can expose what's coming

next to the user, just like a translucent modal exposes what's underneath it,

while your app is doing the cleaning, while iOS is getting it started up,

while you're transitioning into the app experience.

But don't use that as an opportunity to provide a lot of branding,

to do a logo, or an about page.

You don't know how long it's gonna be there, because there's a variable

amount of time in how long it takes iOS to bring your application up to speed.

So don't put a lot of information that the user needs to absorb.

Don't put a lot of branding that makes your app look overly spammy or

over commercial.

Ideally, launch images should ease the user into your app experience.

It should be almost completely text free, or

a very simplified version of a user interface.

And the good thing about being simple, is simple is also fast.

So, it's interesting to look at an example of the way Apple has done this.

So, in their weather app, their launch screen looks like this.

It's a very simple blue gradient, that has a couple icons at the bottom that indicate

what the user's gonna see once the app is fully loaded,

has gotten the information about current weather, and displays it.

So from this launch screen, the screen that gets rendered is this.

And you can see that, that blue has been transformed into a graphic,

all the images have been overlayed on top of it.

Doing that well is a good way to improve your user experience on launch.

When you restart, we've talked a little bit about life cycle in the past.

At any given time, your app can be restarted.

We've seen how your app can be put into the background.

When your app is put into the background,

you are at risk of having your app ended at any given moment.

And so what you wanna do is as much as possible as your user is stepping through

the process of doing whatever task you support,

make sure that you save information along the way, so

that if your app does get backgrounded, and then removed from memory,

when you restart, you can bring the user back into the spot at which they were,

in your workflow, with whatever forms they were filling out, ready to go,

whatever stage they were in the application.

All just as they left it.

It's even feasible to keep track of where in a page someone had

scrolled to if they were reading a book or reading a note.

So that as they come back into your application,

they're presented with almost the exact same location, if not the exact same

location information that they had before the app was swapped out of memory.

Reloading it, keeping track of that state as the user moves along.

Storing it in persistent storage, so that when you start,

you can look in that persistent storage, and

restart your application from wherever your user left off.

Finally, I wanna talk about stopping.

Some of the best known practices for stopping in iOS,

is, for example, that iOS apps don't have a close or quit option.

Have you ever noticed that?

There's no X to close a window in iOS, like there is in desktop applications.

There's no place where you actually like can quit it.

The only way that you can swap an app out of memory is if you happen to know

the double tap, multi tasks swapping view, and then swiping your app out of memory.

It's kinda a little bit mysterious if you're not a computer,

technical person to even know what any of that is doing, It's by design.

Apps, when users are done using apps,

what they're going to do is they're gonna multitask, they're gonna switch out of it.

So don't provide something like a close or quit option, and

certainly don't do anything within your application that causes your app to quit

from the program side, or programatically.

If you do that, it makes it look like your application has crashed, and

that's really bad for presenting a professional image of your application.

So because a user might stop your app at any given time,

save your users data regularly.

Once you're in the background you can get moved out permanently, and

if you can save fine grade state information like that, like I mentioned,

the scroll bar position in a view.

A lot of this centers on an idea from user interface and

human computer interaction, that's called locus of control.

Locus of control means that, the locus means the position, or the center.

And the HTI principal locus of a control says that we want the center of control,

or the place from which agency originates, where the action comes from,

to be centered, that locus of control to be centered on the user.

That means that we don't want the application to be making actions,

doing actions on the user's behalf, because it confuses them, and

it makes them feel like they don't have the ability to control their environment

which makes them feel out of control and not want to use your app.

So, as much as possible, we want to allow the users to make their own decisions

about what to do within an application.

For example, if something isn't set correctly, a good way to handle that is to

inform the user of the situation, what's causing the problem,

inform them how to fix it, and then wait for them to do so.

That enables them to understand when things are in an error condition and

perhaps there are things around their environment that they might wanna do

differently, or maybe they are intentionally setting that error condition

in order to cause something in the rest of the world to work for them.

If you go about fixing error conditions too much, or

in cases where it feels like the user is losing control,

they can become disoriented and not understand when your app does things, and

then stop wanting to use it, cuz they don't feel like they understand it.

So here's an example from the human interface guidelines,

Apple's human interface guidelines,

about what you might do if all of the apps features are unavailable.

For example on this podcast app, if there are no subscriptions, there's not much

you can do with the podcast app, because you don't have anything to listen to.

So, what the designers of the podcast app have decided to do, is to present a screen

that tells them, why is there nothing that can be done, well, you have no podcast.

And then, tell them how to fix the problem.

Subscribe to a podcast or download episodes to add them to my podcast.

And then there is a very clear button that users can interact with,

in order to start the process of subscribing to a podcast.

Now that's something you do if all the features are not possible,

because the user hasn't done something.

It leaves the locus of control with the user though.

The user isn't automatically subscribed to a set of podcasts, they're walked

through a process of suggestions and options so that they can decide, and

they have control within them in order to change the situation.

An alternative situation is if only some of the app's features are not available.

In that case, you still wanna tell them what's happening,

possibly through a modal dialogue, but

let them use the rest of the app even if all the features aren't available.

Giving them the locus of control to correct that if that's what they wanna do.

So here's an example of that happening in the Apple Maps application.

So if you start from the home screen and this is my home screen.

And a user clicks on Maps in order to start the mapping application,

you may notice that my phone is currently in the airplane mode.

So it's not gonna be able to access any of the data in the network, so

when the map application loads up and

tries to download the data, it notices that the connection is failing and

it says, oh you need to turn off airplane mode or use WiFi to access data.

There's a button to clear the dialog, and there's a button to go to settings so

that the user can fix that if they want.

But if you hit OK, the app works fine, you can move around,

you don't see any of the background images.

You see the last Starbucks I was at, and

you can click on it, but you won't be able to get any information

from the internet until you fix the things that are a problem.

In some cases, the map app might work with cached data,

that was collected last time you were online, and so

there might be a certain area that you could scroll through.

But then if I decide to go to settings, or in this case I used the control panel from

the bottom, and I go from airplane mode and leave airplane mode, so

that my app can get all the data that it needs, then as soon as it's available

the app fills in and provides all the functionality that is needed.

That left the locus of control with me though as a user

to fix the problem on my own, and if I didn't want to,

maybe all I wanted to do was check how many stars that Starbucks had received.

And I didn't want to bother with turning on my cellphone coverage.

So, in summary, what we're talking about is trying to move from high level

aesthetic concepts that govern the design of the Apple interface, and

the vision that Apple wants their application developers to put forward.

We're moving from that down into Xcode, and along the way,

we're going through the human interface guidelines that bring us from those

aesthetics down into the specific code.

A big part of that is not just the user interface elements that we're using,

but the behavior that your app exhibits as you are functioning.

So some of the processes that have best known practices are starting, launching,

restarting, and stopping, they're very important parts of the user experience.

And high quality user interfaces, like the ones that we want you to be

able to design, handle these situations gracefully.

Make sure that your app follows these recommended practices, and if you do, you

will communicate a high quality experience and your user will be more likely to find

value in what you're doing, possibly being willing to pay you, or possibly giving

you the satisfaction of knowing that your app is well designed, loved and used.

Thank you.

[MUSIC]

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play