iOS VoiceOver Getting Started Guide

The iPhone and iPad have some of the best accessibility tools built directly into a mobile operating system. The VoiceOver and accessibility tools allow you to use the iPhone without looking at the screen. This has obvious benefits for people who have no vision or low vision but it also has a benefits for people who do have their vision.

I happen to have my vision but I still frequently use VoiceOver features.  I’ll skim emails in bed, read tweets, check Facebook and listen to music and audio-books. I can do this lying down comfortably in a pitch black room. The lack of light helps your body go to sleep and not having to hover your phone over your head is much more comfortable. I’ve also used VoiceOver to keep my eyes on the road while driving or walking down the street. I’m able to use my phone instead of staring at it.

Getting Setup

Most of these settings can be accessed via:  Settings, General, Accessibility.

As part of my basic setup I have set the tripple tap home button setting to turn VoiceOver on and off. This allows you to turn on VoiceOver when you want to use it and quickly turn it off as well.

The Basics

The operatin of the iPhone when in VoiceOver mode takes some getting used to. The basic gesture are mostly one-finger gestures and allow you to use most of the features of the phone.

  • One finger scan – sweep your finger across the screen. As you touch different areas the iPhone will speak the label. The home screen is a good screen to try this out.
  • Double tap – once a label has been read double tapping anywhere on the screen will activate the last item read.  This is nice because you don’t have to tap in the exact same spot. If you heard the label “Email” and that’s what you want you can double tap anywhere on screen to open up email.
  • One finger scan, second finger tap – sweep your finger across the home screen. When you hear the item you want tap the screen with a second finger, keeping the first finger on the screen. This is more efficient then the double tap and allows you to navigate and input text much faster.
  • One finger swipe left & right. Once an item is selected a one finger swipe left or right will select the previous or next item in the respective list
  • One finger swipe up & down. In lists of items, such as email, a swipe up or down allows you to select a secondary action. For example when you select an email message from your inbox default action is to “open” the message. If you flick up the system will read off the secondary action “delete.”  In certain apps like Safari the flick up and down gesture can be customized using the “Rotor.” More on this in the pro section.

These basic give you enough to open apps, navigate lists and take a number of actions. There are many more gestures that are possible and most of these involve multiple fingers.

Intermediate Gestures

  • Two fingers swipe up. Start reading the current list/table from the top. The system will read the entire page/email/list from the top.
  • Two fingers swipe down. Start reading the current list/table from the current location down the page.
  • Three finger swipe up. Scroll down one page. Usually done when reading a long list.
  • Three finger swipe down. Scroll up one page. If you are already at the top of a page this will refresh the content
  • Three finger swipe left/right. Scroll to the next/previous page. This is most useful on the home screen.
  • Two finger double tap. Pause and Play your current music track.

Advanced Gestures

The advanced features allow you to take even more advantage of the system, allowing you to perform more complex interactions and dealing with applications that have poor VoiceOver support.

  • One finger double tap & hold. Allows you to access drag features primarily on the home screen.
  • Two finger tripple tap. Opens up an item chooser dialog that lists out all the items on the screen. Useful for finding something on a long page or when the controls are small.
  • Two finger double tap & hold. Allows you to add a custom label to buttons that have poor accessibility labels. Hold until you hear three beeps, a dialog will pop up allowing you to enter a custom label.
  • Two finger “Z” gesture. When you’re in a navigation controller that has a back button you can often draw the letter Z with two fingers and it will navigate you back.
  • Two finger rotation. This is also called the Rotor, this tools allows you to setup how the speech will read through content. It’s most useful for jumping around in a longer piece of web-content. Once you select a rotor setting the system will read headings, words or characters based on the setting.
  • Three finger tripple-tap. This turns on/off screen curtain. This will dim the screen so you can’t see it. If you’ve figured out the gestures you can use this to use your iPhone in total darkness.
  • Three finger double-tap. This turns on/off speech.
  • One finger tripple-tap. Brings up a context menu on an item if one is available. For example the copy/paste menu in calculator.

 

15Five review

