Guest blog post, content by Nick Hampson UI/UX Expert, looksoftware
Originally published: January 13, 2014 Link to original blog: 1000 Screens to reface: Where to start?
Learn more about how to Modernize & mobilize using Open Standards while leveraging your enterprise systems and existing skill sets at our upcoming Able-One webinar!
By Nick Hampson, UI/UX Expert:
Over the years many of the projects we have worked on with customers have been in the thousands of screens, some upwards of 8000, one around 10,000, often with sections being written by different people to different standards (for instance different F-keys for the same action app to app)
The first thing to do at the start of any project is take a breath. Never just dive in and 'start fixing stuff' without a plan.
I always like to spend a couple of hours going through the app with a few people, preferably with it on a projector, with a whiteboard at the side for notes and lots of coffee and donuts somewhere near. I don't work for peanuts but I will work for coffee and donuts :-)
As you go through the app, navigating around, note any screen where you find an issue and what that issue is (do not try to fix it). After a couple of hours you will have a list that can be divided into two: items that came up once and items that came up multiple times.
The first task is to fix the items that came up multiple times using a generic tool if possible (Settings, Rules, Generic Overrides, Generic Macro/Script - in that order).
The key point here is that it's very tempting to jump in at the lowest level (i.e fixing issues on individual screens) but this approach does not make use of the newlook paradigm, it hinders the product from doing its job.
Two stories here:
1 - My own journey
Back in 1998, while working for DCS in the UK, I had to implement newlook over the core logistics app CIEL (man I loved that app). At this point looksoftware was 5 guys in a garage in Australia so I had to make a start without any training. I put in a week's work, sorting out the app and got through 423 of the 1500 screens. These 423 screens all related to core functions but I had missed much of the lesser used stuff. I remember it was 423 as it gave me RSI using the trackpad on my IBM thinkpad. In October I attended a newlook training course (which was to change both my job and life later) in London. I came back to the office and deleted everything I had done, leaving only 7 specific overrides, but adding some generic rules and overrides which dealt with the app just as well as the earlier work I had done. It also dealt with all the screens I had not had chance to work on and left the application much less vulnerable to double maintenance (to the point that, even with 90 RPG developers, the core file was not significantly altered for 5 years). The approach I took eventually gained a name in 2000, the 'thin sid' (thanks Trevor). It is still the basis of how we approach projects today although the finished product has changed somewhat.
2 - Someone else's journey
In August 2001 I was sent out to a customer in Europe who had been 'developing' for 3 months and was struggling with their 1000 screen application. All I knew before my arrival was that they had taken a short training course given by a partner and felt there were 'some issues'. On arrival they showed me the app (with its 500 overrides) and some genuine performance issues they were experiencing with its menus. The main problem they had though was that they were working screen by screen and were struggling to keep up with ongoing changes to the developed application. In 2013 the 'menu issue' they were experiencing is laughable but they were getting a 3-5 second response out of their newlook menus which was very slow, even in the days of 1Ghz PIII desktops. After looking at their menu override I found it contained 4 images 'to spice it up', one in each corner, nothing of great concern. I then looked at the images in more detail and noted that they were 1Mb each and fairly high resolution files. Today that sounds small but back in 2001 the average PC had a 2.5Mb Gfx card. I played with the images in Photoshop on my laptop and created a single background that did not need to be scaled by the PC. This took the file size down to 45Kb and the response back to sub second, I am a newlook God!
Next I looked at their 500 overrides and realized they had not quite understood the newlook paradigm. Apart from the sign on and generic menu the other 498 overrides were not required. So I deleted them and created a few rules that fixed all 1000 screens, as they required. I am a newlook Idiot!
Why am i an idiot? Because I didn't consider how stupid this made their team look to their boss (I had done twice as much as they had done in 3 months, in 12 minutes). Exit stage left and, even though I left them with a 100% working solution, they canned the project and the use of newlook. (How often politics get in the way of the right choice.)
Moral of the story - start off right, understand the product, ask for advice, make a plan and then begin.
Once you have the generic stuff sorted and are starting to work on the specifics, always keep an eye out for things that you may be able to do globally, it's more likely to be less effort in the long term and probably just as quick to do.
For me, a successful modernization project has two general goals:
1) It should provide usability and graphical styling consistent with a modern app (i.e. it should feel like a PC / web or mobile app - it shouldn't feel like an emulator app)
2) It should add value. I hate webulators! I don't believe that altering colors and making an app run in the browser is any real step forward. If you want your modernization project to be compelling to users, it needs to add some value that the 5250 version either could not or did not. Without this I don't see the point. You can alter colors in client access for free without losing the keyboard buffer/type ahead, response time, print support and PCO.exe. (webulators loose this, we don't).
I've always preferred a phased approach with my projects (I'm not a project pro like my friend Kimmy so I try to learn from his projects whenever I get the chance). What I like about this approach is you get deliverables, and the related feedback, quickly. In the end this delivers a better solution and you don't suffer from ocean boiling, scope creep and all those other project nightmares nearly as much.
I usually shoot for a simple 2 phase approach:
Phase 1: Get the app or module working 100%. Add a few new features in key places you have identified in your research with users. This might include improved workflow via the use of tabs, web and desktop integration or the like. Don't do too many, just 1 or two, in places where they will be seen and used. Don't invest emotion in these features, consider them a proof of concept. What you want is for people to see them, try them and provide you withuseful feedback. Something along the lines of;
"I loved that feature, we really need this here also"
"I liked the idea but its not really any good where it is - but could you do it here?"
"This functionality doesn't help me at all, what I really want is….."
You will notice I left out "that was great" in the list of useful feedback, as "great" doesn't take your company stock up or put dollars in your bank account. Even negative feedback is far more valuable if it helps you refine your solution and improve the productivity of users in the long term.
Phase 2: Either additional modules or value-added items based on phase 1 feedback. As with Phase 1, make sure it's a short deliverable project with SMART targets. You can add as many extra phases as you wish - I really like phases that are 1-2 weeks long at most, similar to Agile sprints, so you can get something of value out to the users, obtain feedback and continue.
Project length: Well 'not long' is what I would expect. Once you know how to use the tools and have some solid training under your belt, no project phase should be more than a month in duration. Some of the biggest projects we have done have taken 3 months for 8000-screen apps. The project needs to be short to eliminate scope creep and to get the app in front of users ASAP.
Thought Process: It is helpful to visualize the application as a new app. Where possible, name, badge and present it as a new app to users. Resist the urge to show them the 5250 under the covers. If you, and the users, think of it as a new app you will find that you are not constrained by the way it used to work. It may sound silly but, after a decade of seeing this every day, I've learnt that it is very important. Your app will always have some familiarity to your users in certain places (which is a bonus when it comes to training) but it must be treated as a new entity.
Learn more about how to Modernize & mobilize using Open Standards while leveraging your enterprise systems and existing skill sets at our upcoming Able-One webinar!
