All posts tagged mobile

  • FirefoxOS: Beyond Idealism


    My former colleague Sergi Mansilla, now working on FirefoxOS, wrote a nice article about the promise of FirefoxOS:

    But Firefox OS will not be directly battling against other mobile platforms. Its main objective is to change the way the world develops mobile apps, and even in the unlikely event that Firefox OS itself disappears in the process, if web-apps become mainstream, it will have succeeded.

    The fact that any website is a potential app can’t be underestimated. By tapping into extremely popular and flexible technologies such as HTML5, CSS3 and JavaScript, Firefox OS instantly promoted millions of web and JavaScript developers into app developers. All they have to do is download a free simulator addon (and not even that is strictly necessary if your app is not going to use phone APIs). Developers already know the browser environment and the tools, and there’s no need to learn any new language or framework.

    I appreciate that the vision of FirefoxOS is that mobile apps — like desktop apps before it — need to move to the web. I also appreciate the idea that even if FirefoxOS itself fails, but web apps will have become the go-to platform for mobile in the process — that this will be considered a success as well. That’s very admirable.

    I’d like to talk about is the case where FirefoxOS does become a success.

    Read more

  • Facebook’s Project Spartan

    While Facebook released its video calling feature yesterday, something much more interesting may be coming, possibly later this month. It is called Project Spartan.

    Our interpretation of TechCrunch’s posts about Spartan is that Facebook will do for mobile what it did for its regular web version before: upgrade its “application” status to “platform”. A few years ago Facebook started enabling developers to build applications into Facebook, integrating them with the timeline, getting access to friend information etc. This enabled companies such as Zynga to create incredibly successful social games. Since that launch, Facebook is no longer just a website, it has become a social platform — the social platform.

    Soon, Facebook will do the same thing for mobile.

    There is a big difference in landscape, however. On the desktop, Facebook is primarily accessed through the web browser. On mobile, this is not yet the case. The majority of users access Facebook through one of its native applications. With Project Spartan, Facebook will go for a hefty HTML5 push.

    Why? Freedom and portability.

    Freedom from Apple’s restrictions on the ability to extend the functionality of iOS applications on the fly, by downloading new code — which is disallowed by the iOS developer terms. This means that it would not be allowed to let external developers extend the Facebook mobile app the way they can extend the regular web Facebook.

    Portability: Facebook is maintaining about a dozen mobile applications right now. It would be a breath of fresh air to drop a few of those in favor of HTML5 implementations.

    If it’s true, Facebook will essentially be launching an alternative AppStore, with its own set of APIs and own payment system. Still, a lot of questions remain: how will developers develop for this new platform, will there be tools available? Will it come with a custom set of Facebook-style user interface controls? How are the applications hosted?

    According to TechCrunch the focus will initially be on iOS (iPhone, iPad and iPod Touch). Presumably to get the experience right without having to deal with the idiosyncrasies between mobile browsers. After the initial launch, it will quickly spread to Android and other platforms as well.

    (Supposedly leaked screenshots of the service.)

    Even if you are not interested in Facebook, this will be a development to watch: it could mean a big push for HTML5 on mobile if Facebook pulls this off. In the end, it will all depend on what the experience will be, and if its applications are attractive enough.

  • Google’s New Mobile Tab Interaction

    It’s always interesting to observe how regular desktop web interactions can be translated to mobile. With the launch of Google+ with accompanying mobile web app, Google has changed the tab bar along the top of their mobile web apps. At first sight, they seem to have shrunk significantly:

    When looking more closely you notice an orange thing at the top right. What’s up there? To find out you can swipe the tab bar downwards:

    As it turns out that each tabs is accompanied with a giant product icon that creates a large enough touch surface to select it even with the thickest of fingers. At the right there’s the Google+ notification counter with a “More” area. When you select it, it slides down and shows more Google products.

    As it turns out, this “More” section contains sub-sections of its own: “Search”, “Apps” and “Notifications”. When selecting “Notifications” a list of Google+ notifications appear that can be acted upon:

    Note that all this action takes place in the tab section of the screen. At the bottom of the screen, you can still interact with Gmail as usual. This is Google’s mobile version of the pop-over it uses in the desktop browser versions of its applications:

    A clever solution that works very well in practice.

  • Xamarin Progress

    If you heard of Microsoft’s .NET, likely you will have heard of Mono, the free and open source implementation of the parts that comprise .NET: CLR, Framework and C# compiler.

    For a long time Novell was a major contributor to Mono and employed a number of its developers, including Miguel de Icaza and Nat Friedman — two big names in the Linux community. Recently, Novell fired a bunch of people, including the entire Mono development team.

    A commercial project that was developed under the Novell umbrella was Mono Touch a (commercial) set of tools to develop native iPhone and Android applications using C# and Mono.

    After being fired by Novell, de Icaza and Friedman started a new company: Xamarin and are currently working to reimplement a framework similar to MonoTouch (which is still owned by Novell). They are making good progress:

    Structurally, we are better off than we were the first time that we built these products. We have more developers working on each product than we did the first time around, so progress is faster. But we also had to swap the developers around: those that wrote Foo, can not work on Foo again. This is just one of the things that we have to do to ensure a clean room implementation.

    Our vision is to create happy developers. We did that in the past by bringing the C# language, garbage collection, LINQ, strongly typed APIs, Parallel FX, intellisense and inline documentation to iPhone and Android developers. And by making it possible for the world’s 6 million .NET developers to reuse their skills on the most popular mobile platforms.

    And they have their first applications running:

    It gives me great pleasure to say that we have elevated the discourse on the iPhone simulator and my Chicken-powered TweetStation is up and running with the new iOS product. The picture on the left is TweetStation powered by MonoTouch, the picture on the right is TweetStation powered by Xamarin’s iPhone product [left is MonoTouch]:

    We also have the delicious iOS5 APIs exposed as strongly-typed and intellisense-friendly C#. We are now updating the APIs from Beta1 to Beta2, which should be completed today or tomorrow.

    Our Android efforts are moving fast. Only this morning we got Layouts to render on the device. This is a lot of work, as it gets Dalvik to start Mono, and initializes our entire bridge and exercises the C# and Java bridge. In addition, we have identified and fixed a serious problem in the distributed garbage collector.

    An initial release of the product is expected this summer.

  • Mobile Web Browsers Wars: iOS vs. Android

    iOS 5 will be featuring a few new features that enable a better user-experience for web applications. Great news for those rooting for mobile web apps. Matteo Spinelli (creator of iScroll) even claims that web apps are now completely ready to replace native apps on iOS:

    The real revolution might be iOS5. In the first beta they revealed overflow:scroll and position:fixed, while the second beta seems to unleash the devastatingly cool -webkit-overflow-scrolling:touch CSS property.

    With -webkit-overflow-scrolling:touch you can finally have native scrollview inside your web app and together with webGL there’s no reason on Earth to go Object-C (I’m over-exaggerating, don’t flame).

    As it is already happening for Mac Apps you may decide to publish your future iOS apps on the Apple Store, or release them on your website, or take advantage of the two worlds and follow both paths.

    I envision a future where 90% of the native apps are just webview wrappers (as it is already happening thanks to Phonegap).

    Although clearly iOS is moving in the right direction, it is not there yet. Beside the issues of still-limited access to device APIs and somewhat worse performance, there are some subtle issues (even in iOS5). For instance, web apps added to the home screen do not support multi-tasking. When switching between applications and switching back to a web app, the app completely reloads.

    Still, iOS is doing way better than its main competitor Android.

    It’s ironic that iOS is far ahead of Android when it comes to mobile web app support, given the fact that Android comes from this company called Google, that is all about the web, or so they claim. Apple, on the other hand embraces the web, but mostly as a transport mechanism and utility. Apple’s vision of the future is native apps, mixed with pragmatic use of web views.

    As a case in point: iOS allows users to add web apps to the home screen, appearing like any other locally installed application — runnable without any browser chrome (no back and forward buttons), you can set the top bar color and the icon to be used on the home screen. Android offers no such feature. You can create a bookmark on the desktop, but it really looks like a bookmark, and when tapped simply switches to the browser and displays the page like any other website you visit.

    It gets better, though. Consider Google’s own web version of maps for mobile. While on iOS you can use pinch-to-zoom, the Android version does not support this feature and requires the user to use zoom in/out buttons. Why? Android does not implement the required HTML5 features to implement this, as became painfully obvious when asked during a Q&A session at Google IO.

    Shi Chuang:

    When someone asked about the lack of effective zoom feature on Android browser. Susannah said the pinch-and-zoom feature is supported by iOS, because iOS has a meta data setting used to specify that this map should be displayed full-screen and should not be resizable by the user.

    Chuang observes another problem:

    Android never reads W3C papers written by other Google employees. Andrei Popescu and Steve Block at Google W3C team has written a paper about DeviceOrientation, again, ironically, a draft initiated by Google’s employee is implemented by its rival Apple iOS, but nowhere to be seen on an Android device.

    Although Android’s browser is a great browser to browse the “desktop” web — arguably as good or better than iOS — it does not seem to take the web as a web application platform seriously enough. Which is ironic — you know — because it’s Google.

  • Mobile Apps Are Bad At Mobile

    David Singleton monitored his Internet connection while on a train journey. Most people have experienced what it is like using mobile Internet in a driving vehicle — it’s generally pretty unreliable.

    David found that the big issue is incidental latency. Latency can vary wildly, in his measurements between 100 milliseconds and 20 seconds. TCP does not deal well with such differences, due to its exponential backing off. Do we need something built on IP that deals better with extremely unreliable connections?

    This makes a strong case for offline capable mobile applications: make sure your application is still useful during those 20 second latencies. Cache data. Precache data. Show something more than just a spinner.

    As it turns out mobile apps are generally good at the “app” part; not so much on “mobile”.

  • Are Web Apps An Insult To Users?

    Web apps vs. native apps for mobile — this appears to be what everybody is talking about these days.

    I think native apps currently provide the best user experience, don’t you? As a user, given the choice between a web app and native app, which one would you pick? Unless you signed your life away to the web browser, it’s likely going to be the native one.

    Still, reasons to develop for the web are there: portability, simpler deployment, perhaps simpler development — all developer reasons.

    But ehm, who are we developing sofware for? Ourselves or our users?

    Following that logic — aren’t web apps a statement saying to users: we favor ourselves over you?

    On the desktop this is not really the case. Over the past decade, web apps have not become popular because of developers; they are convenient for users too: no need to install anything, access from any computer, no (manual) software updates, usually free, data “safely” stored in “the cloud” and easily shared with others. The fact that the user experience is a bit limited is a small price to pay.

    On mobile, the story is a little bit different. Every smartphone comes with an application store of some kind from which you can easily install and update applications. Since a phone is a personal device, rarely shared with multiple people, it’s less common that you want to use somebody else’s phone to access your applications — which makes the “login from any computer” pitch less relevant. And mobile apps almost all store their data “in the cloud”. What is left of the web app advantages are developer specific: portability, easy development and deployment.

    So, I ask again: is a mobile developer using web technologies choosing himself over the user?

    As usual, it’s not that simple.

    Let’s say I run a one-person company and I want to build a mobile app. I have three months to go to market. Effectively, I have roughly three options:

    1. Pick one mobile platform, say iPhone, and develop only for it.
      Advantage: I can focus on a single application and provide the best possible user experience to my users.
      Disadvantage: my users are going to be only iPhone users — Android, BlackBerry and Windows Phone users will be left in the cold.
    2. Instead of one, I pick multiple platforms, say four, and develop separate apps for all of them.
      Advantage: I reach a much larger audience with great, custom tailored mobile apps.
      Disadvantage: the mobile apps will only have about one fourth of the functionality I had planned, because I had to develop every feature four times as code reuse is barely possible.
    3. I develop my mobile application using web technologies.
      Advantage: I have to implement my app once and it runs on multiple platforms. In addition, my application has all the features I intended to build, because I only had to build them once.
      Disadvantage: The user experience is worse. The application doesn’t blend in or integrate with the OS.

    So, what have we learned?

    1. Reasonable time to market
    2. Flawless user experience
    3. Big reach

    Pick any two — a company with limited resources cannot have all three.

  • Web vs. Native On Mobile: The Never Ending Struggle

    It seems to be an everlasting battle: what’s “better”: developing mobile native applications or developing mobile web applications? Sadly, the answer is boring: it depends.

    What matters to you as the developer?

    Multiple-platform support. Web applications are a cheap way to go. Develop your application once, run on many platforms immediately. You can reuse the same code base on multiple platforms. When going the native route you will likely have to entirely redevelop (and maintain) your application on every platform.

    Quick iteration. Iteration can happen quickly on the web: simply deploy a new version and all users get it instantly. Deployment of native applications requires an explicit update action from the user, plus a (possibly lengthy) approval process on some stores (e.g. Apple’s AppStore).

    Integration with the OS. Web applications can do less than native applications. Need access to the camera, file system, address book, notifications (or even extend those features)? That’s a no-go for pure web applications (at least, for now). However, you can wrap your web app using PhoneGap to get access to many of those APIs as well, the drawback is that you lose the advantage of being able to iterate quickly, because you have to deploy your applications through app stores.

    What matters to your users?

    Performance. Web applications are typically slower than native applications. Of course, it is possible to write extremely slow native applications, but assuming good development practices: a native application will always outperform a web app. That’s the way it is, that’s the way it will be. However, on the long term, the performance of native and web apps will converge. The question is: what are your performance requirements? Is a web application fast enough?

    Native look and feel. By default, a web application is not going to have a native look-and-feel. You can get quite far in mimicking a native look and feel (e.g. by using similar colors, similar transitions), yet — very likely — your users are going to be able to notice the difference. I have yet to see a web app where I couldn’t notice it was not native. The question is: does it matter? How important is it that the user notices a difference? Take the Gmail mobile web application, for instance. It doesn’t look native, but it looks clean and it works well. Does it bother me it’s not a native application? Not enough not to use it. I prefer it over Apple’s native mail application because I choose functionality over looks.

    User experience. The way the user interfaces are laid-out and operated differ slightly from platform to platform. Although iPhone and Android appear to be extremely similar, there are subtle differences in how the user interfaces are organized and operated. Android makes use of the touch screen, as well as three (hardware) buttons: back, menu and search. No such buttons exist on iOS. The back button is typically an on-screen button, but the idea of a pop-up menu is inherently non-iOS-esque. For web applications this is a problem. First of all, a web app cannot take advantage of additional hardware buttons (other than the back button), but beyond that, you will likely not want to redevelop the way your UI is laid-out for every platform. Thus, you have to come up with some sort of greatest-common denominator: pick the user interface elements that all platforms support and use those exclusively. Is that a problem? Depends who you ask.


    Even though I develop mobl (a language for mobile web application development) I’ll be honest. As user, if I could choose between a web app and a native app, having the same feature set, I would go for the native one. However, from a developer’s perspective it’s a much more difficult choice. It completely depends on target audience (what do they care about, what devices do they use?) and specific requirements of the application (do I care about performance, do I need OS integration?).

    And I haven’t even touched on development models and tools yet.