This year the German IT trade show CeBIT tried something new: A conference for mobile developers, called moosecon (mobile operating system conference).

The conference lasted three days, of which I was present at two, Wednesday and Thursday. Here's a short recap of the talks, I visited.

Wednesday - March 6, 2013 / day one

Thanks to the German railway system I was late. Nearly one hour later than expected. Thus I missed much of the first talk of the conference. And to make matters worse, the conference organizers decided to change the schedule.

HTML5 for the mobile web - Firefox OS
Chris Heilmann, Mozilla

The train delay and the reorganization both resulted in me missing most of Chris Heilmann's talk about Firefox OS. From what little I could hear of the talk, it probably was the most interesting talk of day one. Especially since I am very interested in Firefox OS.

Those that follow me at Google plus know that I hope for FirefoxOS to become a viable competitor to iOS and Android - even though I remain sceptic of the chance to get there. I think it can only be good for innovation in the field if there is a bit more competition and if there are more open players. I am an Android developer and intend to stay one, but this doesn't mean that I might not have a look at other systems.

Right now I mostly despise HTML5 apps on Android - simply because they do not fit. They often lack the necessary visual integration into Android and just do not feel right. That's not too surprising, because right now most apps, if not all HTML5 apps, are created to save money while deploying the same app on multiple platforms. That's something that simply doesn't work too well. It has been a problem for Java apps on the desktop for years and it's no different for HTML5 - so I guess it's not something that will just vanish when HTML5 gets more mature, it's API more stable and unified across browsers and so on.

Nevertheless I think there is a place for HTML5: For apps within a browser or if HTML5 apps are first class citizens of the OS as in Firefox' case. In the latter case the problems that apply to webapps on Android are simply no problems, because all apps are webapps - with probably some kind of standard look & feel as well. Performance problems though might remain.

What I heard of Heilmann's talk centered mostly around Web-Activities. Those more or less resemble intents. Google had introduced a proposal of Web-Intens before - but from what I understood at the conference, Google doesn't use those any more and both now work together on Web-Activities (though this was a bit vague).

I still haven't seen Firefox OS in action and if Chris has shown a live demo I must have been to late for it. But from this talk, I still consider it to be an interesting approach.

If you want to know more about developing for Firefox OS, visit Mozilla's developer site for Firefox OS.

Effects of Firefox OS
NN,Telekom

Someone from Telekom's management replaced Martin Kurze, who got ill. I didn't get his name, but he was pretty high up. Given that he was management it was surpirsing that his slides were the worst ones presented. Whatever you can do wrong on a slide, you could find it here. But apart from that the talk was more interesting than I had expected.

He outlined why the Telekom is supporting Firefox OS. Purportedly because Telekom is all for openness. He made a big fuss about HTML5 and that this is an open standard and what not. Yes, it is and that's what I like about it as well. But in the case of Telekom I guess it has more to do with them not wanting Google, Apple or Microsoft to be the only ones profiting.

Be it as it may, this carrier as well as many other carriers is supporting Mozilla to create another competitor and to keep relevant and get a share of the revenue. While I couldn't care less who get's the biggest piece of the cake, it could prove important for Mozilla in getting some traction - especially in markets in which customers are still using feature phones by a large margin (Telekom for example starts with handsets in Poland).

Successful Inhouse Enterprise Apps
Patrick Blitz, Weptun

This talk centered mainly around two aspects: Security and Connectivity. The talk was too high-fly for me to really like it. Nothing wrong with giving an overview. But moosecon is a developer conference. And as such I would have liked to see some remarks about difficulties and problems in implementing each of the solutions.

Maybe he should have sticked to just covering security. After all connectivity is a problem common to nearly all apps and thus not specific to in-house enterprise apps.

Enterprise apps nearly always have to deal with very sensitive data. Data that has to be kept private - no matter what. I really would have liked to hear more about that.

The bad audio situation didn't help the talk either. Not the fault of the speaker who spoke clearly and articulate, but of the conference setup. More about that later on.

