Angelina's edit of Curtis' script on basic usability for apps

gistfile1.txt

5 Crucial Usability Tips for App Designers and Developers
----------------------------------

Hey, everyone. I'm Curtis Lassa, and I'm here to share some very simple 
usability guidelines with you for application development.

By the end of this video, you should have a better understanding of how to design a UI that is intuitive and easy for your users to make sense of.

Let's begin by examining one of the fundamental pieces of applications on the web: hyperlinks. On a dekstop, it's much easier to be precise about where you want to click because your mouse cursor is small. You know what's not small? Our fingers. Relative to the pointer, of course. So, this means that when you're considering your application for touch-screen devices, you need to adapt accordingly.

Links should be _obviously_ clickable. So what makes it obvious to a user that something can be clicked on?

Modern app development style is becoming very flat and minimalistic -
which, I'm not going to lie, I like a lot - 
but one of the reasons that buttons with that pop-out gradient effect 
were so popular was because it was always REALLY EASY to tell that 
"Hey, you can CLICK this thing". 

If you're targetting mobile devices, avoid links in favour of buttons. This doesn't mean you can't use anchor tags, but style them to be 'button-like', and pay attention to how big those buttons are! Your buttons should be at the very minimum the size of a chubby finger. At minimum they should be about 44px tall, and min 48px wide. Sometimes you can make them a little bit smaller, but not by much. It really depends what other elements are nearby. You don't want users frustrated when they mean to tap on one button but hit another near it by mistake because the area they have to tap is too small.

If you have a web-style link, which is to say a more traditional anchor tag like you'd see on a desktop site, it's important that the link stands out.
The colour of your links should be different than the colour of your text.
If possible - blue. 
That really ugly blue colour that just screams "this is a
clickable link, you should click this thing." or something that draws that kind of attention to it.

That brings me to my second point. The reason that blue links are easier
to use than red links or green links is because we expect that links are
blue. It's a convention that's been around since the dawn of the web. It's a pattern users are familiar with.

Be conventional. 

I know that, when you design things, there's a really strong desire to 
be unique, to be clever. 

It's hard to say 'don't be unique and clever' with a straight face - 
but I can at least say 'don't be too unique if you don't have to'.

[^^ Could be a good place to insert that quote - 'don't be original, just try to be good']

There's a wonderful design library out there, composed of every 
website and application that your users use every day.

[^^ This last bit is confusing - I'd remove it or extrapolate what you mean here]


When things look and act familiar, your users 
can become conversant with your software much more quickly. 

When you're using a mobile application and you pull the content down
to refresh? That's another convention, or 'design pattern' as it is sometimes put.

Let's take a look at the major search engines on the web and see what we can observe about them.

Give Bing a try. Look at how closely they modeled their
search interface on Google's. Now try a Yahoo search. Yep, it looks 
just like a Google search. Google has clearly hit on a really effective 
user interface for searching, and this convention has spread.

There are other conventions that users find really useful, like the back button.

Don't break the back button. 

This is a wide generalization, but so be it: most users don't read everything
on a page before they decide on what to click. Users who are looking for
something quickly scan the page and click the first thing that looks even 
vaguely like what they want. 

Part of the reason that this sort of behavior works for users is that the
cost of visiting the wrong page is so low - the 'back' button supports 
a quick exit from anywhere you might visit. 

And the 'back' button isn't unique to the browser. It's reached the point
where this ubiquitous button is appearing again and again in iOS applications.
Most Android devices have a 'back' button built right in.

And yet with all of this support for the 'Back' button, some tools break 
this functionality. 
Lots of banking applications and older Java applications
have serious trouble handling the back button. 
Single-page javascript applications have to be extra careful about this - 
a user could intend to leave a window that you've taken them to, only to
leave your application entirely. 

Modern client-side frameworks used to build single-page applications have implemented back-button support - 
look for a 'router' class - make sure you're paying attention to this crucial feature early, right from the beginning.

Designing with it in mind from the beginning? 

Oh, that reminds me of my next point:

Proofread & edit. 

You wouldn't think of this as a usability tip, but it absolutely is.

If your application has text in it - and most applications do - go over
that text with a fine-toothed comb. Make sure it's clear, and make sure
it's concise. 

Write what you want to say, and then as an exercise walk away from it for an hour or two, and when you come back, try and make your second draft shorter than the first. As mentioned earlier, often users don't read everything on a given page, and this is especially true when there is too much content. It can be overwhelming!

To get your message to your users, make your point as breif and concise as possible.

# commented out
#Keep your marketing, sales, and legal teams well away from any copy that 
#ends up in your software - you want simplicity and readability, not reams
#of self-congratulatory SEO horseshit.

It's as simple as going through your wording line-by-line and, for each
line, asking yourself: is this necessary? Could I make this clearer?
If you're just a soul whose intentions are good, you have to read your text
and ask: how could this be misunderstood?

Why does this button read 'submit'? 

Which takes me to my last point:

Sometimes you should discard conventions that don't work. 

For some reason, one of the most common bits of text you'll find on a button, 
is the word 'submit'.
'Submit' as in 'submit this to the server', not like 
'SUBMIT TO MY WILL, FOOLISH MORTALS'.
It's almost always a valid thing to put on a button -
'send this to the server' is often what you're doing, but it's just so 
general.

The thing is, though, a lot of times 'send this to the server' is just a 
step in the process. Stop for a second to think of the end result of
clicking on the 'submit' button. Will this create a user? Then the text
on the button should read 'create user' or 'create'. 
Will this send an email? 
Then the text on the button should read 'send email' or 'send.'

Okay, that's a wrap. Remember to like and subscribe, and thanks for watching!