I hate meetings, and you should too. Meetings are good for making decisions and for having conversations between 3-5 people. Meetings are really bad at communication between more then five people. Email is equally bad for communicating between more then five people.

When the company was a small it was fairly efficient to have meetings 2-3 times a week to update everyone on status, information and progress. Everyone goes around and says what they are working on. Quick & Easy. This worked well but started to break down as we had more then a dozen people. There were different teams, projects and interest levels, the meetings started to be high noise to signal. Further when you have over a dozen people no one wants to stick out and say they have a problem or a concern.

I was excited to Alpha test 15Five, a new service launched by my college friend David Hassell. The idea is that managers could get the information they need in just 15 minutes and that employees could supply that information in just 5 minutes. At the time we were having three half hour meetings a week with 15 people. This was about 22 hours of meetings time per week.  On paper this looked like it could save us a ton of time, provided that managers were getting the same information and employees didn’t feel out of the loop.

Overal I would say the tool has been a success. The biggest barrier was the resistance to using any tool at all. Having a meetings was very informal, having to write status was less so.  This was good and bad.

Pros:

  • Everyone has a voice. Even people who normally stay quiet in meetings will express their feelings, success and goals in writing.
  • Managers can have visibility across the organization.
  • You can easily spot problems before they happen.  In the month of initial evaluation we discovered a number of issues weeks before they would have surfaced otherwise.

Cons:

  • Resistance to process / documentation
  • Filling out a weekly status is not “fun” it feels like work
  • Consumption and creation tends not to more then the prescribed 15/5.  I’d say that double these estimates is typical but overal it’s still a savings if done well.

The tools costs about $60/employee/year. This isn’t a major con but certainly something to consider. If you can save each employee an hour or two per year on meetings and discover a problem early it’ll justify the cost. If it helps run the business then it’s a no brainer.

 

Notification center redesign

The notification center in the new Mac OSX Mountain Lion is a nice step toward notification unification but in my mind it’s a long way off from where it needs to be. The problem with the new notification center is that it’s an isolated design. It hasn’t taken into consideration how to eliminate a lot of the cruft that has accumulated in OSX.

The Mac Shell/Chrome should provide a unified view of launching, viewing and managing applications.

 

Orientation
The notification center doesn’t feel like it should be along the right hand edge of the screen, it feels like it should be on the left hand edge.  The notification center is most closely associated with the dashboard concept. Docking notification to the right makes sense if you’re a third party app like growl and have no choice but the OS can break this limitation and put itself in prime position.

Apple Menu
 The Apple meny is fairly useless for a beginner and replacing it with something like the notification center is a much better use of screen space. The key actions from this menu are preserved. More obscure menu items are duplicated in other parts of the system.

I experimented with adding menu items near the Apple Menu but on deeper consideration I felt it wasn’t necessary. System Information can be launched and has all the same “About this Mac” info. The App Store has it’s own icon in the dock. The finder has its own Recent menu. Advanced users could be satisfied with an advanced ⌘+Click combo to reveal the original meny style..

Siri & Search & Spotlight

While the long-term path is likely to introduce Siri into the OS, the first step of that should be dictation/search. The spotlight system could use a visual overhaul and integration into the side-bar made a lot of sense. Similar to the notification center it seemed like searching was a launching action and could live within the notification area along the left. Typing a search would replace the notifications with search results.

It should be noted that on iOS a similar unification unification should be done. The search on iOS is hidden to the left of the 1st screen while the notification area is hidden above the screen, Siri is hidden below all screens. Rather then using all the edges we can simplify the model entirely.

Widgets

The OS still has widgets? Yes and they are done fairly poorly. Widgets should be  light weight and allow you to get key information and then get out of the way. Items like stocks & weather, are arguably persistent notifications and hence could live in the notification center.

The full widgets screen could also be tied into the notification metaphor using gestures. Pull to the right a little and the notification center. Pull a little further and the whole widget screen slides in. Things like twitter would be a notification widget, not something special.

Logout / Shutdown

Yep, just matching the visual style of the login screen. Hold down option and your shutdown item becomes a “Restart.” I’ve never intentionally restarted, usually it’s an install/update that forces the issue but I’m sure someone wants it.

 

 

