By controlling the front end of mobile apps from the back end we can build customized experiences at runtime, creating cleaner interfaces and reducing load times.

Article No :1245 | May 28, 2014 | by Nithin Rao

Steve Krug famously said, “Don’t make me think.” This statement is simple, profound, and especially true in the case of mobile interfaces. With smaller screen real estate, increased app fatigue, and decreased user adoption rates, there has never been a better time to revisit these words.

The key to keeping apps ticking, alive, and successful is captured right in that statement. Create an intuitive user experience; don’t make the user think.

User experience is the art of weaving together context, design, ease of use, uniformity, context, relevance, and consistency. On mobile, this experience is what sets apart the successful apps from the rest. Every interaction that the user has with the app turns into an opportunity to be seized to turn it into a deeper, longer relationship. This can be accomplished in two ways:

Through colors, design, and typography—the purely visual end of the user experience spectrum. Designers can use these elements to create visual continuity, pleasing interfaces, readability, and functionality.

Another equally important and oft-overlooked aspect is controlling the front end of mobile apps (the mobile UI, screen layouts, and elements) from a back-end (such as the server or Content Management System or Web application). This philosophy makes it so that screens can be built at runtime allowing them to be either data or user driven.

Reams of digital paper have been written on achieving user experience through purely visual elements. Let us delve a little deeper into the latter approach.

The Over-Arching Process

The back-end, be it the server or CMS first identifies the context.

Depending on context, this back-end generates screen element information and selects the content to be displayed in the app.

This information about the screen elements and content is sent to the front end, which is the mobile app.

The mobile app renders the screen accordingly.

What Impact Will this Have on Users?

A superior and more convenient user experience. Period.

By getting rid of screen widgets that are not needed for a particular kind of user or a kind of data, we can offer users an uncluttered app interface. We can re-use the same screens for different use cases. We can make the application scale automatically and enhance functionality without having to deploy new code.

Context 1: Users

Identify user groups based on login and display screens accordingly. Let’s take the example of an enterprise iPhone app being used by employees of a company to fill in timesheets.

Upon login, an employee views just his or her timesheet and has the option to fill in the fields with hours spent and project worked on before submitting it.

If the user is a senior manager, however, upon login, his or her screen would show his or her own timesheet and additional links or buttons to see the timesheets of team members and approve them.

The back-end identifies not just that this user is a manager but also the employees that are in his or her team, allowing access to only their timesheets.

For managers, the screen could also throw up a dashboard for analysis such as a chart of employees vs. time spent on work.

Context 2: Data

Identify the data structure and display content accordingly. Let’s take the example of a mobile app that requires users to fill a form with different fields.

The back-end application can be built in such a way that it allows for fields to be added with names and their types. For example, Name would show up with a text field, whereas a “need pick-up” option would show up with a toggle switch with “yes” or “no” options.

If we take another case where the data type is a list, this is identified and sent to the mobile app along with the list contents. The app will then display a widget that can hold a list.

The fields can also be reordered exactly the way the mobile app has to display them.

When the business requirement changes to show new fields in this form or to hide this form altogether from the mobile app, it can easily be accomplished using the database or a content management application.

Context 3: Input Fields

Identify the input field and display appropriate attribute field. For example, an admin user uses a CMS to create a form for patients to fill up in their mobile app.

This user can create a field “Registration Number,” which is a text field, and specify its attribute as “numeric input.”

Accordingly, in the mobile app, that form displays a text field that shows up with a numeric keypad when user tries to enter information.

Context 4: Geo Location

For this example, a mall has an app that visitors have downloaded.

As they move around, visitors will see trending offers and coupons on their screens related to the stalls they are closest to.

Also, depending on where they are, they see screens getting refreshed with relevant content. So, if they were close to an apparel store, the UI would be a product catalog whereas if they were near a restaurant, they would see a menu listing.

Context 5: Operating System

For cross-platform apps, this could be a real boon.

The app could show iOS style buttons if the device is detected as an iPhone or hide the “back” buttons if it is an Android phone that has the device “back” option built in.

The true advantage lies in retaining the native feel even with cross-platform or web-based apps.

Context 6: Screen Resolution

Let us take the example of an app that has images coming into the app via web services.

The exact number of images would be known only at runtime, so a single image will have to be shown and centralized on the screen, but multiple images would require an image gallery.

Similarly, large devices can show a grid of thumbnail images and allow users to pick one to see full screen view. For small devices, the grid would not work because each thumbnail is too small for the user to make out anything.

So, the best UI would be to use a carousel or a horizontally scrolling set of images for the user to browse through the entire set. Another option would be to have the same grid style, but bigger-sized boxes in it.

Dissecting the Pros and Cons

