HCM Processes & Forms: Just because it is called a “form” does not mean it has to be boring!
Maybe this blog should be filed under “rant” or maybe moreso, a bit of “showing off” (haha), but I thought I might talk about what many consider the “ugly side” of HCM Process & Forms….the FORM!
I often see comments like this when people discuss HCM Process & Forms using Adobe Interactive Forms (and even WebDynpro ABAP) as the front-end for the user:
- “They are just so limited and stale.”
- “Users find them ugly and too form-like.”
- “It’s not a very dynamic interface…enter fields, next step, check fields, next step.”
- “It’s like they took their old dynpro programming and implemented it in Adobe! haha”
- “You can’t put lipstick on a pig.”
WHAT?!?! I am blown away when I hear things like that. I wonder “What have they been looking at?!?! What have they seen?!?!” Ok….I will admit, if you are looking strictly at the standard SAP sample forms for HCM P&F, they are pretty stagnant. But they are not meant to be showcases for Adobe Interactive Forms! Most all of them are meant as reference, to show some bit of configuration or in-form scripting. As for WebDynpro ABAP, well, I think Thomas Jung has proven time and again that you can do some pretty “fancy” interfaces with WDA. I will stick with Adobe forms for this blog.
Here is SAP’s sample for the “Org Unit Change” form (and yes, I agree it is stale and simple in appearance)…
Here is an example of a section of an “Org Unit Change” form that I did for a client recently using a “dynamic” image the made the form more “interactive”…
As the user made changes on the form, the image would actually change to reflect what they were doing as the completed the form. This happened all without the need to reload or make round trips. It was all handled in client side scripting!
Again, here is SAP’s sample “Org Unit Create” form…”basic” for the most part…
Here is another example of a section of an “Org Unit Create” form that I did for a client recently using another “dynamic” image…
It does not even have to be that complicated or extensive. Sometimes it is just nice little things. Here is an example of using “links” in a form to show/hide additional information that would otherwise “clutter” the form if shown as static, “always visible” text:
To take this idea a bit further, we can use our standard field “FORM_SCENARIO_STAGE” to know “which” step of a process the user is on and then display context sensitive help to them (ie. show them help information that pertains exactly to their current step!):
Using the same idea, you could have a button that triggers to “show or hide” information for a particular field. In this example, the user needs more information about the possible payment types and what to select. By clicking the “i” (information) button, we show/overlay a hidden subform that contains all of our static content.
Using values bound to hidden fields, we can use scripts to “inspect” these values to show or hide other visual cues for our user. I have shown this in another blog, but in this example, we are showing the user that an attachment is not yet uploaded by a simple image and text displayed in the header of the related area on the form.
For the most of these prior examples, you will learn the usage of the “presence” property will become your new best friend. (haha)
Here is another fun one. Want to display graphs on a from? Want them to be “interactive”? Simply use bound data fields to some values we want, then use positioned subforms with different “fill” colors as your “bars” of your graph. Lastly, in the “form ready” event for each of your “bar” subforms, set their width (or height if showing vertical) based on those bound data values.
Want to take it a step further? Make those text fields editable and use your “exit” or “change” events on them to fire events to “reload” the form when a user changes the values thus making your bar graph appear dynamic!
Neat stuff..and soooo easy too!
What about something as simple as having buttons on your form that do not look like plain old grey drab buttons? What about buttons with images? Or Images used as buttons? Something like….
Again….very simple. Instead of having text on your button, give it a text of something like “?” or “.” (the period or hyphen works great!) Then, size your button down to the width/height of whatever image you want to use. Lastly, create an image control, pick your image, select it as “embedded in the form”, and place it ON TOP of your button. Viola! You now have an image that works like a button (because the standard image control has no “click” event, it will pass through to the underlying button control to handle). Now you can set you button’s fill color to whatever you like..even empty…so to the user, all they think they are seeing/using is a clickable image. Pretty sneaky, eh? haha
You can also combine all of this form scripting “trickery” with using WDA within your form as I discussed in this blog (HCM Processes & Forms: Adobe or WDA? Why not Adobe AND WDA!?!?! ). Given your available tools now and thinking outside the box a bit (and outside the traditional limitations of a “print” form), you can really create a rich user experience that truly feels “interactive”.
Of course, I can’t give away all my little secrets (haha), but I hope this blog might help change some people’s perspectives of what a “form” can be in HCM Processes and FORMS. As always, I hope this has helped…till next time….enjoy!