A very interesting thing happened yesterday (1st of July, 2010) - Slovenia’s leading mobile operator, Mobitel, announced (no English news available) that they will be cutting down the amount of data traffic available in its subscription packages. They have been offering packages including 1GB of data traffic for more than 12 months and got many new subscribers on board during this period.

Yesterday, Mobitel decided to cut down the amount to 100MB, 900MB less. Users revolted, filling Mobitel’s Facebook page with angry comments in addition to a huge amount of posts on Twitter.

It is quite clear why Mobitel had to do this - their network was hardly keeping up with the heavy usage induced by almost flat fee pricing as 1GB per user is a lot in mobile. Some users with unlimited, flat fee packages commented that they transfer almost 70GB of content in a normal month, combining mobile surfing and tethering, mainly using YouTube, Flickr, MySpace and other web applications.

From my point of view this shows us an interesting insight - apparently many, many common users (not early adopters/geeks/nerds) care about their online mobile services and that they regard mobile web/data access as something really important, as important as calls or SMSes.

This is quite exciting for those of us who are trying to be active in the mobile space, meaning that we can hope the mobile web will become as ubiquitous as the “attached to a wall” internet is, not only from the technology perspective, but also from the user’s perspective, thus forcing operators to adapt and provide an even better service.

In the last year there have been a ton of mobile application challenges. Mainly because other players in the industry want to compete with Apple’s iPhone ecosystem - the iPhone SDK and the Appstore being at the center. Nokia, HTC, Samsung, Vodafone, O2, T-Mobile and many others (including some local operators in the Adriatic region) have been trying to spur mobile development by pouring massive amounts of money into prizes for dev competitions. I firmly believe this approach is wrong and that it can yell no tangible results in the long run.

The problem(s)

App challenges are usually organized in order to convince developers to try a new platform. It is important to stress out “new platform”. This means that the skill levels of developers on these new platforms are usually low to medium and in very rare cases advanced. In addition to that app challenges usually target developers who have few if any mobile projects in their portfolio and are only experiencing the mobile world for the first time - lured in by technology that is similar enough to what they have been used to develop for in the past (Java in Android, C++ in QT, Objective C for iPhone).

Furthermore these developers (who are usually not mobile professionals) need some guidance and assistance, specially in order to avoid classic design pitfalls and in order to deliver a great user experience - let’s face it, developers need designers and vice versa.

Finally, many apps lack the business/marketing component that would make them viable in the long run.

The goal

Setting the right goal is crucial. Getting 101 amateur apps (remember the low/medium skill levels from above) is not really what you want unless you just want to crunch numbers. Aiming for a small number (5 is a nice number) of high quality apps is a better strategy (at least from my personal perspective).

The (proposed) solution

With the problem and goal in mind the solution offers itself. To solve the problem you need to bring those developers to at least a medium skill level to start with, help them build teams and monitor their work process in order to be able to help.

You can then help them get in touch with mobile experts, organize one on one sessions and nudge them in the right direction when needed.

Long term benefits

I fully understand that this kind of approach requires much more effort than just naming a large prize and wait for applications to start flying in, but I firmly believe that the results will be worth it.

With this kind of approach several long term benefits for developers can be achieved:

• developers learn how avoid mobile design pitfalls  (always handy, no matter what the technology)
• developers learn how to deliver a great (not average) mobile application
• developers get to know designers, mobile experts and business mentors
• get applications that can sustain themselves in the long run, so that their creators see the benefit to keep working on them
• the contest organizer has the possibility to build up an organic community through long term interaction
• the technology providers can build up a knowledge base about their SDKs - learn what sucks and needs fixing

In this spirit I will be joining the Nokia App Forum Slovenia’s summer Academy, where we (along with Matevž, Andraž and Žiga)  will try to take teams of young ambitious developers on a journey of mobile application development and teach them all the tricks of the craft in the process.

btw: the deck was selected among Slideshare.net’s featured presentations.

Adobe is getting ready to launch Flash 10.1 on Android and several other mobile OSes. They are promising to deliver a unified platform for awesome (but according to Apple not magical enough) games and applications. The whole idea is to have one tool/development environment for all those platforms, but there are some interesting details behind, that not many people noticed so far and those little details are usually crucial for success.

