Thanks for all the responses! I mispoke on ALGs in general-- I meant that "Interactive" ALGs do not work on the web:
>From the 7.1 Workflow guide: Interactive guides: Walk users through filling out a form or direct users through each step of a procedure, much like a wizard. (These are also known as "navigational guides.") Interactive guides can be implemented in BMC Remedy User, but not in the web client. It sounded like Interactive ALGs might be useful for helping a user fill out a big form. But what I am hearing is maybe all of these tasks should be seperate forms-- "more modular". But unless I can present all of these modular forms as one big form or a series of steps in a wizard I do not think it will meet the requirements (based on the existing form). What about a parent/child relationship? The new/existing employee information being the parent form, and the tasks all being child forms listed in a table (using a ConsolidatedList form to collect all the children)? Buttons on the Parent form could open the task forms in a new window and then refresh the consolidated table on submit... Sadly I will probably keep the form more similar to the existing form to keep it "the same" as we migrate from the old system. But in the future when we want to allow "Self-service" it would be nice to present an existing user with just the small form to fill out (for instance, I need a new computer)-- but reuse that same form as part of the "new employee setup" which would be a collection of all these small forms tied together somehow. Any other suggestions are welcome! Thanks much! Brien On Wed, Nov 19, 2008 at 5:03 PM, Joe DeSouza <[EMAIL PROTECTED]> wrote: > ** > Correction to your statement: Active Link Guides DO work fine on the > web/mid-tier.. > > Wherever you got that from you got wrong information. I think the only A L > related action that isn't supported on the web as of the latest release is > the Macro option and to a certain action the Run Process action if there is > no supported java process to run that is equivalent to the process you run > from the regular WUT client. > > That being said some of the older macros from pre version 4.5, can be > converted to native ARS actions using the convert functionality built into > the admin tool, such as the actions that might have been defined for opening > another form wherein pre version 4.5 was only possible through a macro. > > Joe > > ------------------------------ > *From:* Phil Murnane <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Wednesday, November 19, 2008 5:25:49 PM > *Subject:* Re: employee setup form best practices? > > ** Brien: > > You're right in that a Change Field action cannot make a field become > Required. I think the "no Active Link Guides in Mid-Tier" is an old > limitation, though; and shouldn't affect you with ARS 7.1. > > It sounds like maybe you're mixing a couple of different topics: > > 1. Data Integrity -- many people find it's best practice to use only > Filters for data integrity checking. That being said, there is some benefit > to doing basic checking in Active Links when your application will be run > through a browser, in that the end user will see better performance. Active > Links can also make the uesr experience better by providing visual clues > (eg, in the case of multiple validation failures, changing all failed fields > to red labels). Filters will always enforce data integrity rules regardless > of what kind of client is talking to ARS (not all clients understand Active > Links). Setting fields as Required is a nice convenience, but I've worked > on applications where the development guidelines state not to use the > Required attribute in order to prevent failed DSO transfers or for other > considerations. > > 2. Presentation -- I'd suggest a more modular approach to your > application. Regardless of whether the end user is entering a new employee > or updating an old one, all the same rules generally apply. So why not use > the same screen (form/view) for data gathering regardless of the operation > being performed? Most data entry screens are accessed from a control panel > of some sort, so have the end user choose new/edit from the control panel; > then the system will present the data entry screen, which always looks the > same. The basic idea is to separate the control panel type of functions > from the data entry functions. Alternatively you could have two different > forms ("New Employee" & "Update Employee"), but that increases complexity of > the application and can lead to an overall increase in cost of ownership > (maintenance, performance, etc). Yet another approach can be used when the > data entry screens start getting too complex/crowded, and that is to use > dialogs to build "wizard" type functionality into the application -- BMC > uses this approach extensively in their complex ITSM forms. > > Just Some Thoughts, > --Phil (another Arizonan) > > ------------------------------ > *From:* Brien Dieterle <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Wednesday, November 19, 2008 2:44:22 PM > *Subject:* employee setup form best practices? > > ** I'm building a custom form to handle changes for new/existing > employees-- things like account creation, email setup, shared group folder > permissions, new computer setup, office phone setup, furniture and even name > changes. I am duplicating an existing form from a different system that did > all of this on one form using dynamic html to hide and show fields as > selections are made. > > I was wondering if anyone had any suggestions as to how to handle a big > form like this, or if this is the wrong approach entirely (should it be > split up into smaller forms?). My first problem is that the form starts > with a basic information gathering: > > Select employee type: New or Existing. > > Now, depending on what you select there are different fields available to > fill out (by hiding/showing different page holder tabs). The pain comes > when certain fields are required only when a certain choice is made. (If > you select "New", well, you better provide a first and last name, right?) > It doesn't seem like you can change a field to be required on-the-fly using > "change fields" (is that correct?). So I am left with leaving them blank > and using filters to check the required fields, or using activelinks to set > the unneeded "required" field to bogus values like "N/A". > > Not a pretty picture. My gut says when something is difficult it is > probably wrong. Active Links Guides look like an idea but this needs to be > web-based (ALGs don't work on web?). > > Thanks for any tips! > > ARS 7.1 patch 003 > MS-SQL > Tomcat > > Brien > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
