Why you’d like to use HTML5 audio in iOS 5

It’s all about apps these days. The question is whether you want to make the commitment and investment (of learning a new language) to program natively for one platform or leverage the web dev skills you already have? HTML5 is the way to go if you sympathize with the latter.

Let’s face it: The main problem for web developers that want to make apps is to deliver a great user experience. Hence, you’d like to use as much of today’s web technologies as possible to enhance the UX. One profound way of doing this is audio feedback. For example, many twitter apps use sounds if new tweets come in and another sound if no new tweets could be found. This kind of response is intuitive to the user. This is what you should go for.

Also, imagine a game without sounds. Would be kind of boring, wouldn’t it?

Naive Assumptions: What you’d expect

Fortunately in iOS we have rich HTML5 support built into mobile Safari. Initially, Steve Jobs wanted all apps to be web apps! So what you’d assume regarding audio is the presence of the HTML5 audio tag. And guess what, there is an implementation of the audio tag in iOS. Hurray!

So what do you expect from an audio tag implementation:

• call .load(), .play(), .pause() and other methods via JavaScript
• use remote files, dataURIs, cached files and other sources
• play several audio files / tags at once
• mix audio from several sources with different volumes, etc.

Reality checks: What should work but doesn’t

It becomes clear pretty fast that it’s not that simple. With iOS it’s a disaster. The bad news first:

It is not possible to load or play audio without user interaction.

Sad, but true. Apple deliberately decided that a touch event is mandatory to load and play audio. There is no workaround for this.

If we accept the fact that we need a touch event to play the audio, is it possible to use the audio tag as expected? Hmm, no, not really. So what’s broken as well?

Latency: Loading audio files on demand (after the touch event fired) is unusably slow. The desired user experience can not be achieved using this technique.

One audio tag at a time: You can never play more than one audio tag at once. This makes it impossible to mix sounds on the fly which would be necessary for games that have a background music and must also play sounds dynamically (e.g. when the character jumps).

Audio files only: You can not use anything as the source besides audio files (uncompressed WAV and AIF audio, MP3 audio, and AAC-LC or HE-AAC audio). If you could use dataURIs then it would be possible to preload the audio.

Workarounds: How to play anyways (at least somehow)

We invested a lot of time researching the audio tag on iOS 5. If you want to know how we play audio, read on.

So what do you do with this crippled audio tag? Well, you trick it a little bit and use it as much as possible. Here are several ideas that work best for different scenarios:

Bind touchstart event to body: As you have to play on a touch event, we bind a touchstart handler on the body. So wherever the user touches first, we can use this event to load the audio file. Even better, from now on, we can load and play different sources from this audio tag.

Hot swapping sources: We can now change the “activated” audio tag’s source on the fly. So it is now possible – without user interaction (!) – to load and play different sources. But you can only play one source at a time, of course.

Use audio sprites: The guys over at Zynga use audio sprites in their Jukebox. This means that you have a huge audio file containing one sound that you want to play, then one second of silence, then another sound and so on.

Example for a sound sprite structure:
1 second silence
First sound
1 second silence
Second sound
1 second silence
Third sound

In this file you include all the audio that you possibly want to play in your app. You only load the source once (as described above) and then jump to the relevant parts in the file. So the file is always playing but most of the time it just plays silence. When you need the sound, you can quickly jump to the part in the file that you need to play. This solution is quick (much faster than hot swapping!) but requires a long preloading phase before you can play the most sounds, because the file is bigger.

tl;dr

So audio in iOS is pretty much broken. If you are using a native wrapper like PhoneGap you could use native APIs via plugins like SoundPlug. We’ll try what is possible in the upcoming versions of iOS. Please let us know your ideas and feedback in the comments.

Update:

Regarding Philip’s comment, this is how we think it could be.

Modules

AMD stands for “Asynchronous Module Definition”. So, what are modules? I’ll quote the definition from the CommonJS Module specification, as it describes it very well:

This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.

So, modules are isolated parts of code that live in their own scope and are kind of self-contained. Well, that is pretty much how we see the individual Features in EmbedJS – we made our feature implementations as small as possible and reduced dependencies as much as possible. Many of EmbedJS’ features are also browser-independent, so why not make it possible to use some of the tools in a non-browser environment?

(If you want to learn more on modules and why we need them, I recommend @briancavalier‘s presentation on modules.)

Features in EmbedJS

So far, I didn’t really explain what I mean with “Features”, so let me do another quote, this time from the Project Page:

EmbedJS uses the concept of features: Functionalities are split up into features, as fine-grained as possible, and each feature might have multiple implementations.

Our Features are kinda small and contain only few methods, sometimes even just one. The asyc-promise feature, for example, will get you Promises, and the transport-jsonp feature will get you a method for pull in data via jsonp – and that’s it.  If multiple methods are contained within one feature, this is because they are too closely related to each other to split them up, like the html-class feature, which contains the addClass, removeClass, toggleClass and hasClass methods.

