Skyfire and the Mozilla platform

Congratulations to Nitin, Erik and the whole Skyfire team on the beta release of their mobile browser, and the great reviews and feedback they’ve gotten.

It’s great that the Skyfire team is using the Mozilla platform to give their users a true Web experience. As Nitin said on the Skyfire blog:

With a simple mission of “PC web experience”, the choice was easy. Firefox has great compliance to standards and to content. My wife uses Firefox on her Mac because many Indian web portals wouldn’t work well on Safari. Finally, the vibrant developer community made that decision very easy and simple for us.

I visited the Skyfire offices yesterday, and could feel the excitement that’s always in the air around a new product launch. I love the fact that the Mozilla community and technology is strong enough to build a business on.

Skyfire, welcome to the club.

Does “Send to Phone” matter?

Joey is a Mozilla Labs project that enables people to send information, including text, pictures and video, from the Web to their mobile phones. Doug Turner has kicked off a discussion on the Mozilla Labs forum about what we’ve learned about Joey and what we should do with the project going forward.

As Doug points out, we need to look at the big picture, and broaden the discussion to consider any and all ways in which we can leverage Firefox on the desktop to improve the mobile experience. I will be writing more about this.

But for this post, I want to stick to an evaluation of the Joey value proposition, explain why I think the basic approach taken by Joey could remain valid even as mobile browsing improves and get your feedback.

The basic user behavior promoted by Joey, that of capturing information found using a desktop PC and explicitly sending it to a mobile device, can be useful. This user behavior will be superseded to some extent by improved mobile browsers, and yet further by the introduction of an online services component that implicitly makes Web browser history, bookmarks and other browsing metadata from desktop Firefox available on mobile phones. However, explicitly sending content could remain useful for some time to come, regardless of how good mobile phone Web browsing becomes.

Why?

Because even if the mobile browsing experience is good, capturing a small piece of information that you need to retrieve quickly while on the go, or share with someone else, is fundamentally different than returning to an entire Web page.

A Joey “snippet” can be the result of a relatively laborious session, requiring cookies, logins, a shopping cart-like process, POST data, or some other chain of events that can’t be quickly and easily reproduced on a mobile phone. Yet the resulting snippet can be very important, like a booking or purchase confirmation code, an address or phone number, or a list of movie or train times. You may want to send the result to your own phone, or to a few different phones to meet up with people.

The value in approaches like Joey is that they enable people to easily use the Web in research mode at a desktop (or laptop) computer with its big keyboard, big monitor and mouse. When people step away from your computer into the real world, they often want to take the results of that research with them. It’s important that those results are easy and instantaneous to access (which may mean using SMS when the content is small and text-only).

All that said, I don’t think Joey, or Yahoo! Local “Send to Phone”, or the Google “Send to Phone” Firefox Add-on have set the world on fire. Or have they? Are these all solutions looking for a problem?

Does “Send to Phone” matter?

Picking up where you left off

Last week, Chris Beard kicked off what will be a valuable discussion about how we could leverage the capabilities of the network itself to “…further enhance the user experience, increase user control over personal information, and provide new opportunities for developers to build innovative online experiences.”

There are lots of areas to dig into, but as a starting point, I’ve been thinking about how we can improve the personalization of the Firefox experience by taking advantage of an online platform component, and specifically, how we can make the personalized experience portable.

Firefox makes it easy for people to customize their browser interface to suit their unique individual needs. And Firefox itself accumulates information through its use like history, bookmarks and form-fill data that makes the interface even more useful and personal. Most of us have experienced this first hand. Have you ever sat down at someone else’s computer or used a fresh install of a browser?

Because Firefox stores this information locally, as soon as you step away from the PC where that information has accumulated, you’ve lost your window on the Web.  Sit down at another computer and you’re back to a generic experience.  Try to use the Web from your mobile phone, and you need to do a lot of work just to find the information you’ve already found at your desktop.You can’t just pick up where you left off.

The number of people using multiple computers to access the Web is growing.  Use of shared computers in schools, cyber-cafes, libraries, and at home is expanding.  And while it’s still small in absolute terms, mobile use of the Web is finally becoming a reality.  Because of this evolution in our use of the Web, picking up where you leave off will become more and more important.

There are point solutions to pieces of the puzzle, such as browser synchronization utilities.  But making the personal experience portable is about much more than sync.

Moving browser metadata into the cloud, putting APIs, encryption and access control around it, and giving the user control of its disclosure and transparency into its uses could enable new user experiences that are appropriate to the human activity the user is engaged in, and the device being used, not merely synchronized images of a Firefox desktop experience.

