New iPad Browser: Coast by Opera


This post originally appeared yesterday on my blog.

Yesterday Opera announced the release of its newest browser, Coast, built specifically for iOS tablets (I would say just iPads, but if my fridge gets an iOS tablet UI then I’d be wrong and will have paid too much for a fridge).

Background

Recently Opera moved away from Presto as its rendering engine and hitched its future to Blink, the rendering engine born from WebKit that powers Chrome. Now instead of Opera worrying about the rendering engine, it is focusing on the user interface, the place where it can set itself apart from the other browsers.

Essentially Opera is removing the browser chrome (implying to the user that a web page is just an app) and adding gesture support. Given that Opera was the browser that introduced us to mouse gestures well over a decade ago, and given that a touch screen is an inherently gesture-based UI, this seems like a natural fit.

Bits for Developers

Sadly, my office wifi was down and I couldn’t play with the browser immediately (my crusty iPad 2 is wifi only). So instead I took some time to read through the developer notes.

Tablet First

Overall Opera recommends general responsive design current best practices, though it promotes a tablet-first approach. Opera offers some CSS you can use to specifically target iPads Mini, 2, 3 and 4 (Retina and non-Retina), though it leans on vendor prefixes with only a brief note to also use other prefixes and unprefixed rules.

Responsive Images

It’s also clear that Coast supports the new srcset option for responsive images. It even offers a code example: <img src="image.jpg" srcset="retina.jpg 2x">

Note: As Bruce was kind enough to inform me (because I missed it in the dev notes), responsive images will be supported only in iOS7 and up.

Update as of September 20, 2013

According to Opera, iOS7 did not come with a WebKit update. That means Coast cannot support responsive images via the srcset attribute without a polyfill. Nor can Safari, of course.

Tile Speed Dial Web App Image

Instead of “Speed Dial” icons/images, Coast now looks for a “web app image.” If you don’t have one, Coast will first look for a Windows 8 tile image, then an Apple touch icon, then a shortcut image, then just a favicon. You can, however, create your own 228 × 288 pixel image and stuff it into your site with the following HTML:

<link rel="icon" href="$URL" sizes="228x228">

User Agent String

Don’t use this to do any browser sniffing. Browser sniffing bad. This is instead handy for recognizing it in your logs:

Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Coast/1.0.2.62956 Mobile/10B329 Safari/7534.48.3.

General Review

Getting going is pretty easy, just start typing into the only field on the screen. As you type you can see a Google preview on the left, which you can tap at any time to go to Google, or a list of icons on the right which correspond to sites you might mean. The icons start out just displaying the first letter of the site, and then identify the site’s tile or shortcut image.

Screen shot of Opera Coast navigate screen.
Note the handy “.com” and “.net” options that appear above the right end of the text box.

Once you are on a page, you can go back by swiping from the left, forward by swiping from the right, or reload the page by pulling down from the top — but not too far or you get the iOS menu instead.

Vine of me playing with back, forward and reload in Opera Coast.

Opera Coast skips tabs and windows altogether and, frankly, feels a lot more like Internet Explorer for Metro than other current tablet browsers. It’s pretty easy to see the open “tabs,” flip through them, get more details, and discard them. It’s also incredibly easy to forget you have so many tabs open. I regularly found myself littered with tabs because of all the links opening new windows.

Testing Opera Coast window/tab management.

While in that tab view, you can also see how “safe” the page is and can get to options to share it, email it, print it, and so on.

Screen shot of Opera Coast safety and share information.
The arrow on the right gives you all the share options.
Opera Coast print dialog.
I don’t have a printer installed, so I’d love to hear feedback on how Coast honors print styles.

Adding and removing a bookmark, tile, whatever, is pretty easy. It took a few swipe-fails, but I got the hang of it well enough to show the whole process in one uninterrupted Vine:

It takes a little getting used to, but it’s not too hard

Gotchas

There were a few things that threw me off. Perhaps because I am a power user, perhaps because I only played with it for one evening.

Swipe History

The swipe for back/forth is handy, but conflicts with behavior I have already learned. In Chrome for Android, swiping left or right has the infuriating feature of bringing me to the next or previous tab in the stack order. For those rare sites that implement a slide that is swipe-friendly, imprecise swipes will move me back and forth in the history instead.

Web App Images

Using the browser in portrait view, the additional screens of tiles (speed dial icons if you are already familiar with Opera) aren’t immediately apparent. It wasn’t until I turned to landscape that I saw them. The tiny dots under the Coast icon weren’t enough for me to intuit that. They also aren’t nearly large enough to tap to jump to a specific screenful of tiles.

