WWDC2010 Session 100

Transcript

>> Gregory Hughes: Good morning.
My name is Gregory Hughes and I'm
a software engineer at Apple.
I'm really excited to be able to have the
opportunity to speak to you this morning,
and today you're going to learn how
to use universal design principles
to make your applications better and more accessible.
And I want to start off by explaining
what I mean by universal design.
And to illustrate universal design, I thought I
would use something we're all very familiar with,
and that's the kitchen stove.
I'm sure most of you use the kitchen
stove on a very regular basis
and most people accept the design of the kitchen stove.
However, it turns out that the design is actually quite
poor, specifically the row of knobs across the front
and the back of the stove that
are used to control the burners.
Each of these knobs requires a small icon or a localized
label to tell a user what burner that knob controls.
Now I know with this design I personally
have accidentally turned on the wrong burner
and this is a really, really common mistake.
And in the case of a stove, it can
actually be a very dangerous mistake.
Now, users make this mistake for a number of reasons.
Perhaps, they're in a hurry preparing dinner
for guests, maybe water is boiling over
or maybe the user just forgot their glasses in another room.
However, with this design, there are
also a number of accessibility concerns.
For someone with low vision, it can be
very difficult to read these labels.
For someone who is completely blind, it could be really
difficult to figure out which knob controls which burner.
And for someone with a cognitive impairment, it
can be very difficult to create the mental mapping
between this row of knobs and the matrix of burners.
So if we design the stove more universally, if we
think about the needs of all users including users
with disabilities, we can end up making a much better stove.
If we rearrange the knobs so that
they're in the same order as the burners,
the stove becomes much easier to use for everyone.
You no longer need to read a label.
You instantly know which knob controls which burner.
It's now also more accessible because someone with
low vision doesn't need to read a label and someone
who is blind is able to feel the knobs and
know exactly which burner that knob controls.
And equally, someone with a cognitive impairment will
have a much easier time making the mental mapping
between the arrangement of knobs
and the arrangement of burners.
In the case of the stove, an equally valid
design choice may be to rearrange the burners
so that they're in the same order as the knobs.
So we see here by applying some universal design
principles, by looking at the needs of all of our users,
we end up making a much more usable,
much better product for everyone
that everyone will have an easier time
using and will reduce user frustrations.
And so that's what I would like to talk to you today
about: How you can apply these universal design principles
to your software to make it better for everyone so that your
users experience less frustrations in using your software.
At the same time, you'll be making
your software more accessible.
And to talk about that today, I have three main focus areas.
First are the end users.
Now with all design, you want to start thinking
about the needs and requirements of your users.
Oftentimes universal design goes hand in hand with the term
user-centric design, and that's design focused on the users.
So, not only do you want to think about the users here
but you want to think about how and where and potentially
when they'll be using your software
and under what circumstances.
So then, I'd like to speak about some of the accessible
technologies that Apple has built into a number
of our products, and these help highlight how
accessible technologies also make products better.
These universal design features are making the operating
system and our portable products better for everyone.
And last, I want to talk about how you the developers
specifically can make enhancements to your applications
to make them better for everyone
and more universally designed.
So, let's start with the users.
And to get an idea of what we're talking about
here, I want to start off with some statistics.
In the U.S., 10 million people have a vision
impairment, 31 million people have hearing impairment,
and 12 million people have a learning disability.
And what that means is that 1 in 5
people in the U.S. has a disability.
That's 50 million people.
Let's stop and think about that for a minute, 50
million people have a disability in the U.S. alone.
By making yourself more universally designed
and more accessible, you're going to be able
to have a much easier time reaching
this huge percentage of the population.
At the same time, you can have an easier time
entering government and education markets,
which often require your software to be accessible.
So there's a huge potential audience here
especially world-- including worldwide.
So to look at this audience, there are
4 main areas we want to think about.
First are visual considerations, and these
are considerations pertaining to vision.
These are considerations for users that perhaps have
reduced visual acuity, users that are maybe color blind,
or users that are completely blind, and even users
that just don't have their glasses with them.
Then, we have auditory considerations and these are
considerations for users with hearing impairments.
Users who can't hear as well as the average
user or users who can only hear out of one ear.
This also includes users who are completely deaf.
And then we have physical considerations,
and these are considerations for users
that have a hard time physically
interacting with a computer.
These are users who have a difficult
time using the keyboard or mouse.
And then cognitive considerations,
and these are consideration
for how a user thinks when they're using your software.
This potentially includes users with
learning disabilities and other users
who just need an easier time using your software
who would benefit from a more simplified interface.
So we've now talked a little bit
about the users and let's look at some
of the technologies that Apple has to address these users.
First is a very common universal design feature that
you'll see a lot this week, and that's Fullscreen Zoom.
This is used a lot in presentations to highlight a
specific portion of the screen, but it's also indispensable
for a user with a vision impairment because they're
able to zoom in on various areas and enlarge the font.
There's a number of these large
font solutions across the OS.
In Address Book, you can make phone numbers large print.
This is great if you're sending a fax from across the
room but also wonderful for someone with lower vision.
In the Dock, the Icon Magnification helps
someone with low vision see the icons,
but it's also really aesthetically pleasing.
So we see how these features make the software more usable
and at the same time have the benefit
of making it more accessible.
We have closed captioning in iTunes, iPods, iPads,
iPhones and pretty much everywhere we have video.
This is obviously really important for someone who
is deaf, but it's also crucial if you're trying
to watch something while on the gym or in the airport
and you don't have the ability to wear headphones.
Or maybe you want to want a documentary in the
library and you can't listen to the sound there.
So, again another universal design feature that's helping
everyone but is also increasing the accessibility of video.
There's also-- we have talking iPods, and this originally
was designed for people who are completely blind
so they could interact with the iPod and listen to their
music, navigate through the menus, but it's also very usable
for someone who's driving a car perhaps and
they just want to scroll through their music
without diverting their visual attention.
And now this interface turned out to be so usable and so
successful it's the only interface on the new iPod shuffle.
So it's a great, great universal design feature that turned
out to be the only method of interaction in newer hardware.
And then we have VoiceOver, and VoiceOver
is Apple's screen reading solution.
And what this does is it converts all of the wonderful
graphical information on the screen into spoken information
so that someone who is blind can use a computer.
And VoiceOver now has been shipping for 5
years and it's installed on millions of Macs.
And this number is really important because the
VoiceOver now is installed on more computers than all
of the other screen reading solutions combined.
And that's really important because it shows what a huge
role Apple is playing in the assistive technology market
and how important it is for you as
well to make your software accessible.
VoiceOver now is also shipping on the
iPhone as of the iPhone 3GS and on the iPad,
along with a slew of other universal
design features that help all users,
and most of these you don't even think about.
For example, Pinch to Zoom in Safari.
We all use that but it's a great feature
for someone who is visually impaired.
And so if we think about some more of these features
that we can add, we end up making better software.
So with that, I'd like to look at
how we can make better software.
What you can do to your applications and how to look at your
applications to find these areas that could be improved.
So remember, we have these 4 groups:
visual, auditory, physical, and cognitive.
And when looking at these 4 groups, we
have 4 categories that we want to think of.
The first is perceivable.
Can the user perceive the information
you're trying to present?
Do they have the ability to get the information?
This is generally going to deal
with the output of your application.
Is your software operable?
Does the user have the ability to operate your software?
Can they provide the input that you're expecting?
Is it understandable?
Does the user understand what you're
trying to present to them?
Do they understand the UI?
And is it robust?
Can your software adapt to the very needs of users in the
varying situations where they might use your software?
And so, this ends up forming a nice grid and you
can actually use this as a report card to go through
and look at your software, and it helps you
to think about all these different areas
and we would love you to get A+
marks across this report card.
And if that's the case, you end up having much better,
much more well-designed software for all of your users.
And throughout this talk, I'm going to use a small sample
app to highlight some of these universal design features.
This is a portfolio watcher.
It just watches some stock, shows me how
they're doing and gives me my day's change,
and we'll see how we can improve
this through universal design.
So first let's look at these-- the visual
considerations, and generally these considerations fall
into the perceivable category because
we're dealing with vision.
Can a user perceive the output
that you're trying to present?
And to start, let's look at iTunes.
Now, iTunes has a wonderful high resolution interface and
in the iTunes Store, they're displaying a lot of content.
And you can resize the iTunes window
and resize even smaller.
And as it turns out, this is really important for
accessibility because a very common technique for someone
with low vision is to increase the screen resolution.
And so having your window be resizable, usable at all
resolutions, it makes your application much more accessible,
and at the same time it gives all users
the ability to control the window size
and it lets the user select what
window size works best for them.
So generally, we recommend that your
applications be usable down to at least 1024x768.
And the important distinction here is
that it's usable at that low resolution.
We really want you to develop beautiful high resolution
interfaces to take advantage of our large displays,
but you always want to keep in mind that
some users are using these lower resolutions,
so you want all of your features to
be accessible at these resolutions.
This is also going to help when presenting your software.
You never know when you're going to connect to a
projector that's 800x600 and you don't want to be caught
in a situation where you're giving an important presentation
only to have half of your features inaccessible.
And that's going to help pretty much anyone who is reducing
their resolution to help release-- relieve eye strain.
I know a lot of travelers do this
often when working on an airplane.
It's really, really simple to do right at Interface Builder.
You just want to set the minimum size of your window
to the absolute minimum size usable
and then check your application.
And sometimes this might involve adding some scroll areas
here or there, but in general it's really, really easy.
So next, I want to look at Mail.
And here's a screenshot of Mail and I'm sure it's very
difficult to see especially if you're sitting in the back.
And if I blur it a little bit, it helps us to simulate what
it might look like to someone with a vision impairment,
and now it becomes absolutely impossible to read.
Now, Mail has a wonderful feature that's
used by everyone and it makes Mail better.
You can adjust all of the font sizes in Mail.
And now this is great for any user or someone who's
presenting Mail and showing off the interface,
and you can make that even bigger, which
is wonderful for someone with low vision.
And so this is a really, really important
feature that makes the software much more robust.
And you'll see this across a number of Apple applications.
In the System Preferences, you can often
change the font from the Key Content area.
Sorry, in the Application Preferences.
And the Key Content area is the important distinction here.
You want to look at your application and figure
out where users spends most of their time visually,
and concentrate your attention on trying to make the
fonts in that area larger or at least user sizeable.
So in an application like Safari, the
Key Content area is easy to determine,
it's the large web area, but sometimes
it's a bit more difficult.
So this obviously is going to help users with low vision.
It's going to help elderly users, users who
don't have their glasses with them, and again,
it's going to help you if you're ever
presenting your software so that users,
so that people in the audience are able
to see what you're presenting to them.
It's really, really simple to do.
What I recommend is creating one
bottleneck in your application.
And at this point I do want to mention that all of
the source code I'll be presenting here is available
on the WWDC web site so you don't need
to worry about copying any of it down.
So if you create a single point in your application,
you can always ask that method for
the current user to find font size.
And here is just a quick example, I'm asking System--
or asking my Application Preferences for the font size, then
bounds checking it and returning the user desired font size.
To use it is easy.
I'm going to ask NSFont for a system font of that
size and I'll get back a valid NSFont that matches all
of my other system fonts, and then I can just apply
that to any NSTextField really, really easily.
Now, the other very common area
for adjusting fonts is in tables,
and tables are slightly more involved
but still not that difficult at all.
For a table, remember we have columns
and so we need to iterate
through the columns and set the font for each data cell.
So we go through that here.
Going through the columns we grab the data
cell and then set the font for the data cell.
And then the only slightly tricky part is now that we're
increasing the font, we need to change the row height.
So in order to do that, we can ask
NSLayoutManager for the line height for our font
and then set the row height appropriately.
So as you can see a bit more involved, but still
really, really simple and not much work at all
to make the fonts in your application resizeable.
Next, I want to look at another interface
that probably looks very common to you.
So let's just demonstrate-- this interface is
showing two stocks and showing their day's change.
However, for a user who is color blind, this
interface doesn't convey any information.
I don't know if the stock is going up or going down.
So the important thing here to keep in mind is
never to use color alone to convey information.
So using color is just fine and it's a really,
really nice way to quickly convey information.
Just don't use color alone.
And oftentimes this is simple to solve.
In this case, if we add a plus and a minus
sign, it now will tell a user who is color blind
which stock is going up and which is going down.
So the difference is very, very small here but it
can make a world of difference to a lot of users
who are using your software, and it's also going
to make your software easier for everyone to use
because it's now going to be quicker
to glance at because we have color.
And if you're looking at it more closely,
you have the plus and the minus sign.
So all of that is really good for our low vision
users, but what about users who can't see anything?
How are they going to access this visual information?
And as we saw with the case of color, we don't
want to convey information with color alone.
As it turns out, we don't want to
convey information through vision alone.
We want to be able to provide a
spoken interface to every application.
And on that front, all of the hard work is actually
already done, and that's done through VoiceOver.
Remember, VoiceOver is the screen reader which is going to
convert all the visual information into spoken information.
But sometimes it requires a bit of work on
your part to make your application more usable
with VoiceOver, and that's really easy to do as well.
In Interface Builder, you can set the
Accessibility Description, Help Tag, Title Element
and Linked Element without ever leaving IB.
So it's really, really simple to do this for
any of your controls that you have right in IB.
As well, there's a programmatic way to do this.
You can use the convenience method set accessibility
override, and here you can set the override for any
of your standard controls for its Accessibility
Description, Help Tag, Title, or Linked Element.
Now, if you have a control that is your own custom view,
you will need to do a bit more work for accessibility,
and there's some great past talks on that.
I encourage you to look at the WWDC 2009
talks, and they go into great depth on how
to make your custom views more
accessible and usable by VoiceOver.
But for today, let's just look at the standard cases.
So, with that, I'd like to show you here how we can
apply some of these techniques to our sample application.
So, here we have Xcode.
If I run my app here, it's the sample app that I
showed you in the slides and we can look at this window
and I can't resize it much more than this, which
can be frustrating for any user who just wants
to make the window small and push
it to the side of the screen.
So let's go into IB and fix that.
So here we have our window.
If we bring up the inspector for the window size-- but
here it's already set to a minimum size of 900 and I know
that my application can be resized all the way down to 450.
So really, really simple to change,
we switch and look at that now.
I can resize the window quite a bit smaller.
So a small change has a significant impact for the
accessibility and usability of your application.
Next, let's take a look at fonts.
So here, if I look at my Preference window,
I see that someone has already left me
a convenient place for a font slider.
So if we bring up the library here and add a slider,
you see that the designer has also already decided
that we want a font size between 8 and 40, and this range
will probably be dependent on your application but 8
and 40 is probably a pretty decent range to be considering.
And I want to make sure that my bounds of the slider
are the same so I'm going to set those to 8 and 40.
And I also want it to update continuously.
And now for my slider, I'm going to bind it to my delegate
and I'm going to bind it to the font size property.
So if we save that, we can now go into Xcode and look
at the methods that we need to control the font size.
So let's bring up the delegate, and I'm
sure if you have ever worked with bindings,
you know the first thing you'd really want to do is make
sure you add your getter and setter for the property.
So let's add those now.
Here we have first a very simple setter.
We're going to take in a value, and first because
we never want to be dealing with fractions
of a point, we're going to round the value.
Then store in Preferences, Synchronize Preferences,
and update the fonts for my application.
The getter is equally simple.
I load the value from Preferences then
bounds check it against my lower bounds.
You may also want to check your upper bounds and then again
return a rounded value because I want to just doubly check
that I'm never dealing with fractions of a point.
So now we need to get a system font, an NSFont of that size.
So that as well is really easy.
We're going to get the font size that the user
wanted and ask for a system font of that size.
And now we have our method here which
is going to do the updating for tables.
Remember, we're going to iterate over the columns,
apply the font to each data cell and
then lastly update the row height.
So a bit more involved for tables
but still really, really easily.
And now the last thing we need is
the actual method to do the work.
And if we add this method here, we see for our
three text labels, we're going to set the new font
and then for our two tables, we're
going to set the font of those tables.
And now to make sure I always have
the current user preference,
I want to make sure to call updateFonts
in my awakeFromNib method.
So at the end of awakeFromNib, I'm going to
call update fonts and let's run the application.
So now if I bring up our Preferences here, I have this font
slider and I can adjust all of the fonts of my application.
And you'll see here we have a slight problem.
Our two labels are being cut off.
And let's go and fix that.
[ Pause ]
So in our updateFonts method, we
just need to also update the layout
of our UI, so I'm going to call self updateLayout.
And now that's going to call a
method that I've already written.
The method is a bit long but the
logic is really, really simple.
It's all just basic math, laying out the controls
appropriately within my view, and when possible,
letting Interface Builder take advantage of all
the springs and structs that I've already defined.
So let's take another quick look.
So now when I adjust my font, all of my
controls layout and resize appropriately,
and I think that's probably a good font size.
If I'm demoing my software, now it's
much easier for everyone to read.
So next I spoke about VoiceOver and how we want to
make sure our application has this audible output.
Now, there're some really great tutorials on
how to use VoiceOver built right into the Mac.
When you turn on VoiceOver, you'll have the
opportunity to learn how to use VoiceOver.
But for today, I just want to let you listen to what a
VoiceOver user might hear when navigating our application.
>> Unknown: VoiceOver on portfolio watcher
window, portfolio watcher edit text, add a symbol.
>> Gregory Hughes: So here we hear add a symbol,
and if I go through the UI we'll hear each element.
>> Unknown: Edit text, blank button.
>> Gregory Hughes: So here we see one
problem, VoiceOver just says button.
VoiceOver doesn't have enough information
to tell the user what this button does.
And so we'll have to go in and
add a description for that button.
Let's continue along.
>> Unknown: Table one row selected, symbol AAPL, name Apple.
>> Gregory Hughes: So it works fine for the
table and you'll find that it works fine
for any standard Cocoa control,
especially the text controls.
It's generally your custom controls or any graphical
elements that you'll need to do a little bit of work for.
>> Unknown: Days change zero dollars
and 82 cents, zero button.
>> Gregory Hughes: And so again we have this other button.
And those aren't accessible because they
have images and we're just going to need
to provide a quick description for those buttons.
Let's do that now.
>> Unknown: VoiceOver off.
>> Gregory Hughes: If we're going to Interface Builder,
I can have the description for one button right here.
Right here under accessibility description,
I'm going to call this the Fullscreen button.
And just to show how to do it, I'll
label the other button programmatically.
So if we switch back to Xcode and I have a small
two line method here to update the other button,
we see we're going to grab a localized string
because just like our UI it needs to be localized.
Our strings for VoiceOver need to be localized, and I'll
set that string as the description for the button cell.
I also need to make sure to call this method when I
awakeFromNib just like I wanted to update my fonts.
So at the end of my awakeFromNib I'm going to call self
updateAccessibility and let's take a quick look at that.
>> Unknown: VoiceOver on portfolio
watcher window, portfo-- add stock button.
>> Gregory Hughes: So here we now
have a description for this button.
>> Unknown: Take date fullscreen button.
>> Gregory Hughes: And a description for our other button.
So you can see adding this basic accessibility
really doesn't take that long at all.
It just involves going through your application, finding
the areas that need a little bit of work and updating them
so that VoiceOver has something
to speak for all of your controls.
>> Unknown: VoiceOver off.
>> Gregory Hughes: So next I want to talk about audio
considerations, and again these are considerations for users
with hearing impairments, users who are perhaps
using mono audio or users who are completely deaf.
And to start out, I want to show a quick video.
[ Pause ]
Now, I'm willing to bet you can't get a whole lot of
information from this video because the only means
of output is audio and I muted the video.
So you can see how difficult it would be
for someone who's working in a library
or someone who's deaf to access that video.
Let's take another look at it.
[ Pause]
And now actually, this demonstration worked out pretty
well because there was actually supposed to be audio
with that second video, and it shows how important it is to
make sure that everything you're presenting is accessible.
You were still able to get the information
out of that video by reading the subtitles.
So the important part of audio is to make sure that
you're never presenting information using audio alone,
that you always have some other method of
conveying that same piece of information.
You also want to be aware that
some users are using mono audio,
that they don't have the ability
to hear the two stereo channels.
And also some users have sensitivity or
can't hear higher or lower frequencies,
so you may want to consider having
assignable user sounds in your preferences.
This is going to be up to your application and, you know,
how much flexibility you have with
what sounds are being played.
So if we want to make sure that we always have this
visual counterpart to our audio, how do you do it?
Well, one very convenient and easy way is to use NSBeep.
Now with NSBeep, there's a systemwide preference
that someone who's hard of hearing can set so that
when NSBeep is called, the screen will flash.
It looks a bit like this.
So, whenever you're going to use something where there's
going to be sound, if you want to play the system sound
but also provide that visual feedback, always use NSBeep
because it's going to give you that accessibility for free
for those users who have the need for the screen flash.
But there are a lot of other ways that you can display
visual information to go along with your sounds.
One of the really great ways is to use your Dock Icon.
For example, I've been demonstrating
the stock watching application.
If my application, if my stock portfolio dropped
a huge percent in a small amount of time,
I might play a sound to warn the user, or
I could also change my Dock Icon to be red,
and it provides that visual feedback
that goes along with the sound.
Equally, I may change the Icon to green
if the portfolio is doing well, again,
providing visual feedback to go along with the sound.
And so we see here the importance of providing these
multiple methods of information output to a user and it ends
up making the application much more
usable for everyone, much nicer to use
and it helps convey all the information
you want to convey in an easy manner.
So, changing your Dock Icon is really, really simple.
In two lines of code given the PNG, you can set your
Dock Icon to pretty much whatever you would like.
But there's a lot more that can be done with the Dock Icon.
You can badge your Icon, and this is a
really convenient way and very common way
of conveying visual-- conveying new information.
For example when you get a new mail message, you hear the
new mail message sound but it's combined with the updating
of your unread message count in the Dock.
So it's that visual and audible component to the
information that mail is trying to present to you.
And you can also bounce your Dock Icon, and
this is a great way to visually tell a user
that your application wants attention
while it's in the background.
Maybe this goes along with an error
sound or some other method
of informing the user that you want-- you want attention.
So, I'd like to quickly show you now how
we can apply some of those techniques
and making our application more accessible
to users who are hard of hearing.
[ Pause ]
So here, if I go to my non-audible feedback section,
first, I'm going to add a method that calls NSBeep.
You can see how simple it is.
We'll just take a look at what that
looks and sounds like on a real system.
Next, we have how to change the Dock Icon and this
method looks a bit long but it's really, really simple.
All I'm doing is a bit of string coercion here.
My method takes in a number between negative 1 and positive
1 and then displays an icon that varies from red to blue
to green to represent the status of my portfolio.
So here, I take in the number.
I then find the appropriate image name for that number
and then these two lines here do all the
actual work of setting on your Dock Icon.
So, really, really simple here to change your Dock Icon.
Obviously now, I want to call this method from somewhere.
In my application, I have a timer
going to update my portfolio.
So, let me call that from my refresh method.
At the end of this method here, I'll call self
setDockIcon and I'll set to change percent sometimes 5.
So, in dealing with nonaudible feedback, you also want to
think about your application and what you might be able
to do to make your audible feedback
have some visual component to it,
and this could be different for every application.
This could be some animation that you provide
to go along with your audible feedback.
And just as a quick example of an animation that I chose,
here I have a message that's going
to flash my window different colors.
And so, I'm going to cycle through a few
colors and flash the window that color.
And so, just as playing sounds can sometimes be annoying,
some of these animations could be annoying to a lot
of your users and in that case, you want to make sure to
put them behind User Preferences, and that will allow a user
who needs this option to enable it where appropriate.
And the last one I want to show was bouncing a Dock Icon.
And because my application used to be in
the background to bounce my Dock Icon,
I'm going to call this on a delayed performSelector,
and then there's just one line to bounce my Dock Icon.
So, let's take a look at this now.
So we see here, first my Dock Icon is
green because my portfolio is positive.
If I now bring up the Preferences, we can
see what NSBeep looks and sounds like.
So, a great way to provide that visual feedback
automatically and it lets the user select
which sound they would like to hear,
which sound works best for them.
It can also bounce the Dock Icon, so a
great way of telling the user visually
that your application would like attention.
And lastly, just a quick very, very rough
animation, I can flash my window different colors.
And this might just tell the user different
statuses or different things have changed.
So there we have it, some very, very
simple changes that you can make
that will greatly help users with hearing impairments.
So now, let's talk about users with physical
impairments, the physical considerations
that we need to think about with our software.
These generally fall into the operable category.
Can a user operate your software?
Can they provide you with the input that you expect?
And when thinking about this category, we
want to look at the keyboard and the mouse.
These are generally the two primary
methods of providing input on Mac OS X.
And we want to think about users who perhaps
don't have the keyboard or can't use the keyboard,
or maybe users that don't have the
fine motor ability to use the mouse.
Meekly, we want to consider users that don't have either one
and are potentially using speech
input to control your applications.
As it turns out, there's a lot of permutations here
of the various input methods that could be used,
but they're all very simple to address. And you can address
them by providing full keyboard access to your application.
This is really simple to test.
Just try to use your application without using the mouse.
Try to make sure that you can use all the features
and all the functionality with just the keyboard.
That you can navigate to every single
control and use every single control.
Some of the tactics here to do this are to
provide keyboard shortcuts for the menu items
so that you can quickly activate
various options in your app.
So here, this is a great case where this universal design
feature is going to strongly or greatly help your super--
or your power users who want quick keyboard access to
the very commonly used features and at the same time,
you're going to be helping users with physical disabilities.
Now, two of the common areas that I've often
seen where full keyboard access is difficult are
in reordering lists and doing dragging and dropping.
Now, reordering lists is common-- are commonly done
by dragging one row and dropping it in a new position,
so somewhat difficult to do with the keyboard.
It turns out the solution is quite simple.
If you just add a moveUp and a moveDown command to your
Edit menu, you now allow a user to use their keyboard
to reorder any list that you have in your application.
And equally here, you'll see I've also bound this to
a keystroke, so the menu item has a keyboard shortcut
which is also going to help my power users.
Now, for dragging and dropping, for
example, an application that requires that--
where a user is going to move a photo from one album-- photo
album to another, instead of dragging it from that album
and dropping it in a different album, I could simply
cut it from one album and paste it in another.
So, by fully implementing cut, copy and paste,
we help get around the keyboard navigation
problems of drag and drop interfaces.
So, this is really, really easy to do and
it's implementing NSPasteboard protocol
and there's some great documentation online
on how to do this for your application.
So, I also said you want to be able to make sure that
you can get to all of the controls in your application
that you can Tab through your application.
And when doing this, you want to make sure to enable
full keyboard access, and what this is is a feature
in the operating system to allow a user to navigate
the entire operating system using the keyboard alone.
And in keyboard-- in system preferences under
keyboard preferences, you'll see here at the bottom,
there's a small checkbox to enable
full keyboard access to all controls.
You want to try this on when testing your application
to make sure that you can Tab to everything.
So, let's take a look at that now.
So, first let's take a look at reordering lists.
I'm going to go into Interface Builder.
I've already implemented the drag and
drop portion of reordering my list
and now, I need to add the keyboard access to it.
So, I'm going to bring up my Edit menu here
and add two items, moveUp and moveDown--
[ Pause ]
-- and also provide them with keyboard shortcuts.
Now, I've already written the prototypes for
these methods so I can go ahead and bind them.
And now, let's look at the work
that needs to be done in Xcode.
So, I've already written all of the methods, as I said,
for the actual dragging and dropping implementation
and the key here is that it's already architected well.
Here's my method that's dealing with the actual drop.
I mutate the numbers a bit to get
them in the format I expect
and then call my one method that does all of the work.
The method is called Moves Dock at Index to Index.
So, this is the method that's actually
going to do the work of reordering the rows.
And given this architecture, adding a moveUp
and moveDown command is really, really simple.
So we see here, moveUp is two lines.
We get the currently selected index in the table and then
we move that index to the currently selected index minus 1.
MoveDown is just as simple, we're just going to add 1.
So here, we see with 4 lines of code, we're going
to have greatly increased the keyboard
navigation of our application.
So, if I now Tab to my table, I can Arrow to my
table and then with Command and the Arrow keys,
I can move one of these stocks up or down in my list.
So you see, this is going to be great for yours-- your power
users who want to get it on to your application quickly,
but it's also going to be the way that users with physical
disabilities are going to be interacting with your software,
and so you want to make sure it's
all usable with just the keyboard.
And so now, we want to look at Tab navigation.
We want to make sure we can get to all of the
controls, and so the first thing here as I said,
we want to go to System Preferences and
make sure turn on full keyboard access.
So, we're going to turn on all controls here.
And now, I'm going to Tab through my application
and just make sure I can get to everything.
So, at the Add a Symbol field, I move
to Add a Stock button to the table
and then to this Fullscreen button at the bottom.
So, I can get to everything just fine here.
If I open up the Preferences, I'm starting
here at the Tab control at the top.
Pressing Tab moves me to the font slider,
and Tab again moves me to the negative color
and then backwards to the positive color.
And so, something is wrong there with the automatic
Tab ordering that was created by the operating system.
So, you always want to check your application,
make sure the Tab ordering is correct.
As it turns out actually, in this case, I had to play some
really evil tricks to get the Tab ordering to be incorrect.
So almost always, it will be fine.
But let me show you how you would
fix it if it were incorrect.
If I go into Interface Builder here and I look at my
Preferences window, what I want to do is first start
at the window, and I'm going to set the initial
key to this initialFirstResponder to my Tab control
and then for the Tab control, I want to set
the initial first responder to the slider.
From there, the slider's next key
view will be the positive color.
And from the positive color, the next
key view will be the negative color.
From the negative color, you want to make sure to make a
full loop, so we're going to go back up to the Tab control
and set the next key view to the Tab control.
So, let's take a quick look now.
So if I press Tab, I move from the
button at the top to the slider--
oh, and I didn't do something right,
so let's take another look here.
So from the slider, we want to go to the positive color.
Positive color to the negative color and
then negative color back up to the top.
So, if I press Tab from the button
at the top, I go to the slider,
then the positive color then to negative color and back up.
So really, really simple to test, really simple to fix
and it greatly improves the usability of your application,
again for those power users who want to get around quickly
and for users who don't have the ability to use the mouse.
As well as I said, this is going
to solve all of your input issues.
For users who are using speech input, they're going to now
be able to use Apple scripts to control your application
because it's fully navigable with the keyboard.
So, we solved a lot of problems
with a very small amount of work.
So, next are cognitive considerations,
and these are considerations
for how user thinks when they're using your software.
These are considerations for users
that perhaps have disabilities
like learning disabilities or maybe
even just the type of user.
For example, a student is probably going
to use your software in a different way
than a teacher is going to use your software.
And so, to look at cognitive considerations,
I want to look at iPhoto.
Now, iPhoto has a great interface and it's a
very, very powerful photo management application.
And it also allows me to edit my photos.
Now this interface can actually be a bit confusing
and overwhelming to some users because all you want
to do is just browse and look at your photos.
And iPhoto has done a great job solving this.
To do it, iPhoto has implemented Fullscreen mode and
in Fullscreen view, you can go through your album,
look at all of your photos and
eliminate all of the distractions.
Now, while in this mode, you can
also get to a lot of the UI.
You can get to the photo chooser by going up
to the top or the edit controls at the bottom.
So, this is really important because iPhoto is presenting
only the controls that the user needs when they need them.
So, it's eliminating distractions
and also hiding unnecessary UI
when it doesn't-- the user doesn't need the UI.
As it turns out here, entering this
Fullscreen mode is super, super easy.
You can do it with one line of code.
Given an NSView, you just say enterFullScreen
mode, provide it a screen
and there are few options that you can pass in as well.
So, really, really easy to implement this, a very,
very powerful way of making your application easier,
simpler to use for everyone, but also more
accessible to those users with cognitive impairments.
Now, I said iPhoto is hiding some UI and
hiding UI is really, really important here.
We want to make sure not to overwhelm a user with UI, so
you want to think about what options are more advanced,
what options are less used and see if you
can come up with ways to hide those options.
A great tactic is to use a contextual menu.
So perhaps you have a lot of buttons and 50 percent
of those are used by 2 percent of your users.
Consider putting those options in a contextual menu instead.
Another great way of hiding more complicated
or less used UI is to use menu alternates.
What this is, it's something we've probably all seen.
When you open up any menu in OS
X, you can press the Option key
and it will display different menu
items if they're provided.
For example here in the Apple menu, if I press
the Option key, a few of the items change.
Now, that was actually pretty difficult to notice
in the slide, but if we look at the two menus,
we see that about this Mac change the system profiler.
The system profiler is something that most users
never ever need but we still provide that option.
So, the important thing here is that you don't really want
to take away features from the user but at the same time,
you want to balance that with making your UI simple,
making all of the features used by 90 percent
of the users available all the time
and maybe hiding those other features
that are used by only 10 percent of your users.
So the-- to add a menu alternate,
you simply add a new menu item
and in Interface Builder say this is an alternate menu item.
What that means is that that menu item will replace
the previous menu item when a user presses the option,
so really, really simple to do and very powerful
nice way of hiding more advanced or less used UI.
So, let's take a look now at how to
do Fullscreen mode in our application.
So, if we switch over here to the application,
I have a place for the Fullscreen method.
[ Pause ]
So we see again very, very simple method.
I already have the button in the UI.
The buttons are already wired up,
so let's take a look at it.
So we see here now, we've able to enter Fullscreen mode
really, really easily, eliminated all distractions for user.
But the same time here now, we see how a
lot of our work today has come together.
We're now able to make the font sizes larger.
We're using color and the plus and the minus sign
to convey information quickly and to all users.
And we've generally made our software more
usable, more robust, and easier for everyone.
We've just made the software better
because there are more options to the user.
Someone now could set this on a second monitor
and just watch their portfolio all day long rather
than having to search through windows to look at it.
So, you're going to make your applications much better
and much more liked by our users because you're going
to eliminate some of those frustrations that
users often run into when using your application.
So, in summary today, we've talked about 4 groups.
We've talked about visual considerations,
auditory considerations,
physical considerations, and cognitive considerations.
For visual considerations, remember,
we want to keep in mind the resolution.
We want our application to be usable at lower resolutions.
Whee possible-- we want the font size of the key
content area to be adjustable by the end user.
We're going to make sure we keep in mind
colors that are used in our application,
never use color alone to convey information.
And lastly, we want to make sure that the
application is accessible to VoiceOver
by implementing the NSAccessibility protocol
on any custom classes and providing information
in Interface Builder for any standard Cocoa controls.
For auditory considerations, you want to make sure to
always provide information through multiple channels.
Never provide information through audio alone.
Always be aware that some users are using mono
audio, and you also want to make sure that any videos
that you're presenting have closed captions.
For physical considerations, you want to consider
users that aren't using the keyboard and mouse.
And to do this, you want to make sure that your
application is fully navigable using the keyboard alone.
Some tricks here are to use many
alternates and always make--
sorry, many shortcuts, and always make sure that
any mouse actions have a keyboard alternate.
Lastly, we have cognitive considerations.
These are considerations again how a user
is going to think when using your software.
You want to make your UI as simple as possible.
And to do this, you can use things like Fullscreen mode.
You want to also consider hiding more advanced to less used
UI by either contextual menus or making menu alternates.
So, if you have more questions, there's a ton of information
available regarding both accessibility and universal design.
I strongly recommend that you join
the Accessibility Mailing List.
It's a very well trafficked and friendly
mailing list for any of your questions.
There's also great documentation in which
you can get to via the WWDC website.
And Apple also has a really wonderful accessibility
web page which talks about accessibility
and accessible interfaces in all of our products.
It also provides you with links to
any documentation that you may need.
We also had some related sessions this week.
There's a session on iPhone accessibility
tomorrow afternoon and we have two labs.
Now, both of these labs are the ones
that says OS X and ones for the iPhone.
The entire team of engineers that work on
accessibility will be at both of these labs.
So, if you have any questions, whether they're iPhone or OS
X, please come to the labs and talk to any one of us.
We'll all be there.
And I'd like to thank you very
much for your time this morning.
It's been a pleasure talking to you.