Here are just a few of the things I’d like to be able to do in this area that may be facilitated by an online component:

• I want access to my personalized view into the Web on any PC, mobile phone or handheld computer.
• I’d like to be able to walk away from my PC, pick up my phone and head out, and then by using something like the Firefox 3 Location Bar, tap just a few keys to pick up my browsing where I left off.
• When I’m out and about, and encounter (in conversation, on a billboard, on the radio, etc.) something that I would like to learn more about when I have the time and a bigger screen, I’d like to be able to capture that interest easily through my mobile phone and have it queued up for reading/research later.

Making the personal user experience portable is just one of many results that could result from introducing an online services component to the Mozilla platform; and this post just scratches the surface on how that personalization could work

What ideas do you have?  Come join us at the Mozilla Labs forum and help us figure out what we could do.

Both far off and inevitable

In today’s Sunday Times, Michael Fitzgerald gives a status report on the Mobile Web in Mobile Web: So Close Yet So Far.

A survey cited in the article gives a feel for where the “Mobile Web” is in the technology adoption lifecycle:

…only 13 percent of cellphone users in North America use their phones to surf the Web more than once a month, while 70 percent of computer users view Web sites every day. (Yankee Group)

Mr. Fitzgerald’s article focuses on these reasons for the poor adoption to date:

• Poor usability
• Confusing pricing
• Closed to innovation

One statistic quoted in the article gives a hint of the business imperative that helped lead to some of the walled-garden network operator behavior that has slowed down innovation:

Caroline Gabriel, an analyst at Rethink Research…said data would make up only 12 percent of average revenue per user in 2007, far below the expected 50 percent.

Why is this statistic telling? Average revenue per user (ARPU) is one of the key metrics for operators. It’s pretty simple: once you’ve got a new customer, lock him in with huge contract termination fee (check); and make as much money as you can from him every month. To recoup their multi-billion dollar investments in 3G networks, the amount of mobile data revenue they needed to generate had to grow to be a significant chunk of that monthly bill. The people responsible for managing the mobile Web experience had aggressive numerical data usage and browsing targets as their personal and group business objectives. Their general response to meeting such tough objectives was to “program” a set of services onto the limited screen that they felt had the best chance of getting good usage.

This strategy, of building a vertically-integrated walled-garden, was understandable, if misguided. At least it was something you could build a business model for: If x% of people adopt service y, and use it for z minutes (or kilobytes) each month, we will generate such-and-such dollars of revenue. That’s easier to explain to your boss than “well, we don’t know what developers will do, but they’ll do something, and it will be really cool” and then build a business model around that. Especially if your boss is from the telco world, where innovation from outside the firm has never been trusted (remember, when you had to rent your phone from AT&T?). The thesis: short-term revenue and usage pressure leads to the exercise of more control because of the illusion that control will lead to more predictability. That control instead chokes off innovation, and because it’s hard to predict what will work, you can’t “program” success.

Later in the article, Tom Huseby nails this issue:

You have to have open systems, to allow the vast creativity of people to take place

This is obvious to Web people (especially in the Mozilla community), but the fact that it still needs to be said in the mobile Web world is pretty telling.

On the user interface front, I don’t believe that either the widget-based systems, or the pure voice-driven systems mentioned in the article, are panaceas for the user interface challenges, though they are part of the solution.

Mr. Fitzgerald closes the article with this:

For now, widespread use of the mobile Web remains both far off and inevitable.

This captures it: there is a lot of work to do. But, there is no question that people want access to the information and services they care about when they’re on the go.

Mobile and the Mozilla manifesto

In my last couple of posts, I’ve tried to provide a little context about mobile and how changes in technology are creating an opportunity for a transformation of how we use the Web on mobile phones from that of a dumbed-down, non-standards-based “mobile Web” to the Web.

Coming back to Mozilla’s manifesto, and the changes happening in mobile, where is there an opportunity for Mozilla?

Not an opportunity, a responsibility
My read on the Mozilla manifesto tells me that there’s not only an opportunity presented by mobile, but that we have a responsibility to help crack open the mobile environment. Why?

• For millions of people, mobile phones will be the primary way, if not the only way, to access the Web; for this reason alone, we need to be involved to meet our mission of protecting an open Web
• Firefox and the Mozilla platform are being targeted by developers as a primary platform for the development of rich Web-based applications; we have a responsibility to those developers to help them extend their reach to mobile
• Many of the issues in migrating toward a toward a better Web experience on mobile phones will be intertwined with technology that Mozilla is deeply involved in: for example, JavaScript and its manipulation of XHTML, CSS and DOM to enable Ajax applications

