Now Featuring...

With the OpenEdge Advanced GUI right around the corner (well, coming soon anyway), I thought that it was appropriate to start a discussion on one of those four application pillars - Features.  As you may recall, I defined features as those characteristics of the software that aid in usability but are not domain specific.  Most features are somehow related to user interfaces - navigation systems, look-up systems, sizing attributes, etc.  But there are others:  Reporting, security and access, personalization and customization methods, etc. For this discussion, I'll concentrate primarily on the user interface features.

There are a number of subjects that we need to cover in here, so I will likely spin these out through multiple blog entries.  And if anyone else has ideas or questions, we can weave them through the process.  Here's the most important place to start:  To be effective, any feature that you put in your software must meet these rules:

1. Any user interface feature that you put in your application should be as intuitive as possible.  If you have to spend time learning it (or re-learning it), then it really isn't much or a feature.  Remember that some percentage of the users of your application are occasional users.  If they can't easily understand or remember how to use a feature, then they won't use it.
2. All features, particularly user interface features, must be consistent.  If navigation works in a particular way in one part of the application, then it should work the same way in other parts of the application.  That doesn't mean that there is only one way of doing something, but it does mean that the methods offered are consistent in every part of the application.
3. As much as possible and applicable, a feature should be implemented everywhere throughout the application.  The excuse of "Oh, that's an older part of the application, so it doesn't work there" is an internal excuse - it makes no sense to the user of the software.
4. An the design and implementation of any user interface feature, be very conscious of the habits of the users of the application.  Some people in some roles are very comfortable in using a mouse and a highly visual environment. In other cases, the interruption caused by having to look at the screen and move the hand from keyboard to mouse back to keyboard can be very irritating.  That's why so many features need a non-visual equivalent.

With those rules firmly in mind, let's look at how to think about and design features for your application.  It's tempting to jump right in to the particulars of a given feature or a given UI, but here's something I learned many years ago:

• The user interface is the prospect's window into your application.  Your competence, currency, and understanding will be judged by what the prospect sees in that window.  Features are emotional, functionality is factual.  If a prospect does not "feel good" about your feature set, that feeling will likely trump great functionality.  If you don't believe that is true, just look at Microsoft's success.

There's an important idea buried in that statement.  For functionality, we tend to look to customers, domain experts, and direct industry competitors.  For features, we should look at prospects and the wider software industry.   The applications that we tend to build  don't directly compete with Outlook, but we will compete with Outlook for the perception of our software in the user's eyes.

This makes it more difficult to design and implement good application-wide features.  We're out of our comfort zone.  So here's a method for prototyping and implementing features that I learned many years ago:

• Mock up two or three screens of an application that are working on.  Make them standalone so that you can run them and work with them without impacting the entire application.
• Using those two or three screens, prototype up every single user interface feature that you intend to support:  Navigation, look-up methods, menu options, linking methods, drill-down methods, message boxes, error systems, access controls, personalization methods, help and learning - everything.  We call this "hanging ornaments on the Christmas tree."  Just load it up with everything you might support some day.
• Use those screens to validate your efforts.  Try them out on current customers.  Show them to salesreps and see if they can be demo'd well.  Compare them to what you see in other places in the software industry and to your competitors.  Bring in analysts and usability experts and have them test-drive the features.  Do everything you can to lock down the feature set using just this small number of screens.
• When you have all the right feedback and have made all the appropriate adjustments, use these same screens to lock down the implementations and the usage rules of these features.  Turn the feature itself into a reusable object that becomes an automatic part of the implementation of any part of the application (templates work great here).  But more important, make it very clear that these implementations are a part of the specifications for the applications.  Developers are not allowed to deviate from these features without express permission of the application owner.  Each feature must be implemented as-is in all appropriate places - no exceptions.
• Finally, set up a small committee (by now you'll know the right people) that controls any changes to this feature set.  Individual designers, developers, and product managers are not allowed to implement new features nor alter existing ones without the express approval of this committee.

Those last points may seem a little harsh, but inconsistency inevitably leads to application degradation.  And none of us want that.

That's enough for this first posting on features.  We'll follow it up by getting in to the various types of features and how to think about each as you use the new Advanced GUI to build a new application or freshen up your current application.