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.