BlackBerry SDK’s

Despite the decline in BlackBerry popularity it still has a lot of existing customers. So we wanted to demo some functionality for our AppBlade product, since it’s multi-platform.

Ok. Well Let’s write a little app.  We just need an SDK.  Shouldn’t be a big deal. I’ll just download the SDK…

  • BlackBerry Java SDK v7.1
  • BlackBerry Java SDK v6.0
  • C++ Native SDK 2.1 Beta
  • C++ Native SDK 2.0.1
  • C++ Cascades BlackBerry 10.0.0.4 Beta
  • BlackBerry WebWorks HTML5 SDK 1.0.0.15
  • BlackBerry PlayBook SDK for Adobe Air
  • BlackBerry 10 SDK for Adobe Air
  • Command Line Tools for Android Apps

With so many choices it’s a wonder that developers aren’t flocking to this platform.

Smarter Keyboards

The argument used to be that you could never change the QWERTY keyboard design because so many people had learned it. In addition the hardware change was too expensive.  It seems that this is changing. With modern cell phones using adaptive full screen interfaces the market is ripe for keyboard innovation.

While things like the Dvorak layout aren’t yet making their way to your iPhone there are a number of interesting keyboard designs and technologies that are being explored across a number of devices.

BlackBerry

Perhaps BlackBerry has fallen out of favor in the mobile community but the recent BB10 preview offers some interesting innovation in the keyboard space.

The keyboard works like normal but also hints words above the letters that they are typing. If a hint word is correct the user can swipe up to toss the word into the text message.

This is a clever idea as it puts the auto-completed words right at your fingertips in the location that you’re already looking to type the word. Clever.

Android

The idea of tossing words into the editor is new however the idea of predictive text has been around for a few years. Android ICS has this feature and third party keyboards for Android such as SwiftKey also have this functionality. In the android designs the predictive text is shown above the keyboard area.

Predictive text is interesting but I worry that it biases people in unusual ways.  Word choice may be selected even when it doesn’t match the original thoughts you were thinking. This subtle shift in word choices may impact the meaning of the intended message.

You start typing “I thought” but the keyboard suggests “I think.” The typer may select the choice as close enough. This actually changed the meaning. The former was perhaps a question or assumption the latter was a declarative statement.  In the BlackBerry design you don’t have this problem as much because “Think” would hover over the I and “Thought” would hover over the O.

Another interesting innovation on Android has been a technology called Swype. The idea with swype is that you don’t lift your finger between letters as you write a word. This creates gestures and shapes on the screen surface that draw out words.

It’s a clever idea that mixes the drawing and typing.  The finger trail it leaves behind is interesting but probably not useful to the user.

The trail can cause an occlusion problem where the trail can cover up the letters you’re trying to use.

Apple

Not to be outdone Apple is also doing some interesting things in the keyboard space.  Apple’s design elegantly deals with occlusion problems, aka the obstruction of the keyboard by your fat fingers.

When you tap on a letter a larger letter pops up letting you visually confirm that you’ve hit the right letter. If you keep that letter held down additional options are made available.  Try holding down some buttons and you may be surprised by some of the other options.

 Voice

Both Google and Apple are exploring voice on the keyboard. It’s certainly a time saver if you’re alone and can use voice.  People seem to feel conspicuous talking into their phones and the dictation, while good, isn’t good enough to be used reliably.

Th future 

The future of input and keyboards is bright for mobile devices but it’s still held back on desktop computers. I have hoped to see desktop adaptive input incorporate this since 2007. There’s a ton of opportunity to change the way we type, think, create.

 

 

Enter a title here

It’s amazing how many things happen because they are the default choice.  Default labels & buttons, meals, seats on planes, colors, suggested friends, coupons and email prompts lead to default interactions.

Two key ideas:

  1. Spend time obsessing about choosing the right defaults.
  2. Question the defaults provided to you by others.

Can the default choice be “smarter?” Can it provide deeper value to the end-user? Can you make it automatic? Can you make it seem to disappear?