AMD vs CommonJS Modules 1.1

Now that we knew modules were the way to go, there was another, quite important question to solve: There are two common patterns for modules, so which one do we want to apply? One pattern is described in the above mentioned CommonJS Wiki, the other pattern is described in the AMD wiki.

Well, there have been some blog posts lately that compare the pros and cons of each of them, so I don’t want to repeat all of this – but I’m hiving a similar tendency towards AMD. Besides this, there was another big reason to go with AMD: Remember, EmbedJS is based on the Dojo Toolkit, and it’s a Dojo Foundation Project – and we hope that the efforts that went into making EmbedJS might flow back into the Dojo Toolkit one day. And as the Dojo Toolkit uses the AMD approach, the decision was quickly made to do so as well.

Implications for EmbedJS

There are several huge benefits for EmbedJS in using the AMD approach. The most noteworthy surely is the ease-of-use for developers. In your code, when you find you want an EmbedJS method, you look up the feature name that provides this method, add it to the require statement and there you go. Man, easy.

A second important thing is that EmbedJS now plays really nice with AMD based projects. In fact, you could see EmbedJS now as a collection of small useful modules, that can be easily integrated – and also easily extended.

The third major benefit is that we can now get rid of all the custom tools we built around EmbedJS – you can load features with any AMD loader (though we use and recommend RequireJS) and build it with any AMD optimizer/builder (we recommend r.js).

Let’s have an extra word on

Building

It was always possible with EmbedJS to create a custom build that would contain only the features you wanted/needed in your project. But, you had to use our build tool that we created. And learning & using Yet-Another-Build-Tool™ is always… well, let’s just say it would be cool to avoid it (and, not to forget, so is maintaining it). We did a lot to improve that, we created a GUI that allowed you to just “click together” the features you wanted, and we worked on a dynamic loader that would ease development. But still, the situation was far from ideal, and people just ended up going for our ready-made “kitchensink” builds that contained all of the features.

Now, we still provide those ready-made builds that contain only the implementations for a given platform (and are stripped of require/define calls), but I really hope that using the AMD approach and using an AMD optimizer to deploy will become the more adopted style.

Q: Cross-target? A: The Feature Plugin

One goal of EmbedJS is to allow for easy cross-device development. We got rid of run-time branching but instead went for an approach that held the different implementations for a given feature in separate files, so that one only has to deploy the actually needed code to a given device – and not all the alternate implementations, that sit useless in the device’s memory and never get used. We needed to achieve that with “in-house” means provided by the AMD approach. Lucky us, there’s the concept of loader-plugins, and so I created a feature-plugin for AMD loaders. The idea is simple yet effective: You create an implementation map that maps a feature name to an implementation, and if there are multiple implementations, you supply tests that tells the plugin which feature to use.

When you’re ready to deploy, you have two choices: I f you really don’t know on what target your code is going to end up, you can use the dynamic implementation map containing the tests for the optimizer, and you’ll get a build that contains all of the available implementations. Then, during runtime, the feature plugin will run the tests and load the specific implementation. But, if you do know what target your code will run on, you provide a specific implementation map that doesn’t contain tests but directly maps to the according implementations, and you will only have those in your built file.

Synopsis

AMD is exactly what we needed to make EmbedJS more what we want it to be – an easy to use JavaScript toolbox that is especially handy for cross-target scenarios such as cross-platform mobile development. So, please don’t hesitate and check it out on Github, read the project page and check out the examples!

Resources / Further Reading

• EmbedJS on GitHub
• EmbedJS Project Page
• EmbedJS API Docs
• AMD-Feature plugin
• AMD Wiki
• CommonJS Wiki

Uxebu is now operating it’s business purely in the JavaScript space for about three years (oh that reminds me we should have a party!). We are convinced that JavaScript is ramping up now and we see that there are more and more things done and possible with the language. The browser landscape is developing rapidly and changing every day. The mobile industry is pushing the limits and we are helping to do our part in it. We learned a lot and are still learning. As it is in the nature of our company to spread our knowledge to allow everyone to use the technology at it’s best and push the limits with us, we think now it’s the time that we share our knowledge and pass it on to those hungering for diving into JavaScript!

We really have gathered a lot of bright, bleeding-edge people and each of us is learning from another everyday. If you want to get some of the know how (at least as much as we can pass on in a two day workshop) you are invited to join our workshops. There will be one held in Munich 29th and 30th of June and another one in Amsterdam 11th and 12th of July. We will always have at least two uxebus teaching you the latest and hottest. We might even have some of the latest bleeding-edge mobile devices for you to run the app you will develop in the workshop.

Workshop Details

In this course we will cover a broad spectrum from JavaScript essentials to the bleeding edge of cross platform HTML5 development. We start from the ground up and go step by step, depending on the level of the participants we accelerate to show you the deep and dark sides of JavaScript.