Flash 10.1 for mobile devices will finally support RTMP/RTMPT for streaming media, but unfortunately only from the server to the clients. All those real-time video streaming applications will not be able to use the same infrastructure they are using to stream from webcams in real-time on the web.

In addition to that application developers will not be able to access cameras and microphones on mobile devices for any kind of operation. The lack of access to the camera means that developers will be unable to develop Augmented Reality (AR) applications by using Flash. This is a pity since AR is a really hot area that could have given the Flash platform an additional appeal, especially because most of the consumer targeted AR applications on the web is done in Flash with the FLAR toolkit

I certainly hope the boost in interest and the heavy hype around AR will make camera and microphone access on mobile devices a priority for Adobe. Until then we will just need to keep writing native applications.

p.s.: it would be a dream to have this functionality straight in HTML’s JS API, but I think my beard is going to be quite long before we will get it.

HTML5 is being developed as the next major revision of HTML (HyperText Markup Language), the core markup language of the World Wide Web. It aims to reduce the need for proprietary plug-in-based rich internet application (RIA) technologies such as Adobe Flash, Microsoft Silverlight, and Sun JavaFX.

Source: Wikipedia

As part of this initiative the HTML video tag is being introduced as well in order to unify the way video is distributed on the web. Currently most online video is distributed via Adobe’s Flash platform, on the contrary of what Apple and Steve Jobs would like you to believe, but we will not go deeper into that debate.

The HTML5 video tag is already supported in several browsers, the latest versions of Firefox, Safari (on all iDevices), Chrome and Opera. It would be great if you had the chance to serve video to all those browsers with the same code, same codecs, but guess what - you can’t, these are standards after all :)

Embedding media in HTML5

Embedding media in HTML5 is fairly simple and straightforward. You just need to use the <video> tag along with the <source> tag to define the path to your media content.

<video controls>
<source src="foo.ogg">
The text written here will be displayed if your browser does not support the <code>video</code> element.
</video>

So far everything looks great, but if I tell you that there is also an option to add many sources in order to assure playback in different browsers the thing starts to smell fishy right.

<video controls>
<source src="foo.ogg" type="video/ogg">
<source src="foo.mp4">
The text written here will be displayed if your browser does not support the <code>video</code> element.
</video>


By adding another source, you can specify the fallback file for browsers that do not chew up videos contained in the ogg () container (usually encoded with the Theora codec).

For more info on how to include HTML5 video and 1001 detail you should read Mozilla’s guide (where I borrowed these examples).

Fragmentation

This is how HTML5 video is supported at the moment of writing (source):

• Mozilla Firefox (3.5 and later) supports Theora video and Vorbis audio in an Ogg container.
• Opera (10.5 and later) supports Theora video and Vorbis audio in an Ogg container.
• Google Chrome (3.0 and later) supports Theora video and Vorbis audio in an Ogg container. Chrome also supports H.264 video (all profiles) and AAC audio (all profiles) in an MP4 container.
• Safari on Macs and Windows PCs (3.0 and later) will support anything that QuickTime supports “out of the box.” This is a long list, but it does not include Theora video, Vorbis audio, or the Ogg container. However, QuickTime does support H.264 video (main profile) and AAC audio in an MP4 container.
• Mobile phones like Apple’s iPhone and Google Android phones support H.264 video (baseline profile) and AAC audio (“low complexity” profile) in an MP4 container.
• Adobe Flash (9.0.60.184 and later) supports H.264 video (all profiles) and AAC audio (all profiles) in an MP4 container.
• Internet Explorer has no HTML5 video support at all (surprised?), but virtually all Internet Explorer users have the Adobe Flash plugin.

Just look at the table if you didn’t get it:

To put it simple - if you want your video to play in every browser (on every device) you need to encode it in two different formats (Theora+Vorbis in Ogg for Firefox, Opera and Chrome & H.264+AAC in MP4 for Safari, Mobile Webkit on Android and Flash).

Serving content

All these videos can be hosted on common web servers, the same that you use to host your static files.

Are you feeling dizzy yet? We still have to work out live video streaming, but we will do that in another post (coming soon).