If you are considering building your mobile channel, will you choose to build a mobile app or should you build a mobile Web site?

Before we get into the finer points of this debate, we can ask a few qualifying questions first:

1) Do you need to access the phone’s camera?
2) Would you like funtionality available regardless of whether the phone is on the Internet (online or offline?)
3) Would you like to access the phone’s contacts?
4) Would you like to access the phone’s location or other core features (e.g. accelerometer, bluetooth)

If the answer to any of the above questions is yes, then your choice is simple.  Build a native mobile app.  If you did not answer yes to any of the above questions, here are some guidelines you can use to think about this question:

Native mobile apps

• Pro: Access the phone’s core features (see #1-4 above)
• Pro: Faster user experience (apps can more easily handle caching on the phone client)
• Pro: Richer user interface and user controls (more dynamic/graphical)
• Con: You may need to build multiple apps — one for each device: iPhone, Android, Blackberry, Symbian

Mobile Web

• Pro: A single mobile Web site may work on multiple phones (through each phone’s browser)
• Con: May be slower (more latency)
• Con: Less attractive user experience
• Con: Cannot use phone’s core features
• Con: Cannot work online/offline

There are some who believe that a new browser technology (HTML 5.0 and CSS3) will enable the mobile Web to become more competitive with the user experience of a mobile app.  This may narrow (but not close) the performance gap in the future.  In the meantime: If you choose to build a mobile Web site, you’ll spend less money and potentially reach more devices with a single solution.  If you choose to build a mobile app, you can take advantage of more features and capabilities on the device, the location of the user, etc.

There are two other trends to keep in mind:

1) Smartphones (can run mobile apps) will overtake feature phones marketshare in 2011.
2) 74% of smartphone traffic is on iPhone or Android

According to AdMob, if you choose to build mobile apps, iPhone and Android will enable you to reach 74% of mobile users as of Feb. 2010.

Wow, Google may be about to become a 21st century Ma Bell. Instead of the government stepping in and saying we’ll provide the infrastructure for a next generation of high speed (100 times today’s speed) for consumers and businesses, looks like Google might. Google says that it won’t be a service provider, will allow others to resell.  On the positive side, we’ve all been hijacked into paying huge fees to Comcast and other service providers, so perhaps we’ll have more choice and lower costs?  On the other hand… maybe Google is just organizing the next expensive oligopoly?

HTML5 may be the biggest innovation in browser technology since… perhaps Netscape.  It’s really a game changer.  I was fascinated to read that Google will be sunsetting Gears in favor HTML5 , though it makes sense given that one of HTML5 coolest features is that it’s designed to support the sometimes connected computer.  This means that you’ll be able to continue to interact with Web sites or Web/SaaS applications when you’re offline, they will sync up when you’re back online.  Google implemented Gears for that purpose, but when HTML 5.0 is available, it will support that.  We’ll soon be able to take advantage of the Cloud even when we’re offline.

(Incidentally and ironically, I write this while flying at 35,000 feet on a wifi connection, so fortunately those offline pockets will become fewer and fewer in the future!)

Check out Google Wave, perhaps the biggest e-mail innovation since the 1990’s switch form Pine to desktop e-mail. See http://wave.google.com, the video is about 1hr 20min. The short story is that Google has created some really amazing innovations rendered in HTML 5.0 (which is also about to change the way you view the Web). The innovations include (a) merging chat and e-mail into a single app, (b) the ability to view e-mail as waves of collaboration that allow you to revisit, edit, append, and converse by thread, (c) highly integrated text, photos, gadgets, and feeds, and (d) if you join a wave late, you can “play” the wave sequentially to see who added content in the flow.

There was a time when icons were just lowly functional images, to be seen, but not touched.  Their only human computer interaction comprised the occasional click of a mouse.  Well, that’s all over now baby!  Icons are all about touch these days, especially when it comes to iPhone applications.  Now we need to make clear and memorable icons that also have a target size for a wide range of human thumbs, large and small (and even index fingers, any of you out there?) .  It’s important to remember that in the brave new iPhone world where icons are to be seen AND touched, traditional approaches for iconography still apply.  Here are some best practices that we recommend:

• Simple — keep the design and colors visually simple
• Memorable — icons should be easy to associate and remember
• Familiar  — use iconography your audience will find recognize and associate rapidly
• Consistently styled — a group of icons should have a similar look
• Differentiated — don’t make one icon too similar to another
• High contrast — icons should have strong contrast to make them scannable
• Contiguous — icons should have a single contiguous image (not two images as a compounded icon)
• Consistent lighting — use shadows sparingly so the image is clear, use a consistent lighting source

Oh yes, and don’t forget to make ‘em big enough for my thumb.

As it turns out, according to research conducted by Chris Wilson at Slate and Prof. Lauren Ancel Meyers at the University of Texas, the “25 random things about me” trend on Facebook mirrors the “classic exponential growth of an epidemic curve.”  By way of background, many people on Facebook have been writing down 25 random things about themselves and then tagging 25 people with whom the information is shared.  As it turns out, each author is “contagious,” because among the recipients of the message, a predictable number of them produce a list of their own, and in turn, tag another 25 people.  The pattern of growth across the system follows a classic viral marketing curve that Prof. Meyers says replicates an epidemiological system exactly.   Here is the original article.

It would be interesting to study further the pattern of growth within viral marketing systems and the factors that contribute to the speed of that growth and decline.  For example, if we were tagging only 10 people, not 25, would the “virus” spread more slowly, but nevertheless, reach the same level of adoption within the system, just at a slower pace?  For example, once the trend has run its course, if 18% of Facebook users ultimately create a “25 random things” page, would that number remain the same if we tagged 10, not 25 people (tagging 10 people takes less effort)?  Alternatively, would more (or less) people participate if you only had to tag 10 friends instead of 25?  In the world of social computing, there are many potential levers to create viral growth, and we’re just beginning to understand what works best and how to optimize the effects.

