Form Design Tip: Caption Top

One of the first tasks that a new customer goes through when starting to use SmartForm Composer is the design of a cust0m template and stylesheet. And one of the first decisions that most customers grapple with is: “Should the captions  go above or to the left of the fields?”

At Avoka, our form designers have a very strong opinion on this – captions should always go above the field. There are a whole lot of really good reasons for this, including factors such as optimum layout, readability and accessibility, and form refactoring. In fact, we believe this so strongly, that all of the “off-the-shelf” stylesheets available in Composer use caption-top placement.

However, it’s not just our opinion. Or in fact, anyone’s opinion. There is a significant body of empirical research that supports this position. I’m not going to repeat all this information in this blog, but rather point you at an excellent blog from a colleague and independent expert in form design, Jessica Enders.

http://formulate.com.au/articles/alignment/

We strongly encourage anyone embarking on a form standardization project to take notice of this research, and use caption-top alignment.

 

Radio button groups, cross-field validations, and more…

Composer is a continuous work in progress, and sometimes new features may slip in without you noticing.

Some of our most recent improvements include:

  • Improved Radio Button Groups. These are similar to Radio Button Lists in Designer, but allow the buttons to be physically separated from each other, which gives you improved layout capabilities. For example, you can use Radio Button Groups to lay out Radio Buttons using a grid layout, which is THE best way to lay out your radio buttons well. An entire blog about Radio Button Groups is coming soon.
  • Made several improvements and bug fixes in data binding.
  • Fixed some issues with clearing hidden data on submit.
  • Added support for cross-field validations, at both the global level and within repeats. A cross-field validation is a validation that involves multiple fields, any of which can change. For example, four fields that must add up to 100.
  • Added support for warnings. (These are similar to errors, but don’t prevent you from submitting the form.) To use warnings you must use the new and improved Errors and Warnings block.
  • A number of bug fixes and minor improvements.

 

Speed Blitz

In the last few weeks, we’ve been putting some real effort into improving Composer’s performance, particularly with larger forms. The improvements are both in the speed of Composer itself, as well as the speed of the forms that Composer produces. Improvements include:
  • Reduced time to save a form in Composer (on a large form) by a factor of 10 (from 50s to around 4s).
  • Reduced startup times in Reader of large forms by about 70%. (From about 20s to about 7s.) Most of this was achieved by optimizing the processing of initialization events.
  • Made improvements in speed of clicking Submit button. (most of the delay was due to firing validations, and clearing hidden field data.)
  • Similar improvements in speed of clicking Save Draft button (most of delay was due to making mandatory fields non-mandatory, and then back again.)
  • Made Composer itself much snappier with forms that have large numbers of business rules by allowing users to turn off automated dependency and problem checking (you can now click the refresh button manually if it’s turned off.
  • Improved performance of the Data Binding tab, especially in forms bound to large Data Dictionaries.

We’re also working on an AIR-based version of Composer. This will make use of access to the local file system to do much more caching on the client, resulting in improved speeds for many operations, especially loading an Organization.

We hope that these improvements will make both developers and users happy.