On automatically generating fully functional mobile user interfaces

An upcoming feature in Cloudfier is the automatic generation of fully functional user interfaces that work well on both desktop:
Screenshot from 2014-01-29 13:57:47
and mobile browsers:

Screenshot_2014-01-29-13-45-01 Screenshot_2014-01-29-13-44-53
This is just a first stab, but is already available to any Cloudfier apps (like this one, try logging in as user: test@abstratt.com, senha: Test1234). Right now the mobile UI is read-only, and does not yet expose actions and relationships as the desktop-oriented web UI does. Watch this space for new developments on that.

The case against generated UIs

Cloudfier has always had support for automatic UI generation for desktop browsers (RIA). However, the generated UI had always been intended as a temporary artifact, to be used only when gathering initial feedback from users and while a handcrafted UI (that accesses the back-end functionality via the automatically generated REST API) is being developed (or in the long term, as a power-user UI). The reason is that automatically generated user-interfaces tend to suck, because they don’t recognize that not all entities/actions/properties have the same importance, and that their importance varies between user roles.

Don’t get me wrong, we strongly believe in the model-driven approach to build fully functional applications from a high-level description of the solution (executable domain models). While we think that is the most sane way of building an application’s database, business and API layers (and that those make up a major portion of the application functionality and development costs), we recognize user interfaces must follow constraints that are not properly represented in a domain model of an application: not all use cases have the same weight, and there is often benefit in adopting metaphors that closely mimic the real world (for example, an audio player application should mimic standard controls from physical audio players).

If model-driven development is to be used for generating user interfaces, the most appropriate approach for generating the implementation of such interfaces (and the interfaces only) would be to craft UI-oriented models using a UI modeling language, such as IFML (although I never tried it). But even if you don’t use a UI-oriented modeling tool, and you build the UI (and the UI only) using traditional construction tools (these days that would be Javascript and HTML/CSS) that connect to a back-end that is fully generated from executable domain models (like Cloudfier supports), you are still much but much better off than building and maintaining the whole thing the traditional way.

Enter mobile UIs

That being said, UIs on mobile devices are usually much simpler than corresponding desktop-based UIs because of the interaction, navigation and dimension constraints imposed by mobile devices, resulting in a UI that shows one application ‘screen’ at a time, with hierarchical navigation. So here is a hypothesis:

Hypothesis: Mobile UIs for line-of-business applications are inherently so much simpler than the corresponding desktop-based UIs, that it is conceivable that generated UIs for mobile devices may provide usability that is similar to manually crafted UIs for said devices.

What do you think? Do you agree that is a quest worth pursuing (and with some likelihood of being proven right)? Or is the answer somehow obvious to you already? Regardless, if you are interested or experienced in user experience and/or model-driven development, please chime in.

Meanwhile, we are setting off to test that hypothesis by building full support for automatically generated mobile UIs for Cloudfier applications. Future posts here will show the progress made as new features (such as actions, relationships and editing) are implemented.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

3 thoughts on “On automatically generating fully functional mobile user interfaces

  1. Andrew McNair

    February 9, 2014 at 10:21pm

    The generated UIs look great! I’m not sure what early adopters you’re targeting right now, but a friend of mine was recently paid to write an admin website for a company that had made a mobile app – all they wanted was a simple interface that they could add content to and a json api that the mobile app would talk to. Alternatively now there are a lot of websites that need to either create mobile versions or apps, and are using things like phonegap to help with that. I wonder if you could pitch cloudfier as an alternative where you’ve already implemented either the mobile or web, and cloudfier makes it easier to re-implement the core functionality and deploy as the other half of things. I guess my opinion is that often there’s one interface you really care about, and other interfaces that auto-generated UIs might be good enough for.

    • admin

      February 12, 2014 at 7:47pm

      Hi Andrew, thanks for the comment!

      Right now, there are 3 niches I am considering:

      • services that play a non-critical role in the customer IT environment (because any cost to develop is hard to justify)
      • prototyping (because it won’t require a production ready implementation)
      • information-centric apps that will need a mobile UI (because most devs have yet to have an experience building such apps)

      Cloudfier currently wants to own the back-end (for the functionality that is modeled) from the REST API to the business layer to the database, so it won’t be able to use an existing database or API. Integration is possible though, so it could send/fetch data to/from other existing services (that address other requirements) if needed (like an expense reporting application that sends approved payments to an Accounts Payable application).

      But at this time it won’t help with giving an API or a mobile UI to an existing application.

    • admin

      February 12, 2014 at 10:16pm

      Notifications were broken (DigitalOcean keeps blocking smtp), please see reply, Andrew.

Comments are closed.