What are prefixes for?

When the standards organization started to explore how to evolve the language, there were browser manufacturers that grew impatient with the time it took for adoption, so in an attempt to push the technology of the web faster, they implemented their own experimental extensions into their browser rendering engines. These extensions were implementations of draft proposals that were still undergoing debate or discussion within the standards orgnization. In other ways, there were new ideas that were being implemented to demonstrate technology that was to be introduced as draft proposals into the specficiation. All of the browser rendering engines, WebKit, Firefox, Opera, and Internet Explorer have prefixes that are used for custom implementations.

The plan was, at a certain point, the specifications would be formally adopted and made “law”, at which time the browsers would drop the prefixes and there would be a single, common implementation that would be consistent on the web.

So what happened?

To support all of the custom implementations for a CSS rule, all of the prefixes are needed to support this specific browsers:

a:hover {
 color: red;
 -webkit-transition: color .25s linear;
 -o-transition: color .25s linear;
 -moz-transition: color .25s linear;
 -ms-transition: color .25s linear;
 transition: color .25s linear;
 }

The code above is directed to support each unique browser, but as you can see, the code is very lengthy in order to target everything. As the rule gets adopted, the browsers would drop their unique implementation and would then map to the non-prefixed rule at the end. To do this each time, for every rule, takes a lot of time on the effort of the web pro. Also, instructors (and I’m guilty of this as well) typically instruct with only the -webkit rule and speak to the need to do all of the unique implementations.

What has happened is that people have only implemented the -webkit version of this, either from training or for time, supporting only Safari and Chrome. Other browsers therefore don’t get the same support based on their unique implementations. The result is inconsistency and an experience that wasn’t originally intended.

In an effort to help normalize the experience with WebKit browsers, Firefox through changing the UA string will allow a number (but not all) -webkit prefixes to work in Firefox.

Is this wrong?

It isn’t necessarily wrong–Trying to provide the best experience possible is always the best goal a browser can achieve. The issue is that this is a workaround for a problem by the web pro. It also is supporting a bad practice that can add complexity later on as new capabilites are added like shaders and other new proposals to the specification process. Also since Firefox will only do this with a subset of -webkit properties, it can become complex to know exactly which will or will not work.

Even if Mozilla adopts this workaround, it should not be a crutch for web pros to rely on to support web standards. While it may be a burden to map to all of the prefix elements, to ensure the best experience for in-process properties and rules, we need to remember why and how these prefixed properites are intended to be used, and eventually retired in favor of the approved implementation.

What can I do?

So even if you are initially coding for WebKit, part of a web pro’s workflow should be to do a final pass before deploying to make sure that they have well balanced and bulletproof CSS rules in their markup. Browser fragmentation is a mess, I know, but by recognizing how prefixes were indented to be used will help ensure our web projects to work today–and tomorrow.

Change is hard, but trying to get in front of that change and ride along with it is even harder. In my talk, I mentioned how technology that we used to work with is only a small sub-section of what is needed in the industry today. With this it is nearly impossible for us to have a full mastery of the technologies that are out there today. Instead, through a deep understanding of the principles and fundamental concepts behind what we do, like with content strategy, design patterns, interaction design, and others, we can build on top of these universal concepts with technical mastery. This technical mastery is a combination of what we love and are passionate about, as well as what we can build a business around based on what is in demand.

You can download my slides from my SkyDrive using the link below:

Converging with Change

I’m happy to announce that in February, I’ll be joining the amazing team at Lynda.com as Senior Content Manager for Web and Interactive courses and programs. I’m extremely excited about the role, and look forward to working with great folks like Mordy Golding, James Williamson, David Gassner, Ray Villalobos and all of their amazing staff and community authors.

A few months ago, when I changed roles at Adobe to become a web community manager, I wanted to shift my focus onto mobile and tablet user experience design and development. I have always been more fascinated by applications than websites, probably because of the ability to tie directly to the computer or device and create something very immersive. Adobe AIR is a great technology to go to multiple devices; however, there is a “normalization tax” you have to pay to get this. While the costs of developing are reduced through having a largely reusable code base, the user experience needs to be homogeneous across the devices, plus it needs to be custom designed from scratch. Apple, Google and Microsoft have spent millions of dollars of research, design and usability testing into their components and user interface design. I wanted to harness this more and create applications that look and feel more like the native ecosystems that they were on. My first step was to play with Titanium from Appcelerator. It provides a JavaScript API for building applications using native components across platforms. The technology is very cool and you can quickly create native applications that look and feel like the rest of the OS, but there is still a lot of branching of code to provide the exact user experience for the platform. So I decided to dive head first.

It’s time to learn native development.

Now, I have been an ActionScript and JavaScript person for over ten years, so the thought of starting over and learning native app development felt very daunting and overwhelming. But after doing some research, I found that my understanding of the fundamentals of how ActionScript works makes it much easier to learn native development. It is like learning a spoken language. If you learn Spanish, you understand how to conjugate verbs, how to work with feminine, masculine or neutral nouns and how to construct sentences, commands or questions. The vocabulary or syntax build on these basic fundamental items. After learning Spanish, you can make the jump to Italian, French, or Portuguese with a lot less difficulty than it took you to originally learn Spanish. The same applies to computer languages. Learning the fundamentals of ActionScript makes it much easier to learn Java, Objective-C, or C#. The concepts are the same, but the syntax is a little different. This is one reason why when I teach ActionScript I teach HOW the language works, and not just run through a bunch of code snippets. Knowing these fundamentals allow you to transfer these skills to other languages, which in this industry is a huge advantage to have.

