Web forms: The good, the bad and the ugly

By Monika Pletschke on Jan 15, 2015

We all have experience interacting with forms on the web. On-line purchases, web registrations and subscriptions and travel bookings are among the many ways we daily interact with companies in our connected lives.  The experience can be a pleasant one – quick and efficient, or it can be frustrating experience. Much of this depends on the design of the form presented to us.

This article intends to shed some light on what constitutes good vs bad design.

Here are some of my personal likes and dislikes from experiences with web-based applications:

	The form is responsive:  Reaction to invalid input should be as close as possible to the time of input.  Meaningful feedback for invalid input which allows you to identify and correct the error quickly.
	Wait until all the fields are filled before issuing an error message. Do not reveal where the error actually is. Clear the form when an error occurs requiring everything to be filled in again.
	Validation is intelligent. It recognizes context and relationships to other inputs and makes relevant suggestions.
	Input screens are compact and preferable fit on one screen.  The form only renders the fields which I actually have to fill in.
	Forms where you have to use left/right and up/down scroll bars.
	The application considers the rendering device: On a laptop it is easier to type a 4 digit year, whereas on a smartphone it may be easier to turn a scroll wheel.
	Scroll wheel  gadgets:  I was born in the last millennium and don’t appreciate having to turn the wheel from 2014 backwards!  Or how about selecting the country from a drop if you are a Zambian?
	Predictive text completion when it works and is language sensitive.
	Spell checkers which do not recognize the language and make random corrections. (E.g. Why does Windows always correct “for the” to “fort he”?)
	A calendar gadget for input of dates.
	Long periods of wheel  turning  or a blank screen with no feedback whatsoever.
	Unclear date input instructions. Does the form require DD.MM.YYYY or MM/DD/YYYY  or one of the many other combinations used around the world?
	Automatic conversion of time zones. Location sensitive units of measure (metric vs imperial for different countries)

Winshuttle Designer and its successor, Winshuttle Composer, are tools to create enhanced or extended solutions for your business. With a user-friendly front-end, easy no-programming integration to SAP and a custom designed workflow, many Winshuttle customers have managed to increase the value of their ERP investment.

While the tools offer absolute flexibility in design, here are some design considerations for getting the best out of your Winshuttle solution.

1. Do not start with the most complex process as a pilot. As with any development environment, the authors have an initial learning curve to overcome.
2. For maximum adoption pick the processes according to the Zorro principle: Choose initiatives first where low effort will yield high value (“quick wins”) before moving on to high-effort/high value, etc.;
3. Avoid complexity: “Cater- for- all-events” processes may just replicate the complexity of your ERP system. Rather create multiple fit-to-purpose solutions targeted specifically at a specialised set of functionality or a specific set of end-users.
4. Pick the most appropriate source for validating and looking up data: An F4 Lookup directly from SAP is relevant for dynamic data (e.g. customer number). A drop-down in provides fast response time and is appropriate for limited sets of values (e.g . “debit” or “credit”); a SharePoint list may be appropriate when the user does not have access to SAP (e.g. list of currency codes).

Have fun creating your Winshuttle solution and do share some of your own design tips…