Each day of the course is split into an intensive “knowledge transfer” session in the morning and a hands on hacking workshop in the afternoon in which you will apply the contents learned during the morning. At the end you will have touched all contents not only through theory but also through intensive real life application and coding.

Note that this course will not explain you how to work with jQuery and also not how to work without jQuery. The course mainly focuses on JavaScript, mobile and HTML5.

Day 1 (part 1) – JavaScript

We start with a small overview of the history. We tackle the basic structure of the language and move on with statements, expressions, functions and objects. We touch the different operators and when semi colons are introduced.

We continue our way through the JavaScript landscape by taking a look at objects, properties and built-in functionality. At that point we’ll encounter our first major obstacles; scopes and closures. Once we conquer these we touch on the difference between functions and constructors. This is followed by our second major obstacle; prototype and the various values of the this keyword.

Day 1 (part 2) – Hackday: HTML5, CSS3

During the second part of day one, we will take what we have learned in the morning and mix it with a little shot of HTML5 fanciness. We will look at all those new APIs we can now access on our (mobile) devices to bring JavaScript to a new level. We will include cool APIs such as the Audio API, Video API, history, Canvas, SVG, File API, WebGL, DeviceMotion, WebWorkers, WebSocket, GPS – and if all ingredients fit well you might just end up with your first app written in JavaScript.

Day 2 (part 1) – The App Day

During the second day we willl continue with timers, callbacks, web workers, eval and the future of JavaScript. The speed of the course is matched with it’s participants. The important parts of the languages will be handled in the workshop. During the first part of day two we will also specifically look into topics which you want to cover after determining those during day one. This will give you the chance to get all your open questions answered so that you have your pockets full of knowledge after the workshop is over.

Day 2 – part two (Mobile)

JavaScript has grown strongly into the mobile space, so we will show you how to get the app you have started building during day one onto mobile devices. You will learn about media queries, some device sensors, performance and HTML5/CSS3/JavaScript tricks and how to optimize some parts for mobile and how to make a native app out of it, so you finally could even make get it into the app store and make money with it.

Now you want to join our workshop?

Join us either

• in Munich 29th and 30th of Juneor
• in Amsterdam 11th and 12th of July

Coworking in Valencia

My week in Valencia started out to look very quiet and just pure work. I tried to contact some JavaScript/mobile/web guys in this area before hand, but somehow didn’t really succeed. Some tweets went around but I didn’t really reach anybody. But I made sure I have a great place to work at, which was Coworking Valencia, Rosa Montesa runs this place with so much passion – wow. And I just had to think of the Combinat56 Coworking space in Munich where we normally go, which is run by Sina with an equal lot of passion. Just great girls!

So I arrived there Monday morning to do my work, and off it went. I chatted a while with Rosa and some other coworkers and from there I couldn’t stop it. At the end of the day my calendar was filled with lunches and meetups. I met a lot of interesting people, first Rosa had organized a small come-together the next day with the company Brainstorm from right above, mainly hackers too, so we had quite some stuff in common. There I met Jorge who introduced me to more geeky people, thank you so much!

Spanish way of life

So the week went on and I tried to work a little bit, but I was basically so happy to live the spanish way of life a little bit. In the morning you don’t buy a take away coffee, actually you don’t see the busy people running around with their coffee mugs in there hands. I also just did that the first day, after that I adopted the spanish way, which is sitting down in a bar (also if it just for five minutes) and have a coffee. A lot of people there have a carajillo in the morning but that was not appropriate for my mornings :).
For lunch (later than normal for me, around after 2pm) we mostly went to some place outside, since it was at least 20°C, beautiful sun just perfect. And then on the way home you just take some tapas maybe a beer in the bar around the corner and late at night (normally after 9pm) we had dinner. For me working there felt really comfortable and easy going. But I have also heard that normally working in Spain is not normally that relaxed.

The real geeks

On Thursday I went to the BeCode guys’ office in the nice Barrio del Carmen. The first thing after I arrived was “let’s go for a coffee” :). That is the spanish style! We exchanged the ideas of how we work and the kind of projects we do. Xavi the daddy of BeCode (scnr) told me that they are an incubator and try to have people come in and realize their ideas, pretty cool stuff. Was so refreshing and forward-thinking, I felt home.
Funny enough that day I learned about Jasmine there, they used in a project. Unfortunately we had no internet that day, so I was pretty much offline until the afternoon, which was somehow good, but not when you really want to get some things done. So I promised to be back the next day and then the office was also really crowded and I got to meet all of the BeCode team. In the evening I joined my first coding dojo, this one was held in the offices of OpenFinance. We were given the task to write a roman to latin numbers converter in whatever programming language you like. You are given half an hour and try to get as far as you can, I joined forces with Jaume we got it easily done in the half an hour time, we simply used the webtestsuite as our testing framework since I know that one best and of course we wrote the converter in JavaScript :). As a second Kata you could hack the conversion the other way around. Jaume and I felt that this would be just another hacking it the other way job was, so we looked for a new challenge and we said let’s just use the google search engine for converting it for us and we just grab the result from there. We looked at a couple of APIs, at YQL but there was no real solution, so we went the scraping route. We got it almost done :). But as you can see and read we had lots of fun and enough beer!
Of course we went for dinner later and were still hanging out some time around Valencia and in the BeCode office later. There the guys told me about an Code Retreat which is going to take place somewhere near Valencia “en el campo” with Paella cooking and hacking, I hope that some of us uxebus may join, hope to find out details soon.