Hit Sizes

The 9-box grid at the center bottom as well as the three rectangles at the bottom right are the only real browser chrome in play as you surf. They are also maddeningly small to tap. And I have dainty, lady-like fingers, so I suspect it may cause consternation for others.

Address Bar

If I am on a site and I want to change the address of the current page (maybe I fat-fingered and got to a 404, or I know a super-secret URL), I could not find a way to bring up the address bar and change it. It also made it impossible to know the current page address at any time. As someone who regularly looks at the URL for familiar addresses, indications of scam sites, quick commitment to memory, and so on, this alone takes it out of the running as an everyday browser for me.

Email a Page

I did not care for the email feature one bit. Not only does it embed a screen shot of the page (with a Coast watermark), the screen shot won’t display on other devices. Outlook blocked the image because the attachment ended in .com (not .png or .jpg). Had it not come from me, I wonder if Outlook would have blocked it as spam. My Android email client couldn’t display it because there was no file extension to give it a clue.

Screen shot of emailing a web page from Opera Coast.
What you see when you choose to email a web page from Opera Coast.
Screen shot of received email from Opera Coast.
Best case scenario of what the email recipient sees, though the attachment was blocked in Outlook and unusable in my Android email client.

Tweet a Page

Tweeting a page left me similarly dissatisfied. By default it includes a Twitpic screen shot of the current page with an Opera Coast watermark. When composing the tweet, I tapped the paperclip icon to see if it would do anything, but nothing happened. I opted not to tweet again.

Screen shot of tweeting a page from Opera Coast.
Tweeting a page from Opera Coast.

The resultant tweet:

Wrap-up

Overall, I like the browser. I like what it’s trying to do for consumers. As a power user, however, It’s not a fit for me though I’d be interested in bringing it in front of some other members of my family.

I also didn’t get to try out unsafe sites, printing pages, responsive images (need iOS7), or poorly-built sites. My opinion might change as I continue to play with the browser.

Open Question

There are a lot of Android tablets out there, not just the four screen size offerings from Apple. So how long before we can see Coast on my Nexus 7, if ever?

Updates

I’m adding notes throughout the day as they come up.

Surprising no one, the following reviews from more mainstream sources completely fail to include any screen shots or videos that weren’t pilfered from Opera. I only say that to remind you that by reading this post you have gotten the most in-depth review currently on the web and you should be excited and send me a thank you note and maybe read all my other posts and high-five me on the street.

These articles are, however, worth visiting just to see the comments and how others are reacting to it.

Tips from Bruce:

Update: September 18, 2013

Opera has fielded some questions about Coast and collected them into two posts (so far):

Advertisements

App Store Meta Tags

Screen shot of Dominos home page on Nexus 7.
Why yes, Dominos, I’d love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.

This is an adapted and updated version of a blog post on my site from last week. This post includes a real-world example of the feature.

This may be old news to some of you, but I haven’t found a place that collects this in one spot.

One of the most offensive experiences I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site’s app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don’t expect to be served the page I came to see, but instead shunted to the mobile home page).

If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.

Platforms

iOS 6

Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

  • app-id is required and references your app’s identifier.
  • affiliate-data is optional and uses your iTunes affiliate string.
  • app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple’s developer site: Promoting Apps with Smart App Banners

Windows 8

Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the “charms” feature of Windows 8.

This code is relatively simple as well, though it requires two meta tags and supports up to five:

<meta name="msApplication-ID" content="microsoft.build.App"/>
<meta name="msApplication-PackageFamilyName" content="microsoft.build_8wekyb3d8bbwe"/>

  • msApplication-ID is required and references your app’s identifier.
  • msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.
  • msApplication-Arguments is optional and lets you pass arguments to your app.
  • msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.
  • msApplication-OptOut

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.

If you know of other app stores that offer similar features, please let me know so I can update this post.

Real-World Example

One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.

Screen shot of the QuantumCMS custom meta tag screen.
Screen shot of the QuantumCMS custom meta tag screen.

If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:

Site on the iPad3 without the app installed. Site on the iPad3 with the app installed.
Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.

Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.

If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.

Related

There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.

Letting Mobile Users See Desktop View of RWD Site

Originally posted on my blog on January 11, 2013.

Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?

There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.

Clearly it’s enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the “desktop” version of a site from a menu built into the browser.

Except that feature doesn’t work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn’t do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.

Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we’re kind of stuck. While I have many ideas on how that might work, that won’t address the issue today.

While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.