Having been a Web consultant since 1995, I have learned a thing or two about bubbles.  As the dotcom era of the 1990s transitioned from irrational exuberance to disillusionment, the most important common denominator was the irrationality of both extremes. In recent years, Web 2.0 and social computing have driven a wave of investment with some people now concerned about another bubble.

The problem with the bubble metaphor in technology is that it implies an ephemeral, fragile, and rapidly rising trend which… pops.   The truth about the past dotcom bubble is that now, 8-years after the “pop” none of us could imagine running a modern corporation without e-mail and a browser on our desktop, to say nothing of E-Commerce, VOIP, chat, etc.

The term bubble is an oversimplification of a short-term speculative boom & bust, and most importantly, it is misleads investors, enterpreneurs and the public from a sustained and rational confidence in an underlying trend of lasting innovation.  This is not to say that there aren’t winners, losers, and lessons to be learned in the advent of any new technology, but social computing is here to stay.  We’re in the midst of a revolution in collective intelligence, with thriving and vibrant online communities breaking down boundaries between public and private life.  This is changing the way we work, play, and collaborate forever.  We’re really at the beginning of a new era in social computing, and a there is nothing temporary about it.

Firstly, a note of thanks to colleague Hal Reed for introducing me (and now you?) to the term deprovement. Hal defines deprovement as “a change that is intended to improve something, but in actual practice makes it worse, e.g., harder to adopt, harder to use, or less reliable.”

In the world of software or Web applications, deprovement is all too often what occurs when a company enthusiastically announces their next release. Today, I was inspired to learn that Mozilla added an honest to goodness improvement in their 3.0 release of the fast growing (and excellent) browser Firefox. Their secret: Version 3.0 is reported to run “more than twice as fast as the previous version while using less memory!”

How many times have you opened the newest release of a software application only to find that the latest improvements and new features have substantially deproved your system performance? This is even more serious for a large scale Web site or Web application. As an industry, let’s try to remember that speed is one of the most important elements of software and Web site usability!

For applications that have not been well structured for internationalization (I18N), the prospect of extracting and then replacing localized strings is a little like removing 30% of the strands of spaghetti in a bowl of pasta and then putting them back where they belong. If that’s not tough enough, each new strand may have to change color at a moments notice depending on who’s eating the pasta.

Even for other applications that have relatively well externalized strings, there still remains a daunting challenge of managing the text extraction, delivery to the translation partner, then reinsertion of translated code. As it turns out, the using the XML Localization Interchange File Format (XLIFF) is a great way to simplify and scale this process while making it much more efficient.

The underlying issue that led to the creation of XLIFF is the problem of format. A translator frequently receives source documents for translation that may be in diverse formats such as Microsoft Word, Txt, HTML, RTF, and XML (with an unlimited variation of DTDs). Translators first have to deal with the challenge of simply reading the source file. This requires identifying and potentially obtaining and installing the right software package. It’s not enough to have Microsoft Word or Adobe Framemaker, but also each translator needs to have the right version of that software. We can only picture the late nights and multi-hour support phone calls required by the IT staff charged with the impossible task of setting up and maintaining these workstations.

“Hello, this is IT helpdesk, how can I help you?”
– “Would you please install Framemaker 6.0 on my workstation?”

“ Pardon me, but didn’t I just install version 7 for you yesterday?”
– “Yes, but that was for a different job, and this file doesn’t open in the new version.”

“So would you like me to uninstall version 7?”
– “I am still working on the prior job, I need both version 6 and 7!”

The problem of format is not just confined to the translator. Publishers and software developers have the challenge of extracting and sending text (strings) from documents or applications for translation. How can you be sure that the sentence or string that you extracted from your source can be reinserted in exactly the same place? In other words, each strand of spaghetti must be uniquely identifiable. The easiest way to do this is to attach little tags on the ends of each strand of spaghetti with some additional information about that strand (like attributes).

Fortunately, there is an organization that is dedicated to solving these kinds of standardization problems. The Organization for the Advancement of Structured Information Standards (“OASIS”) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. In February of 2008, OASIS members approved the XML Localisation Interchange File Format (XLIFF) version 1.2 as an OASIS Standard, a
status that signifies the highest level of ratification.

The Bryan Schnabel, the co-chairs of the OASIS XLIFF Technical Committee describes XLIFF very simply as follows:

– XLIFF is “[a] powerful and concise format for content that needs to be translated. ”

For a company seeking to build or better manage a global Web site, XLIFF provides far greater efficiency in the setup and maintenance of content for translation. The XLIFF schema remains stable even if document format changes or software code features change over time. For the translation service provider, XLIFF greatly reduces the complexity of managing source file formats and technologies and allows translation service providers to focus more of their time and resources on the work of translation itself. For both localization customers and service providers, XLIFF also provides workflow metadata providing better communication between both parties throughout a translation lifecycle. In sum, XLIFF greatly simplifies the challenge of selectively removing and replacing multicolored spaghetti from your bowl of pasta.

Recommended Reading

OASIS Standard for XLIFF Version 1.2

OASIS XLIFF FAQ

Forget the iPhone, if you want to browse the Web while on the move, this is the best way to do it! Eliot and I found this handy Web kiosk in a McDonald’s drive-thru on Rt. 128, just south of the Mass Pike! Leave your iPhone at home and don’t spill coffee on the keyboard!