So I have been working with a number of books that have been teaching me about my three favorite mobile and tablet platforms: Android, iOS and Windows Phone.

I like to learn in multiple ways…I go back and forth between video based training and written books. For topics like programming, I tend to prefer written books since it forces me to type and code to see the progress that happens in the book. I find it is too easy for me to watch the video, miss a step and then just watch the video through instead of stepping backwards and finding where I took a mis-step. When it comes to books, I am pretty mobile, so carrying around bunch of heavy programming books gets cumbersome. Also, when it comes to tech books, after a year the books can become dated and take up a lot of space, so I became a subscriber to Safari Books Online and use the iPad app. You get thousands of tech books and they are easy to work with in the iPad app.

In addition to learning how to author apps for these platforms (and hopefully make a buck or two), I wanted to see how the various authors that are teaching each platform start a user out at the beginning first steps to help define how I can teach these platforms in the classroom. I love teaching and would love to cover classes around these ecosystems in the coming future and seeing how different people introduce topics like application lifecycle, workflow, best practices, and other topics is helpful to know more about the platform.

I have been jumping first into Android, but I hope to go through all three of the platforms in time. Here is the book lineup that I have decided to go with:

Android

I wanted to start with Android. I have heard that Java is very similar to ActionScript in many ways and thought it was a good place to start. I have been working with the following book:

Sams Teach Yourself Android Application Development in 24 Hours, Second Edition; Lauren Darcey and Shane Conder

iOS

Clearly iOS is the most dominant platform in terms of app sales, so that was next on the list. I have heard that Objective-C is quite a bit different in terms of syntax than other C-style languages, so I wanted to start more at the basics and see where the path goes. I decided to go with this book:

iOS SDK Programming: A Beginner’s Guide; James Brannan and Blake Ward

Windows, Windows Phone and XBOX

I have a Windows Phone. I love my Windows Phone. I want to make apps for my Windows Phone. Clearly Microsoft is pushing big for Windows Phone, but when combined with Windows 8 and the XBOX 360 console, it is a pretty powerful ecosystem to author for. I decided to try and learn all of them, but start with the desktop first. I noticed that a lot of Windows Phone books ask that you already know C#, so I got a basic C# book to start, then cover Windows Phone, then dive into XBOX 360:

Stephen’s C# Programming with Visual Studio 2010 24-Hour Trainer; Rod Stephens

Windows Phone 7 Application Development 24-Hour Trainer; Brian Faucher

Microsoft XNA Game Studio 4.0; Rob Miles

Wrap-up

So with all of that, I have a lot of reading (and coding!) to do over the next few weeks. I really am excited about learning something new—and to do something that is purposefully not Adobe to try and fully immerse myself within mobile.

I’ll provide more information along the way on how I’m doing with all of this training. For now, it’s off to Android and Java!

This week has been a struggle to say the least, but I know that tomorrow I need to go into my classroom and in front of all of my students give them answers that will make sense to them for their education and careers. This same information is relevant to anyone who has clients or customers that rely on us to make sound technology decisions to help them have successful businesses.

First, adopting Flash and AIR as a platform to build content is still a sound and strong platform for customers and to teach our students. This week though, the types of projects that you build with the platform has changed significantly from what we have been used to for the last several years. With this, where to take our customers and students now has multiple paths.

As I mentioned before, Flash in the desktop browser isn’t going anywhere. In fact, it is going to only get better when Stage3D ecosystem frameworks become more popular and available to the community. Projects like Starling are a perfect example of how Flash is a great platform for desktop browser gaming.

Next, AIR is an amazing platform to create custom experiences for the desktop, Android, iOS and Blackberry, and soon when Stage3D support comes to AIR, we will have a kick-ass gaming platform for mobile that uses our existing ActionScript skills to create great apps that can be monetized through app store and in-app purchases. With Adobe’s Creative Cloud Touch apps built using Adobe AIR, it is a safe bet that Adobe is investing in this technology for the long haul.

The Flex team at Adobe announced today that they are moving to an open development model, merging with the Spoon project and contributing the project to an open source foundation. The contributors at Adobe and Spoon will continue to collaborate to develop the technology. In a group chat tonight, a number of the Spoon project board members joined in and talked about some of the specifics of how Spoon got involved with Flex. They are a great group of dedicated community professionals, smart engineers, and otherwise awesome people who understand the world of enterprise, browser and mobile development and have been part of the Flex community for several years. One thing that was mentioned was the desire and need to have the Flex framework target more than just Flash. As someone else said—it is drawing bits on the screen, and with work, it could be adapted for other runtimes or ecosystems.

This type of outlook with Spoon and Flex is something of a shock to a lot of us in the Flash community. But now there are other technology options for the community, and from the messages of Adobe there is an underlying message that has been pretty consistent: that HTML5 will become the dominant platform for expressivity, and Flash and AIR are focusing on gaming and mobile applications.

