GLOBAL – Opera Software has been building web browsers for almost as long as there’s been a Web. Opera Mini is one of its flagship browsers and is available for just about every mobile phone on the planet, helping users consume regular, desktop-class web pages on slow data connections and with limited screen real estate. To examine the thought processes that went into creating this mobile miracle, I chatted to Phillip Grønvold, Product Manager for Opera Mini about its history and its development.

 

How did your team originally get the idea for Opera Mini? What did it develop from?

Opera Mini’s roots can be traced to a customer visit about 7 years ago now. It all started when two Opera engineers were on a customer visit, with extra downtime. In the evenings back at the hotel, our two engineers found themselves having a bit of spare time to think about mobile web browsing on feature phones. Why do we have to have WAP, they asked themselves? The answer up until that point was because mobile phones at that time were not powerful enough to view full HTML web pages. This got them thinking: “true, the mobile phone does not have enough power to render HTML, but the powerful servers back at Opera HQ do” (have the horsepower). With some coding experiments, over the next few nights at the hotel, Opera Mini, the client-server browsing phenomenon, was born.

How long has it taken to create so far, in man hours? Hundreds? Thousands?

It is fair to say we have spent multiple man-decades in development. Seriously. The significant development investment has been mainly due to Opera Mini being available for over six years, now on eight mobile platforms, plus the development of support technologies, such as the Opera Mini server infrastructure. To minimize the development overlap between platforms, we have invested since day one in developing a cross platform code base, creating toolkits to aid development and QA, and creating scalable server infrastructures.

What have been the hardest and easiest parts of development? Any major roadblocks you’ve had to overcome?

Due to Opera Mini being available natively on eight mobile platforms (at the moment), the hardest part is maintaining a portable codebase that also works with the proper integration on each platform (e.g. Symbian). A close second place in difficulty would be supporting (and testing on) over 3000 devices.

Other major roadblocks have been lack of NDK (Native code Development Kit) availability on certain mobile OS platforms – and the same roadblocks apply when there are restrictive terms of agreements in NDKs. Thankfully, this has never been an issue on the Nokia and Symbian platforms.

What are the tools you’ve used? i.e. What language and/or toolkit do you write in?

Opera Mini and Opera Mobile use a mixture of languages and toolkits. The core of Opera Mini is developed in J2ME JAVA and Objective-C. The Objective-C version being the basis of the native Symbian Opera Mini port. The Opera Mini UI is written in an in-house cross platform language. This cross-platform UI has its own set of compilers and toolkits. Other UI toolkits we have used are Qt and GDK. On the server side, the development language is mostly PIKE.

How do you test Opera Mini as it develops? How many testers do you have and how do you manage them and their feedback? Do you have an automated change management or fault logging system?

Testing and QA on over 3000 devices is a major task. To keep track of development and QA, we use a JIRA-based tracking system, and a ‘Git‘ versioning system. Testing is distributed across multiple sub-components, across multiple teams. A key to successful QA has been constant internal, partner, beta and public release channels to funnel QA feedback back into the development process as early as possible.

How has Opera Mini evolved since your first versions – why and how?

Over six years in public release, Opera Mini has seen its share of evolution. Opera Mini 1, 2, and 3 all used a single column view or Small Screen Rendering (SSR) mode for viewing web pages. This meant that desktop web pages were transcoded to fit within the small screen size of older mobile phones. This introduced full HTML pages to phones as a vertical web page, only needing to vertically scroll with the keypad. This feature is still present and is still quite popular in Opera Mini today.

With the release of Opera Mini 4 in 2008, “PC-like” HTML browsing support came to feature phones. For the first time on a feature phone, users could view desktop webpages in full (2D) overview and zoom in to the area they wanted to view. This revolutionized mobile browsing for many feature phone users who at that time were more familiar with WAP-only on-deck content portals from their operator.

WIth Opera Mini 5 in 2010 and the recent Opera Mini 6 release in 2011, the product saw touchscreen integration and compression optimisations.

The key to making Opera Mini a truly successful mobile app has been the scalability of the Opera Mini server infrastructure. Opera Mini has seen exponential growth for 6 straight years. Keeping up with exponential growth has required a world-class Opera Mini server team. The Opera Mini servers in May alone supported over 113 million active users, who browsed over 63 billion pages, which consumed over 9.6 Petabytes of data traffic. [More information about Opera Mini statistics is available in the monthly State of the Mobile Web report at http://www.opera.com/smw ].

How have you reacted to Ovi Store feedback? Do you monitor it? Has it proved useful at all?

User feedback has always been critical for our mobile app development. In this regard, Ovi Store feedback has been instrumental for us gathering feedback from users. The Ovi Store feedback has helped us manage our Symbian platform roadmaps and fix minor bugs. We also always encourage feedback in the Opera bug report wizard, or on the Opera forums.

What’s your #1 tip (or tips) for someone wanting to get started in mobile app development?

 

The mobile phone is not a PC. Many conventions in PC app development do not transfer to mobile devices. To develop successful mobile applications, you need to be mobile focused from the start. Not just mobile focused in the codebase or UI, but in all aspects of the mobile app ecosystems, such as app distribution models, to in app payments and adverts.

Thanks, Phillip!