The advantages that this approach offers designers and users vary from more innate user interactions to reduced code deployments. Specifically:

Reduced number of screens in the application

Reduced number of clicks to get to a feature/functionality

Gets rid of unwanted screen elements making for a cleaner UI

Enhances user experience by keeping content contextual to user/data

Retains flexibility to introduce new screens or new screen elements by giving a few user controls in the back-end system, which also allows for scalability

Reduced need to deploy new code on the web/mobile application each time you want the screen to look different—especially true with mobile apps, where every code change will need a new version of the app to be uploaded on to the app store

Give clients the power of self-styling their screens

Render widgets according to the OS, browser and screen resolution of the device

That said, there are a few data points to abide by:

Stay away from introducing unnecessary complexity

Try not to integrate unnecessary logic into the screen-building, keeping in mind that since this happens at runtime, you don’t want screens to take ages to load (Take the case of inheritance of widgets: if widget A is present show widget B with X content else if widget A is absent, show widget C with Y content—avoid this kind of logic if not really necessary)

Use intelligent data structuring—building web response templates in a way that the mobile app can easily use means processing time on the mobile device can be kept at a minimum

Use this approach only in cases where it makes sense to do so—there’s no need to follow this approach of building screens dynamically at runtime if: functionality can be easily achieved by controlling it at the front end; functionality can be easily achieved by hard-coding the screen layout; there are not too many varying contexts in the scope of the application

Conclusion

When the goal is an app that delights and engages, user experience is the key—this is a universally acknowledged truth. But, with mobile apps, decoding user scenarios and coding your app accordingly will surely get you on the path to a longer user commitment.

About the Author(s)

Nithin Rao is the President at Boston Technology Corporation, a custom mobile and Web application development firm. The role he truly relishes, however, is that of Chief Experience Officer. With expertise in interaction design and usability, his focus is on getting his team to deliver a winning user experience with every app. Every pixel matters and no detail is too small to him in his quest for creating apps, that users love coming back to.

Comments

Collette Ostler

June 9, 2014

Hi Nithin - this seems to address exactly the issues I have run into in complex enterprise application spaces.

I also see that it moves us further towards user interface design as modular, re-usable elements (which is excellent), but that still need to hang together seamlessly for a user task flow, in a wide variety of permutations (which is cool, but definitely complex - even to document / track all of the ).

I am curious if have been able to 'bake in' analytics in your applications where the UI is so malleable & data-driven. From my experience, that has been very difficult.

You are spot-on. This approach is especially useful in scenarios pertaining to complex enterprise applications. In fact, the complexity can sometimes push you to adopt this approach! The second para in your comment correctly sums up what this approach entails and what we have seen in some of our projects as well. And yes, the large number of permutations can be very difficult to track or document especially if you design a framework that can be re-used/tailored to address a variety of business functions. In such cases, it would make sense to, rather than document all possible permutations, have the design tested on the lines of your user personas and their primary business needs and see if the system will be able to satisfy them. By virtue of framework flexibility, you should also be able to address on an ongoing basis, a good number of new and evolving business needs. Or perhaps apply minimal changes to the framework, to address them. As for analytics, depending on the kind of app it is, you can either present analytics on the mobile app itself or on an associated application such as for example, a website dashboard. Analytics is generally plotting of varying kinds of data in different formats. In the context of data-driven UI, complexity could creep in due to

a) greater number of business scenarios to be catered to – providing analytics for all the n kind of business functions you are trying to achieve with your flexible UI. Not much you can really do about this because your app was anyway built to achieve all those business functions. One thing that you can take care of, though, is designing your analytics interface to accommodate growing data either with a scrollable view or allowing the viewer to choose what they want to see.

b) UI (screen layouts and elements), for analytics changing based on the kind of incoming data. One way to cater to this is to have pre-defined sets of data types (and your flexible UI mechanism would pick up one each time and render the screen accordingly) and corresponding pre-designed analytics interfaces for each of them.

We have encountered scenarios where we need to project analytics of mobile app user actions, on a web-based dashboard application. I would classify that under point ( a ) mentioned above.

Firstly, thanks for your detailed response as this brings up scope for constructive idea-sharing. I think the points the article was trying to present, didn’t get across to you in the intended manner. There are some clarifications needed on what you are thinking and here they are.

Please find my responses to your points below:

1. Quoting you: Removing all the stuff about 'back-end' in the article it can be summarised in my mind as follows "Understanding your users needs and how they differ in your application opens up opportunities to deliver the right information (content or as you call it 'widgets') to them when they need it"