When I face my students, that is exactly what I’m going to tell them and that they should burn this week’s news into their heads, because it is a perfect example of how technology changes affect a community at a dramatic level. What is happening right now—right in front of us, is historic. The unfolding of a technological change of this magnitude does not happen often. But at the same time it teaches us something, and it is this type of change that keeps us in this industry—because our skills and expertise are what allow our customers, clients and students to be successful and navigate the waters of technology and software.

As I said tonight in the chat, the Flash community has taking a beating this week—and they deserve some time to rant, yell, kick and scream to get it out of their systems. But we are also an amazing community that evolves and changes as the need arises.

This week, we have a new need for evolution and change, and it is within our opportunity and responsibility to do the most with it.

First off, I want to thank everyone for all of their messages, e-mails, texts and thoughts on my behalf. Leaving a company you love is always hard, being laid off from a company you love is even harder. I was very shocked on Tuesday when I heard the news about my fate, but you have all helped me get through the week and I am very excited about my future and the opportunities that lie ahead. Layoffs suck, but they aren’t personal—they are business, and while you and I may not agree with the decision, it was made for business reasons, and I’m not angry with Adobe or any of my former co-workers and peers.

Whenever you get laid off, there is always a mixture of emotions. Happiness, relief, grief, anger and fear. That is hard enough, but when you combine that with Adobe’s news on Wednesday, the way it was communicated, and the community reaction, the emotions were exponentially magnified. Now, that being said, while I want to just sit on the sidelines (or my couch) and tune it all out, I can’t—because of my love for this technology and the community that I have tried to support for many years.

I also find myself in this weird middle ground. I am no longer officially working as a community manager or product manager at Adobe; but there are NDA restrictions that prevent me from sharing the how and why of the week’s news. While I might not have my Adobe badge anymore, that in my eyes does not take away any of my responsibility as a leader in the community and speak on your behalf to the stakeholders that are at Adobe. Which brings me to an important point—the product managers, evangelists, community managers, and developer relations team members found out the news and the way it was communicated at almost the same exact time you did. They are wrestling with the news and your reaction in real time—so please be supportive of them as they dig through everything. They really really have your back and are working hard to bring your reactions and feedback to the people that need to hear it.

So, on to the news itself:

First, let’s look at the facts of yesterday’s announcement. The announcement stated that Flash Player for mobile browsers was no longer going to be developed internally, and the technology and product teams at Adobe are focusing on Adobe AIR applications for application development, and continued investment in the desktop browser plug-in.

From an engineering perspective, getting one platform to behave nicely is hard enough, but when you consider the number of devices, operating system fragmentation, and wide range of device hardware, it was going to be a huge mountain to climb. The Flash Player and AIR teams implemented a number of changes to how they make their products and how they release them to try and meet this demand; but when you look at it from a ROI perspective, the investment outweighed the benefit.

Now those are the facts of the announcement—the part that was missing and was handled poorly by communications was around the technologies and roadmaps that go into it. The flow of the information started with a press release from Adobe, that went to the press who want to get attention from their readers, so they linked the “reason” to the Steve Jobs message around Flash, which was read by all of our clients, investors, backers, and then ultimately, us. All of these individuals contacted you, the designers and developers of the platform, and wanted an explanation; however Adobe didn’t prepare the community with information that would be helpful to defend our technology choices and expertise. This then compromised our integrity to our clients; the factual technology announcement didn’t matter—it was communication flow that backed the community into a corner.

The other side of this is the perception and the fundamental value proposition of Flash: to normalize user experiences across platforms, browsers and devices and make it more efficient for designers and developers to create amazing stuff. This gap of not having the mobile player directly hits that value proposition.

Now, let’s look at this from another point of view. HTML5 on desktop browsers is a mess—low adoption, inconsistencies, etc. On mobile, the support is far better and consistent, but the app technologies and languages are the biggest hurdle now between Objective-C, C#, Java and C++. So for Adobe, the choice was to continue to help normalize the developer experience for desktop browsers, and offer the same benefit for app development using AIR. With HTML5 being “better” (not perfect—I know better than to say that), the benefit and more profound impact that Adobe could bring to the community was better tooling support for HTML5 and to have a seat at the table for those that are charting its path. That is what has driven new products like Edge and Muse that I am proud to have played a hand in their early days.

The challenge that Adobe faces with Flash, Flex and AIR is to communicate a roadmap that is reliable and long term to the community to understand and trust and take it to their clients and know that they have Adobe’s 100% commitment behind it. It is this roadmap that I feel will be difficult to deliver, since for a number of the community that work with enterprise know—the roadmap needs to be long term between three to five years. In addition, it needs to be within the mobile and device ecosystem, which has become so volatile that any roadmap will need to have significant shifts and changes since the platforms themselves haven’t provided clear roadmaps of their own. It is the silence around the lack of a road map that has been deafening—but the teams are working hard to give you the information you need to do your job and run your businesses.