I think a bit more in-depth coverage of what the biggest problems are (from a developer point of view) would have helped this talk.

Creating Backends in Minutes
Lutz Kohl and Philipp Michel, Apiomat

The speakers presented backends as a service (BaaS) in general and exemplified the key points with apiomat, the solution of their company.

Obviously the speakers had an interest to present BaaS in the best possible light - and they did a good job at this. There are very good reasons for using backend services in the mobile environment. Their main point was that it reduces time to market, that it helps safe costs and that you do not have to care about getting the necessary amount of power and of getting this right. Time to market is probably correct, depending on the flexibility of the BaaS provider. I also think that it's difficult to estimate the necessary computing power and that for many projects it's an unnecessary burden to have to think about load balancing, redundancy, failover solutions and what not. So far I'm in the BaaS camp.

But I think the speakers purposefully underestimated the complexity around REST - which will remain independent from using a BaaS solution or a selfmade one. Thus I do not believe their cost estimate at all - but well, of course they were a bit biased 🙂 Granted, BaaS probably is cheaper, but the difference is much smaller than presented here.

They showed how to use apiomat, how to generate code from their website, where to create custom business logic besides simple CRUD-logic and how to integrate apiomat into your app. Both speakers did a good job, but some stuff could have been a bit more detailed. Also the dashboard and any reports would have been interesting.

Nevertheless BaaS solutions are interesting and can help your project siginificantly. Apiomat is a German solution targeting the European market, so maybe they are the right solution for you. Which BaaS provider to use comes down to a business and a trust decision. The latter is very important since BaaS requires a trustworthy partner. And don't forget the privacy aspects as well. At least we Germans are very sensitive when it comes to this.

Push Notifications
Benjamin Broll, Little Postman

Benjamin talked about push notifications and how complex this can get - especially if you want to use push for different target platforms. The latter is made worse because each platform has it's own notification model and each provider handles communication between your backend and the notification delivery service (e.g. Google Play Services for Android or Amazon Device Messaging if you care about the Kindle Fire). He detailed the problems you have to deal with if you want to do so on your own. Well, of course he was on a mission as well - but this part of his talk was really good!

He also stated reasons why push is a good solution and that it might help user satisfaction - especially if you find innovative uses for push - the examples he gave were also interesting to hear.

So far so good. But why not show how to do all that with Little Postman? After all, that's his company and there's nothing wrong to present your stuff if your general points are presented in a more or less neutral fashion. I think he missed an opportunity here to drive home the message, that Little Postman could be the solution of choice for you.

Overall impression of day one

I have heard some nice talks but obviously missed a very large part of the most interesting talk. All in all it was too little code and often too high-fly for a developer conference.

But the worst thing was, that it didn't get the attention that is so important for conferences. Attendee numbers were quite low - especially in the closed area. So one of the great by-products of conferences - being able to meet people you know via the many social channels as well as to network with other devs - was nearly completely missing for me.

Audio quality also was a big problem - at times nearly unbearable. The sound level at trade shows is always very bad. But in this case the open and closed stages were too close to each other, which sometimes made listening unnecessary hard.

Wednesday - March 7, 2013 / day two

I was on time - great. But there had been a shuffling of talks once again. The first two talks at the open stage were swapped. Thus I couldn't hear the Google TV talk I originally had planned to go to and instead listened to a white-collar talk I hadn't had on my agenda.

Cross Platform for White Collar Workers
Marcus Ross, Zahlenhelfer Consulting

Marcus is developer and project manager - but in this talk he was all project manager. The title of the talk says it all: It was no technical talk.

Obviously Marcus thinks much more of HTML5 apps as a cross-platform solution than I do. He believes that they can be a good fit for apps, that must run on multiple platforms. He mitigated this by saying that it depends on the requirements, but still...

