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.

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.

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

• 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.

• Search code
• Browse code
• Code History

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.

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

Learn more about Raizlabs from our homepage. 

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.

That being said, I enjoy exploring what I may have done different. See my previous FourSquare Exploration.

Here’s the original main screen:

Here are my issues:

• The people icons are too small, the self icon is circular but friends are rounded rectangles.
• The refresh icon isn’t needed on screen, a pull to refresh could have been used, or nothing at all.
• The current time also isn’t necessary as it’s built into the iPhone status bar.
• The update Status + icon overlaps people’s faces and seems to get in the way of the notification bar.
• The comments icon implies a happy face. In fact the button allows you to add comments and perform other actions beyond smiling at things.
• The notification bar doesn’t feel like it fits with the interface.  These notifications are part of my path but are visually represented as separate.

• Large faces, using the round icon treatment
• Removed refresh and time indication and replaced it with recent notifications
• Right column contains number of views or a + to allow users to add a comment/smile, etc.  The + could become a strong brand element so it may be nice to use it throughout.
• Status area is more obviously place to either type or add some other media. Encouraging text input plus media will make the content easier to consume and socialize.
• The notification area is moved to the top (as part of your path). This way it doesn’t overlap posts or the input area.

What would you have done different?

I was quoted in the Boston Herald yesterday but I think the new pricing announced really underscores the importance of this device.  At $199 this isn’t just a tablet competitor this is a low cost competitor from a company that has the content stack to make it profitable.

Amazon has books, music, videos and apps. There’s only one other company with a similar content stack and it’s not Google, Microsoft or Facebook.

Designing for Thumbs and Fingers from Greg Raiz on Vimeo.

This being said I feel I can share some tips for how I’m able to receive hundreds of emails yet keep my inbox fairly organized.

• Learn to love gmail.
  The spam filtering is the best I’ve ever seen. Even if you’re not in love with the web interface the reduction in noise is a must-have.
• Scan to delete
  When I’m reading email subjects I’m usually take a quick pass and delete all messages that I can delete based on the subject and sender.  This first pass can quickly eliminate Facebook alert noise, Google+ notes, LinkedIn replies, Eventbright registrations, etc.
• Unsubscribe from Noise Newsletters
  I try to actively unsubscribe from anything that I haven’t read in the last couple months.  If you don’t take the time to unsubscribe the messages keep coming and distracting you.
• Don’t respond too quickly
  Most senders don’t expect a response too quickly and a surprising number of messages resolve themselves in a few hours.
• Learn keyboard shortcuts
  In gmail press (?). In Windows Outlook it’s the Alt Key. Learning a couple shortcuts like select, delete, archive, label can make things fly.
• If you’re writing more then a few paragraphs something is wrong.
  I try to keep my writing too the point and I avoid word-smithing.  If something needs clarification a deeper design, specification, or presentation then a phone call is likely more efficient.
• Use the add-ons
  Boomerang is an incredibly useful service it allows me to delay reading or sending a message until needed. The same company has an email game that improves email productivity through game mechanics.  I use Boomerang to efficiently read and schedule emails and I use the email game to get through messages that I’ve procrastinated.  Two other services I use are Raportive and Google Labs “Canned Response.”
• Out of sight, out of mind
  I try to keep my inbox messages on one screen so I can see everything I have to process. If it’s not on the screen it’s in a task list, archived or deleted.
• In Search we trust
  I use labels very minimally. (Usually for priority) It takes me time to label, star, flag, tag or otherwise mark a message. It general it takes almost no time to search for something. I think Google could vastly improve email search but even in its current form it works much better then any tagging or organization structure.
• Email Less
  Seems obvious but it does work.  Getting back from a vacation I can get through all key emails in an hour or two. If that’s true then simply spending less time in email will make your emailing habits more productive.