I think this whole article talks about controlling mobile front-end UI using a back-end support system such as a server/CMS/web application. If you are choosing to remove all connection with the back-end here, then the summary you have is of general UX principles and that, I agree, is nothing new. The article was trying to tell you how you can, on an ongoing basis, control what your mobile app is showing to users and not always go to the App Store to deploy a new app for every new field or screen element you introduce to your app. And not deploying a new app for each change is just one of the advantages.

Secondly, by ‘widgets’, we are referring to screen elements such as text fields, picker wheels, dropdowns etc. and not the content they hold. This article speaks about building UI with widgets chosen based on the info received from a back-end server or a supporting CMS or web-app. This info that controls the UI could also be generated by an admin managing the web-app. Please see the patient
registration example given to a reader below.

2. "By simply understand each users needs you will ultimately arrive at different IA priorities and different primary functions they need to perform.
Employee's primary objective: Submit timesheet
Employee's secondary objective: Review my time sheets/nudge for sign off if necessary
Manager primary objective: Review submitted time sheets. Authorise/Decline
Managers secondary objective: Analyse employee's time sheets and KPI data
Clearly we can see just by understanding our users and use cases that the application needs to deliver different UI priorities. And yes this is dependant on who logs in, but it does not require the UI not be on the users device with the app using the right local framework and sending the right API data to the client rather than the entire UI.
Any app mobile or web wanting to be successful today and tomorrow needs to have this distinction baked in from the outset. The concepts are neither new or ground breaking. Software has for along time allowed various user types and responds accordingly. Admin user gets a control panel a normal user gets main app UI for example.
I am just confused at what this article is really saying? "

What you are saying above relates to design practices that are generally followed for any app irrespective of how you implement them. Identify your user personas, list out their primary and secondary functions, decide on what they will see on their screens and so on. Agree. This article is not a lesson on these standard UI/UX design practices targeted at freezing upon a set of screens and how they will look in your final app.

This article is about the next step (and we apologize if that didn’t come across to you clearly in the article) – the best implementation approach – to decide how you bring those screens to life.

Implementation questions could be:
a) Do you just hardcode screen widgets as part of the app’s code and fill in streamed in or static content? Or do you build the screen with widgets based on the info you receive at runtime? What approach will work best for your app?
b) If you have two user personas with two completely different workflows and screens, are you going to launch two apps for them?
c) Or will you build two sets of screens in your code and just show/hide them based on the login?
d) Or, if most elements between the two workflows are the same, would you save coding effort and re-use the same screens for both user groups by enabling/disabling fields based on who is logged in?
e) Would you allow a web-app side admin to respond to changing business needs, and tailor the screens for the user personas by just doing a quick change with some inputs in the web app instead of launching a new app in the App Store to have these code changes get in?

These are the considerations the article is trying to address. And, if you read the article again, you will see that Users is just one context based on which screen elements can change. There are a number of other contexts where regulating or controlling UI from a back-end support system would be applicable.

3. "It's premise in UX leaves out the parts about defining the users, the use cases and how to validate them (like using persona's or user testing) to arrive on the need to cater to different user scenarios.
It's a confused mix of focusing on technologies (specifically ambiguous back-end 'stuff') with no real substance.
Of course it is important to provide context sensitive applications, of course it is important to deliver deep personalisation, of course it is now almost a prerequisite to build task orientated interfaces with clear signposting of usage.
I was just a little disappointed with this article and that is just doesn't seem to achieve close to the value you were intending. It isn't even a good reinforcement of:
Simplify
Understand users needs
Define users and user types
Apply technology to deliver rich user focused experiences"

I agree with all of the good UX principles you have listed above. The article is not in disagreement with them nor is it trying to reinforce already-known UX and design principles to decide what elements to have on your screen. As I mentioned above, this article speaks about the next step – once you know what screen widgets you want each user persona to see and once you know how you want screen content to change based on varying contexts of location or kind of device being used – you could explore the option of back-end regulation to build those screens at runtime instead of hardcoding widgets the way it is usually done.

4. "There is no real reason to rely on the backend the way in which you are advocating, in fact relying on the backend to deliver the wrappers and the content for a mobile app would have serious downsides. Limited connectivity, catering for a wide array of device performance, connection performance (GPRS/2G/3G) are just a few of the things that question this approach for a rich mobile centric experience.
I am just not seeing how any of this apart from contextual UI actually aids the users experience or delight (engagement) with an application."

As with all technology implementations, there will always be downsides to an approach. We need to see what suits our requirement best and then apply any implementation methodology. The article cautions as to where this approach should not be the most preferred. It also states the advantages of using the approach. So it all boils down to going for it if the pros outweigh the cons, keeping your app requirements in mind. Someone did ask about connectivity issues and there was a reply posted for that below. Please see that as well.