Last week I started a new semester teaching ActionScript 3.0 at San Francisco State University. One of the first things I said, and I said that my recent book reflect this, was that the biggest opportunity for new developers to the Flash Platform was in making apps for the smartphone and tablet markets through multiple app stores and ecosystems. The announcements this week are a validation to that belief. In a couple of weeks, I’m also going to start my new HTML5 course where I will be featuring Adobe Edge and JavaScript instruction for creating content for browsers. As an educator and a community leader, this is where I see technology going.

Say what you will about the way the message was communicated, but know that the teams at Adobe believe in you, support you and go to bat for you every day.

I know that I do…

…and always will.

In other industry reports, Canalys also published their Q3 shipment report for smartphones. The report confirms previous reports with Samsung leading globally, however in the USA, HTC beat Samsung and Apple with a shipment of 5.7 million smartphones.

Links:

• “IDC: Samsung, ZTE see jump in mobile shipments…” / Engadget
• “Canalys: HTC overtakes Apple as top smartphone vendor in US” / Electronista

In iPhone 4S news, the offical launch date for the C-Spire network in the US, and Hong King, South Korea and 12 other countries was announced for November 11th (which is also the launch date of the Motorola Droid RAZR–see below). One notable exception was the announcement that US Cellular was offered the iPhone 4S, but turned the offer down based on “unacceptable terms” required by Apple to include the device in their offerings.

In addition, Apple has been working quickly to address the battery drain issue that has been reported in iOS 5 by pushing two updates to their developers for version 5.0.1, and 5.0.2. A ship date for the update has not been announced.

In other Apple news, the Garageband application that was formerly for the iPad has been retooled to work for the smaller form-factor of the iPhone. It is available in the app store.

Realted to the Apple app store model, Apple also made announcements that all future applications released next year in the Mac App Store (for OS X applications) will require sandboxing.

Links

• Apple Press Release / Apple
• “iPhone 4S arriving in Hong Kong, South Korea…” / Engadget
• “US Cellular: We said no to Apple’s iPhone” / FierceWireless
• “Apple to Require Mac App Store Sandboxing Next Year” / PC Magainze

The world of Android was relatively quiet for the week with information about some release dates, and information on Android 4.0 Ice Cream Sandwich adoption.

The biggest announcement was from Barnes & Noble, who announced the new Nook Tablet and a price reduction on the original Nook Color. The Nook Tablet will launch on November 16th for $249, with the Nook Color coming in at $199. Also reduced is the Nook Simple Touch, now at $99. The Nook Tablet has the same design as the Nook Color offering Netflix, Hulu Plus pre-loaded on the device. The device also supports expandable memory (via microSD) and a 7″ IPS display. The device runs Gingerbread and uses the existing Barnes and Noble Marketplace.

ASUS has indicated that they will launch the Transformer Prime on November 9th, and will release two additional Android tablets later in 2012. For the Transformer Prime, as well as the Eee Pad Slider, they will both ship with Honeycomb, but will get Ice Cream Sandwich updates at some point in the future. As a side note, ASUS also will continue working with Microsoft’s Windows platform and indicated it will ship tablets based on the Windows 8 OS in 2012 as well.

Android also recently beat Opera Mini for total worldwide browser usage according to Net Applications. In October 2011, Android’s Browser share was 18.7%, beating Opera Mini’s 13.1%. The largest share is owned by Apple’s Mobile Safari which grew from 55.6% to 62.2%.

Google released and update to the Android Market SDK (3.3.11) which adds support for auto-update by default, allowing updates to only happen when conntected to WiFi, and automatically place shortcuts on the home screen.

Motorola and HTC announced three new products the Xoom 2, Xoom 2 Media Edition and the Rezound featuring Beats Audio. Samsung also started shipping the Galaxy Tab 7.0 Plus, an update of the original Galaxy Tab shipped last year. The previously announced Motorola Droid RAZR has an official ship date of 11/11/11 at 11:11 a.m.

Finally, Engadget has provided an aggregation of the devices that have announced either officially or have been rumored to support Ice Cream Sandwich (Android 4.0) in the future. Check out the link below for more information.

Links

• “Android’s native browser beats Opera Mini…” / Android Community
• “Android Market 3.3.11…” / Android Police
• Motorola.com
• “HTC Rezound Unveiled” / Engadget
• “Samsung Galaxy Tab 7.0 Plus shipping early from Amazon…” / Android Community
• “Which devices will get Ice Cream Sandwich?” / Engadget

New Devices

Motorola Xoom 2

Motorola Xoom 2

Specs:

• 10.1″ 1280 x 720 HD display with Corning Gorilla Glass
• 1.2 GHz dual-core processor
• Android 3.2 Honeycomb (Upgradable to 4.0)
• ~630 g / 22 oz
• 5 MP rear camera with 720p HD video capture
• 2 MP front camera
• 2GB RAM
• 64GB built-in memory
• Bluetooth 2.1 + EDR

Motorola Xoom 2 Media Edition

Motorola Xoom 2 Media Edition

Specs:

• 8.2″ HD display with Corning Gorilla Glass
• 1.2 GHz dual-core processor
• Android 3.2 Honeycomb (Upgradable to 4.0)
• 20% improvement in graphics performance over the Xoom 1

HTC Rezound

HTC Rezound (Verizon)

Specs:

• 4.3″ HD Super LCD, 720×1280
• 1.5 GHz dual-core processor
• Android 2.3.4 Gingerbread / Sense 3.5 (Upgradable to 4.0)
• 8 MP rear camera with 1080p HD video capture
• 2 MP front camera
• 1GB RAM
• 16GB built-in memory / 16GB microSD
• Bluetooth 3.0 + EDR
• Beats Audio

Barnes & Noble Nook Tablet

Barnes & Noble Nook Tablet

Specs:

• 7″ IPS VividView display, 1024×600 resolution
• 1 GHz dual-core processor
• Android 2.3.x Gingerbread
• 1GB RAM
• 16GB built-in memory /  microSD slot expandable
• 802.11 b/g/n WiFi 

The recently announced Nokia Lumia 800 has a confirmed release date in the UK of November 16th. In addition, Nokia announced that the Nokia Maps application will be available to all Windows Phone devices (without voice navigation) in the Windows Phone Marketplace.

Acer announced their first Windows Phone device, the Allegro, to be released soon in France. The device will get a new feature called “Fast Charge” that will allow the device to charge 2.5 times faster than other Acer devices.

In other Windows Phone application news, Microsoft approved ChevronWP7, an application for unlocking the device allowing for home-brew applications to be tested and run on unlocked devices.

Finally, the popular Spotify music service will release their Windows Phone 7 application sometime in the next few days with feature parity with their current iOS and Android versions.

Links

• Phones Review
• “Windows Phone Mango Acer Allegro…” / Pocket-Lint
• “Nokia Maps will appear for other Windows Phones…” / Phone Arena
• “Windows Phone unlocker ChervronWP7 Labs is now live” / WPCentral
• “Spotify app on Windows Phone hands-on” / Engadget

New Devices

Acer Allegro

Acer Allegro (France)

Specs:

• 3.6″ WVGA Display (480×800)
• 1 GHz Qualcomm Snapdragon MSM8255
• Windows Phone 7.5 Mango
• 5 MP rear camera, LED flash
• 8GB built-in memory

It was a somewhat quiet week for RIM. The company announced that the BlackBerry Bold 990 and Torch 9860 were coming to AT&T this week, and the Curve 9360 is coming out November 20th.

In application news, BBM Music was released in the US, Canada and Australia with additional locations coming soon. The service integrates with the social networking BBM platform giving users the ability to share music preferences and profiles.

Links

• “BBM Music is here for BlackBerry smartphones” / BlackBerry Blog

The company behind Titanium announced that they have raised $15M in new funding, and revealed they are now the largest third-party app publisher on both iOS and Android. Their funding will be used to expand into Europe and Asia and to help expand the capabilities of the Titanium platform.

• “Appcelerator raises $15M…” / Venturebeat.com

Notable Marketplace & Ecosystem News

Amazon

Amazon and Netflix extended their content offerings with new deals with ABC, to include access to shows like Grey’s Anatomy, Los, The Secret Life of the American Teanager, as well as other series. Amazon expects to add some 13,000 titles to its Prime Instant Video service.

In addition, Amazon announced the Kindle Owners Lending Library, a new service that offers one book per month from a selection of thousands of titles at no additional charge to Amazon Prime customers. This supports existing Kindle devices and the upcoming Kindle Fire.

Finally, Amazon also released Amazon Flow, an application that let’s smartphone users to scan a barcode, check Amazon.com and purchase the product instantly from your device.

But with these platforms comes the need to have strong user experience for these applications. One of the promises for cross-platform development has been the “write once, deploy everywhere” concept, where an application would take itself and then adapt completely for a different device. I think that this can work, but only within classes of devices. In this article I’ll show some examples where this can break down and ultimately hamper your overall experience, in the next post we’ll take this further, reviewing the development options for the varying platforms as they relate to user experience.

Responsive Web Design

One of the new “buzz” terms is Responsive Web Design. The idea here is that a web site that will be viewed at various sizes will swap out different CSS style sheets to display the semantic data underneath in a different way. This is performed through a number of means including the use of media queries or JavaScript. The Boston Globe is an example of this in action:

Desktop

At the desktop version, the approach is a basic three-column website, but as you shrink the browser window down, the layout adjusts to meet this different resolution. The layout and user experience of the site continues to adapt as the window size gets smaller and smaller:

Tablet

High Resolution Phone

Low Resolution Phone

For websites, this concept is great and it allows for a single source of semantic content to have adaptability over a wide range of sizes; however, where does this apply to the mobile application workflow? Websites are about consuming content and they have a traditional flow. Applications are generally focused on completing tasks and require a stronger two-way communication with the user. Each platform approaches the transition of applications from smartphones to tablets in a different way. In this post, I’ll review three of these starting with Google and Android.

Android

The Android platform supports multiple form factors including smartphones and tablets at varying sizes and resolutions. With Android, you are able to create applications for any of these devices. If you create a smartphone application first, you are able to make the application for resolutions that are within the range of the “default” resolution of 480×800, like the Skype application running on this Samsung Captivate:

Skype on Samsung Captivate

Now this application looks pretty good, the interface is relatively clean and easy to understand, and it looks right for the screen size on this device. When you start to bring these applications to the tablet space, things start to get a little awry.

The Android platform allows applications that were designed for smartphones to work on tablets, unless the application developer specifically blocks it. This same Skype application is not blocked, so I can run the application on a tablet running Honeycomb:

