Modernization Beyond the Technical Eye: Prepare for the Culture Change

Posted by Nick Hampson on Jan 6, 2014 11:00:00 AM

   

First of all Happy New Year!

This is a difficult post for me to write. Even though the topic is something I am passionate about and know inside out, it is also the part of my job (and part of modernization) that people ignore and value the least, as per the feedback I get and see (or don't for the most part).

multiple-devices


The classic components of application design, database design and coding are not going to go away, and never will. However in today's technological landscape there are some new skills, ideas, and considerations that need to be taken into account. 
 
First for me is usability, this has been called many different things, but what I am referring to is the efficiency of a user's interaction with the system.

How fast can data be entered, how easy is it to learn, how quickly can users recover from errors and how aligned with the user is the application? 

Many application developers give this little or no consideration... so today, we cover menu design...


Menu Design

More often than not, app menus are laid out in a manner that mirrors the underlying database structure or the logical layout of application areas. For example, an Accounts menu heading may have the following menu items: Accounts Receivable, Accounts Payable, General Ledger, Billing, Stock/Inventory, Purchase Order, Sales Order, Bookkeeping and so on. A structure like this may seem logical, grouping related processes together, however it does not mirror how most people use the application. In this example, a user may only need to access one accounting function in their daily work. A branched structure will force them to navigate up and down a series of menus to access the item they use every day. It's common to see users going up and down 3-5 menu levels to perform their daily tasks.

A while back we did a webinar with Travis Riggins who put this into perspective with a very useful analogy. It's like going to the office and parking your car, walking to the front door, going through reception, up some stairs, along a corridor, through a door to get to your office. So far so good, dull but unavoidable. The analogy gets relevant when we decide to get a coffee from the staff kitchen next door. Do you go all the way back to your car and navigate to the kitchen from that point? Of course not. This kind of navigation is slow and requires far more effort. To navigate an app designed in this way, users need to create a detailed mental model, and often it's complicated to get to even the most frequently visited items.

Another way to look at it, is that the structure is inflexible and without any care for the people actually using it. Surely no one would want users to think of their apps in this way.

Compare the above example to a modern system, one that provides access to frequently used functions via a single click and allows you to quickly find items you access infrequently (once a month, year end, holiday/sick cover etc.). This kind of structure not only saves time and effort (in both navigation and the initial learning curve) but it feels like an app that supports the user rather than the other way around. 
Hopefully this simple example shows just how different an app can feel to a user with a little fore-thought.

I don't think you need to stop coding and go hug trees, but I do believe that, when it comes to laying out the interface, you need to actually look at what users do and examine the work-flow from their perspective. One thing that was drilled into me years ago was the importance of getting the 'context right'. A practical demo of this idea is asking someone to give directions from a map. Most people will give directions to the final destination without ever asking where the starting point is.... they assume it is where they are located.

The similarities in application design are apparent. Unless you started as a user of an app and moved into development, your view of the "map" is likely to be different. It's important for those views to be aligned. It doesn't constrain you in any way, in fact, it aligns the application with its needs more closely and is likely to minimize the need for change down the track.

Seems so obvious doesn't it?
Then you would have to wonder why, after 13 years of doing this, I still harp on about it so much? Evidence shows that, while it may seem obvious, it's not the way many apps are being built or modernized today.

It's pretty easy to give users access to their "top 10" items, based on their role or by using simple routines to monitor which options they select (and I know its simple as I've witnessed RPG devs add these features to big ERP systems overnight).

The sample below was prepared with a partner in Canada back in 2007. They still have the traditional menu structure in place but navigation has been improved through the addition of search options and custom tools. It's worth noting that this example was pre-Open Access so the underlying screen that is driving this is standard 5250. I've not even hooked up the custom icons in this screenshot, they are generated from the 5250 to allow for easier future maintenance.

Untitled-2

Menus are also a great place to display KPI/Dashboard or Message info to users. Gone are the days of portals, with navigation requiring great slabs of screen real estate. Navigation should only be there when required and, if its complex enough to need to be displayed permanently, perhaps its time to revisit the drawing board.

One part of this disconnect is due to the fact that IT and users often don't get on. This has always seemed weird to me, but I wish I had a penny (I'd have my Aston Martin by now) every time someone dealt with an end user in the same way they wipe crap off their shoes. While I understand people don't always share the same views and priorities, if developers acknowledged that users are the subject matter experts (without expecting them to be IT experts) and users understood the complexities IT is faced with, the world might be a better place.

 

Nick Hampson
Author
Nick Hampson
UI/UX Expert, looksoftware

 

 

 

Topics: IBM i, Application Modernization