[Sigia-l] Multiple submit buttons vs. Check boxes on a form

[Pradyot Rai]

Hi Jeff,

Advice that I have is to "not" default (or put multiple 'tasks' in one
bucket) "print" with any other features ('Save and Print' in this case).
It often is confusing and may results in poor user experience. The
problem with web interfaces and "print" feature is that the content of
the stuff to be printed can't be controlled -- printer may not print
everything that browser sends, printer may not print as it looks on the
screens, etc. And think of it, no "print" command from web UI will go
straight to printer. It will at max. request the API to open the
standard "print" dialog for user action.

The work around? -- Provide a consistent feature for 'print', across the
interface where ever applicable. Incase if you don't want
user to print all the interface elements, provide him means to "Export
to Print". Allow exporting content to a popup window with just the
content to be printed, without all the look and feel elements. This
popup window works as preview for the content too. You can provide a
button called "Print" to send it to printer.

The only problem with this suggestion is that it adds one extra "click"
to the interaction. Good thing is that user knows what is going to be
printed, because most of the time controlling the layout of the print
output is beyond control.

> I am designing a web application with a number of forms. Many of the
> forms allow the user to print a copy of the form after they have saved
> the information. As part of the business process, the users are often
> required to print the form so this is something they do frequently,
> but not always. I've seen this handled a couple of ways.
>
> 1. The form has multiple buttons at the bottom. Save | Save and Print
> | Cancel

Consider splitting you tasks in a different "groups" -- Allow operations
to be performed on the form itself (to be reflected on the server) to be
on one "Group", say, on the bottom. In this case, "save"/"cancel" makes
good sense to stay at the bottom. And those which are common tasks (mere
UI enhancements) to stay elsewhere on the UI, which is in this case to
provide "print", "export to Print", etc... (you may choose the words to
define it).

> 2. The form has a check box above the buttons "Print this Form on
> Save" and then only two buttons Save | Cancel. You could either
> default the check box checked or unchecked depending on the frequency
> of the need to print.

And, how will user print if he "un-checks" it? and still wants to print?
 IMHO, "Print this Form on Save" with 'check boxes' is "sticky" and
"cheap". It may reduce the friendliness of the interface. Look at all
the possible scenario in which this feature (Print & Save) will be used.
Have the alternative ideas in place and bargain it with all usage
scenarios. That way you will know which one is preferred. Another, means
to pick one option over other is - How much time you have to implement
it? Any implementation with 'check boxes' or 'radio' buttons alone, may
cost less.

> I'm curious if anyone has seen studies or had any experience with the
> usability of these two approaches (or others that you've seen that
> accomplish the same thing).

A nice thing to do is to spend sometime with similar applications,
especially some of the UI guidelines to study how user tasks are
arranged in terms of layout. Look at some of the interfaces yourself and
try forming *patterns* for your own. Consider some very simple examples
- "yahoo", "Online banking Apps", "enterprise portals", “shopping Carts”
etc. Read about web UI guidelines/concepts, such as Oracle's Portlet
(keyword: "BLAF guidelines"), or SAP's own interface guidelines
(keyword: SAP guidelines), etc.

The best way to learn about the "issues" on web interfaces is to play
with all that is available. Try forming the *patterns* and avoid
re-inventing the wheel. There are really no "standards" that you can
borrow for web UIs, although so much has already been done that you can
save a lot of time looking at them. And remember “print” from the web
app.s is the most unfriendly feature, no matter what ever you do.

Hope this will help. If you have any cross questions, I will happy to
explain with examples.

Pradyot Rai