Duh! Good call.
Here is the vendor's website:

All the user group documentation is on a Google site (pre um google conversion,) so it's a little obfuscated, but we are happy to share more info if folks are interested.


On Fri, Jan 22, 2010 at 3:18 PM, Zachary Johnson <[log in to unmask]> wrote:
Maybe I missed it... but does this product have any screencasts or demos or tours online?

Santiago Fernandez-Gimenez wrote:
Yes, those concerns are always credible, and we've worked around some concerns, especially related to validation.  WFG itself has pretty hokey, non-accessible validation built in.  But we experimented with it and discovered we could do pretty much whatever we wanted with the form code, so we could use Javascript validation, .net validation, or we could build something server-side.
There are definitely trade-offs, as with any development tool.  For example we want to redirect a user to a One Stop page upon submission ( "Thanks for submitting the form, and here are the expectations of when your appeal will be resolved.")  When we add the redirect out of the WFG system, the whole form gets wrapped in a frame. Yuck. We complained to the vendor on that one. That's certainly not ideal, but on the whole, we've found we have pretty direct access to the markup.  

On Fri, Jan 22, 2010 at 12:33 PM, Zachary Johnson <[log in to unmask] <mailto:[log in to unmask]>> wrote:

   Sounds pretty interesting.  When I hear "pre-existing .net tool" my
   experience immediately makes me wonder about customizing form
   markup, validation, error states, javascript hooks, etc.  Often it
   seems to be the case that you get point-and-click DW routing or
   whatever at the expense of form usability and accessibility that
   looks like it was hacked together in 2001.  Any credibility to my
   concerns with this particular solution?


   Santiago Fernandez-Gimenez wrote:

       Regarding the pre-populating of form data:

       One Stop has tons of paper / pdf forms that need automation.
       Most of them include sensitive information. After a pretty
       detailed analysis Academic Support Resources determined that the
       type of software we needed to solve the "forms" quandary was
       generically called "workflow" software— automating the form is
       fairly trivial, but routing the data and doing the work was
       difficult to solve securely. The Graduate School and Disability
       Services, with a SPIF grant, had purchased a tool called
       "Workflow Gen", and after comparing it with some business
       criteria, we determined it was worth giving it a try, so we've
       been piloting it this year.  It is not an "Enterprise" tool at
       this time, so each unit that participates is sharing the costs.

       WorkflowGen provides a web-based process management interface
       that plugs into a .net form.  You have to build the .net form in
       Visual Studio, so hold your nose if you're a MS hater. MS
       antipathy aside, we have found that the tool is pretty efficient
       and opens the door to real service and process improvement.
          * Form authentication is via the CAH hub.
          * We are pre-populating the forms with appropriate data from
       the DW,
            providing students the opportunity to vett their PeopleSoft
            information, and linking to the "personal information"
            if they see something out of date.    * We can pull in data
       from the DW that is not visible on the form,
            and use that for routing logic.    * Someone with a
       "business analyst" skill-set can plot out the
            routing of a form with conditional logic and notifications
       via a
            point and click interface.    * Someone with a
       "junior-developer" skill-set can build the form in
            .net and template the email responses.          There is a collaborative consortium / user group on campus
       funding and using this tool, but based on our brief pilot
       experience, we are advocating for this tool, or some sort of
       generic workflow tool like it, to be adopted as a common good
       for the enterprise.

       If you want to find out more about the tool, send an email to
       our User Group listserve:  [log in to unmask]
       <mailto:[log in to unmask]>
       <mailto:[log in to unmask]
       <mailto:[log in to unmask]>>. We have tons of
       documentation if you want to hear more.

       Sorry I missed the meeting. Sounds very interesting!


       --        Santiago Fernández-Giménez
       information architect / web project manager
       Academic Support Resources
       University of Minnesota - Twin Cities

       [log in to unmask] <mailto:[log in to unmask]>
       <mailto:[log in to unmask] <mailto:[log in to unmask]>>


       On Fri, Jan 22, 2010 at 7:26 AM, Peter Wiringa <[log in to unmask]
       <mailto:[log in to unmask]> <mailto:[log in to unmask]

       <mailto:[log in to unmask]>>> wrote:

          Here are a few notes from my end and some questions for the

          It sounded liked there was interest in a central repository
       of form
          information and including some basic form styles and elements
       in the
          templates would be useful. A general feedback form seems like
       a good
          starting point. What other types of form or multi-element
       form parts
          (i.e. EFS) might be good to include and would serve a broad

          For those of you using a tool to help generate forms and
          or server-side validation, what tools are you using? Web Form
          Factory may be generating again and provides a solid start for
          simple forms, as a I recall (PHP only).


          On utilizing central authentication and LDAP to improve the UX of
          form by pre-populating info, it doesn't seem like we landed on
          anything with regard to security considerations. If someone is
          signed in, and would be forced to sign in if they weren't,
       what are
          the issues with pre-populating fields using information about the
          user that's publicly available in LDAP? Here's an example of what
          might be returned.


          Anyone from OIT Security on the list who can shed some light
       on this?

          As Chris suggested, you could attempt to pre-populate fields for
          logged in users, but not requiring people to login. Switch to
          get their cookieauth cookie, run it up against the central
       auth hub
          to get their Internet ID, and then query that. Are there
          security implications for pre-populating fields in this case?

          Of course, directory-suppressed students won't be found in public
          searches of LDAP.

          Central auth info

          Accessible anti-spam techniques

          Good read on validation

          --    Peter Wiringa
          Electronic Communications
          University Relations
          University of Minnesota
          (612) 625-3252
          [log in to unmask] <mailto:[log in to unmask]>
       <mailto:[log in to unmask] <mailto:[log in to unmask]>>

          "I gotta hold on to my angst. I preserve it because I need it. It
          keeps me sharp, on the edge, where I gotta be." - V. Hanna

   --    ______________________________
   Zachary Johnson * Web Manager
   Student Unions & Activities
   (612) 624 - 7270

Santiago Fernández-Giménez
information architect / web project manager
Academic Support Resources
University of Minnesota - Twin Cities

[log in to unmask] <mailto:[log in to unmask]>

Zachary Johnson * Web Manager
Student Unions & Activities
(612) 624 - 7270

Santiago Fernández-Giménez
information architect / web project manager
Academic Support Resources
University of Minnesota - Twin Cities

[log in to unmask]