Welcome!

@CloudExpo Authors: Yeshim Deniz, Zakia Bouachraoui, Liz McMillan, Elizabeth White, Pat Romanski

Related Topics: @CloudExpo, Artificial Intelligence

@CloudExpo: 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

CloudEXPO Stories
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a multi-faceted approach of strategy and enterprise business development. Andrew graduated from Loyola University in Maryland and University of Auckland with degrees in economics and international finance.
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a member of the Society of Information Management (SIM) Atlanta Chapter. She received a Business and Economics degree with a minor in Computer Science from St. Andrews Presbyterian University (Laurinburg, North Carolina). She resides in metro-Atlanta (Georgia).
We are in a digital age however when one looks for their dream home, the mortgage process can take as long as 60 days to complete. Not what we expect in a time where processes are known to take place swiftly and seamlessly. Mortgages businesses are facing the heat and are in immediate need of upgrading their operating model to reduce costs, decrease the processing time and enhance the customer experience. Therefore, providers are exploring multiple ways of tapping emerging technologies to solve this industry problem. During this session, Chander Damodaran, Chief Blockchain Architect at Brillio Technologies, will discuss how blockchain could transform the mortgage business and its value chain. Blockchain can bridge the gap and provide a seamless digital channel to enable quicker and transparent mortgage processing thereby elevating the overall experience and helping drive costs down.
This session describes how Professional Services organisations can deliver within Technology-as-a-Service (IaaS) constructs, in private and public enterprise cloud scenarios. See how professional services can be packaged and funded by IaaS cash flows, based upon consumption of technology services. Learn how significant, IT infrastructure transformations can be funded through OPEX spending models with multi-year As-a-Services based contracts. Understand how the automation of repeatable services can positively impact the commercial viability of Professional Services within As-a-Service constructs. Hear how innovative IT infrastructure service offerings can elevate the impact of professional services engagements, and accelerate positive business outcomes.