There are some core steps the hammer out in the logic of any solution:

  1. Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.
  2. In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.
  3. Either using a round-trip to the server or client-side script, remove the media query logic and serve up the “desktop” CSS.
  4. Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.
  5. Now display a link to view the “mobile” version of the site. Again, this can be done with or without script.
  6. If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.

This process is a bit oversimplified, but it covers the broad strokes.

There are some hurdles, of course. Your users might not understand what you mean by “desktop” or even “mobile.” You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don’t clear the link from the page for them. And so on.

You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.

These screen shots should give you an idea of what to expect when you visit the site:

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7, all styling determined by media queries.
CHSBuffalo_iPhone_desktop CHSBuffalo_Nexus7_desktop
The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7 after clicking “View desktop layout” (with the zoom as the user would initially see it). The link to return to the mobile layout is at the top, though not as obvious as it could be.
CHSBuffalo_iPhone_desktop_oops
This is what the user on an iPhone sees as soon as the desktop view loads—note the link to return to the mobile view is nowhere to be found. We did a poor job there and will have to fix it. Don’t make the same mistake if you try this.

Related

HTML5 and Enterprise on Mobile

This post originally appeared on my blog on Saturday, March 10, 2012.

An Argument

HTML5, CSS3Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That’s as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you’ve read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author’s inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as “enterprise” to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn’t addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what “enterprise” means.

Security

So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven’t been inculcated in an enterprise environment and maybe don’t think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the “new shiny” and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn’t mean they aren’t in the code borrowed from somewhere else, especially if the developer is new to the game.

Synchronicity

I’d like to think every developer has already built a system to lock records — ideally one that doesn’t halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don’t “log out,” and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it’s a bit trickier with more likelihood of flaky connections and long wait times. It doesn’t need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don’t have clean methods of handling dropped connections and can end up leaving users stranded.

While that’s not the technology’s fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you’ve been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla’s IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren’t in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.

Conclusion

Look to the business case. Don’t fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don’t fall for the arguments in favor just because of a knee-jerk reaction against “stodgy” enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.

Comparing Mobile vs. Desktop Data for Improved Experience

Mobile web sites and web pages are all the rage and it’s no wonder, with sales of mobile devices soaring (Gartner). So, maybe you’re considering a mobile version of your own site, but you want to be smart about it, doing what’s best for your site based on what makes good sense for your business. Thankfully, web analytics is here to the save the day! Analytics = super exciting, right? Well, bear with me here.

Start by accessing your Google Analytics account (if you don’t have Google Analytics installed on your web site, check it out to learn more about the insights and information the service can help you gather about your site).

You’ll want to set your date range for the past 12 months and go to the Mobile Overview section* (Click images for larger screen shots):

Mobile Data Overview

This report will show the percentage of visitors came to your site from mobile devices during the past year. If it’s a decent piece of the pie chart, usually 10% or more, the data is telling you it would probably be smart to invest in the development of a mobile site.

Click one level down to Devices and you’ll see which mobile devices are the biggest drivers to your site. It’s important to note if Apple devices are at the top of ­the list as Flash won’t work on these devices (and probably never will). You’ll want to keep this in mind and consider an alternative to Flash when designing your mobile site.

Now, let’s dig a little deeper. What kinds of content are your mobile visitors viewing most often (Content>Site Content>Pages)? Does it differ from desktop users? If so, those answers can point you to better ways to organize your content for a mobile site design.

Here’s how: Hop down to the Content section, click on Pages, and bust out some Advanced Segments. Under the defaults, you’ll automatically have a Mobile Traffic option at your fingertips. This report will give you insight on what the most viewed content from your mobile visitors is. Is this same content at the top of your mobile site design or extremely easy to access on a mobile device? It should be.

You could just compare “Mobile Traffic” to “All Visits” but let’s be more awesome.

Create a quick and simple “Custom Segment” for Desktop Visitors.

Click “+ New Custom Segment” > Name itDesktop Visits” >Select “Include Mobile Exactly Matching No” > Test then Save your segment. You’ll know you did it right if your Mobile Traffic and Desktop Visits add up to All Visits.

Creating Desktop Visits Custom Segment

Now, you can start comparing differences between your mobile and desktop site visitors. Just select the “Mobile Traffic” advanced segment and your new “Desktop Visitors” custom segment, hit apply, and check out the differences. For example, on our own site I found mobile visitors spend way more time on our Web Design and Careers pages than a typical desktop visitor.

Mobile vs Desktop Visitor Data

If you don’t see a lot of differences between the way mobile and desktop user visit and interact with your site, simply creating a more mobile-friendly version of your current site is probably a valid option and should work perfectly for the vast majority of your mobile visitors. On the other hand, if there are big differences between the two kinds of interaction, you may want to consider a new design for your mobile site, pushing the most important content for mobile visitors to the top or highlighting it to make it more easily accessible via mobile devices.

