MentalPolyphonics
Where have all the plumbers gone?
One thing that was sad was people emphasizing...I just did a little project I’ve been noodling since back when I was an accountant: An application to generate GST returns with the minimum amount of data entry.
A few of my design considerations:
Accountants aren’t necessarily technical and are usually pretty conservative. Therefore look and work like paper as much as possible. In a sense this lets the application fake like it’s WYSIWYG too.
Take all of paper’s good bits (in this case mostly familiarity) and add the part computers are good at: changing text high-lighting to show the user what they’re working with, and doing the adding and text arranging for them.
Accountants also know about the tab key. Let the user tab between data entry fields (allow acceleration for power users).
Big buttons are easy to click on. Big text fields are easier to enter data into. This is more than convenience: It makes the application faster and easier to use (actions are clear and don’t require as much pointer deceleration).
Still, I would have liked it all to fit cleanly on a 1024×768 page. Maybe in the re-design.
Keeping the graphics simple made the application look easy to use, I think. The only text on the screen (aside from text in the images) is the default helper text in the business number field which goes away if the user ignores it.
I also kept the business logic simple. If you enter your net revenue as “three plump oranges”, that’s what goes in line 101. Data validation isn’t necessary in the face of multiple cheap retries.
Like most computer people I have no training in accessibility. Mostly I just added “alt” text. 
I tried for maximum compatibility. As always, IE is proving to be a special case…
Anyway, if you have any suggestions let me know. It’s in Google-stylee public beta at the moment. Oh, and: The name? That’s me picking something that’d appeal to accountants
Jared
Comments:
Jack
@Help text:
Good one.
@Separators:
I’m going to try a version of the fields without them. Yes, they’re unhonored — and will be in the form too when it’s cleaned up (I always used to write in the space over the separators at the firm).
@Date fields:
I did think about calendar fields, but the “multiple cheap retries” idea makes those unnecessary too.
The “from” and “to” dates are quarterly, unless it’s a partial-period return. The due date is also statutory, but you can finesse that too. There’s a lot of “validation” possible there that would just get in the way.
Calendar pickers aren’t really useful for picking quarterly dates — you’d have to start each use with paging to the correct month, a huge time-sink. That alone is enough to nix them for me.
Once I start adding validation there are so many special rules on the dates that I wouldn’t have finished. Add to that: Some firms might want dates in different formats. Or different formats for different clients.
But low-cost text-based retries fix all that. Basically: Date picker fields are out-of-scope because they’ve got an inappropriate cost/benefit trade-off. And yes, I thought about this before starting
@Usability:
Usability includes validation when failure takes ages to recover from. If your feedback loop is tight enough I assert that validation is a waste of time. Interactive script sessions are more responsive than debug/compile/test.
I might do number field checking, but the cost of user failure recovery is so low the task is not urgent.
Jack
I’m also concerned about accessibility.
Jack
Also:
Paper doesn’t validate.
Calendar pickers cause a context change from keyboard entry to mouse entry, and all the default calendar pickers have tiny buttons.
Jack
Added show/hide of help text. Here are the rules:
1) Start with the help text.
2) If onFocus the text is still the help text, empty it.
3) If onFocus anywhere else and the help text is empty, reset it.
I did it that way because I hate not being able to get back to the start state of a program — I didn’t want the text to disappear forever. This raises a potential issue though: What if the user wants to print a return with an empty business number?
Really I want to set a flag if the user changes the text, but that can go on the TODO list.
Jack
TODOs:
Add clear button.
Only hide help text if the user changes it.
SSL certs.
PDF cell alignment and stretching.
Jared
Where did this “multiple cheap retries” model come from? Did you come up with it? It’s interesting, but I’d like to see usability metrics.
Are you developing this on OS/X? Because loading a PDF is not so seamless on operating systems that don’t use the format natively. On a badly-configured workstation, the debug-compile-test cycle you’re forcing the user into will be longer.