[Article] Part 2: Upsizing Your Existing Solution—User Interface & Functionality

Bob Cusick
ClickWare, Inc.

The first part of this series dealt with the decision process of whether to migrate your solution or fix what's broken. In this installment - we'll have a look at the user interface and functionality aspects of migrating your existing solution to a Servoy solution.

If It Ain't Broken, Don't Fix It - Redux

I'll state again my personal number one rule: if it's not broken, don't fix it! Not only does this apply to the database engine and the overall solution, but it also applies to the user interface and the way an application functions as well.

Aside from "performance" (or lack thereof) issues, most users still have a memorized way of doing things. In general, they use only part of the solution that is applicable to their areas of responsibility. And they're used to the way it works (flaws and all). They also usually have a memorized (or sometimes Post-It padded) way of interacting with the application to get out the data they need to get their work done and go home.

The goal of migrating your solution out of one technology and into another should increase

the productivity and speed at which people can access, use and re-purpose the data they need to interact with. The goal should not be because "...the technology is cool."

Step 1 - Analyze What You Have - Redux

Assuming you've already examined your existing solution to determine what you like and don't like in terms of performance/scalability/maintainability; and in terms of what you can and cannot "fix" - now would be a really good time to examine your solution to determine what you like and don't like in terms of the user interface/functionality.

Take a look at all of your forms, layouts, and reports. Do you still really NEED all of them - or are some of them "leftovers" from a bygone era? Do you have forms or reports or layouts called "Jim's Letter", "Evette's Mailing Labels", etc - all for people who have left the company?

How about data entry screens that are no longer used - or fields on data entry layouts that no longer have a meaning? Check the data or better yet - talk to the data entry operator(s) and see what they have to say. What you find might surprise you.

On a recent quest to do exactly what I'm preaching here - I asked the data entry operator what a series of 5 fields were that they manually typed "N/A" in for each and every record. She said "...that data used to be on a 504 report that we had to use for corporate. It's been replaced by the 504a, 504b and 504c that don't require that data anymore - but if we leave the data blank - it shows up on the printed report the wrong way." So, they would manually type in "N/A" (never mind that they could have the program do it for them automatically) on every record. By modifying the report and by changing a single "find" request - we saved them (literally) 21 man-days per year by not having to enter "N/A" where it wasn't needed.

The point is this: go through EVERY screen and EVERY report to determine the stuff you MUST have and the stuff that is no longer used or no one can remember why it's in there. You'll probably find that anywhere between 5% and 50% of the "stuff" in the current solution can be ignored in the new solution.

Step 2 - Talk to the "Owners"

Schedule about an hour or so with the data entry operators to evaluate the current solution in the "real" world. You should do the same thing for the people (or person) that uses the printed reports. See if there is any additional data that would be helpful and verify that the reason they created the report in the first place still exists.

Arm yourself with hard copy printouts of each data entry screen and printed report - and markup the actual paper with notes, redundant or unnecessary fields, additional requested fields and functions. Be on the lookout for responses like "I don't know why that's there - that's just the way we've done it since I've been here." Ask them about features or fields or automation of tasks that would help them to be more productive. You may not be able to give them everything they ask in the first release, but being aware that the need exists will help you as you plan the rest of the interface design.

Once you have this blueprint from the end users' perspective, you're ready to move on to the next step.

Step 3 - Eliminate Workarounds

Once you've talked to the "owners" of the information - and you've mapped out the screens and reports that are needed - it's time to take a look at the actual screens and the way they function.

Take a good look at the navigational elements, printing buttons, search screens, etc. and look for simple ways you can improve them. Remember, most existing solutions have been a "group development" effort over many years - usually with many different developers all with their own particular style and level of skill. Invariably, there will have been some "good" developers and some "crappy" developers at some point in the current solution's lifetime. The individual programmer's skill level will usually determine whether a particular feature was implemented with minimal automation (i.e. the user has to do loads of manual steps); or whether they were implemented with "brute force" (i.e. a single button that searches, prints, exports, updates the website, then proceeds to wash the user's car).

Here's a partial list of things to look out for in the current solution:

Are there individual little buttons all over the place to print specific reports?

Is the user forced to go to a specific "search" screen to enter valid criteria?

Does the user perform 5 steps manually that you could easily automate into a single click?

Can you offer in one report, information that was on 5 separate reports?

Does Servoy allow you to add additional value with a minimum of work (i.e. tabbing out of a field to take an action rather than the user having to click a button - or automatically hide non-searchable fields when the user goes into find mode, etc)?

Also, you'll probably run across buttons, scripts, forms or reports that no one can remember the purpose of; or you'll find a whole bunch of interface elements that were put on in a "rush" as a "temporary fix" - and have remained there for years. There's no reason you should waste your time in re-creating all of these inconsistent, unused interface elements, forms and reports. Find out what's needed and build that.

Step 4 - Build a "Lite" Version

Start simple: build a two or three screen prototype of the most-used data entry screens and one or two reports. This will allow you to validate your new design & consolidation ideas - before you get too far down the track.

There are several features in the Servoy environment that will allow you to present two or three different design approaches in your prototype, with a minimum of effort:

1) Custom controllers. You can make one or two (or more) controller forms with different looks and features - and easily substitute them (in design mode only - not at runtime) on your forms;

2) Repository-based solutions. Once you have your prototype solution, you can export it from the repository - then re-import it with a different name (i.e. "Prototype2") and change the controller on your forms so you can quickly give end-users more than one choice (or look-and-feel);