Some goals
If our mission commits us to playing a role in mobile, what should some key goals be? Here’s my initial take:

• We should build versions of Firefox that provide access to the (standards-based) Web from phones and other non-PC devices, while recognizing that this doesn’t necessarily mean forcing developers into a one-size-fits-all-devices user interface for their Web sites and apps
• We should support our developer community with a migration path, guidelines and tools that help them deploy their apps to mobile devices; done properly, this will spur broad innovation in Web-based mobile phone apps
• Just as on the PC, anyone should be able to incorporate Mozilla technology to build branded browsers (as Nokia has done for the N810) and applications

What would you like to see us do?

From the “mobile Web” to “the Web” on mobile

In yesterday’s post, I tried to make the case that, even while slowly opening up from a theoretical perspective, the mobile Web is still pretty closed in practice because we haven’t made it easy enough to use to attract and retain developers and users.

What’s changing? Can the mobile Web be made open?
Device capabilities — processor power, memory and storage capacity, etc. — are improving quickly now . These capabilities will trickle down to lower-end phones over the next couple of years. Typing is getting easier, though on phones without (physical) QWERTY keyboards, things are still pretty rough. Networks continue to improve in speed, and many devices have built-in WiFi now to make things zippy if there’s an open hotspot nearby. All of these underlying advances will get us to a point where a proper Web browser can run without too many compromises

Moving toward one Web
On the desktop, the Web is on a path to providing a level of interactivity that is becoming good enough for many classes of application. The Web browser provides the application container and abstraction layer that lets developers use one set of technologies to target all platforms: HTML and XML, CSS and JavaScript combined with the server-side stack of their choice.

A true flourishing ecosystem of rich mobile applications on mobile won’t be triggered until the same Web-standards based stack works more or less as-is on mobile, and is broadly deployed — that is, not just on very specific handset/browser/operator combinations. There’s one Web, that’s the platform.

When the platform is up and running, “normal” (i.e., not just “mobile”) Web developers will be able to deploy their rich apps to Web-capable phones and other mobile devices. We need to build upon open standards so that each user can experience as much of the Web as possible, and not experience some parallel, compromised Web; and so that each developer can create Web sites and applications without the pain that’s involved today.

But don’t forget, it’s a phone
This isn’t to say that there isn’t specific functionality, use cases and challenges associated with mobile, nor that one single *rendering* of a site or application is the best fit for all devices. On the contrary, mobile creates new use cases and opportunities (for example, use of GPS, SMS messaging, voice calling and address book functionality), and presents some new constraints. Many sites will, and should, choose to create additional user experiences that make sense given the form factors involved. “Widget”-type user interfaces make good sense in many cases. But rather than implementing mobile-optimized versions of sites on, say, a WAP stack, though, standard Web technologies can and should be used.

I realize that I glossed over the hard part by saying the the stack needs to work “more or less as-is” on mobile. The evolution that gets us there has many components that we need to sort through, for example, what it’s going to take to migrate AJAX functionality to mobile browsers. We’re digging into those details now and want to work with you to figure out what’s best.

Summary
The technology has advanced to where we can contemplate wide deployment of proper Web browsing on mobile phones. We won’t use “the mobile Web”, we will use “the Web” from mobile phones. It will be built on Web standards, but developers will still want to optimize the user experience for mobile.

Next post
What does this mean for Mozilla? What should our role be?

How open is the mobile Web?

As Schrep wrote a few weeks ago, Mozilla is serious about mobile. He outlined at a high level why it makes sense for us to be in the game, what our plans are, and some hiring we’ve done to kick-start the effort.

The Mozilla manifesto champions the principles of openness, innovation and opportunity. Applying those principles to mobile, some of the first questions that seem relevant are: How open is the mobile Web today? Why should Mozilla be involved? How should we be involved?

This post tries to set the stage with a few thoughts on the first question: How open is the mobile Web today?

The recent debate about “open access” in the coming FCC auction of wireless spectrum, and controversy about iPhone unlocking and third-party hacks, have increased the visibility of openness issues in the mobile environment. There are challenges at every layer of the technology stack and in business models.

Pertaining most directly to Mozilla is the question of how open and accessible the Web is on mobile phones. Obviously, there’s variance across geography and across manufacturers and network operators. My personal experience has been mainly in Europe and the US.