All in all a big thank you to all you guys and I can just say I had a great, though also really exhausting, two weeks in Spain. Hope to see you soon!

Recently the new WAC 2.0 Spec got out and it’s looking good.
Compared to WAC 1.0, the WAC 2.0 Spec is a shift into the right direction:
Instead of inventing new APIs, WAC 2.0 adheres to web standards like HTML5 and W3C Widget Packaging.

Let’s compare the two major spec revisions in that repsect:

As said before, the WAC 1.0 Spec described distinct APIs, e.g., for audio, messaging (SMS & email), camera and geo-location.

Taking photos, for example, involved assigning a callback to a global value inside the Camera object and invoking Camera’s captureImage method.

There’s a problem with that: What if two pieces of code both assign their own callback to that shared value?
The one which assigned its callback last will be executed. The first callback is “dead code”.
Of course this can be remedied by the app developer, but I believe it’s the library’s job to get something as essential as deferred execution right.
All WAC 1.0 APIs use this global callback model and inherit the problem.
There are better, more elegant ways to defer execution (e.g. dojo’s Deferred or node’s callback passing & EventEmitter).
And fortunately, WAC 2.0 replaced the old model with a callback passing approach.

If everything goes well, what could WAC provide developers with?

1. An easy way to package web apps “for home screens & app stores” by wrapping web apps in native container apps.
2. An extension of browsers’ capabilities to enable richer web apps. This includes APIs for camera and file access.
3. In contrast to alternatives WAC has a strong focus on carrier network APIs. This could enable purchase through carrier billing.
4. A security model to effectively protect user’s privacy and security.

So go ahead and look at what the new WAC 2.0 has to offer.
I’m excited to build apps with it once it’s running on some major platforms!

To conclude I’d like to end this post with my personal opinion on what I believe WAC needs to focus on to succeed:

1. WAC runtimes have to run at least on iOS, Android and a few other major-marketshare platforms. There’s no point in developing cross-platform web apps if you ignore major platforms.
2. WAC’s marketing & identity need to be more developer-centric. Different top-notch WAC runtimes need to be advertised by WAC. Ideally there would be an official runtime for each platform.
3. Apps built on top of WAC runtimes have to be compatible to major app stores. For example, imagine a developer is targeting Android and iOS. What if Apple rejected WAC-based apps because of, e.g., a bundled custom WebKit build? I’m pretty sure no sane developer would consider WAC if that effectively banned their app from ever going into the most profitable app store. And while there will be carrier-operated stores I am not overly confident in that. Human beings simply prefer one familiar store/market on their phone.
4. Web app developers want their code base functioning consistently across multiple platforms with little or no effort. This implies that different WAC runtimes should strictly respect the specification. If there are implementation differences it’ll result in multiple code branches in the app code to repair broken implementations. Well, if WAC wants to succeed this must not become an issue for the app developer! Most apps are going to need custom code to support physical device differences. So hey, it will be incredibly helpful if the basic APIs were consistently implemented! Please don’t screw this up, because I somehow doubt someone would develop a cross-WAC-platform JavaScript framework.
5. WAC 2.0 runtimes with the above properties should appear very soon. They also need to be advertised in an easy to understand manner.
6. WAC should stick to W3C specs & drafts for APIs. If an API becomes part of a given platform it should be removed from that platform’s WAC runtime. Think back to when Google removed Gears support from their own browser to make way for standardized APIs.

You do not only get to travel in uxebu. First and foremost we want to give you the opportunity and platform to accelerate the things you can do, show it to the community and enable you to reach more than you could on your own.
It doesn’t matter where you live! We are currently flirting with San Francisco too :).

But we are also a family company! We encourage you to have fun and put the priorities right. And family and health are top priorities at uxebu. As you can also see, as long as you like traveling and hanging out with the top geeks in our community you get to do that at uxebu, a lot. Because this is the bread and butter of high quality that we offer to our customers. And in order to become a top geek (which is one goal that we have for you at uxebu, if you aren’t one yet :)) you should be around those where you can suck know how and hopefully also give back and share yours as well.
You get the hardware that you need to work as efficient as possible. You prefer working at home or in a co-working space? No problem, feel free! Once in a time we meet some place and hack together for a couple of days, talk about our roadmap, find out where each of us wants to head and we figure out the way how to achieve reaching the goal we determine together. We normally meet some nice place, like at a lake or in the mountains. The last times we had both :). And we take the families with us.

