[MUSIC] Earlier we explored the difference between

UI patterns and persuasive patterns.

Now we're going to look closer at some examples and

we'll start by focusing on UI patterns.

For the rest of these lessons, we're going to look at specific problems and

apply design patterns to fix them.

First, UI patterns, and then later persuasive patterns.

I want to warn you, many of these patterns may seem like obvious advice,

because you've probably seen them before in web apps and

mobile apps that you've used in the past.

The thing you should learn to identify is the initial problem

because the solution will follow.

Oftentimes when creating apps, it's easy to build things a little too quickly and

create user experience issues.

But, if you can spot these problems early, and

fix them with a pattern, your users will have a smoother experience.

The other caveat that I would like to point out now

is that this will not be an exhaustive look at every design pattern out there.

There is simply way to many to give each one it's own example.

Instead, we will break down patterns into broad categories and

take a look at a few select examples to give you an idea

of the types of problems that design patterns can solve.

On the web and in mobile apps, it's common for

the user to input information in a web form.

And if the user doesn't put in data in the way the system expects,

we need to provide the user with feedback so they can make corrections.

This is called form validation.

Let's take a look at a few UI examples and try to improve them.

In these lessons i'm going to use Balsamiq mockups,

which is available for Windows and Mac OS.

Check out the notes associated with this video for

a link to Balsamiq, if you don't have it already.

You don't have to use Balsamiq for these lessons because really any drawing app or

mockup program will do.

Even a pen and paper will work fine.

I'm just using Balsamiq because I find it's one of the easiest tools for

me to use when demonstrating UI concepts on video.

First, let's quickly draw out a typical registration form.

The fields we want are an email address, password,

password confirmation, and a phone number.

And lastly a submit button

that says register to indicate the action we're taking.

So here in Balsamiq there's a couple of ways we can create UI elements.

I'm going to go up to Common here.

And I just need some text or a label.

And I'll call this email and then we're gonna need a button.

So let's just that grab that now.

We'll put that down at the bottom and rename it later.

And then we're also going to need an input box.

So I'll jump over to forms here,

scroll over to the right and grab this text input.

So let's drag that out for Email.

And I can select these.

And just Command+C and Command+V.

To copy them and paste.

And, I'll rename Email to Password.

And then we'll just paste again,

and say Confirm Password.

And paste one more time And

double-click to rename this to Phone.

And then we change the label on this button by double clicking and

we'll call this Register.

Hit enter to confirm.

So this form is okay on its own but pause the video and

think about what might make this better.

The first thing I notice about this form is that I don't know what's required and

what's optional.

Let's say this service doesn't require a phone number and it's optional.

That's great, because personally, I don't like putting in my phone number into

services, because I want to avoid spam calls.

It's great that it's optional here,

but how do I know that it's optional without submitting the form first?

There's two ways we could approach this.

We could mark all the required fields with a red asterisk or

text that says it's required, since that's a common pattern across many web forms.

But in this case, all of the fields are required, except for the phone.

So, the second way to approach this, is to only mark what's optional.

A typical way to do that is to include the term

optional in parenthesis next to a form field.

So let's do that now.

I'll double click on Phone and I'll add a space and

in parenthesis I will say it's optional.

Great, now what happens if the user puts in a bad email address or

an invalid phone number?

And what if they type in a weak password?

We should always have server side validation to check the input.

So if they hit enter to submit the form, even if they've hacked the JavaScript,

or have JavaScript disabled,

the server will still return them to the same page with the errors highlighted.

However, that's kind of a clunky way to find out

after the fact that your input was no good.

Instead, let's add some real-time form validation.

Real time form validation is advice that will pop up when the user moves

from one form field to the next.

There are lots of ways you could display this information.

But I'll put them in yellow bubbles to the right of each field.

A check mark will note a good input and

an X will show where corrections need to be made.

So I'm going to go to containers here and

I will draw out a rectangle.

Next to email here.

That should be good.

And I want the style to be rounded, so I'll change that in the inspector,

and then next I want to add a text label.

And let's say that this email address was invalid.

We'll say in,

valid email address.

And let's make that a little bit larger here.

That's good.

And then i'm looking for the X icon.

So we can just come up to the search in the upper right here, and

I think we can find that.

That's called Times, in this case.

I actually think I want this Times Circle.

So we'll put that there.

And let's change the color on this to red.

And on this rectangle, we'll change the background color to a light yellow.

And I think that looks good so far.

Let's actually double-click on the input here to change this to an invalid

email address.

We'll see nick@example@com.

Of course that is wrong.

And then let's have a password mismatch here.

So I'll type in a password first and I'll just type in a bunch of asterisks here.

And then I'll only type in a few here.

And let's copy this, actually let's make this a little smaller first.

And then we'll copy all of this stuff.

Paste it a few times here, because we're going to need it, for these other two.

And here we'll say passwords don't match.

And here it will say that this is actually a strong password and

we need to change this to a check mark.

So let's search icons here for the check.

There it is and we'll change that to green and I think that looks okay.

Contrasting colors and

shapes can be used to call attention to information like this.

And if the user happens to have a valid response and

changes it to something that's invalid, or

if they make a correction these bubbles can update as the user types input.

Updating after each character is particularly useful on the password field,

we can tell the user if they have weak password, or a strong password but

still accept weak passwords, if they choose to submit them.

This is actually one form of another pattern called a password strength meter.

If you wanted to take this idea a step further, you could include a set of

bars below the password box to indicate the strength of the password.

This is much better than where we started.

Now users can get feedback before they submit the form, which can encourage

good security practices with stronger passwords, and it saves some time

because they don't have to submit the form to see if their input is valid.

And if the user happens to submit the form anyway, these same bubble can

appear after a page reload once the data is validated on the server side.

As you can imagine there are many more design patterns,

in the notes associated with these videos you can find resources that list

examples of many other types of design patterns.

Don't worry about trying to memorize all of these,

what's important is learning to recognize UX problems.

Then, you can search these resources, or

search the web, see if there's a pattern that matches the problem.

Now, let's move on and look at some more UI patterns.