Native vs. HTML apps

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.

Post to Twitter

PixelPushing: Twitter

The twitter iPhone user-interface is, for the most-part, slick however there’s one screen that has a large number of interface complexities and design issues. For me the search screen sticks out. The twitter business model has shifted toward “trending” and “promoted” tweets while the UI has traditionally lacked a focus in theses area. As a result compromises have been thrust on users in the form of the #DickBar. This could have all been avoided if the search interface had properly incorporated trending and promoting terms as part of the core design.

Here’s the current version:

Original Twitter Search UI

 

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:

Search tweets core

 

  • 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

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

Searching twitter for local content

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

Post to Twitter

Pixel Pushing: FourSquare

This is the first in what I hope will be a series showing basic UI explorations and critiques of various user interface screens, with a focus on mobile applications.

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.

FourSquare Places UI Screen

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

Post to Twitter

<Video> killed the H264 *

Google recently announced their plan to remove H264 video support from chrome’s use of the HTML <video> tag.  This caused a lot of people on the internet some anger, tirades of evilness and more.  I however view this in a different light.

Google can do whatever it wants to in its browser and if I don’t like it I can use something else.  Even if Google wanted to kill H264 it would likely have little luck without at least the cooperation of another large operating system player like Apple or Microsoft.

  • There are no shortages of open source browsers.  Firefox, Opera and Chrome itself. If Google does something that doesn’t make sense there are plenty of other browsers to take Chrome’s place.   Google’s browser market share is still small and is primarily composed of early adopters, exactly the audience you don’t want to upset.
  • Arguments about video-codecs and encoding have taken place for years.  Real Networks, Windows Media Player, QuickTime, etc. Every company that’s in the video space tries to create a better video codec. It’s not really surprising the Google is trying to push it’s own WebM technology. The problem is that rather then introducing a new codec and trying to prove it’s value and worth they are instead limiting choice.  If Google added their WebM technology while keeping H264 support web developers could make the choice themselves.  By pulling built-in support for H264 it forces web-developers to use Flash to work around Google’s limitation.
  • It’s most surprising that Firefox and Google don’t have a joint strategy for online video.  Both in theory support open standards, open source and even have offices right next door to each other.  By having divergent strategies it actually slows down innovation as there is no clear right way to do video.
  • The big elephant in the room that Google is ignoring is the close to 80 million iOS devices.  H264 is requirement to access these devices. Large web properties (including YouTube) are unlikely to re-encoded all their content for the potential of streaming to one browser.

Ultimately search traffic is more important to Google then video standards. If this change causes a shift in the former I expect them to back peddel on the latter. Even if WebM is a better format the right way to gain adoption is not by trying to force the format on web developers and consumers. If it’s that good Google should convince the Firefox team and WebKit teams to support it.

Post to Twitter

BlackBerry first impressions

I’ve been working on iPhone apps for the past three years and more recently we’ve been exploring Android and iPad apps as well. These are my first impressions of a Blackberry Bold:

  • The lock-unlock button is hidden. It’s in the upper frame of the phone but it’s not even clear that it’s a button. It can be pressed on the left side but not the right.
  • On the phone I was using you can’t touch the screen. Ok, you can but it doesn’t get you anywhere.
  • The Operating system is very much file/folder based.  Apps live in a folder, within folders. The interface has no labels unless you hover over an icon. This is particularly bad as most built in icons are mono-tone.  This is a classic example of “Mystery Meat Navigation
  • Overall there is a ton of inconsistency between various user interface screens.  Some screens are skinned with a black chrome glow while others look like a page out of Windows 3.1.
  • The typography across the phone is terrible
  • The web-browser goes into a “mouse pointer mode.” This is pretty bad and is the reality you face when you don’t have a touch screen. It’s the only way you can tap on a specific region of the screen.
  • The camera seems adequate.
  • Installing applications from the app-store is completely broken. I was able to install a couple apps like Facebook, Yelp and Twitter but the process was really confusing. Only determined users will do this. I was unable to pay for an app. It was just too much of a pain.
  • Most aspect of the phone were inferior to Android and iPhone except for one, battery life.  The thing lasted all day without issues and under a fair amount of use.  No wonder the device is closely associated with email.  The built-in keyboard and long battery life lend it well to email tasks.

What about the apps?

The apps that I explored were very inconsistent. Even across popular and built-in apps the UI was questionable and certainly not elegant. The developer strategy is confusing. If developers are worried about fragmentation the fear is much more real on BlackBerry then on Android. The platform actively sells multiple platforms, resolutions and capabilities:

  • Torch 480 x 360
  • Style  360×400
  • Curve 320×240
  • Pearl 360×400
  • Bold 480×360
  • Tour 480×360
  • Storm 480×360

Across these phones you’ll also find different capabilities across single lines of phones. This can make testing across devices to be challenging.

I think about BlackBerry in the same way that I think about Internet Explorer. You can’t ignore it as it has a non-trivial market share but part of you is rooting for them to go away.

Post to Twitter

Apple Predictions

  1. 2011 – iPad with forward facing camera
  2. 2011 – iPhone on Verizon
  3. 2011 – AppleTV with 3rd Party Apps and App Store
  4. 2012 – iPad with Retina display
  5. 2012 - iPhone with RFID
  6. 2013 – AppleTV subscription channels
  7. 2013 – iPhone with haptic feedback
  8. 2013 – iPad Apps that run on the desktop
  9. 2014 – Macbook Air – with detachable iPad as display
  10. 2015 – We’ll have to wait and see.

Post to Twitter