Don’t default on yourself.

Designing navigation – GitHub

This post explores a design simplification on GitHub.com. The aim is to explain the process of a UI redesign and how aspects of UI can be consolidated and simplified.

Before:

After:

This example is a typical project page. There are a little over 40 navigation elements in the before image. (buttons, tabs, links, etc.) This UI can be difficult to manage. The primary problem is both clutter and context. To begin to simplify the navigation structure we need to understand the elements on the page and the core uses of the site.

One key principal I use:

Each page should have a key purpose. The UI should be optimized around that key purpose and extraneous things should be moved or removed when possible.

With this in mind I would say that the purpose of this page in GitHub is to browse source code. It serves a number of other purposes but it’s core use should be to explore code.

I’ve broken the navigation out into core actions. It’s important to group actions, buttons and links by logical area, and not by the location that it currently appears.

Global Context – (Actions that operate with no context)

  • Explore – explore the site
  • Gist – a clipboard system using git
  • Blog – news from GitHub
  • Help – documentation and information
  • Search – global
Personal Context  (Actions that impact my account)
  • My personal profile
  • Create a new repo
  • Account settings
  • Logout

Repo Context  (Actions that impact the current source repo)

  • Clone
  • Download Zip
  • Change branches
  • Sub-navigation within repro:  Commits, tags, downloads, wiki, graphs, etc.
Code Context   (Actions that impact the code)
  • Search code
  • Browse code
  • Code History
Fixing the core navigation

In thinking about navigation I tend to start from the top and move down. The first part is identifying the core navigation and tasks on the page.

The likely actions are interacting with your personal account or performing a search. The blog, explore and create repo actions are not core to the daily interactions.

  • I removed the icons from the navigation and replaced them with text. This is done in other areas of github and works well. Icons are nice if you know what they represent but can be confusing otherwise.
  • I consolidated account inbox and dashboard.  Both areas represent a way to update you on what has changed recently. There’s no good reason to have both.
  • I removed the advanced search glyph. I expect users should try a basic search before feeling the need access advanced search options. The default search should be to search code within your own repos.  Search my stuff first, give me the option to search everything on the results page.
  • I removed the global navigation. Elements like the blog are not core to the daily use of the site and can be relocated in the footer or other company information pages.

Now for the hard part…

  • Working down the page I wanted to simplify the project navigation and unify it with “Branch” navigation.  Conceptually a branch is a high level context switch.  Even if other sections are not contextually aware of the branch it’s better to have the higher level switch and allow for such context aware behavior in the future.
  • I’ve removed many of the buttons including: Pull, Fork, Zip, Code %, etc.  These appear to have accumulated over time. It makes sense that there would be a “dashboard” tab that could contain this and other non-code things like the ssh/http cloning URLs.  It’s sufficient to have a “clone” button that could reveal much of this secondary UI.  Such a project dashboard would naturally also have the default “ReadMe” for a project and provide a jumping off point for more esoteric features.
  • The tabs containing File, Commits, Branches are tertiary navigation. I’ve moved them under the secondary navigation and matched the selection and tab styles to show the visual relationship.  In the current design Tags and Downloads were arbitrarily right aligned.  Pulling these in cleans up the look & feel.
  • As noted before Search was pulled up into a global context.
Next steps
This is only a quick design sketch and could use significantly deeper exploration across other impacted pages. It’s easy to remove things and hand-wave about those features being moved elsewhere. It’s an entirely different matter to account for every feature and make sure it satisfies the design goals and doesn’t hurt usability.

 

Web App vs Native App

Companies deciding how to invest in mobile applications ask the question of web app or native app. To understand the answer companies need to understand the pros and cons of each.  Ultimately it’s not one or the other.

HTML gives ubiquity. Native development gives excellence. You want both.

Development Costs

HTML will win hands down in simplicity. You can get a basic web page online and running on every major mobile browser in an hour and have time left over to check your email and update your status. The complexity and development costs on native apps however can add up, especially if you need to develop for multiple platforms.  Getting a basic “Hello World” app running in 2 major app-stores requires knowledge of ObjectiveC & Java. Not to mention the submission, review and approvals of these apps.