Jens Arps joined uxebu in May 2010, he is the guy behind StorageJS, he is project lead for the just new dojo foundation member embedJS and is working on a really exciting HTML5 customer project that I can not link here :(. Stephan Seidt has hacked the newest (still unreleased) apparatio API, he is the one who does the node.js stuff in our team and WebGL is what he is passionate about, really passionate! I don’t have to say much about Tobias Schneider the guy behind Gordon, he has become famous over night, spoke at the last two JSConf’s and is our hard-core optimizer. David Aurelio has created TouchScroll and if you team him up with Tobias Schneider we have ALL JavaScript knowhow in da house, and they are currently hacking together on a really awesome project. Nikolai Onken a co-founder of uxebu is our social community front man and the party goer number one and besides that he has created HumanAPI and knows all the JavaScript guys around! Tobias von Klipstein is also guilty of founding uxebu and he is our Jack of all trades, he had created the first version of apparatio almost all alone.
Me, I write blog articles, sometimes. But I get to go to all parties anyway :).

If you are a JavaScript geek, love to walk along the edge of what is possible with web technologies and think that HTML5 is the rocket ship you should send us an email with some links to some of your projects and a short, convincing reasoning why you would like to work with us. And if you think that you can’t work with us because you are not ready yet, shoot us an email anyways and let us talk first and decide later. We are made of talented individuals each. But working together as a team is what makes us really strong. Be ready for it!

And btw get ready to learn something new every day. And do also pass on your know how!

What is it?

It‘s a JavaScript Toolkit, especially aimed at embedded devices. Embedded devices, that is phones, tablet devices, TVs, car dashboards and the like. Devices that are capable of running JavaScript. We are sure that this list is going to grow over time – and will hopefully one day also include devices like your fridge. EmbedJS is based on the Dojo Toolkit.

Why?

Because the toolkits and frameworks that exist focus on desktop browsers and therefore have a different approach – an approach we didn‘t find that suitable for embedded/mobile development. And the JS frameworks that target mobile devices are flawed, too: either they target only a specific device or platform, or they provide far more than we do need and want.

What we wanted was a toolkit that offered a unified API across different platforms, but with the best implementation that was available for each platform. And we didn‘t want to ship code that implemented a certain feature for, say, an old Blackberry device to an iPhone. Plus, we wanted that API to be small – enough to assist us in our daily work, but not that bloated that we would ship code to a phone that we wouldn‘t need in most of our projects.

The Dojo Toolkit

We at uxebu have a strong affinity to the Dojo Toolkit – most of us are committers – for a good reason: we believe that it has done many things right, and that it has an excellent code quality. Thus, finding a starting point for our venture to what was later to be EmbedJS was pretty easy: It was the very core of the Dojo Toolkit, dojo._base.

We examined the code and split it into its smallest parts (features, how we call them in EmbedJS). After having the features all nicely separated, we could look for the best implementation for each of the platforms we wanted to support, and put it into a separate file. Then we optimized our code, tweaking here and there, but also using the code from dojo._base as it was, because it already was the best implementation.

And we needed to find means to put all these tiny parts together again, respecting any given dependecies, to create a file that then contained all the feature‘s implementations for a given platform – so the EmbedJS Tools were born, including our highly flexible build system.

API

EmbedJS‘ API is a small subset on Dojo‘s API. It provides around 70 methods, from the fields language enhancement (like Array manipulation or JSON), OO (like classes and inheritance), transport (like JSONP or XHR), event system (like connecting to DOM events or methods), DOM manipulation (like style or node creation) and misc things like Promises or pub/sub.

We kept the method signatures intact so that you can import your existing knowledge from working with the Dojo Toolkit to EmbedJS. There are only a few minor changes where we
a) found a new name highly useful, e.g dojo.io.script.get() is embed.jsonp()
b) we needed to strip given functionality for the sake of code size.

All methods in EmbedJS are available under the embed namespace as well as under the dojo namespace. I.e. to call the connect method you can use dojo.connect() and embed.connect().

The full API documentations is here, though it‘s undergoing some updates right now.

Summary

I didn‘t want to dig too deep in the first article on EmbedJS, but I guess you got the point: EmbedJS is a highly optimized Dojo core, and offers you a specialized, optimal build for a given platform. To explain how the build system works, how we manage dependencies, how we separate our features and our implementations and how one can create a project-oriented custom build will need another blog post – but if you are too curious, you are invited to take a look at the source code at github; a lot is self-explenatory there. A further source of information is the EmbedJS project page, as well as the EmbedJS Tools source.

Connectivity