I hope the replies above have given you more clarity than before. If there is one thing that can further help you understand this concept, it is more of real-world scenarios and examples. If you need them, please feel free to reach out to me and we can discuss them. We have implemented this concept in some of our enterprise and B2B mobile solutions and it works beautifully.

Clearly we can see just by understanding our users and use cases that the application needs to deliver different UI priorities. And yes this is dependant on who logs in, but it does not require the UI not be on the users device with the app using the right local framework and sending the right API data to the client rather than the entire UI.

Any app mobile or web wanting to be successful today and tomorrow needs to have this distinction baked in from the outset. The concepts are neither new or ground breaking. Software has for along time allowed various user types and responds accordingly. Admin user gets a control panel a normal user gets main app UI for example.

I am just confused at what this article is really saying?

It's premise in UX leaves out the parts about defining the users, the use cases and how to validate them (like using persona's or user testing) to arrive on the need to cater to different user scenarios.

It's a confused mix of focusing on technologies (specifically ambiguous back-end 'stuff') with no real substance.

Of course it is important to provide context sensitive applications, of course it is important to deliver deep personalisation, of course it is now almost a prerequisite to build task orientated interfaces with clear signposting of usage.

I was just a little disappointed with this article and that is just doesn't seem to achieve close to the value you were intending. It isn't even a good reinforcement of:

There is no real reason to rely on the backend the way in which you are advocating, in fact relying on the backend to deliver the wrappers and the content for a mobile app would have serious downsides. Limited connectivity, catering for a wide array of device performance, connection performance (GPRS/2G/3G) are just a few of the things that question this approach for a rich mobile centric experience.

I am just not seeing how any of this apart from contextual UI actually aids the users experience or delight (engagement) with an application.

That’s a very good question. It is important to note that the entire app’s UI will not be back-end driven. A lot of the app’s screen widgets will be hard-coded into the app. It will usually be just a few screens or screen elements in your app whose UI will need to be back-end regulated. So in case of connectivity issues, you must handle these just the way you would handle regular functionality. For example, when the user taps on a button that will take him to the back-end regulated screen, you can show an alert saying something like ‘Please ensure internet connectivity to use this feature.’

A good practice would be to fetch the info needed from the back-end, at strategic points in the app. This would ensure that the user doesn’t see too many loading indicators in the app and screens can render instantaneously based on information already fetched from the back-end at an earlier point in time.

Perhaps I have also missed a point, but @Darrel - yes, this also sounds like webviews to me too.

I would also question the increased complexity this introduces into the experience design phase, as this doesn't sound very Lean to me. Shouldn't planned iteration and including an early stage user testing feedback loop allow for UI elements and patterns to be abstracted enough to cater for these various scenarios upfront anyhow?

About the webview question, please see the reply to Darel below. These are not webviews we are talking about.

The point you brought about complexity is understandable. Which is why the article cautions that you must use this approach only where needed and not for every app. The methods of planned design iterations, early stage user testing etc. are general UI/UX practices that must be applied to the design process of any app. The outcomes of these will guide you as to what is important for each user group and what are the screens your app must have. They will also contribute to help decide whether the kind of requirements you have would make sense for your back-end to control some of the UI on an ongoing basis.

I am also a bit confused by this article – or – is it just some wording? Isn't everything dynamic (data, user, UI, content, location, context, etc.) in a real-time (mobile) web app? Never heard about "back-end design".

A mobile web app renders content dynamically. Agreed. But what we are saying here is not just fetching content from a server and displaying it on screen using the screen widgets you have already built and defined for the app. That is a common thing we see in several apps. What we are saying is you can control the layout, the actual elemental widgets seen on your screen, based on certain information streamed into the app from an external server/website/CMS that it communicates with.

No, this isn’t about using webviews. Webviews are useful when you want to display web pages within your app. So basically, the webview displays content that is hosted online. But that’s not what we are talking about here. This article is about controlling the UI of your native app screen, using a back-end support system such as a web application, CMS etc.

By feeding the native app info about what kind of UI elements you want the user to see, the app would render those widgets/screens accordingly and hide the rest. So as requirements or business scenarios of your app evolve over time, instead of having to deploy a new app to support the new functionality – you could foresee these changes coming and build a supporting back-end for your app that will help you control/change its UI any time you want.

A quick example: You build a patient registration app for your client. The client already has a web-based CMS where they manage patient information. They now need a mobile app to help patients register the mobile way. They know that as of today, they need the user to fill up 6 fields in the form. As time passes, the client may feel the need to take off a field in the form or introduce new ones. Instead of deploying a new app (which some users might not even upgrade to) with all the code changes, the client should be able to just add/edit/delete form fields in their web-based CMS, which will in turn communicate with the app, and update the form the next time the user launches the app.