There is little code re-use across platforms in native apps. Your typical Android app isn’t going to improve the development of your iPhone app or vice-versa.  There are cross compilation projects that attempt to bridge this gap however only lower level C/C++ cross compiles with any consistency and this generally is the functional, not user-facing portion of the app.

There are at least a dozen tools that promise cross platform development. These tools are either compilers that produce native code or wrappers around web API’s. These tools generally sit between you and the platform you’re trying to support. This layer between you and your users can dramatically impact the…

Quality of experience

When it comes to quality of experience native applications tend to win. Native applications perform faster and have access to more aspects of the phone’s operating system. This allows for better animations, camera and video access, richer native controls and navigations and more.

HTML has greater flexibility in presentation and allows for content updates to happen via the web. This can enhance the user experience when content is updated frequently or the user interface tends to change often.

In some cases the quality of experience when using web technology is acceptable in others it’s clearly a sore spot. One down side to native experience is crashing.  While web apps can also crash they often fail more gracefully.

HTML – The promise of write once, run anywhere

HTML(5) promises developers that they can write their web-app once and have it run anywhere. Tools like phonegap & Sencha provide bother wrappers for native API’s and Javascript libraries to allow web developers to look and perform closer to native.

Sounds good, except when you deal with the details. In particular performance and native user interfaces.

Things like scrolling a list and basic object manipulation in HTML can feel… “Sticky.”  This is because the design and layout are interpreted by the web-browser and this interpretation takes time.

HTML is reasonable to use on layouts that are primarily presentation of static content (the original purpose of HTML). It tends to break down in quality of the user experience as it strays toward interactivity or large amounts of data.

Some examples:

  • Facebook uses HTML to present static status updates but their slide to reveal interface is native.
  • LinkedIn uses HTML to present static profile data on users but much of their core UI is native
  • FlipBoard uses HTML to layout content pages of their articles but the animations and flip transitions are native
Even in these examples the use of HTML can impact the performance. Ideally the technology choice should be transparent. Users shouldn’t be able to tell.
How to choose?
Design should come before you choose. Don’t choose a technology before you understand what you want to build. There may be places where you want to use HTML and places where you want to be native.  Don’t try to force native things to be web or web things to be native.
HTML performs best in mobile when it’s informational/content. It’s possible to get some performant interactivity out of HTML but it’s difficult.
Native code tends to interact better with core services, it tends to provide better animations and transitions. If you’re interacting with lower level OS features or tying into the platform or 3rd party SDK’s, you’ll likely want that aspect native.
Choosing the right technology is a balancing act between providing a great experience and providing developers with some flexibility.
It comes down to a choice between ubiquity or excellence. Use HTML to give you elements of ubiquity and native to push the bounds of excellence.

How to Create a Mobile App

This is a 20 minute presentation I did as part of a HubSpot’s mobile marketing workshop. There are three additional sessions available from HubSpot.  My talk covers the basics of creating an application and covers the process and common issues.  My company Raizlabs does strategy sessions for many national companies. This talk is a small glimpse of what we do.

Learn more about Raizlabs from our homepage. 

On my way to forgetting passwords


Google is exploring ways to eliminate passwords as we know them. They are doing this by linking the trust you have with your phone to online trust.  The idea is that instead of a password field you scan a QR code with your phone and your phones signs you in. Your browser updates and you’re logged into from your computer. You can try Google’s system here. 

The advantage of this system is that your password is never entered into the computer. This is great because I hate entering passwords.  We’ve also de-coupled the site security from your phone security.

Your phone is physical so it’s much more secure. Random people on the internet will have a harder time getting hold of your phone to hack your password. Right now most sites have no physical security.  Paypal, Amazon and many banks lack any physical security token.

Higher end security services make use of a security FOB. These are electronic keychains that have a cryptographic key, aligned with a timer. These add the physical security but from a user experience they make the user enter more data to login, rather then less.

Google’s solution uses a QR code and QR codes are still a little; well, dorky. But the idea is sound and on path to less passwords.

theme by wp-svbtle