Skype on Dell Streak 7

Now this is the same application running on a tablet. As you can see, although the platform allows the application to run on the larger screen, there are layout issues and significant wasted space in the UI that starts to make the application look awkward. At an even larger screen with the Samsung Galaxy Tab 10.1, the same issues are exaggerated even further:

Skype on Samsung Galaxy Tab 10.1

Other applications have the same issues, like the ESPN ScoreCenter application.

ESPN ScoreCenter on Samsung Galaxy Tab 10.1 and Samsung Captivate

When you look at these side by side, you can see even more where the issues lie. The smartphone version has a nice, tight, and easy to see format, while the tablet rendition of the same application is stretched and looks awkward because it is straining to adapt to the resolution. There are also items that don’t adjust as well, as you can see with the advertising widget at the bottom of the screen:

Ad Rendering--Smartphone versus Tablet

Looks great on the smartphone, but the tablet has it stretched and just looks sloppy. Google does provide developers the means to create tablet-only applications; however, if you recall in the previous post, there are a class of tablets (like the Samsung Galaxy Tab 7.0) that run smartphone class operating systems (specifically Android 2.2 or 2.3). In the case of these tablets, if an application has a smartphone or tablet version, the smartphone version will run, even though it is a tablet-sized device. There are some limited ways to control for this by blocking out specific devices; however, from an end user experience, it can be very awkward since then no application may be available, as I’ll get into next.

The added complexity for consumers using these devices is around application availability. Look at this example:

Search Results for "Sirius XM"

You just got a new car with Sirius XM radio installed and also got an Internet streaming account to listen to music on the go. You get home and look up the app in the Android Market and what do you find? Well, it depends.

With these three devices, the application only was available on one. The Captivate had the application, but the two tablets did not; whereas if you search for Netflix, you get that on all of the devices.

Search Results for "Netflix"

With so many Android devices available, how do you know if the applications you enjoy will be on the device? What prevents Sirius XM from being on the tablet, when Skype proved that the same application from the phone can run on the tablet with no problems (other than some user interface oddifies)? There really is no easy explanation for the consumer, which can lead to significant frustration.

One additional headache with Android devices is the difference in user interface across the platform. TouchWiz, Sense, Blur, Nook, Kindle Fire, Stock Android—these are all modifications of the basic user interface of the device, which can make user portability across devices very complex. Throw in the UI specific implementation of widgets and settings options and you can get a lot of very frustrated people trying to wrestle with their devices. For instance, all four of these devices are showing the settings for the hardware. From a user experience perspective, they are all significantly different:

Settings on Four Android Devices

Now depending on your experience level, you can probably navigate between these pretty easily; however, I always like to think of what I call “The Grandmother Test”. When I help her or other people like her with gadgets and computers, they are looking for visual consistencies that they can rely on, and that never change. Statements like “Click the green button” are easier to understand than “Click the button with the label ‘Go’”. But when one device calls something “Airplane Mode” versus “Flight Mode” and a default button skin is changed from green to blue, the “Grandmother Test” fails pretty quickly.

iOS

With iOS things are quite different with application portability, but it still leads to some awkwardness for the user experience.

Up to an including the iPhone 3GS, there was a single resolution for all of the devices for the platform: 320×480. This was for the iPhone, iPhone 3G, iPhone 3GS and the iPod touch—a single resolution for all. It made development for the platform much easier since there was consistency between them.

When the iPhone 4 was released with the Retina display, this changed things significantly for the developer of these applications, as now there was a significant increase in resolution to 6480×960. This was twice the resolution of the original phone. What was interesting about this bump was that the resolution was exactly double of the previous resolution. This had some advantages. First, applications that were created for the iPhone 3GS resolution could easily be “scaled up” by using 4 pixels for what previously used 1. Applications would continue to have the same aspect ratio, same layout, and so on. The only compromise was that there was some slight pixilation when viewing the apps on the new iPhone 4 screen. Apple did perform some sub-pixel optimization to slightly smooth out the scaling effect, but it was a compromise. The Bejeweled 2 application is an example of that, as it was originally designed for an iPhone 3GS screen and is scaled up for the iPhone 4 resolution.

Bejeweled 2 on iPod touch

Now for developers, this meant that if you were targeting either the iPhone 3GS or the iPhone 4, you would need to design for both devices. If you wanted maximum amount of visual clarity you needed to create two sets for the two resolutions.

Until the iPad came out.

When the iPad launched, one of the big selling points was that all of the existing iPhone applications available in the app store could run on the iPad. This was great news for consumers that had already invested in their favorite apps for the iPhone. But there was a catch. Since the iPad resolution and aspect ratio were significantly different than the iPhone these applications were run in a unique window within the iPad screen. Specifically, the iPad is a 4:3 aspect ratio device with a resolution of 1024×768, iPhone 3GS designed apps, when run on the phone, displayed within a little box in the center of the screen.

Bejeweled 2 on iPad

Now this is obviously ludicrous to waste so much space on the device, so there is a “2x” button that essentially does what the iPhone 4 does: scale up the app to twice the originally designed size. The only issue was that the aspect ratio was different, so there are black areas around the application window to make up for the difference.