If you’re an analytics user, have you tried any of these reporting options and checked out your metrics? Did you find anything interesting? I’d love to hear about it.

*All data shown is anonymous and is not reflective of our clients’ accounts.

Design Great Tablet Apps By Making Users Forget They’re On A Tablet

Originally posted by Algonquin Studios CEO, Steven Raines, on January 25, 2012 on his blog.

According to Pew Internet, tablet ownership doubled over the 2011 holiday season, with nearly 20% of adult Americans now owning tablet computers. In combination with widespread high-speed wireless Internet service, the market for business-to-business applications for these tablets is set for explosive growth. Targeted sales applications represent a signficant area for innovation since videos, schematics, product specifications, and other documents can be easily transported and presented – either directly on the tablet or to on-site monitors or projectors via optional cables. In essence, it’s a sales manager’s dream come true… especially for organizations that have highly structured sales processes backed by well researched tools.

In a recent brainstorming session with a client, I was asked what features of tablets should be incorporated in the design of this kind of application to really make it stand above other apps or a traditional web site displayed on the tablet (when I say “tablet” I mean the iPad style device with “Apps” not simply a computer without a keyboard.) The client’s question got me thinking about where the real value in tablets lies and how that translates to design. To evaluate this, we have to think first about what it is that makes a tablet special. More often than not, tablets are marketed as being light, easy to use computers. But they aren’t the same as the computers we use for business.

The core value of the tablet is only its form-factor, portability, and battery life. Thanks to solid state memory tablets are light-weight. The limited scope of applications and single-tasking (or more appropriately “serial-tasking”) allow much longer run-times than a laptop. Tablets allow us to have a “book” with a whole library of information stored in something that you can hold in one hand. But to achieve this we give up a lot of great things from the world of PCs and laptops. On tablets:

  • peripherals are limited;
  • virtual keyboards require as many as three clicks to get to essential characters like the equal sign;
  • meta-applications (like plug-ins for the OS’s file manager) aren’t applied to every app that could take advantage of them;
  • devices have small screen sizes;
  • precision control either does not exist (on capacitive touch devices like the iPad) or requires a stylus that is easy to lose and hard to use.

These factors combine with the nature of the applications we’ve come to expect on these devices to create an experience that is wholly unlike the things that make PCs great, such as:

  • True multitasking;
  • dragging and dropping between applications;
  • fine control over drawing / selection (for photo manipulation, CAD, or design work;)
  • context-sensitive menuing;
  • comparing documents side-by-side and referencing the Internet while working on documents.

Since most netbooks and the new “ultrabooks” similarly address portability and battery life nearly as well as tablets but have all the features of PCs, form factor / user interface are all that remain (outside of some hardware that most tablets now have standard like the accelerometer, GPS, camera, and compass.) to differentiate tablets from other computers. Tablet interfaces are significantly less feature rich than even the most basic Mac or Windows netbook. But of course, it IS the form factor and interface that is the whole point of the tablet and that is where the way we think about application design really changes.

Good design for tablets isn’t about taking advantage of some special features only tablets have – it is about providing users with a way to achieve the workflows they have become accustomed to on their PCs while using the tablet. It isn’t about something new, but reinventing something old and something lost in the translation to the new platform. Take Apple’s email interface built into iOS: I can’t count the number of new iPad owners who have complained to me that they could not simply multi-select messages to be moved or deleted. Of course you CAN… but not how you’d expect (instead of dragging to select messages or holding SHIFT and selecting, users click a button and get radio buttons to select multiple messages and instead of dragging to move messages to a folder, users select the action to move and pick the folder.) Apple has been forced to provide an alternate way to achieve something that the interface doesn’t accommodate in the expected fashion.

So the obvious challenge faced by designers of tablet applications is that the expectations left over from the PC experience are many. But a more daunting challenge is that very few new conventions have been set in the tablet world. Without a standard way of replicating the workflows of the desktop, designers are forced to try different things and until a particular way of interacting with apps to resolve a workflow issue becomes dominant, users will be unable to simply “pick up” an application based on prior experience. This prevents designers from relying on user expectations the way they do on a desktop and, to a lesser degree, the web and extends the design process. It also means that application developers will be forced to eventually modify applications to accommodate the dominant convention once it emerges and this refactoring means fewer resources will be available to develop new features for these applications.

The Holy Grail of tablet design is, of course, to develop a way of working that is so intuitive and easy that it makes the transition back to the world of the PC… assuming we still have PCs by then.