According to Marcus, often some kind of hybrid is needed where you access certain hardware features via a wrapper API and otherwise use HTML5 to develop your app. Another point of Marcus was, that unless you are doing in-house stuff or cannot use the app market for business reasons (e.g. for publishers the Apple app store often is no option), you should always use at least some kind of wrapper to market-enable your app.

I think though, that this is risky: Putting your app on the platform specific appstore might make marketing sense, but it also sets certain expectations of the customers. I think HTML5 apps should stay on the web, be clearly recognizable as web apps and as such should use a standalone UI that doesn't try to mimic the native UI. Marcus obviously disagrees and showed samples of apps that try to resemble native apps as closely as possible. Well being an Android native developer, it's kind of my duty, to disagree 🙂

If you wonder how this fits in with my Firefox OS hopes, keep in mind that on Firefox OS it's a completely different story - there HTML5 is native! And I wouldn't recommend to use a Firefox OS app on Android within some native wrapper. I have no problems with them though, if they run within a browser!

At the end the organizers started talking at the second stage - which caused many (including me) to leave this stage. But then the talk actually didn't begin for another five minutes. Sorry, but this shouldn't have happened. The organizers should have been more careful. It simply was not fair to Marcus.

Ugly thruth about HTML5
Robert Virkus, Enough Software