Seemless connectivity is one of the best features of the iPhone, I configure a WiFi once and it uses it without bothering me, if not available it uses 3G. And it does that really fast, that was amazing! Not that other phones don’t have that, Android phones do that pretty well too, but BlackBerry, Nokia and others just never felt so smooth and fast regarding connectivity. You had to fight menus and it was just never as comfortable – though I have to add that BlackBerry6 got a lot better.
But let me differentiate here. The above targets the seemless and reasonable switching for being online, I really mean internet access. But the phone line connectivity felt different. I had been in places where the HTC Desire had phone coverage but the iPhone did not even find a source to connect to. I don’t know why, but a hotel in Munich a bit out of town and the Dubai Airport had been such places. For those iPhone-only users I can just hope that my phone is the exception.
Speaking of connection there was a very special use case that occured to me. On Emirates flights a mobile connection is provided, called AeroMobile iirc. I didn’t manage to connect with either phone, not the HTC Desire neither the iPhone4. But the Desire told me at least that my SIM card is not capable of connecting to this network. The iOS only told me to go into the settings and try to connect from there (also if I was already in there), which always left me hoping (until the Android told me why it couldn’t work).

Location

GPS reception is another thing somehow related to connectivity. And I can just say – awesome. I think I never held a device in my hands that retreived it’s position so quickly like the iPhone. I think GPS was turned on from the beginning (if not it was a single click that made me activate it), and from that moment on everytime I opened the maps app I got a result almost instantly. Maybe I had only been testing it with good reception, I can’t tell. I didn’t explicitly test GPS, it’s just a subjective feeling that my location was always retreived easily. Very smooth, that’s how it has to be.
Though there was one glitch. Once I used instagram and it retreived my location well, but didn’t again at this same spot, but that might have been just a glitch :).

Operator Settings

was another very positive experience the iPhone has to offer. If you have ever been fighting with APNs esp. on the Vodafone networks you know what I am talking about. Since we are working for Vodafone we had the pleasure already a couple of times with different phones, that we had to be careful which APN settings to use. And just to find them on the various different phones is not always easy – Nokia ;). The iPhone is configured for the first time when you activate it via iTunes. That is a pretty clever thing. All pure iPhone users will probably never get in touch with APNs, good for you. Of course the drawback here is that you have to activate the iPhone at all, which I didn’t really feel comfortable with. It felt a little bit like “first you tell Apple that you are the one using the iPhone”. Do I know what data iTunes sends home?

UX

Probably THE major difference to all other phones I had used before (and that have been a lot), was the instant reaction triggered by every touch. It felt good right away, anywhere I touch and expect something to happen it does happen. The LG Optimus with Windows Phone 7 on it is the only one comparable. Now the surface just needs to be smoother, somehow touching the glas makes this very organic touch interface, which works so fine, feel cold in the end. … Just a feeling.
Almost every app is built this way, that it reacts whenever you expect it to. Some are even optimized and built that way, that you get the feedback right away and you know it started working. Very nice. Surprisingly that one of the pre-installed Apple apps doesn’t completely fulfill this expectation, the camera app. First it takes quite a while to open and that really sucks when I want to take a quick picture. And second even though the app opened I have to wait until it is done initializing the app before I can switch between camera and video mode.
Anyway, I would really prefer a hardware button for taking pictures, that could replace a separate camera completely. And speaking of the camera, the HDR mode feels pretty useless imho. I expected much more of it one more feature you can reduce Apple, or improve it by very much, and while you are on it make it faster :).

Back Button Policy

One major difference in using Android compared to all other platforms is the system-wide history. Which easily speaking means you can click the back button (which every Android device has) to step through the history of all you did across applications. E.g. if you open the browser from within a twitter app and keep surfing in the browser, you can go back through the URLs you surfed too all the way back to the twitter app from where you came. This is something that is not possible on the iPhone. If your preferred twitter app doesn’t open a website inside the app you have to open the twitter app again to get back to it. The back button in the browser only lets you surf through the browsers history. In mobile I think the Android concept makes a lot of sense, simply because on mobile I have smaller apps with more focused use cases and combining them makes the mobile really powerful. So the Android way is very efficient for the user to keep the focus and not bother with what app did what, it let’s you simply use the phone. Imho very efficient.
Of course they are fundamentely different concepts, Android and iPhone. Android had multitasking right from the beginning and it always had a hardware back button. As discussed yesterday over dinner with Ashwin, Sudheer and Ramjee the iOS might get a system-wide history in the next major version. As stated above I think that would make such a device way more efficient to use.
The simple solution here, that appeared to me when I first surfed on the iPad is to use the three fingers back gesture across devices (it works on the Mac, but not yet on iPad and iPhone, etc.). That would make the iOS easily “upgradable” to provide a system-wide history, no UI changes necessary :). Who knows …

Add to homescreen

