Thursday, July 17, 2014

The Select Window Component: Addressing the Difference Between Desktop and Mobile Contexts

As is often the case with new technology, we mimic old ways of doing things until we figure out that the new technology is best suited to new ways of working. Case in point, I am writing a blog to communicate with you now when a video would be more effective.

Experienced developers sometimes suffer a disadvantage because these old ways of doing things creep up in new paradigms as old and freshly irrelevant patterns. Such is the case in the numerous differences in best practice between mobile user interfaces and the traditional GUI interaction in desktop software.

With the announcement of Magic xpa Application Platform 2.5, a new Mobile Application Framework was introduced by Magic Software. Let’s take a look at the Select Window Component to see how different mobile GUIs ought to be from traditional applications.
Our example app is a Time Sheet application. In a traditional application where I want to find a particular timesheet, criteria would normally be entered in a multi-field search form, a “Search” button would be pressed and the match or matches would be displayed in a list. In a large screen format this allows me to use human memory to search very specifically. When my memory is faulty, I can search more broadly and then gradually filter the results to get down the actual time sheet I want to see.

A mobile approach will be quite different. My main screen will call out the two categories that I am most likely to use to find a specific project – wither the “Customer” name or the “Project” name. So I might design an interface with just these two menu options. Each will raise an event that gives me more choices.

If I select Customers, I get a list of my Local Customers.

If I select Projects, I get a list of Local Projects.

But if I select customer, and then click on the customer name in the list. I automatically get a list of that Local Customer’s Local projects.

In this example, the projects are simply named by month. Selecting a specific project will then show me the Customer Name, Project Name and my Time Sheets for that project.

To edit a given time sheet, once again I simply select it (by sliding or touching). Setting the time in the report uses features that are “native” or normal for my type of device (Android, Apple, Windows Mobile, etc.) 

The result of setting the new time is a corrected or updated Time Sheet as seen below.

So the flow of the app is something like this:

That is not to say that the old approach wouldn’t work. But good mobile apps strive to leverage the users time and limit typing and button pressing as much as possible. What the user sacrifices in flexibility, they gain ten times in efficiency and overall ease-of-use. 


  1. This comment has been removed by a blog administrator.

  2. This comment has been removed by a blog administrator.