3) Form "Command" Properties. These properties like onFindCmd, onNewRecordCmd, etc. allows you, as the solution designer, to take control of the keyboard commands used for all commands (ctrl-F for Find, ctrl-N for New Record, etc) by running your own method when the keyboard command is chosen. This feature allows you to do things like disable (or even hide!) fields when the user is in Find mode, perform validations when creating a new record, etc.

4) Field Event Properties. Fields in Servoy support onFocusGained (Enter), onFocusLost (Leave) and onAction. (Return or Enter is pressed and the displayType of the field is set to textField events.) You can do simple validations or even show a single field, and then based on the onFocusLost (Leave) or onChange event - show individual field(s) only when data is valid, etc.

5) Tabpanels & Portals. You can use portals that have built-in functionality like the ability to click-sort (ascending and descending), resize columns, and even re-order columns - all without programming. Even better - you can use the native tabpanel objects to display other forms in list view or record view - even forms that contain other tabpanels (so you can display and edit data an UNLIMITED number of files away). Tabpanels can even be "hidden" with tabOrientation (along with right, left, top and bottom) - so you can programmatically control which "tab" shows when - effectively creating a "dynamic" user interface.

The key when you build your prototype - is to make the solution better: more user-friendly, more intelligent, less cumbersome, less "manual"... you get the idea.

Step 5 - Evaluate The Results

Put your prototype into action. Schedule about an hour or so with the data entry operators to test out your prototype in the "real" world. Check your printed reports (with representative or sample data) with the people that need the reports.

To keep your sanity - you should also have a method to prioritize the new feature requests and enhancements. Otherwise, not only will you never get the project finished - by the time you do, the requirements will have changed again.

After you have "fleshed out" a couple versions of your prototype based on the people who actually use the application (and the printed data) - and you have actually (gasp!) asked them what would help or make their jobs easier, and what they like and don't like - and THEN you actually deliver it in your prototype - you'll not only find that they are more receptive (even eager!) when it comes to the deployment - but you will have accomplished what you set out to do: create true value in the redesigned application.

Step 6 - Prioritize and Build

If you've done steps 3-5 to the best of your abilities - then it will be fairly easy to design the "guts" of the new solution. Simply take out your screen captures of the reports and input forms and begin to design your new data model.

Remember to refer to your notes often. Keep in mind the entire reason you're taking the time and effort to re-develop your user interface - you want to create a solution that is easy to use and is tailored to the people who actually have to deal with it every day. When you have a question (and you're not doing it right if you don't have any questions) - go back to the end users (or the person who is using the report) and get their input.

Step 7 - Evaluate and Correct

When you get to the point that you feel your solution is nearly there - don't hesitate to go back to the end users for one final validation check before you clean up or finish up the final functionality. This is the perfect time to get - you guessed it - more input from the end users.

However, beware of "feature creep." It's a very common occurrence for users that have "put up with" a solution for a long time - once they see that they were actually listened to in the redesign of the application - to start getting over-zealous with additional feature requests that are outside the scope of the original application. You need to evaluate these requests. If they are fairly easy to implement (i.e. "It would be great if this were a pop-up menu...", "Can we also show the breakdown by region as well as salesperson...", etc.) - you have to decide whether it's better to implement them or defer them to the next revision.

One thing I can tell you - once you've built an application that people actually "connect" with - one in which they feel they've made a real contribution to - you will be deluged with feature requests and enhancement requests. This is the TRUE test of how successful you are as an application designer. This means that you've captured the essence of the application and you've listened to the people who have to use it every day. In otherwords, you've been extremely successful.

Putting It All Together

As you can see - migrating a solution can take a lot of time and effort on the designer's part (both data designer as well as interface designer). The good news is this: if you take the time to get the end user's input, and you actually re-design your solution - rather than just make an exact copy of what's there - you and your users will reap the benefits in terms of usability, maintainability and productivity.

I know what you're saying to yourself - "But Bob, I have dozens of applications and if I do this process for each one of them - I'll be re-designing for the next 4 years." Ah. Good point. If you're considering migrating out of FileMaker Pro - then I have a possible "quick and dirty" straight conversion suggestion. Use the recently announced FMP to SQL converter from PDM http://www.fmp2sql.com.

Now, I've seen a demo of this tool in action - and it's amazing. It will convert your existing FileMaker solution (fields, layouts, scripts, and even data) into a Servoy-based solution. The good news: it converts almost everything. The bad news: it converts almost everything. For example, I have this workaround I use in FileMaker solutions to sort or filter the contents of a portal containing multi-key concatenated fields, globals, relationships, etc. The PDM Converter converts the solution and the FileMaker workaround just fine - but if I were doing this solution "from scratch" in Servoy, I could simply enable sorting on the portal (by checking a single checkbox in design mode); or I could also sort the portal directly through the relation using a text string (in a single line of code). In either case - the Servoy method of doing things is much more efficient.

The bottom line in the convert vs. re-develop question is: do what you need to do. Some people will want to re-design their most critical applications and simply convert the rest (promising to "clean it up as we go") - and others will just convert, deploy, then start the re-design process.

No matter which way you choose to go - the end result will be a standards-based, scalable, sql-based application that will enable you (or your company or your client's company) to save money by being more productive.

Stay tuned in next month's issue for Part 3 of "Upsizing (Migrating) Your Solution" where we will take a look at the aspect of deployment and maintenance of your new solution.