Welcome!

Gartner Names Winshuttle a "Cool Vendor" in the SAP Ecosystem

Clinton Jones

Subscribe to Clinton Jones: eMailAlertsEmail Alerts
Get Clinton Jones via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, SAP Business One

Article

Three Steps to Awesome Form Design

Technologists will conjure up an infinite number of ways for you to achieve your business objectives

Two articles that I read recently, by Jakob Nielsen and by John Brinkman, got me thinking that it was probably time to revisit the very topical subject of form design. In the world of SAP, it comes as no surprise that people want to retain the rich functionality of the ERP system but get away with doing less in terms of data entry or at the very least spend less time entering data.

Technologists will conjure up an infinite number of ways for you to achieve your business objectives and the web, mobile or form enablement of some of the entry and extract methods people want to use to get to their SAP data seems to be a very obvious choice. I'd assert that this isn't a true situation. Web enabling a process is not necessarily a way to save time or effort in the entry of data in particular. In fact, sometimes web enabling something actually hinders the process.

As Nielsen says: "Forms are rarely the best metaphor for complex interactions with computers." In addition he goes on to say that any online form that goes beyond two screens is often a sign that the underlying functionality is better supported by an application offering more interactivity. If you look at the suite of products offered by Winshuttle, that means going back to a Runner for Transaction or Query.

Brinkman describes how Adobe forms technology has facilitated the creation of behemoth applications in forms that have become uncontrollable monsters with tens of thousands of lines of JavaScript; they are large, open slowly, perform poorly and have a big memory footprint with high maintenance costs and they break regularly.

Admittedly, the creation of the monster forms is not something anyone sets out to deliberately do; however, there is a degree of inevitability about why these monster forms become the end result and a lot of it has to do with understanding what the form's objectives are.

Failure to think carefully about your candidates for forms and how they are designed can lead to a number of negative business outcomes including maintenance, efficiency, version control, quality assurance and the general integrity of the business process automation. Because Adobe forms support the creation of full-blown applications in a form, creating monsters is relatively easy; maintaining them though can be an ongoing headache. Brinkman is not against the use of Java code in Adobe forms, in fact I would say he rather promotes it but I wonder whether this is really what you should be doing if you want to simply automate your SAP transaction screens.

With any form, you want to do the following things:

  • Distribution: Make sure as many relevant people as possible can use your form
  • Rules: Be able to do some basic checking and validation of your data before you try to send it to SAP
  • Usability : Provide the user with a great experience

A form works well when its objective is clearly defined and understood and the expectations for data entry are clear and unambiguous – essentially, it will work well as a solution when there is not much more to it than plain data entry. Always check that your form creation is meeting those basic requirements of usability, being distributable and adhering to business rules.

A selection of entry fields, a handful of drop down lists, perhaps some checkboxes and perhaps a table of data fields. You could build some basic logic into the form such as matching data or dependent choices but you really don’t want this thing to get too complicated. As Nielsen says, “Interactions that are more complicated suffer when you present them as straight forms.

“Most of us would have filled out a federal or state or governmental form at some time and many of us might have been amused by the suggested times it would take to complete the form. You often see this on forms in the US, perhaps less so in other parts of the world. People generally hate filling out any kind of form but then they mostly hate SAP screens too, so we essentially start from a negative position.

From a design perspective, Richard Wootton and Chris Coyier provide some interesting ideas on form design artifacts in their articles on DNNCreative and CSS-Tricks.combut I want to continue exploring some of the criteria you need to consider before you set your heart on turning that SAP transaction recording into a web service and building a form on top of it.

The following criteria can help you decide whether a form is a good choice:

Variability in responses/entries & Linearity
If most of the entries are always the same, then a form is a great choice. Variability is an example of non-linearity, but there are more examples. If users usually enter data in a linear sequence and never need to revisit or revise previous steps then use of a form again, is a great choice. The same is true if the steps don't depend on one another.

Number of steps
If the steps are less than say four or five using a form may be a great choice. Too many list boxes with too many data choices and too many dependencies can be very tedious. For examples, on a web shopping cart, presenting me with a exploded bill of materials that I can then pick and choose from may be very nice if I am building something but it isn’t very useful if I want to simply order a standard package.  The more selections I need to make, the more likely my end-to-end process is likely to fail. (this is often what happens on the SAP screen – do you really want to replicate that?) Another tip I always give folks is, we support the entry of repeating table data, it’s great for things like FB50 journal entry lines or VA01 sales order entry lines but be respectful of the data entry person, once they go beyond about ten lines of repeating table entry maybe it is time to go back to Excel data…

Data Entry Complexity
If the data required is straightforward information that can be easily supplied then a form is a good choice. If users need to be careful about their choices or refer to additional supporting materials then a form may not be a good choice, you may want to rethink this as you will need to provide a lot of lookups, a lot of supplementary logic and reference materials. Consider linguistics here also. If you have to create twenty versions of this form in twenty different languages, can that be easily done with the same form or do you have to create complex derivations of the original.

Great follow-up reading:

Jakob Nielsen: Forms vs. Applications

John Brinkman: FormFeed: Table's with Variable Numbers of Columns

John Brinkman: Forms vs Applications . . . and how to make them behave

More Stories By Clinton Jones

Clinton Jones is a Product Manager at Winshuttle. He is experienced in international technology and business process with a focus on integrated business technologies. Clinton also services a technical consultant on technology and quality management as it relates to data and process management and governance. Before coming to Winshuttle, Clinton served as a Technical Quality Manager at SAP. Twitter @winshuttle