After inscribing the first set of case notes in the Pythonic Forms tale, I leaned back in my worn-out office chair, put a few bits on the benchmark fire, and considered the next chapter. It must include a view from the user perspective, not their experience as such, as who can inhabit another's mind, but their feedback and their commentary. To protect the innocent, I won't reveal who said what.
Fewer mug shots, er, screen shots, this episode. A few though.
The goals of a digital form to replace a paper workflow process (see which) was to cut down on data retyping, standardize categories, and have more accurate records. People's work was not supposed to be interrupted, though in any change there could be resistance. That turned out to be an understatement.
With a newly minted PDF digital document in the arsenal, I thought I'd deputize veterans of this particular event management task. The total pool of candidates was between 10 and 20 and it didn't make sense to blast notes to all of them. It also didn't seem likely to produce balanced feedback with only one or two testers.
Stop me if you've never asked for volunteers.
My first inkling of trouble was the length of one response. You know you're in trouble when the answer isn't "sure, what do you need?". I'll spare the gory details, just summarize with the psychological profile of people who claim to be helping but only if they write the ticket must be fascinating. I chalked that one up to "prefers to not change". Less charitably, does not want to be involved.
The next candidate had a different reaction, or I'd probably be forced to rethink the priorities and approach for the whole idea. There were thoughtful questions, comments, and suggestions for improvement. Useful in the context of time required for updates, level of effort on my part, and whether I could make the fixes with my current skills. Questions about how to use the new form were answered in some cases with "add metadata" in the transmission document, er, cover letter. In other words, a little scope creep, or perhaps just do the best you can. This feedback and forth gave me more confidence I was on the right trail. Saying we need this and I like it are great morale boosters.
The last candidate seemed ideal. An engineer/architect with experience and a range of interests. As it turned out, the communications were not ideal, or maybe my expectations were too high. Instead of feedback on details such as field size, content, order, and appearance, this interaction was going to be about document distribution and collection.
As described in Chapter 1, a saved form may be larger than the original, may have a different identification (fingerprint) pattern, and needs to be named appropriately. Send out "document_001", get back "document_001_saved", or something like that. One venue may have several scheduled events; the single original blank fill-in form could be used for multiple events by saving each as a new document. Including the first event date seemed a good naming scheme.
In an attempt to cut down on email and improve our ability to track progress, I decided a shared Google drive was in order. That tool is well-designed, easy to use for the barely tech savvy, and should have been a problem solver. It wasn't.
First, I didn't want to use my personal account; I wanted the organization to host the content themselves, so I wouldn't be the guy holding the bag when the lights went out (not the bag man, see). Candidate 3 wasn't able to share their folder, and when I hosted the documents, there was continual confusion about what was updated and where. I've gotten used to the clarity of Dropbox communications (so-and-so changed these files this week). Not sure why Google wasn't getting the message across the all points bulletin. We ended up resorting to emails saying "I updated the shared folder" which went against the original idea of fewer emails.
Second, generating the forms was meant to be a simple, periodic process that would replace, or supplement, the old method of printing and copying paper forms. However, the entire set needed to be broken into smaller sets, and different people would manage their own sets. I worked out batch commands to create a few forms at a time that could then be moved to a Google drive folder. Again, not highly technical but the publication needed to be communicated, and the instructions tailored to those (volunteers, all) who were to use the forms. I also set myself up as the sole content provider, and made a mental note to create a simple menu driven app.
Third, not enough testing. Or fence-posting. Or something. The new process went off the rails, as they do sometimes, when the main end user tried to update the PDF forms without having a PC or Mac with the software tools I had expected. Android phones and Chromebooks are wonderful, for many tasks. Just not this one. Early in the form redesign brainstorming, the decision was between online web forms, and offline PDF. There were pluses and minuses for both approaches, and in the end, the decision was made using my favorite Mae West quote, "Between two evils, I generally like to pick the one I never tried before." [ en.wikiquote.org/wiki/Mae_West ].
I wanted to test with PC users, Mac users, and, well, that's all I considered. I have an Android tablet, so I could have looked for an app there and verified whether editing a fill-in form was going to work on that platform. But I don't have a Chromebook, and hadn't considered anyone using that platform in this effort. Short-sighted on my part, with unfortunate consequences.
The biggest complaint about the digital form was the size of the description field. On a paper copy, someone could write in the margin, on the back, or on another sheet of paper if there was more to say. In the PDF form, the size was stuck where I poured it. While I intended the second edition to have a larger space, the first version ended up with a single line that would "scroll" left and right as more text was entered. Terrible user experience, and I should not have let it out the door like that. But we were still testing, and I hoped the rough interface would be tolerated for the sake of progress.
Rich text field in test mode:
In fairness, the one-line form text field was a fix for the issue I hit trying to allow for formatting (bold, underscore, italics) and fonts with a Rich Text variation that ended up hugely inflating the resulting saved file. I had traded off one issue (an internal IT one) for another (an external user interface one). Sound familiar?
The event calendars that these forms populate are published quarterly, so there were deadlines to preparing and sharing the forms. With other organization conditions not relevant here, I managed to push out between 10 and 25 percent of the total to be processed. That was probably a good range for the first version, with the plan being to take the feedback from the user tests and the actual "production" returns to build the second edition after the quarterly publication was drafted (and proofread).
The failure, which it's fair to call it, was the return content from the Chromebook edits. The forms came back as PDFs not Word or other file types, but the carefully laid out PDF field forms were mostly empty. In particular, the description, the longest text content and the most important to the publication readers, was empty. That intended text was embedded in a text box. And I'm not (still) even sure how it was done. It'a a mystery. I knew one can add highlighting and other annotations to PDFs but this was a surprise.
End result: more work, rather than less. And more versions to be accommodated in the flow.
I knew when I reviewed the returned forms that the poor choice of a small text entry area had pushed the users to be creative in completing their part; while the show must go on, fixes were needed. Or workarounds, given the deadlines. And to make it more challenging, the newly created text box didn't act as one might expect on a digital form. When you clicked on it, nothing happened. Like having no shells in the chamber. Me, being the hard-boiled detective sort, quickly realized that a double-click would open up the text box for your basic open and shut case of copy and paste. Or was it a triple-click. I got lucky (punk).
We can't all be ABAP Detectives, though, can we? Some of us are going to be Floyd Thursbys, or Lew Archers, er Miles Archers. When the other office volunteers attempted to pull data off the missing event forms, they got stuck. Explaining a double-click over the phone ended up with static.
The workaround was for me to parse the resulting forms at home, copy out the text field, paste it into an email, and send it to the data entry people. Hardly the smooth automatic data collection and digital paste up I had envisioned.
Lessons learned: get more testers, write/talk more documentation, get management on-board. You know, the usual suspects. Even if the organization decides not to move forward with a digital transformation step, the ground work has been laid on how it could be done. I've learned quite a bit about PDF form management along the way, and have new ideas on how to produce better forms.
Here are screenshots of the next version, in progress (note the "tool-tip" floater):
Revised version, again allowing rich text content (with resulting large file size):
Next Episode: The ABAP Detective Goes Back to the (Database) Dictionary, in which we will dive into the form creation, design decisions on field size/layout, and a few tricks of the PDF trade. I said I'd talk about those topics in this chapter, but instead concentrated on the user experience and change control.
Fewer mug shots, er, screen shots, this episode. A few though.
The goals of a digital form to replace a paper workflow process (see which) was to cut down on data retyping, standardize categories, and have more accurate records. People's work was not supposed to be interrupted, though in any change there could be resistance. That turned out to be an understatement.
With a newly minted PDF digital document in the arsenal, I thought I'd deputize veterans of this particular event management task. The total pool of candidates was between 10 and 20 and it didn't make sense to blast notes to all of them. It also didn't seem likely to produce balanced feedback with only one or two testers.
Stop me if you've never asked for volunteers.
My first inkling of trouble was the length of one response. You know you're in trouble when the answer isn't "sure, what do you need?". I'll spare the gory details, just summarize with the psychological profile of people who claim to be helping but only if they write the ticket must be fascinating. I chalked that one up to "prefers to not change". Less charitably, does not want to be involved.
The next candidate had a different reaction, or I'd probably be forced to rethink the priorities and approach for the whole idea. There were thoughtful questions, comments, and suggestions for improvement. Useful in the context of time required for updates, level of effort on my part, and whether I could make the fixes with my current skills. Questions about how to use the new form were answered in some cases with "add metadata" in the transmission document, er, cover letter. In other words, a little scope creep, or perhaps just do the best you can. This feedback and forth gave me more confidence I was on the right trail. Saying we need this and I like it are great morale boosters.
The last candidate seemed ideal. An engineer/architect with experience and a range of interests. As it turned out, the communications were not ideal, or maybe my expectations were too high. Instead of feedback on details such as field size, content, order, and appearance, this interaction was going to be about document distribution and collection.
As described in Chapter 1, a saved form may be larger than the original, may have a different identification (fingerprint) pattern, and needs to be named appropriately. Send out "document_001", get back "document_001_saved", or something like that. One venue may have several scheduled events; the single original blank fill-in form could be used for multiple events by saving each as a new document. Including the first event date seemed a good naming scheme.
In an attempt to cut down on email and improve our ability to track progress, I decided a shared Google drive was in order. That tool is well-designed, easy to use for the barely tech savvy, and should have been a problem solver. It wasn't.
First, I didn't want to use my personal account; I wanted the organization to host the content themselves, so I wouldn't be the guy holding the bag when the lights went out (not the bag man, see). Candidate 3 wasn't able to share their folder, and when I hosted the documents, there was continual confusion about what was updated and where. I've gotten used to the clarity of Dropbox communications (so-and-so changed these files this week). Not sure why Google wasn't getting the message across the all points bulletin. We ended up resorting to emails saying "I updated the shared folder" which went against the original idea of fewer emails.
Second, generating the forms was meant to be a simple, periodic process that would replace, or supplement, the old method of printing and copying paper forms. However, the entire set needed to be broken into smaller sets, and different people would manage their own sets. I worked out batch commands to create a few forms at a time that could then be moved to a Google drive folder. Again, not highly technical but the publication needed to be communicated, and the instructions tailored to those (volunteers, all) who were to use the forms. I also set myself up as the sole content provider, and made a mental note to create a simple menu driven app.
Third, not enough testing. Or fence-posting. Or something. The new process went off the rails, as they do sometimes, when the main end user tried to update the PDF forms without having a PC or Mac with the software tools I had expected. Android phones and Chromebooks are wonderful, for many tasks. Just not this one. Early in the form redesign brainstorming, the decision was between online web forms, and offline PDF. There were pluses and minuses for both approaches, and in the end, the decision was made using my favorite Mae West quote, "Between two evils, I generally like to pick the one I never tried before." [ en.wikiquote.org/wiki/Mae_West ].
I wanted to test with PC users, Mac users, and, well, that's all I considered. I have an Android tablet, so I could have looked for an app there and verified whether editing a fill-in form was going to work on that platform. But I don't have a Chromebook, and hadn't considered anyone using that platform in this effort. Short-sighted on my part, with unfortunate consequences.
The biggest complaint about the digital form was the size of the description field. On a paper copy, someone could write in the margin, on the back, or on another sheet of paper if there was more to say. In the PDF form, the size was stuck where I poured it. While I intended the second edition to have a larger space, the first version ended up with a single line that would "scroll" left and right as more text was entered. Terrible user experience, and I should not have let it out the door like that. But we were still testing, and I hoped the rough interface would be tolerated for the sake of progress.
Rich text field in test mode:
In fairness, the one-line form text field was a fix for the issue I hit trying to allow for formatting (bold, underscore, italics) and fonts with a Rich Text variation that ended up hugely inflating the resulting saved file. I had traded off one issue (an internal IT one) for another (an external user interface one). Sound familiar?
The event calendars that these forms populate are published quarterly, so there were deadlines to preparing and sharing the forms. With other organization conditions not relevant here, I managed to push out between 10 and 25 percent of the total to be processed. That was probably a good range for the first version, with the plan being to take the feedback from the user tests and the actual "production" returns to build the second edition after the quarterly publication was drafted (and proofread).
The failure, which it's fair to call it, was the return content from the Chromebook edits. The forms came back as PDFs not Word or other file types, but the carefully laid out PDF field forms were mostly empty. In particular, the description, the longest text content and the most important to the publication readers, was empty. That intended text was embedded in a text box. And I'm not (still) even sure how it was done. It'a a mystery. I knew one can add highlighting and other annotations to PDFs but this was a surprise.
End result: more work, rather than less. And more versions to be accommodated in the flow.
I knew when I reviewed the returned forms that the poor choice of a small text entry area had pushed the users to be creative in completing their part; while the show must go on, fixes were needed. Or workarounds, given the deadlines. And to make it more challenging, the newly created text box didn't act as one might expect on a digital form. When you clicked on it, nothing happened. Like having no shells in the chamber. Me, being the hard-boiled detective sort, quickly realized that a double-click would open up the text box for your basic open and shut case of copy and paste. Or was it a triple-click. I got lucky (punk).
We can't all be ABAP Detectives, though, can we? Some of us are going to be Floyd Thursbys, or Lew Archers, er Miles Archers. When the other office volunteers attempted to pull data off the missing event forms, they got stuck. Explaining a double-click over the phone ended up with static.
The workaround was for me to parse the resulting forms at home, copy out the text field, paste it into an email, and send it to the data entry people. Hardly the smooth automatic data collection and digital paste up I had envisioned.
Lessons learned: get more testers, write/talk more documentation, get management on-board. You know, the usual suspects. Even if the organization decides not to move forward with a digital transformation step, the ground work has been laid on how it could be done. I've learned quite a bit about PDF form management along the way, and have new ideas on how to produce better forms.
Here are screenshots of the next version, in progress (note the "tool-tip" floater):
Revised version, again allowing rich text content (with resulting large file size):
Next Episode: The ABAP Detective Goes Back to the (Database) Dictionary, in which we will dive into the form creation, design decisions on field size/layout, and a few tricks of the PDF trade. I said I'd talk about those topics in this chapter, but instead concentrated on the user experience and change control.
- SAP Managed Tags:
1 Comment
