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.
Temporary Views
Loading...
Из курса от партнера University of California, Irvine
Best Practices for iOS User Interface Design
177 оценок
University of California, Irvine
177 оценок
Курс 3 из 6 — Specialization iOS Development for Creative Entrepreneurs
Из урока
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.
Познакомьтесь с преподавателями
Don PattersonAssociate Professor
Informatics and Computer Science
Sam KaufmanPartner at Gradient
[MUSIC]
In this lecture, what I'd like to do is just round
out our discussion of the different kinds of user
interface views that are available on the iOS platform.
By talking specifically about a small class of views that are available, but
ones that you are, probably very familiar with if you have used the iOS platform.
And that class of views is called temporary views.
And they are views that are temporary, as you might imagine.
So there are just three of them that we wanna touch on.
They are alerts, action sheets and modal views, or a modal view.
We'll go through them one at a time.
And just make sure you know the nomenclature and
kind of some of the ways in which they are intended to be used.
So first, let's take a look at alerts.
Alerts are this pop-up dialog that you see sometimes.
In this case, it's a map dialog and
the alert is this portion here, this white portion that's been called out.
In this case, this is an alert that has been generated by the Maps application,
but in your application,
you can also have alerts that implement something not totally unlike this.
This one's being generated by the iOS.
Software development kit when Maps is requesting location permission,
use the permission use location.
But it is an interface called an alert that you can also leverage
in the appropriate circumstances.
So it is a pop up window and it's designed to tell the user about critical
information and the key word here is critical.
It has to be something that's only used very sparingly
because it interrupts all other interaction that's going on in the device.
It takes focus away and
doesn't allow anything to progress until that pop up window has been cleared.
It is based on the UI alert controller class.
This is a class that we worked on previously in this specialization, and it
presents itself like this when it is given the UI alert controller style alert.
So given the style of an alert dialogue.
When you have these they contain three things.
They contain a title.
So the title in this case although it is a phrase that's the title portion.
So the title in this alert is allow maps to access your location
while you use the app.
The second thing that you can have is an optional message, and
this is a description that clarifies exactly what's going on.
So in this case, the optional message says your location may be shown on the map and
is used to provide things such as directions and nearby search results.
And the last thing that an alert can have is, it can have more one or more buttons.
In this case there are two buttons, a don't allow button, and an allow button.
You can have one of them, for example if you had just OK to clear the alert,
if the alert's just giving information.
You could have multiple buttons if you wanted, although
the size of this alert isn't so large that you can handle very many buttons.
When you have the alert, it's easy to abuse them.
And the way that they would get abused is if you use them in too many circumstances,
and you gave too many alerts.
The problem is as that if you have them too often, if you use them in just routine
circumstances the user stops treating them as a vehicle by which
you as an app developer can deliver critical information.
So you've got to be very careful.
So the problem that you can encounter is using too many alerts.
And you don't want that to happen.
And so to prevent that, you should only use alerts for
exceptional circumstances and not just exceptional circumstances, but exceptional
circumstances when the user can do or must do something in order to respond.
Regardless of this,
alerts should always offer critical information and useful choices.
In particular, there have been alerts historically in computing that have said
things like, error 57931, please refer to your system administrator.
That kind of alert is specifically the kind of thing that
the iOS developer human interface guidelines wants to get rid of.
Because an alert that just says error while that may be
helpful to you as a developer it is completely baffling, mysterious, and
a little intimidating actually to a user to see that kind of response.
It feels like they've broken something or
that something may be actually getting damaged with their hardware.
So it's the alert should be used for critical information and
they should provide useful choices that a user can leverage.
The other thing that we want is we want to be aware
that these alerts aren't necessarily the only way that we can accomplish our tasks.
So rather than having a problem of having too many alerts.
We can solve that problem by using something else.
The most straightforward thing is to redesign your user interface to emphasize
important information that would otherwise be delivered through a critical alert.
But that maybe is better served through a highlighted text, through
some kind of a change in a status element that is present on your user interface.
Possible ways to communicate information include Progress Indicators.
There are Progress Indicators that can be added when you're doing network
connections.
They can be added up here.
By little wheels that can be instantiated next to the carrier.
And you may also wanna use a progress bar.
You're probably familiar with progress bars that can be used to
indicate that something is loading or happening.
That can be a useful way to communicate something.
If you're having trouble and want to use a critical alert.
And the other thing that you can use, is you can use an action sheet,
which is the next kind of temporary view that we're going to cover.
All right, so great.
So when we do alerts, what we wanna do is we want to
achieve specific design guidelines in the design of our Alert.
So we want our messages that we communicate to our
user through the text on the Alert to be concise.
We would like to use short sentence fragments.
You don't wanna have lots and lots of fine print.
Users just don't read it and if you're actually communicating
critical information, it's important that the user does read it.
So keep it short and simple.
As we've already mentioned, make sure it's helpful.
Just saying error doesn't communicate very much to the user.
And in your text, be careful that you're not accusatory.
It makes your application seem patronizing or
argumentative or aggressive if you say something like
you didn't set the permissions to allow location access for this app.
That would be a bad way or an aggressive way,
a way confrontational way to present critical information.
And contrast that with the way iOS does it which says,
would you like to allow Maps to access location while you use the app?
That's not a critical way of doing it.
Another goal, a designed guideline is to strive for 2- button alert.
Button 1, button 2.
Now the reason why this is a good design goal, is because,
by having two buttons, it gives the user a sense
that they actually have control over the outcome of this critical alert.
If there's one button, all they're doing is clearing the dialogue.
But if there's two, they get an opportunity to allow or don't allow.
And if there are more than two, it very quickly puts users
into a decision paralysis where they have options in front of them and
it takes them a long time to consider what each of the options means and
the implications of each of them, especially if it's a straight forward
kind of question that you might want to ask of the user.
So, be concise.
Be helpful.
Don't blame the user.
And strive for a 2-button alert that gives the user a sense of control because
after all something critical has happened and you want to make sure that the user
doesn't feel like they've lost control of their device, their information, or
their presentation of their identity to the rest of the world,
through the network or whatever your app is doing.
All right, so we mentioned an another thing that we could do instead of
using alerts is to use an action sheet.
So an action sheet is also a temporary view but it's not a temporary view that
kind of has this in your face pop up stop everything kind of a look.
Instead what it is a short menu that presents itself
in response to a user initiating an action and depending on the way the screen
is currently constrained it presents itself in two different ways.
If you have a compact representation the action sheet shows up in this way.
Comes from the bottom.
And it presents the options that are available.
If you have a full horizontal layout,
then instead of getting it coming from the bottom, instead you'll get a little
dialogue that looks like our pop-up over interface that we saw before with
the same options that are available, with the exception of the cancel button.
A good design guideline is, when you have a pop over like this, you don't need
a cancel button because there's enough space that the user can press somewhere it
can tap, somewhere outside of the pop-up in order to make it go away.
So these are the action sheets, same action sheets,
presented in two different ways, depending on the shape of the screen.
And again, the purpose of these is to provide options when a user initiates
an action.
It's also based on the UIAlertController class, and so
it has a lot of commonality in the way it sort of is,
takes over control of interaction although it's not quite as all consuming and
it also doesn't present itself the same way with a title and a message.
Instead it's just a list of options that are related to the button or
the action that the user initiated.
And the way you create these is instead of using the previous alert cell you
use a UIAlertControllerStyleActionSheet.
And we've seen this UIAlertController created previously in previous courses
when we were working with our social media.
Okay, as we said, an action sheet response to a user action.
So in this case,
what we were responding to is the user clicking on the flag button, and then
the result is that what gets displayed is something that has two or more options
available to it that the user can pick to elaborate on what they wanted to do.
So in this case, they hit the flag button, but it's not immediately obvious what flag
should do, and there are multiple options for how to flag something.
We can just straight up flag it or we can also mark it in different ways depending
on what the user thought it was intended to communicate.
So, a couple use cases for the way that this can be leveraged is it can provide
alternative ways to complete an action.
Maybe there's subtle differences in the way that
a tool bar icon can be interpreted.
The other way that it can be used is,
it can be used to confirm destructive actions.
So, for example, if you have a delete button indicated with a trash can, and
a user pushes it, you could use an action sheet in order to bring up a confirmation
dialogue that says something to the effect of, are you sure you want to delete this?
Picture, email, Tweet, whatever you're working with.
So those are two use cases, two places where you might wanna use it.
Now the design of them, there are a couple guidelines that Apple puts forward in
their human interface guidelines.
One is to make sure that if you have an action that is going to be destructive.
Meaning that you're going to destroy user data, particularly if there's not an undo
capability, to make sure that you highlight that option with red text.
Now these options over here don't have any of them,
don't have anything indicated in red.
So it's maybe not a good example for this one.
The other thing is, when you're in a compact environment,
make sure that you provide a cancel button.
So in this case, the cancel button is here.
Cuz you don't have a lot of screen real estate, and
you would like the user to have the ability to just make that
action sheet go away, a cancel button makes sense.
Finally, you wanna make sure you don't have too many options,
because particularly in this situation, if you have too many options, and
you create a scroll bar on the side, it becomes difficult for
the user to move these actions up and down.
Without actually selecting one of these options in the process of,
I'm trying to scroll.
Plus the user might not realize that there are more things
below the fold that they can scroll up and access.
So, you should think through your UI design, so that there are just a few
options so that you don't put the user in a position of a decision paralysis, and
you keep your UI simple and clean.
All right, the final temporary view that I wanna comment on are modal views.
Modal views are views that are used
less as a way of communicating critical information which is what alerts did,
or of providing options the way action sheets did.
Modal views are used more as part of a workflow.
So as you're doing a particular sequence of actions you may find that one
of the steps in the middle is best accomplished by bringing up
a modal view of some sort.
A self contained step in a workflow.
So here's an example of an email on the left, and
if at some point I were to select this button here to start a new email
as part of a workflow of constructing that email, a modal view will appear.
That modal view is shown on the right but the way that appears is
as an animation starting from the bottom and growing to the top.
Until it fills up almost the whole screen.
And you can see here that this piece right here
is overlaying on top of this view here.
And that came up from the bottom.
Now what you see here is that this is a self contained step of the workflow.
So I'm sending a new email, all the controls and
all the ability to do that is contained within this modal view.
And that's the way it's intended to be used.
So once the modal view is in place, the primary use case when the modal view is in
place is to allow the worker, to allow the user to complete a step in the work flow.
For example, filling out a form that's part of a multi-step process or
completing an email such as, in this case.
And there are a couple of design guidelines for how to build these.
They can occupy the entire screen.
This one is not quite occupying the entire screen.
They can occupy part of the screen, more like this one is.
But the primary thing is that it should be self-contained.
It should have all the text and
controls necessary in order to complete this stage of the workflow.
And, it usually has a completion button or a cancel button.
And in this case for the Email the completion button is the send button
over here in the upper right and the cancel button is up here.
So as you're going to this workflow of looking at your Emails,
deciding to send an Email and then returning back to your list of Emails.
If you were to cancel from this construction modal view that you're in,
you would go back to this view.
And if you were to send,
you would go to a new view in which your action has taken place.
So those two buttons kind of move you forward and backwards.
And of course, the send view might not be enabled until you've filled out enough
information in the modal view to make sending possible.
For example, entering a to address.
All right, so in summary, temporary views are used in exceptional circumstances and
in that case what we would use is alerts.
They are used to clarify and to provide options for users when they initiate
an action and the temporary view that's intended for that case is an action sheet.
And then finally temporary views are also used to support a self contained
step in a work flow, and the primary one that's used for that is a modal view.
These are three temporary views that are present in the iOS STK development kit and
they're elaborated on the Apple human interface guidelines.
Again, this is bringing us from the high level aesthetic properties that
the designers of the whole SDK had in mind, through
the human interface guidelines which are design guidelines for how to use them,
all the way down into the code which tells us which classes do we instantiate, and
what options do we provide when we're actually writing code to do these things.
Okay, that's all we have to say about temporary views.
Thanks for your attention.
That's the end of this lecture.
[MUSIC]
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