Another thing I was a little bit disappointed with was the “add to homescreen” functionality. I added my gmail to my homescreen and even though the iPhone supports multitasking every time I click the gmail shortcut it reloads the page instead of bringing the linked page to the front. That means if you had been searching something in your gmail, open a URL (in the browser) and go back to the gmail app (by clicking the icon on the homescreen) the search result is gone. Here you can also see how well a system wide history would fit into play.
And additionally I think it would be awesome, to make web apps (that are just linked on the homescreen) even more independent by giving them their own browser instance. My gmail did also always show up in the browser tabs, which was first suprising for me. But I guess the mobile web app concept is something around which we will see some movement in the near future. And I am sure a lot of better ideas will come up.

Conclusion

One last thing Apple: please come into the standards world, don’t try to be the next Microsoft. 1) use a proper micro USB port with your device, everybody does that, just for Apple devices I need an extra cable. And 2) if I connect the iWhatever via USB I want access to the USB device as a proper drive, just like everybody offers it. It is very silly that I need iPhoto to download pictures from the iPhone. I understand the business aspect but usability-wise I am sure this could put you in a much better spot. I am sure that you needed to hack quite some stuff into your OSes to hide this “special” USB device :(.
And the very last thing … battery life of the iPhone4 is he best among all the modern smartphones I had been carrying around the last couple of months. The following fail by far compared to the iPhone4: Palm Pre Plus, BlackBerry Torch, HTC Desire, Samsung Galaxy. Those last one day at most.

To close this article, I would like to say that I like the differences and being able to compare. There is sooo much room for improvement and so many great ideas in all the concepts. I am very curious to see where the future is heading. I will keep using as many phones as I can get my hands on … the peek9 just arrived … gotta go playing :)

First I want to thank RIM for sending us two Torch devices. Right away I navigated to the embedJS tests and I didn’t expect it differently, the tests passed without any problem, 100% passed tests. Actually I expected the tests to pass lightning fast, the time it took was ok, but not lightning fast, unfortunately. The test suite executed in about 14 seconds, on the iPhone4 it took about 10. To be fair the processor power and the system architectures are completely different and not really comparable, but the user experience counts in the end. We have heard that the RIM guys are hard working on improvements and speeding up the device, there is some cool stuff to come.

WebKit and WebWorks

The most impressive and revolutionary thing was definitely that BlackBerry brings an 100 points ACID compliant WebKit and runs W3C widgets using it. So there are by default two ways that are even fun to get content onto this platform. You can write mobile websites expecting an a-grade browser and you can write apps, for the so called WebWorks platform (which are W3C widgets inside). All we want. The browser supports CSS transitions and transforms, not 3D though, since there is no GPU in those devices, but you never know what might come next. There is SVG on it, WebSockets, Canvas and a lot more niceties, I just browsed the objects using Object Browser, go try it yourself, on your device.
RIM renamed their widgets that existed already on BlackBerry5 to “WebWorks” and they got completely overhauled. The approach RIM went is pretty close to how PhoneGap works. WebWorks basically is a wrapper written in Java (the native language of BlackBerry) which internally instanciates a WebKit view and provides a bridge into JavaScript where the underlying native functionality is written in Java, of course. The cool thing about it is that this code is completely open source and on github. Unfortunately the build scripts are still not on github, so you would still have to figure out yourself how to use the source from github to package your apps. RIM please push them soon! Currently the executables are the most comfortable way to build your widget.
Back to the API, since the implementation is open source you can easily extend it and make functionality available into JavaScript which currently is not there. So Nikolai’s robotic JavaScript will really become fun and reality on BlackBerry too. Why RIM went this way becomes very obvious when you understand the security concept on BlackBerry. Since all APIs are, in the end, provided by a Java implementation and only “piped” into JavaScript all security restrictions apply to the widget just as if it was a native app. That means if you access GPS in your widget (using JavaScript) the Java function will be called and will be secured the same way as if it would have been called from within a pure Java app. Of course this doesn’t make your widget secure by default, since you are using web technologies you have to take care of writing apps which are not vulnerable by XSS attacs or alike. But it offers really comfortable extendability for this platform and is no workaround to get web technologies onto BlackBerries, I think it’s a very clever approach, good job RIM.

Security

Everybody knows the ridiculous installation dialogs on Android which show you the APIs the app wants to access and the final question if you want to allow the app to access this functionality or not. If you say “no”, the app won’t install. That doesn’t really make me feel that the security concept is very flexible. It’s not giving the user a lot of control. Working with Opera’s widget runtimes already for a while I thought of a concept that would allow a lot kore control for the user and make apps hopefully more successful.
I will use a short example to explain it. Imagine a twitter app that you want to install and that has a lot of functionality but on the first install you only want it to be able to go online to read and send tweets. Functionality like GPS, searching my addressbook or taking pictures with the camera are built in into the app. But as long as i don’t trust the app i don’t want this functionality enabled. So I turn of access to certain APIs upon installation and enable them just when I feel secure and gained trust in the app or had been told by experts that the app is secure. But this is currently not possible on platforms like Android or iPhone. I talked about this idea and told RIM’s Tim Neil about it, in the hope to meet open ears and confirm that this is a good idea. The answer I got surprised me big time: BlackBerry already has this for a while. We got out our Torch devices to look it up, and yes in the menu under “Device / Application Management” you can edit the permissions per app (see picture). Awesome and just right, I love this.
So Opera this was my idea to improve your widget runtime and maybe to jump ahead of the crowd again, I would like it.

