Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
OttoGold
Active Contributor
0 Kudos

I am interested in the user productivity and its connection with the GUI which the users use to do their jobs. I feel a big difference between the most used GUI technologies: SAP GUI, EP/WD/web development for SAP and SAP Interactive forms by Adobe. Also the target groups for these GUIs - imho - are different as well (yes, that is not what you see every day - mostly forms are embedded into the portal, designed to be not-that-simple web services client etc.). These all are the reasons I think it is important to drop a line on this topic - how to fill the form.

Imagine you would give some simple and pretty Adobe form to your grandma. I think she will make it to fill it. She´s doing forms for all her life (post office etc.). Now close your eyes again and imagine you would give her your favourite SAP GUI transaction (e.g. PPOME or ME23N for meJ). Would she make it? Do you agree now you should approach the Adobe form application a bit different than you´re used to when working on WD or SAP GUI screens?

Maybe you will find the topic a little bit odd, but for me Adobe forms are the best interface for the occasionally working user with no or very little computer skill. Most of the topics covered so far very pretty technical.

On my project for the Public sector I was asked to think about the possible ways to work with the "help texts"/ filling instructions and other "attached texts". The number of the users will be pretty high and the impact on the help line or (if the forms were designed not bullet-proof enough) impact on the number of errors. That would be unacceptable. Also the level of the computer skills among the users will be very different. Because of all these reasons all possible helps texts have to be included. But have to be included the way they won´t distract the experienced users.

So I come up with some options how to work with help texts:

  • 1) (Basic) In standard of the forms there are tooltips (tab Accessibility - Tooltip text)
  • 2) (Basic) You can always include some simple static texts about what the user is supposed to fill in here. (My favorite bonus is to create some nice headline which looks like a hyperlink (colored and underlined) or a button which unwrap the longer help text. This is very fast and simple, you only manipulate the help text presence)
  • 3) (Quick win) Do you know it is possible to use floating fields in your static texts? It works the same way when you embed the variables in the standard texts (transaction SO10). You place a floating field into the static text, maintain the binding for the floating field and voila!... there is a nice dynamic text. For example: Dear {username}, please blah blah...
  • 4) (Idea) Our users expect there is something like (F1) help in Adobe forms like in SAP GUI. F1 calls the Adobe Reader standard help, so you cannot use this to call your custom help "window", but you can implement for example little buttons with "?" caption to call these custom F1 helps. Now it is time for a trick - use positioned subforms (although I don´t like themJ) and place them at each other (like 2 layers), resize the help subform to make it smaller (for example A5 format on A4 page), color it and add the help headline. Call this subform (of course with different texts) from you "?" buttons (do not forget to place a button doing "hide me" on the help subform. Looks impressive (help partially overlaps the form layout). For scripting details you´d better read the guide (the solution is not described there, but all the details needed to build it yourself are): LiveCycle Designer Scripting Basics.
  • 5) (Standard text) The customer supervisors want to write down some fill-in instructions to help the users finish their task in the form. And these texts can change. So revise your standard texts knowledge and use them in your forms. Choose the proper text type from 3 options available and add text elements right into your form context. To get the idea with pictures, check the wiki about Using standard texts (SO10) in the Adobe forms.
  • 6) (Attachment) If there is a man (for example in another department) whose job is to write the manuals (simplification, of course) and he has written a manual/ instructions about how to fill in the form, you can add his PDF/ Word DOC or any other file as the attachment of the form. If you don´t know how to work the attachments: Check how to work with the attachments using JavaScript (or WD Java - removing attachment from interactive form), and ESPECIALLY (because you will probably not use any scripting when only attaching the instructions, that was mentioned only because people ask about this very often in the forums...) check the ERP standard reports (using the naming convention FP_*) which work with the attachments: FP_PDF_ATTACHMENT_TEST.

If there is an option I didn´t cover (probably there are some...), please share it with the other readers through a comment. Your feelings and experience is welcome as well, because the Usability of the forms is a great "feature" a great benefit about Adobe forms.

Have a nice day everybody, regards Otto

Labels in this area