Bejeweled 2 Scaled Up on iPad

With such a large screen however, the pixilation effect that was not as noticeable on the iPhone 4 started to clearly show for scaled up iPhone 3GS designed applications.

Pixilation

With this new tablet form factor though, there were obvious advantages that could be used, but the challenge still existed for bridging the user experience with the smartphone versions. The advantage of Apple’s platform is that there are only a handful of devices that are part of the ecosystem. The iPhone/3G/3GS/iPod touch, iPhone 4/4S/iPod touch, iPad/iPad 2. Multiple devices—but there are only three resolutions to design for. With this, it is possible to make applications that can cater to these different form factors more easily, as shown with the Sirius XM app.

SiriusXM on iOS

But this ideal situation for design has developer handicaps. First, is the fact that the OS version on the device can be very inconsistent. Ranging from iOS 3, 4 and now 5, it is possible to have any of these for the devices. A large reason for this is due to the fact that a number of users never connect their phone to their computer, or they have elected not to update their devices when they sync with their computer (which also for the record exists with other platforms including Android and Windows Phone). Apple is attempting to make this fragmentation issue easier through the use of cloud services in the future to avoid a much worse fragmentation issue that exists with Android, but it exists nonetheless.

But even with handicaps, what is a clear benefit for the end user, when compared with Android, is that availability of the application in the app store is generally guaranteed (outside of OS version and hardware requirements) so there aren’t as many arbitrary or mysterious reasons why applications are or are not available across devices like there exists on Android.

Windows Phone

When Windows Phone 7 launched, it was a complete reset on Microsoft’s smartphone strategy. Their previous platform has beginnings all the way back to the Windows CE embedded operating system that was used on personal digital assistants in the early 2000s. Windows Phone 7 was something very different and very new for the company, and being late to the party when compared to Apple and Google made things difficult, but they were able to learn a few lessons from some of their competitors.

Now at 7.5, Windows Phone devices support a single resolution: 480×800. All devices that are on the platform use that screen resolution, regardless of the physical size of the device. While this may seem like a significant limitation it does provide significant benefits for developers. It means that there is only one resolution to target.

Windows Phone 7.5

The challenge is what will happen in the future. With phones like the HTC Titan having much larger physical screens, the desire to get higher resolutions would be advantageous for developers that want to have more refined and detailed user experiences. There are reports that the platform will support varying screen resolutions in the future; however, the biggest challenge is how they will support them. Will they take an Apple route where there is a more constrained aspect-locking approach to larger screens, or will they go the Google route with adaptable layout based on varying screen resolutions and aspect ratios. Simplicity for this platform has advantages today, but there are big unknowns regarding where it will go in the future.

When it comes to tablets, we need to remember that Windows Phone 7 is only for smartphones. If you recall, this is because Microsoft’s future strategy for tablets is with Windows 8, the successor to their Windows 7 desktop operating system.

Windows 8

While this makes user experience design easier for smartphones, it does make it more complex for tablets. This is because, based on a desktop legacy, there are dozens of possible screen resolutions for desktops, notebooks, netbooks and tablets that the operating system can target. To combat this, Microsoft has stated that their tablet-friendly Metro UI will only support resolutions that are greater than 1024×768, which pushes out popular netbooks or tablets with a vertical resolution of 600.

Windows 8 Full Screen Metro Application

But in the case of Windows 8, the question is how traditional Windows applications will co-exist with their new tablet-friendly counterparts work in this mixed system. In Windows 8 there is a decidedly two-sided world of Windows Desktop (what I’ll call the old Windows 7 UI) and Windows Metro (the new UI designed for tablets). You can have the two co-exist in a side by side orientation that can dock scaled down versions of Metro applications to the right or left of the Desktop.

An interesting new twist is then added to the tablet user experience design, and that is multiple forms for the same app. For example, a Metro application has to have the full-screen version, and the side docked version. These are obviously two very different views to the same app, combined with the fact that the other side docked app could be another Metro app, or the Desktop.

Windows 8: Metro and Metro Side-by-Side

Windows 8: Metro and Desktop Side-by-Side

With this, there is a very different mixture of user interface modes and presentations that can have impact on end users that will be experiencing this for the first time. The compromise though is that users will have full desktop functionality on their tablet devices and can use existing desktop software that they already use, combined with external peripherals.

Wrap Up

This is only the beginning to give a high-level view of user experience for these various platforms and the issues that they cause when migrating to different classes of devices; however, these are all devices that consumers are or will be buying and as a community we need to determine the best course of action for how these devices will serve the needs of the end user.

To which brings us to how these applications are made. In my next post, I’ll talk more about the varying native and cross-platform technologies that can be used to create these apps, and where there are gaps or potential issues in how you use them.

Over the last few months I have been working with tablets in various form factors and platforms. My first dive into the form factor was with the iPad, and then I started working with Android tablets using a Dell Streak 7 and then a Galaxy Tab 10.1, which was running Froyo and Honeycomb respectively. Most recently I bought a Dell Inspiron Duo, a convertible netbook that becomes a (really thick) tablet, and have been using Windows 7 and the new Windows 8 Developer Preview on it.