This talk was some kind of counterpoint to the previous one. Robert prefers native. And it's not just what I've written above, but there are technical reasons why cross-platform is not as cross-platform as management thinks. Most platforms (Microsoft's Windows Phone OS and Mozilla with Firefox OS being two exceptions) use Webkit as the default rendering engine, but that's just one part of the story. When it comes to Javascript - and you will need to use Javascript - each vendor uses its own engine. And even worse: Webkit is not the same everywhere. There are tons of compile time flags and Android uses different ones then iOS. Thus you can use some stuff on Android which isn't available on iOS and vice versa.

Than he mentioned the uncanny valley. That's a robotics theory stating that when humanoids get more and more close to actual humans people at first like this, until it suddenly changes and people start to strongly dislike those robots - until approval rises again when the humanoid is nearly indistinguishable from a real human.

He applied this uncanny valley theory to mobile apps. People will dislike your app if it tries to be like a native app, but fails to actually deliver. Thus his advice for any HTML5 apps: "Don't mimic the native UI - use an HTML5 UI". Couldn't agree more!

BTW: That's the reason why HTML5 works for games that do not need native speed. Games most often do follow their own style and thus do not mimic the native UI anyway. And since games never did, customers won't wonder about this. Instead they expect games to be different. In my opinion games are thus currently the only real option for HTML5 apps.

Mobile Market News
Sacha Pallenberg, MobileGeeks

Well, i don't know. I'm no big fan of him. But he definitely is a great speaker and he knows his stuff (mobile hardware) very well. Thus this talk was indeed very interesting. His talk was lively and it was obvious that he really enjoys his field and also talking about it. His talk was hampered by severe technical problems (the beamer going off every now and then for roughly two/three minutes) but he managed to work around that effortlessly.

First he talked about SoCs. Something I'm not much interested in.

Interesting though his take on the battle of mobile operating systems and if competitors to iOS and Android can play any significant role. In short: He's not very optimistic about any of the other platforms - with the exception of Windows Phone. One point for FirefoxOS is that it has the backing of many carriers, but he doesn't believe that it will help them that much.

What took me totally by surprise was his statement, that Nokia managed to keep it's ship afloat because of its Windows Phone transition. Huh? Right now I still think this strategy is not working too well for them. But let's wait what the future might hold. Predictions in this area are not worth too much anyway 🙂

Lessons Learned from Prime Guide
Markus Junginger, greenrobot

Finally two Android related talks. Markus talk about Prime Guide - an Android only TV programme app that I highly recommend and use myself - came first. His talk contained some interesting surprises. Lessons learned are always great and probably should be covered more often (on conferences as well as on blogs or in magazines). Why not learn form others?

The Prime Guide team took great care to deliver an outstanding Android experience - a necessity to compete in the crowded TV-programme market. And it can be seen: As a user of this app, I can confirm that it indeed performs well and looks great. The good ratings of the app are another proof that they did a good job.

The devs made heave use of libraries or created some while developing the app. Something Markus recommends highly to all Android devs. But even with using libraries, the app took still way longer than expected - not least because its developers had to move to customer projects and couldn't work continously on the app. Markus estimated the total amount for the app was more than one person year.

Especially fragments gave them headaches. To quote: "Fragments are one of the most difficult APIs" in Android. Especially together with multi-threading and funny (or rather not so funny) life-cycle issues.

Prime Guide is a good example for why BaaS makes sense. They have two big peaks when it comes to backend hits: In the evening when people actually start to watch TV they use this app the most. From the graph presented it's an enormous spike and to cope with that, you definitely have to use a cloud based service - or use a set-up that idles away most of the day. The second spike comes from when the server downloads and processes TV programme data.

In his talk, Markus mentioned some problems with app engine. One of them stuck with me: When they started out, AppEngine offered no SQL database. And according to Markus "that's not cool" at all (so much for the NoSQL rage) - but instead caused them to adapt the data model to app engines' special needs.

The thing though, that surprised me the most was his statement, that they shouldn't have published the app for all device categories at the same time. Since I think this app is extremely well suited for tablets, I asked him if they wouldn't have been missing out had they done a phone only app first. Markus states that they could have released the app much earlier had they made a phone only app. I guess there is no arguing about that. He also states that when they started out Android tablets had not been as wide-spread as nowadaays. Granted, but I still wonder.

Would their initial rating (4.6 in the first week) have been as good? Wouldn't many have complained and demanded a tablet version? Which might have caused them to rush one with potential implications for the overall app quality. Finally a tablet later strategy might have lead to some serious refactoring when adding the tablet-related aspects later on. With probably even more complexity and headaches. I don't know. Markus has way more experience than I have, so I really would like you to chime in. What do you think about releasing for the phone first? And is this still a viable strategy - now that many more tablets are in use? Please let me know on G+ or in the comment section.

Oh, and here's one last but important advice from Markus: Release early! Don't wait till it's perfect! Users might have different needs anyway (in their case for example they wanted more channels within the app).

In short: Great talk!

Edit: After reading my draft, Markus send me some clarification about this: In this clarification he suggest to only offer the most essential functionality for tablets right from the beginning and to add more later on. Do not waste time with every detail on every screen for all three versions (Google TV, tablets and phones) but concentrate on phones and only for some especially central screens on tablets. Even with this clarification I still would like to hear your thoughts on this in the comments!

AB-Test Library for Android
Hasan Hosgel, Immobilienscout24

In his talk, Hasan Hosgel presented his library CustomersChoice, that you can use to enable AB-Testing within your apps. It's an open source Android library and the project page of CustomerChoice is hosted on github.

Hasan first stated why he created it. The point is that product managers often have no clear idea which features are really useful or how to present those features. Usually you create a short user test to find out, but often you still don't get a clear picture. That's where this library comes into play.

While ImmobilienScout24 (Hasan's employer) can afford customer surveys and user tests, small shops or indie developers sure can't. Thus this library is even more useful.

After this he showed how to use the library. You only need a few lines of code to choose a variation and to report a success - if the user found and used the feature you test.

Configuration needs a bit more code but is still pretty straightforward. Configuration can be done in multiple ways. Either in code or by a JSON definition that the library can download from the web, read from the SD card or get from a resource definition within the app. Here you define the variants and their variations. A variant is one feature you AB-test. A variation is one specific implementation of this variant. So if you want to test which of three colors is the best this would be one variant with three variations.

Each variant has a name you later use in code. They also have optional start and end dates to scope the test. And you can set the ratios between the variations - the default being a uniform distribution of course.

Finally Hasan showed the library in action and it's integration into his code. You can also download a demo of Customer's Choice to have a look yourself.

My only beef with this library is it's name. It suggest a conscious decision by customers about which features to implement in which ways. Which generally is no good idea. You should listen to customers, of course, but which features to implement and especially in which way should be your decision based on user goals, usability concerns, the direction you want to move forward in and the general style of your app. Thus I think CustomersChoice is a misleading name.

So to clarify: This library let's you find out which possible implementation works best for your user base. Exactly what we sometimes need.

Good talk and an interesting library. I suggest to have a look at it.

How Paypal uses Open Identity
Tim Messerschmidt,Paypal

Now, to be honest: If Tim hadn't been in my Google plus circles I never would have watched this talk. Paypal is not my most liked service on the web. Apparently I'm not alone with it, because Tim tried to destroy any doubts about using a Paypal solution 🙂

First Tim explained the concept of identity within his talk. It's mainly about authenticating a user. All those "Log in with Twitter" buttons basically allow you to use one account to access multiple websites.

And here is where Paypal comes in. For shopping sites you may not want to use your Twitter account but a more reliable partner that either already has your credit card information or which you trust enough to hand over your payment information.

Paypal uses OpenID Connect which, according to Tim, is much easier to use for us developers than plain OAuth 2 - even though it uses OAuth under the hoods. He explained that OAuth has developed in a direction where you basically need a custom implementation all the time without being able to leverage code reuse. Something that OpenID Connect seems to solve. Whether that's true or not, I do not know - but I know that OAuth has a reputation of being a mess.

He also showed the different levels of information clients can get from Paypal. As usual the user gets a short list of what is offered by the provider (here Paypal) to the site. In Paypals case this ranges from just a confirmation of the name and the email address to the real-world address of the user to his age information. Finally Tim concluded his talk with a short demo.

Paypal might actually be the appropriate solution in some situations. But for now the only important thing for me is to know that it exists - should I ever have a need for it.

Overall impression of day two

Apart form two things this day was much better. Sound problems were not as pressing - especially since in the afternoon only one stage was used. The problem with the beamer - well this can happen. Not too much of a problem - though they were lucky that it happened while a seasoned speaker was on stage. Totally unacceptable was the early opening of the second stage while a speaker was giving his talk on the other stage. Given the sound condition it was no wonder that many people thought the next talk was starting.

Apart form the first talk, this day was more technical - which obviously is more to my liking. And this day I also met people I knew. I've met Hasan Hosgel at last years Google devfest in Berlin and together with others we stayed at c-base for quite some time in the evening. It was nice seeing him again - though I prefer the c-base atmosphere any day! I hope for another devfest this year. I also knew Markus Junginger, Matthias Friedrich (no speaker) and Tim Messerschmidt from Google plus. Great meeting them as well.

How the moosecon should change

I think the moosecon has a future, but it must improve in some areas. It should be more technical and more dev centric - or offer two slots: One for devs and designers and one for management.

Having mentioned designers: I wonder why they aren't invited as speakers to these events? The design (as well as the usability, which is something completely different) plays an important part in the success of an app - still it's ignored way too often. I'm a dev, I have no talent at all for design, but even I notice apps that are either too complicated to use (bad UX) or simply visually too off-putting to use. The one problem here of course is that UI and UX concepts of all platforms are vastly different. But so are the programming models.

I think speakers should be instructed to give a technical talk (unless the conference offers the two slots I mentioned above, in which case I only speak for the dev slot). To concentrate on those aspects that are most interesting to fellow devs like problems encountered and tips how to deal with them. Or talk about how to use your libraries/products, how to integrate them.

In general the conference must attract more people. The organizers must concentrate on that. Good talks are one way to achieve this, but not the only one. Maybe more hands-on stuff would help. Some kind of app-dev-contest, hackathon or what not. Or offer some power workshops. It was simply too little content.

Another possibility would be to only use two days but more stages. Given that the early as well as the last talks were not visited well it might also be worth to consider reducing the overall time on stage and offer other things like workshops afterwards.

As a final note: The catering was excellent. Thanks!