Composer Tip: Greying Out a Checkbox When It’s Unselected

Background

A customer recently asked us whether we could create a checkbox whose text would be black if it were selected, but grey out if it were unselected. Something like this:

The unselected Checkbox with grey text

The unselected Checkbox with grey text

The selected checkbox with black text

The selected Checkbox with black text

Implementation

Composer doesn’t have a built-in way to do this. However, we were able to achieve it quite easily using a simple technique. This technique also illustrates some of the more advanced features of Avoka Transact Composer, so we thought we would share it. In order to implement this, we simply set up an Editability rule and changed the Editability policy on the checkbox. This is shown below:

Editability Rule and Policy

Editability Rule and Policy

The script itself is trivial – we simply make the Checkbox depend on itself, so that if its value changed, so would its Editability. To do this, click on the “Edit…” button, and then double click on the checkbox itself. This will inject a field reference as: {MyCheckbox} (or whatever your Checkbox is named). The tricky part is the Editability Policy. This is only visible if Advanced mode is selected. We’ve set this to “Grey out Text”, which makes the text grey WITHOUT actually disabling the field. This simple change implements exactly the effect that was intended. This can be used as a one-off, or could be easily created as a re-usable widget.

Form Design Tip: Caption Top

One of the first tasks that a new customer goes through when starting to use Avoka Transact Composer is the design of a custom 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 Avoka Transact 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.

Addendum

As the world move solidly into the world of tablets and SmartPhones, we have an even stronger imperative to use caption top. The full list of reasons is:

  • Wrapping captions. If you use caption left and a fairly narrow caption width, then long captions will wrap – this makes your form look ugly and difficult to read.
  • Stranded captions. If you use caption left with a wider caption width (to solve the above problem), then shorter captions will be physically far away from the fields they refer to, and users will struggle to “line up” the caption with the field. Keeping things that are related in high proximity to each other is a well established best practise in usability analysis.
  • Screen magnifiers. For people who have visual impairments and use a screen magnifier, a big gap between a caption and the field it refers to may mean that the caption and the field don’t both appear in the magnification area at the same time, making it very hard to line up the caption with the field.
  • SmartPhone screens. And importantly, if you use caption left on a narrow SmartPhone, it can push the field off the right of the screen. Caption top works much better on narrower screens.

 

Radio Button Groups, Cross Field Validation, and More

Avoka Transact 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.