Overall the BlackBerry6 platform is very exciting and a lot of thought seem to have gone into it, especially with focus on the web, which is a really good thing. So, I will just step away and try to build the Object Browser as a WebWorks App.

“Modern Company” session – uxebu as the example

But before I dive into the tech sessions I would like to mention that I really felt the need to hold a session which I had called “Modern Company” where I tried to show our philosophy at uxebu, how we work together, how we use the modern media, how it all came about and why we do it this way. First I didn’t know where to start. Then I started to talk about when and how the idea for uxebu came about, that we decided online to found it and really met some months later. Thanks to our open source background and our history we wanted to continue the same spirit inside the company, I tried to show how and based on what facts we grow our team (the word “hiring” seems such a one-sided process). I realize now that I forgot a lot of the good stuff, but maybe this is the chance to make this become a separate talk to hold at other events.
I really loved the discussion and the questions that it had started, notes had been taken, a lot of critical questions came up and had been answered by Tobias and me. One interesting mentioning came up about an article which mentioned a company that pays the same salary to all employees. Thank you for all this input, I really enjoyed it and will definitely talk about this more and will prepare some more info next time.

JavaScript – a topic of big interest

We had founded uxebu purely for doing JavaScript consulting and pushing the limits and it is just really exciting to see how much interest this language is gaining in the last years. Not only jsconf the mother of all JavaScript events underlines this but also a lot of other conferences and events like fullfrontal, fronteers, js1k, 10k Apart, jQueryConf and so on which Béla Varga listed in his “JavaScript Rock’n Roll” session.
The “node.js” session and “JavaScript Rock’n Roll” (by Béla (@netzzwerg) and Tobias Schneider (@tobeytailor)) made it very obvious that JavaScript is a hot topic, the BarCamp was not necessarily overcrowded with programmers, but still those two sessions had been very well filled and the discussions had been really fun. The conclusion of the “node.js” session that Tobias drew and evangelized was “node.js is currently very hyped and just not yet ready for production, so use at your own risk, it’s not even alpha yet”. Everybody also agreed that node.js is not the new saviour and a replacement for Apache, it’s another tool you should add to your tool belt, use it when it comes in handy and be sure to know how and when to use it. Final conclusion was, as usual, if you should use it depends on what you want to do :).
Béla opened up the “JavaScript Rock’n Roll” session by giving a very good overview of what toolkits exist out there, who created them and what they are good for. He very well layed out some of the advantages and disadvantages, the rough corners and what is hard and what easy to learn. Shortly the discussion about the right JavaScript IDE came up but as usual there is no one-fits-all solution, choose yourself! Everybody was very carefully listening when @tobeytailor dove deep into the details of ECMAScript, JavaScript, the differences, the latest specification, the changes, prototypes, __proto__ and so on. Other interesting topics in those sessions had been promotejs, vapor.js, details about storage mechanisms, jQueryMobile, embedJS, apparat.io
That was real “JavaScript Rock’n Roll”!

Native vs. Web

On Saturday, the first day of the BarCamp, I had offered a session “Mobile: Native vs. Web” but didn’t see too many hands raised, so I just didn’t put it in the schedule, later some people asked me when this session would take place and that I should hold it on Sunday, which I fortunately then did together with Florian Detig. And I have to say I am very glad we did so, because 1) we (at uxebu) have a lot of awesome stuff to talk about and 2) it was really fun interacting with the audience and passing on all this information. It is always amazing again how much there is to say about how to create an app which can also be submitted into any of the various app stores by just using web technologies (the adult industry proved that again). HTML, CSS and JavaScript are just way to underestimated for being of good use in the mobile world. Florian first showed his awesome slides (I think they are really cool!). I continued the talk and dove a bit deeper into the mobile web topic, after my try of explaining the different movements in the native API space with players like W3C’s DAP, BONDI, JIL, WAC we deeply went into answering and discussing web technologies on mobile devices, I talked about our experiences, showed some projects we realized and answered a couple questions.
Not really a surprise but still impressing was the positive feedback we got when I showed of apparat.io, our soon to be launched service that will be able to convert a web app into a native app (You want to know about it first – follow @apparatio). The release date for the private beta will be the 25th October 2010, people who follow @apparatio will get accounts first. I also showed our project embedJS a toolkit (based on dojo) optimized for mobile usage.

All in all the BarCamp just made it obvious again that we are playing in an very interesting field and that we at uxebu are pushing the limits, that is fun, as much as the BarCamp was big fun, we will be back next time, for sure!
Thanks again and keep up the good work!