On Flexing the 1040 (US tax form)
Let me preface this post by saying that perception is reality. That is to say that sometimes all you really need to do is instill the vision of what’s possible, and the rest will take care of itself. In the software world we call this a “demo”. Setting vision and demonstrating the possibilities of Adobe software is something I do on a daily basis. With that in mind, I was recently tasked to come up with a Flex version of the IRS Form 1040 (annual taxes for those outside the United States).
I’ve never been classically training in information architecture or experience design, but it is something I find that I have a penchant for developing. Given that I come from a background of desktop technologies, it should be no surprise that I tend to apply this metaphor to my applications - it also happens to be something that’s well suited to RIA. My first line of business then, was to familiarize myself with the form itself, and to understand how it is that users interact with it currently.
When I headed to the IRS web site and opened the Form 1040, I did so using Acrobat Reader 8. I thought to myself that there are a lot of fields here, and that in general the PDF version does a pretty good job of displaying it all. You can turn on highlighting of the fields you have to fill out. You can merrily tab along all day. There’s even a place to create attachments, which is something the 1040 asks for repeatedly.
Then I came to the “Pages” view containing the thumbnails of the PDF. This was particularly not helpful. Two pages with lots of garbage on them left me at a loss for context (where am I in the overall form). The “How To” section told me all about Acrobat Reader, but nothing about the 1040, which is really where I needed the help. To get that help I’d have to open another PDF and then toggle between the two, getting lost along the way.
This is where inspiration struck. Acrobat Reader is relatively unintelligent about these areas because it has to deal with all variety of documents. Some forms might be related to tax, but yet others might have interactive 3D diagrams for uses in manufacturing. It suffers content specificity (usability) for abstraction - and understandably so. What if Acrobat Reader knew this was a 1040? What then would happen if the “Pages” were of the sections of the form, rather than the pages of the document? What if the “How To” contained context-sensitive help relative to the fields on the form? What if rather than reading, I was able to get video/audio help from an IRS representative?
Before I get into the details of what I built, why and how, let’s go back to the “perception is reality” thing. I am one guy. My timeframe here was a single week. My already full schedule was also not going to magically clear itself, so I had to fit in development wherever I could. To that end, this is a demo. There are lots of fun features, but precious little actual functionality. Bugs run rampant. My list of features that didn’t get done is almost as long as what did. Fundamentally however, it does set the vision for the group that requested the work.
Dynamic Form Sections via XML
The first thing to know is that while the 1040 was the main topic of interest, it was expected that after I was done, the demo would live on and need to be repurposed by others. For this I leveraged dynamically generation of the form itself. There’s a single XML file which describes the form and that is loaded when the application first starts. When you see “Accessing form…” in the demo, the XML is loaded and the UI is being constructed at runtime.
Again, perception is reality. The user perceives that the some fashion of network calls are happening and is happy to wait, when in actuality the application is burning your CPU to instantiate all the form line items. This is one of my favorite usability tricks. I also wasn’t going to create the 75+ line items by hand, and have a never-ending support job on my hand every time somebody wanted a new form. Change the XML, change the form - done.
I should also mention that it’s possible to have an XML representation of a PDF, and in theory this same source could potentially be used to drive either UI. It also stands to reason that additional UI could be added to the application to allow the user to select from any variety of supporting forms, which is one of the features I didn’t get to.
Real-time Thumbnail Views
Great, I’ve loaded the XML and built the UI at runtime. What about my main objective however of making taking Acrobat Reader metaphors and making them context sensitive? How was I going to have thumbnails of the form sections when the application doesn’t ever really know what the form looks like? For this I turned to the Bitmap API in the Flash Player, grabbing the screen shots of the forms once they are created and scaling them down to a thumbnail view.
Perception is reality though, right? How do I prove out, or show, that the thumbnails are truly dynamic during the demonstration? I added a few event listeners to my form line items (which are actually instances of a general-purpose line item component), and then grabbed new “screen shots” of the sections whenever a form was changed. Doing so with every keystroke seemed a bit overkill however, so I wait for a change and a focus loss.
Try it - edit a field and then tab off it and watch the thumbnail get updated. You can also navigate to the various form sections by clicking on a thumbnail. By the way, I’ve locked the form fields to accept only numeric data - love that client-side intelligence. Conversely, I didn’t have time to get to the “cents” field, so only the whole dollar fields work.
Attachments
One of the things I noticed about the verbiage of the 1040 was that it often called for attaching additional forms. I thought it was annoying to have to read that and then go hunting down the UI for attachments. I wanted to place context in an otherwise generic Acrobat Reader. I know what the form is, and I know that the user will be queued to attach files via the verbiage “Attach”.
That little line item component I mentioned earlier is smart enough to pick up on the “Attach” verbiage. For there it replaces that text with a paperclip icon. Users can then click on the icon and open a file attachment dialog. The attachment pane in the application will also open if it isn’t already.
Don’t worry, I don’t actually upload your attached files (this is a demo after all), so go ahead and try it. The application limits the types of forms you can upload to TXT, DOC or PDF. I also took the time to create a custom item renderer to show the respective icon for the type of file attached. If you select a file from the list you can also remove it. And of course, going to the attachment section directly works too if you don’t need the contextual icon.
How To
With regards to parsing verbiage, the 1040 also says to “see page” for help repeatedly. This is that aforementioned file you’d have to find, open and toggle between. In keeping with the mission of adding context, the application parses out wherever it encounters “see page” and creates an icon. Just like the “attach” icon, the help icon can be clicked, which will take you to the “How To” section and present context-sensitive help - in this case, video help.
Okay, so I took the opportunity to inject a bit of humor into the demonstration. Yes, that’s me in my office acting like a secret agent. What can I say? I was on a “Men in Black” kick at the time! If the angle looks funny, that’s because I’m 6′ 7″ and had to slouch way down in my chair for my webcam.
I didn’t have time to record the actual help for every line, so I created three videos - line 21, line 32 and line 44. Line 44 is used as a catch-all, so if you click on any other line item that isn’t 21 or 32, you’ll actually get the video for line 44. The video here is delivered progressively (actually downloaded). Ideally, it’d be delivered as streaming video from the Flash Media Server.
Live Help
So long as a streaming server might be in place, why not offer live help for the consumer as well? If you select the “Live” option from the “How To” panel, you’ll find a screen that echoes back your webcam. If you don’t have a webcam, you’ll have to image your pretty face in that black box. With FMS in place, it wouldn’t be your face there, but a customer service representative (CSR), eagerly waiting to walk you through the complexity of filing your taxes.
Almost assuredly not every person in the United States filing taxes has a webcam, so I needed a way to allow the user to interact with the CSR. As I’ve encountered many times through countless e-seminar presentations, text chat performs wonderfully at this task. If you enter a message and click “Send” you’ll get a three second pause and then your message echoed back to you.
Again, part of my thought process was around distribution of the demonstration, and I wanted to avoid a never ending support situation. In a deployed scenario, this type of messaging is a perfect fit for Flex Data Services (FDS). Enabling application sharing through FDS would also be an attractive feature that would allow a CSR to fill out the form remotely.
If you click on the back button in the “How To” section, or the “Home” button, you’ll find yourself back at the original screen where we get to watch video of me being corny. The last type of help I decided to surface in the application was context sensitive by way of mouse click.
If you click the “Context” option at the top of the list, your mouse will turn into a cursor with a question mark. You can click anywhere in the form to make this go away. Clicking on a line item doesn’t actually do anything other than remove the cursor in the demonstration. It does however set the precedent for the empowering the consumer to get their own help in the same context as many other desktop applications.
Missing In Action
I’ve talked about the line item component a few times. It is driven by an XML node, smart enough to know how to parse out verbiage, raises events for user help and attachments, and can even take lightweight HTML for the label. In my opinion however, this is amongst the weakest parts of the demonstration from an architectural point of view.
There’s a number of more complex line items on the 1040 that my little line item component just can’t handle. At least, not in it’s current form. There’s also a limit to the screen resolution that this display mechanism presents. You’ll notice for example that if your screen resolution is small enough, the labels will flow right on into the fields.
If I was going to expand on this demonstration, the line item would be the first place I’d start - allow the XML to describe a more complex line and then to be able to wrap the line where the label is long enough to bump into the field. It should also be pretty obvious that I’m actually missing a number of sections for this exact shortcoming.
Moving Ahead
You may or may not be fond of my interpretation, and I respect that completely. One thing I’ve encountered though is that there’s a distinct shortage of Flex-based RIA (or any RIA really) that account for complex data entry. When they do, they automatically default to the classic desktop metaphors. This isn’t something I’m against, but I believe that we’ve yet to tap into potential of RIA for alternative data entry for enterprise applications. This demonstration however, is hopefully something that instills at least some degree of vision as to where developers might be able to go in the future.
I should also mention that this demonstration stops short at collecting the information. Clearly this data isn’t going to be processed outright by a computer and spit out your refund check. At some point a human will need to review the content and make sure everything adds up. That infers some fashion of workflow that needs to be put in place. A perfect fit for LiveCycle Workflow.
Perhaps rather than submit the information electronically, you want to print it out and put it in the mail. Does that mean that somebody on the other end is going to have to spend countless hours re-keying all this data? What’s to say that you’re going to mail the form to the IRS? Maybe once you’ve filled it out, you want to take it to H&R Block (or the likes). Putting this data into a 2D barcode (PDF 417) a la LiveCycle Barcode would be the perfect fit.
There’s of course going to need to be some fashion of security involved with this form. I don’t want my tax information readable by just anybody. I can also expect that the IRS is going to want to know that I am accountable for the information I provided via signature - digital signature perhaps. Enter into the mix LiveCycle Security.
What if the form evolves and as the issuing institution, I want to be able to control or outright revoke who sees what version of the form? Enter LiveCycle Policy Server.
You see, in the big picture here, going all the way back to setting vision, I think it’s important that developers see Adobe for the broader spectrum of solutions that it can provide. Sure, there’s a great “boxed” product company that offers world-class software like Photoshop and Dreamweaver, but Adobe also offers the infrastructure solutions necessary to support developers building their own world-class software.
While there’s undoubtedly a long way for Adobe to go on the whole to make this type of vision a reality, I think it’s safe to suggest that is the direction it will go in the near-term. The Adobe/Macromedia acquisition has been final for just over a year at this point. That’s precious little time to bring this entire vision together. What will Adobe’s solution offering look like a year from now?