Each of these have components that have worked well for me, and some that have not. So I wanted to share some of my experiences to see if others can benefit and to try and drive better user experience for tablet applications.

The Device Continuum

To me in terms of capabilities and interface, there is a continuum for working across devices. Now, this is just my personal view of the space—and isn’t based on other sources, including my employer Adobe Systems, but it is how I see the world:

For me, as a user, I move through this spectrum from phone through desktop throughout the day. The tasks and activities I need to complete generally dictate what device or system I reach for, or determine the priority of what I’m able to do when I only have certain devices available. All of this probably seems pretty common sense; however, there is an interesting difference of strategy from the ecosystem drivers in how these devices fit together.

First, the phone is meant to be held in a single hand, and the user interface is rough and imprecise, optimized for use with a finger to work with applications. Functions on a phone are more task oriented and mostly focus on reference. For example, checking e-mail, looking at your schedule, finding contact information, or sending a text message. In addition, the phone has become a primary way to access media content while on the go, perfect for waiting for the bus or train, or passing time through media syncing or streaming services.

The tablet builds on the mobile experience in that it is meant to be used with two hands, and newer devices are adding to the touch UI with pressure sensitive stylus input that increase the precision that you can achieve with the device. With this added precision, and the ability to link the tablet with Bluetooth keyboards users can more easily manipulate existing content and do basic content creation within the constraints of the hardware. The tablet does limit portability in that it can’t be easily stored in your pocket, and you can’t access your tablet in as many situations as you can a mobile phone.

Finally, the laptop or desktop is the least portable of the three classes of devices, but it does offer the most flexibility and power to control your input options and your level of content creation. In addition, the ability to connect to multiple display devices, including 3D enabled screens increases the media consumption options for video and games.

Path of Innovation

With the iPad and the various Android tablets, the approach has been to take the functionality of the phone and bring it to the tablet. In that vein, some of the refinements of the tablet experience have made it to the laptop as a result:

For iOS, the innovation started with the phone with the iPhone and iOS 1.0. This then made it to the tablet as the iPad and the operating system has grown with it to provide additional functionality to support the new form factor. At this point, some of the iOS interface elements have made it into OS X Lion (although not without criticism), taking the technology up through the chain. What is interesting though from this path is that the applications themselves aren’t able to grow with the form factors. iPhone apps can run on an iPad; however, there is no path for the tablet apps to make it to the laptop form fractor. In fact, even from a developer’s perspective, the approach and technologies used to make the application on the laptop are different than the tablet. Apple has tried to even this out through vehicles like the Mac App Store (with the nice side benefit of a monetization and revenue share from each sale), but ultimately the experience and applications consumers use break from the chain.

Google with Android has done something similar; however, they broke the chain with their OS when they released Honeycomb, where they wanted to create a unique tablet experience based on Android. When Honeycomb was released, Gingerbread was released alongside, as the successor to Froyo. What is unique about this roadmap was that Gingerbread was a refinement of the previous Froyo system and was used for mobile phones (shown with a red outline), where Honeycomb was a significant departure from the previous chain and was used specifically for tablets (in yellow outline). Honeycomb was also a great way for Google to experiment with tablet-only user interface constructs that were better aligned for the larger screen. Even though Honeycomb was available and made specifically for tablets, there were still tablet sized-devices that were using Gingerbread, even though Gingerbread was intended only for phones. As a result, there was a significant increase in fragmentation across the operating systems compounded with the difficulty of carriers and handset manufacturers being able to push updates to older OSes like Froyo or Éclair. Recently Google announced Ice Cream Sandwich (Android 4.0) which is a unified platform for smartphones and tablets; however, it is too young to see what the application ecosystem will look like with the latest version of Android.

Now Microsoft has approached the problem with a reverse perspective. We may look back and snicker at the Tablet PC initiative they pushed about a decade ago with the Tablet optimized version of Windows XP, but their opinion then still stands today with their vision and preview of Windows 8: A tablet should share the application ecosystem and the productivity level you have come to expect from a laptop in a tablet form factor. Their approach takes the experience of the laptop and brings it to the tablet, but with a catch. Now, instead of the laptop ecosystem being the broken link in the application ecosystem chain, the mobile phone is the break.

With Windows 8, the applications that are part of the laptop ecosystem can run in a tablet form factor with an improved tablet user interface model over previous attempts in Windows 7. These applications though can’t transfer to the mobile phone, and like with the previous example, the tools and technologies used to make the software are very different and require additional work to create the mobile versions.

But Microsoft has done something rather unique with this situation, and that was to introduce the Windows Metro UI from Windows Phone 7 to Windows 8 and replace the Start Menu with an entirely touch optimized UI model on top of the traditional Windows desktop user interface. It isn’t known if Windows Phone 7 applications will be able to run within Windows 8 without modification (something that would really change the ecosystem significantly), but this would significantly repair the break in the ecosystem chain. On the Mac side, OS X Lion introduced a feature called the full-screen application mode, which essentially allows an app to take full control of your screen and interface. This mode could be the way to bring iPad applications to the OS X desktop; however, Apple has not stated if this is the roadmap plan.

With the confusing transfer of applications from device to device mixed with varying platforms and fragmentation, there are significant user experience issues. I’ll review some of these in the next blog post.