The short answer is that the state of affairs is not very good, though it is slowly starting to improve. Despite the multitude of great ideas that individual developers have for useful and fun mobile phone apps that leverage the Web, there has not been the explosion of an ecosystem where using the mobile Web is a natural and everyday activity for most people, as was predicted when it was publicly launched (around ten years ago now!).

(Note: There have been pockets of success. In Japan, NTT DoCoMo successfully created an end-to-end ecosystem that spurred a lot of innovation and usage. That has not been replicated to the same degree elsewhere, but we’ll save that for another post.)

It’s tough on the little guy
Sometimes, openness has been inhibited by network operator gatekeeping. For example, for a developer to distribute an application through a carrier’s application catalog or mobile portal, the developer often needs to go through a carrier approval process and this involves business development, travel and connections that are beyond the means of most small companies and individual developers. Partnering with device manufacturers can help, but has similar challenges for individuals and small firms, and each carrier still makes the final determination on what gets distributed with each handset. (This is changing, but it’s early days yet on contract-free manufacturer-direct sales to consumers in the US. Handset-only sales in Europe are more significant.) In the last couple of years, “off-portal” application sales have started to increase, as some people have gotten to the point where they can find and install third-party applications. This has provided some relief to small developers as third-party marketplaces have emerged. Why does this focus on the “little guy” matter? Because innovation tends to come out of left field, from new entrants.

No excuses
But let’s assume these barriers didn’t exist. After all, if the services were all that great, I like to think that the carriers would let folks get to them and find a way to monetize them. But, even when access to apps and sites are “allowed” as is more or less the case today, the usability barriers have been so high as to essentially drive users back to the walled garden or away altogether: There are plenty of mobile browsers still in the wild that force you to page through a pretty deep menu just to find the “Enter URL” option, where you can actually go to a Web site you want to use. After a fair bit of pain triple-tapping out a URL (with detours to learn things like you need to tap the “0″ key 8 times to produce a “/” on this particular phone and other such nonsense), only to get an error because it wasn’t built as a “WAP” site, it doesn’t take long for people to give up. Compounding that, users don’t understand mobile data pricing (How many megabytes will I need to buy? Oh, you’re going to charge my browsing by the minute? Huh?) We as an industry just haven’t made this stuff easy enough to use. Blaming the carriers can be fun, but it’s no excuse really.

Why is it so hard to build great mobile apps?
Targeting the Web for mobile application development has been a problem because of the need to dumb down the apps because of the limitations of WML (WAP’s initial markup language), XHTML-MP (its replacement, a essentially a subset of the XML compliant successor to HTML), lack of proper JavaScript support, and other limitations. Now, there are a lot of Web sites that, when provided in a “mobile version,” or when such a version is automatically produced by adapting the content on the fly through a proxy or some other means, can be perfectly useful for information on the go. I don’t want to downplay the billions of monthly page-views that are taking place. But our expectations of what the Web is has left behind the idea of a mostly read-only static Web with little interactivity.

To work around the limitations of current mobile browsers and create a richer user experience, developers may take the next step and build “native” apps that give them more control over look and feel and more speed than the dumbed-down browser on the phone. But to reach critical mass of users, developers may need to target multiple platforms and programming languages, and navigate the constraints that each of them place upon your app. Development and deployment tools, while improving, are still relatively immature. Doing a good job at testing on real handsets and networks is a big challenge, and can be expensive.

Thus, the vicious cycle: hard to develop good apps->uninterested users->no market for developers to keep trying to develop good apps->…

Summary
The mobile Web is not yet truly open. Network operator policy has been a barrier, but that’s really no excuse. Fragmentation of technologies, dumbed-down mobile browsing and poorly conceived user experiences are the real problems.

Next post
What’s changing? How will the mobile Web open up to all Web developers and become easier to use for more people?

Welcome

I’m Jay Sullivan, recently arrived at Mozilla, where I’ll be focused on two things: working with the Labs team to push the envelope on new ideas and directions for Mozilla; and working on bringing Mozilla technology to mobile phones and other hand held devices.

By way of background, I’ve been working as a mobile software developer for the last several years, most recently as co-founder and VP of Product Management at PocketThis, where we pioneered the idea of “Send to phone” from the Web as a way to make the mobile Web useful for people. In that capacity, I worked with mobile network operators, mobile infrastructure and browser providers and Web developers building mobile applications in Europe and the US. Prior to that I worked at Oracle on Business Intelligence products, and Firefly Network (purchased by Microsoft) on personalization.

I’ll be blogging mostly about Mozilla-related topics, with an occasional post on music, books and other personal interests now and then.

Welcome!