Introducing the first of a new three-part series by Nick Hampson. Your competition is sexy—stop with the excuses, says Nick. Modernize your apps but avoid these pitfalls.
During the last 15 years, the technology and goals of modernization have changed a great deal but the fundamentals of successful implementations have not. I have seen many issues come up again and again in i-based modernization projects.
Times may change but common pitfalls persist. Over the next three months, I am going to guide you through five fundamental issues so you can avoid making the same kind of unnecessary mistakes that many have made before. This month, I'm going to look at the first two: ocean-boiling and the use of 5250 emulators.
Mistake One: Ocean-Boiling
It is common for people to get excited by a new technology or solution and to then try to deliver everything in one go. This is what I refer to as ocean-boiling: taking on a large-scoped project, not one cup of coffee at a time. The smart solution is to take a well thought-out, phased approach – look at what you need to achieve, prioritize, then segment into manageable phases.
Typically with front-end modernization projects, getting a basic modern interface to the users, with some simple examples of how it can be better, is a great candidate for your first phase. Getting something out there quickly and receiving some feedback is critical to ensure you are on the right track. I recommend adding some simple examples of functionality to show what is possible. This might be anything that you can identify to add value to the application as it stands today. This gets you quick feedback, letting you know if the example is high- or low-value in the real world, and, if it is indeed useful, other places where it can be implemented.
It is difficult for people to describe what is wrong and how to make it better from a blank sheet of paper. It is but much easier for them to see an example and show you where similar items would be more useful to them. Gathering feedback avoids assumption, a very easy trap to fall into.
Seeing how people use technology and how they react to new samples of functionality is far more accurate than assuming or getting too in-depth in research before anything has actually been done. You will move much faster with small steps and the focus on meeting business needs will be better aligned with actual functionality.
Lastly, the phased approach gives quick wins for IT and business. There's no more: "We’ll have something for you in six months and it will be great." It is usually better to get something out in six days, show it and move on.
Mistake Two: 5250 Emulator on the Web
OK, so go look at a calendar. It is 2013 and we can't go back. Emulators still have a few uses in 2013, but, in general, they are not for today’s user-population.
Let’s get one major misconception out of the way: "You can't be as fast as an emulator." Rubbish! Over the last 15 years I have heard this countless times, with arguments of varying quality. A modern UI will be faster to use if it's well-built as you can do many more things than just use the keyboard. You can simplify, shorten, extend, integrate and validate tasks in a way no emulator could.
Modern fonts are easier and faster to read (they are designed that way). Giving users a fixed-pitch emulator font can slow new users down by up to 40 percent.
Once, I had a customer show me the GUI wasn't as quick as the emulator. He then paged-down a subfile 47 times. The emulator was faster. This argument seemed perfectly valid to him and a good reason not to use this new-fangled technology. My response, around using a search function for the subfile so the users didn't have to page down more than once, didn't win me any friends that day.
Today, we would have exactly the same search but without the limitation of page-at-a-time logic. However, just check, based on average searches, how many rows of data to return immediately to balance performance and loading more data.
I have a thousand such little stories, but lets get it over with: GUI has won. Emulators look nasty to most people. There, I said it. If, as a developer, you like the emulator, that’s cool, just don't assume everyone else likes it.
Back to web emulation. Most of the lackluster samples of projects I see have what I call a web emulator. It's not green and black and its running in the browser but it is fundamentally the same thing, just with different colors. Really, other than saving you some supposed deployment hassle, what was the point? You can change the colors in Client Access and save yourself a load of effort and cash. If you’re going to build a new UI, lets make it a modern one.
There is a good reason many people cringe and modernization is often referred to as "lipstick on a pig." That’s because, in many cases, it is. If the colors have changed but the font hasn't and you have limited real GUI controls in your UI, what business issue has this solved? Many people legitimately rush headlong into GUI and don't stop to see how it could add real business value, not just get the CEO/customer off their back about the green screen.
I often get people thinking of me as some type of artist doing UI and UX design. Design is about how it works, and 99 percent of what I do is about making apps work effectively, fit the platform and become more intuitive to the task. It is true that developers are often not blessed with the ability to create an aesthetically-pleasing interface (I’ve learned this the hard way from 15 years of reviewing truly offensive color combinations). But the design of modern UI's is a technical skill following well-defined standards. Developers that have been open to a little reading and effort have proven to be great assets to companies worldwide.
Your competition is sexy—stop with the excuses. Whatever your situation, the app that could replace yours will probably look great. All the other apps people use today on PC's, tablets and phones are also sexy, the bar has been set. Web emulation will just not meet the grade, expectation today is very high. That doesn't mean you should not bother if it’s too hard, just be open to looking at other modern apps and make sure when you compare them side-by-side with yours, you can smile and say "I did that."
If the graphic design part worries you, enlist some help from your website team or bite the bullet and get a designer in to build you a good standard to work from. They don't have to work on every screen but can provide global graphics, fonts, styling and color palette. There’s no shame in admitting that an artist can design a nicer looking interface than you can, and isn’t it more important to get the best possible end-result than to say you did it all yourself?
Lastly, web emulators often lack any business value. By all means get your app a GUI front-end, but if that is all it does you are missing a huge opportunity to make your business more productive with happier, quicker and less error-prone users and richer shareholders. If you are going to build a GUI, let’s ensure you’re adding some real business value that you can hang an ROI argument on. Oh, and if you use an emulator-style fixed-pitch font, I will come and find you!
Nick Hampson has been modernizing IBM i applications for over 15 years, specializing in creating quality users experiences. Designing for desktop, web, tablet and smartphone, Nick works with customers to increase the reach, integration and business value of their existing IBM i applications.
Nick speaks world-wide for looksoftware at a variety of events including COMMON, NiSUG and lookahead. You can read his blog - 'UI, UX, You what?" at http://www.looksoftware.com/blog/nick.aspx#.UaiXOaLVCVU.