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.

I’m a big proponent of wireframing as a tool to create better interface designs. We recently released a mobile wireframing toolkit for keynote and powerpoint.  The toolkit is not free but it compensates by extra amounts of awesome.  More info here.

I wish HTML could be the future of app development but there are a number of reasons it’s not there and unfortunately won’t be anytime soon.

• HTML is always one step behind native.  While HTML can continue to play catch-up with new features it’ll always be a step behind when it comes to new technology.  Features like push notification, NFC, calendar, microphone, accelerometer, OpenGL, contact/calendar access and even basic things like the camera on the device are just not there on the web.  The folks that develop the browser itself are building a native app so the native app API’s have to come first. Even though it seems like HTML is “close” it’ll continue to be close as it’s a moving target.
• Performance is key, especially in mobile.  The best native apps crush HTML apps in performance.  Web-apps have improved a lot over the last few years. The addition of client databases, JSON & compiled javascript have all done a lot for performance.  All this is good but even something simple like a long list of 1000 items shows the performance problem.  On a native app that 1000 item table is virtualized and breezes by with a flick. On an HTML mobile app you’ll experience the joy of the checkerboard pattern.  HTML isn’t setup for virtualized lists. As phones get faster this problem gets smaller but side-by-side you feel the difference.
• Platform consistency. The phone is personal, more personal then a PC. The user interface on each mobile device is also personal. An iPhone app interface isn’t the same as Android or Windows Phone or BlackBerry. Users want platform consistent experiences.  This is something that you just can’t do on the web.
• Discovery and distribution model:  The web is a collection of “pages” that connect to one-another but conceptually these pages don’t always form a product.  The app-store is a model that works because you have a centralized place for complete products, not pages.  These products are rated, ranked and categorized.  In addition to a distribution model native apps have a monetization model that doesn’t exist on the web.
• What about things like PhoneGap? Can’t you get the best of both worlds? Develop on the web then package everything as an App? No. Not if you use HTML to do the rendering of your app.  Apps like Bank of America tried this and it’s pretty terrible. (Yes we can tell BOA.) Netflix, tried to re-create many aspects of native controls using javascript and while the overal service and app is great this just doesn’t work well.

To understand the problems we’re facing today with native vs. HTML we need to roll back the clock back to 1994. This was my first memory of HTML.  I had just taken an intro computer class on basic networking and data structures. We learned about the efficiencies in how packets get sent and recomposed between computers and we also learned how to efficiently pack bits into a data-structure for optimal efficiency.  Native C & C++ type stuff.

My next class was an intro to HTML. At the time HTML was pretty simple and you could count the core tags on your fingers <html> <head> <body> <p> <h1> <img> <b> <a> and <center> and <i>. We were able to create basic web-pages. Really basic, no CSS, no JavaScript almost all text.

Even back then I felt there was something wrong. At the core levels of efficiency of both data storage and network traffic it felt like there were problems. Where were the data-structures?  To create something as simple as a link wasted 16 bytes <a href=”"></a>.  No big deal? What’s 16 bytes anyway? 12 bytes too many.

Yes, it’s a little extra data. But it’s not just storage of the data but it’s encoding the data, sending it over the network and parsing it for display. The inefficiency isn’t on the one tag. It’s on every single tag.  Same problem for network requests. Instead of opening a connection to a server and getting all images and data in one shot you would open a separate connections for each image.

Fast forward to 2011 and the problem getting clearer. Instead of a handful of tags and a couple images we have hundreds of tags, properties, images, css files, javascript files, web-fonts, DTD documents, etc, etc.

Here’s the current version:

The screen is supposed to serve four core functions and several secondary functions.

1. Allow users to search the system using basic text search
2. Allow users to view review saved searches
3. Allow users to search by geo-location
4. Allow users to see currently trending and promoted content

In looking at the screen there are a number of problems and unusual UI patterns.

• It’s unusual to have a down-facing chevron to expand content in-place as in the Saved Search UI. Typically sections don’t accordion in-place, they navigate to a full-screen interface. Full-screen navigations allow more affordances and design patterns for editing, adding, deleting, etc.
• The promoted quotes section with tweets are clipped with an elipsis.  The font is tiny, there’s only 140 characters and it’s clipped? This makes the content hard to read and use. Additionally it’s not clear if these are popular, trending, promoted or random.
• Users are only able to see the first three trending topics.  Assuming the content is important to the business model this is a serious compromise. More on this later.
• It’s not obvious that additional searching affordances are available for searching user profiles or geo-location. These additional interface elements show themselves later. This isn’t like in mail when you get to change the filters of searching for email this is actually very different types of searches.
• The chrome of the twitter frame (both the top navigation bar) and the lower tab-bar take up important space from the search interface. While the buttons to switch accounts and compose a tweet make sense from a consistency standpoint I feel they are less useful from the context of performing a search.

Proposed design:

• The page is focused on searching. The top-area allows you to scope your search while the rest of the page provides space for results.
• Searching tweets/people/Local is an explicit choice.  While some apps like email put the segmented control bellow the search bar I think from an information hierarchy standpoint this is not correct. Having the search context above the search bar allows you to adapt the search content area as needed based on context.
• I’ve used the bookmark pattern found in the built-in maps app to allow users to get to saved searches directly from the search bar.  Like the maps app it would present a modal view to allow you to navigate to a search results page.
• It could be argued that trending has no value for end-users. While this is likely true for end-users it obviously has large value to the twitter business.  As their model shifts toward controlling the client and channeling advertisements it’s critical that this is done in a non-invasive way.  Giving good exposure to promoted tweets along the main navigation tabs will alleviate the need for the more offensive solutions.
• Placing the promoted icon in it’s own column makes the text easier to read for both columns.

• Searching for people is the second core function. In exploring the twitter app there are two distinct people search features. First the app will search locally on the device for users that you follow, however as soon as you hit search it will talk to the twitter service to return the server results.  In the above design I’ve made this simpler and more unified. The iPhone list pattern allows for grouped results. I’m showing local results for two accounts. A third grouping (bellow the scrollview) would present the results returned from the server.  Since search can be cross accounts on your phone it’s actually a good reason to have no specific account context for performing the search.
• The search interface could similarly display recommended users before the user starts typing. While this isn’t illustrated this type of approach can provide user utility and promoted profiles while not interfering with the core user experience. Good for users and for the business.

• Lastly the local search allows you to quickly find both the tweets that are local to your geo-location as well as allowing you to search for specific phrases.
• The map/list icon next to the search field would allow you to toggle/flip the view from a list to a map.
• Promoted tweets with geo-location could be presented here as well. Since the content appears to be sparse minimal promoted content could be useful, especially if it’s free stuff near you. Starbucks and other retails could drive traffic, while giving followers free stuff. Win. Win.

The specifics of how search works within the twitter app are subtle and there are many nuances that are not listed here such as how results are pushed into the view or how search results are saved, displayed or edited. The key point I’m illustrating is that even complex interfaces can be made simpler and clearer while simultaneously improving the business value.

The screen I’m starting with is the FourSquare Places screen. The purpose of the screen:

1. Allow users to select a nearby place
2. Search for places if the place is not in the list
3. See potential specials and nearby promotions.

Issues I spotted with this screen.

• Branding in the title bar. While this may be OK in a key screen it’s unnecessary on every screen and takes up valuable space.
• Because of the branding problem we have a secondary title bar that describes the page.  This is useful as it confirms the page however the text is ALL UPPERCASE and too small.
• The search toolbar is fine except it’s not vertically centered in its bar.
• The list is three lines where the first line is the venue name, the second line is its address and the third is the distance from the venue. This can be collapsed into two lines while increasing the font size.
• There are two bars across the bottom (apart from the tab-bar). This is problematic as it eats valuable list space and it can cause problems as it’s hard to tap items at the bottom of the screen without accidentally changing tabs.

Quick re-design:

• I’ve removed the logo from the screen.  I think a proper title bar is stronger.
• I’ve centered out the search bar.  Additionally the search bar can be hidden by default as it is in the “Notes” app.
• I’ve moved the nearby text into the Nearby header bar.  Logically this information is connected so it makes sense together. The GPS icon has been removed as it serves no obvious purpose.
• I moved the specials up so that they were logically “Nearby.”  This meant the extra text wasn’t needed. Moving this up from the bottom and adding the ribbon effect encourages interaction.  The placement should make it easier to tap and since both the table-header and the specials float above the table we’re not loosing any extra vertical space.
• I’ve simplified the table-cells to two lines by moving the distance value into its own column. This should also aid in scanning locations based on distance.
• The design changes allow a single page to display 6.3 items, the original allows you to view 3.5 items at a time. An improvement of 80%.