January 2010


Options: Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
multipart/alternative; boundary=000e0cd138227c7dae047dc74492
UofMN CSS Web Development <[log in to unmask]>
Santiago Fernandez-Gimenez <[log in to unmask]>
Fri, 22 Jan 2010 15:11:47 -0600
UofMN CSS Web Development <[log in to unmask]>
text/plain (6 kB) , text/html (9 kB)
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]> 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?
> Zach
> 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" application
>>      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]>. We have tons of documentation if you
>> want to hear more.
>> Sorry I missed the meeting. Sounds very interesting!
>> Santiago
>> --
>> 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]>
>> 612-625-6423
>> On Fri, Jan 22, 2010 at 7:26 AM, Peter Wiringa <[log in to unmask] <mailto:
>> [log in to unmask]>> wrote:
>>    Here are a few notes from my end and some questions for the group.
>>    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 audience?
>>    For those of you using a tool to help generate forms and client-side
>>    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).
>>    http://www.webformfactory.com/
>>    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.
>>    http://ur-test.umn.edu/pete/cssdev/ldap-returns.html
>>    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 HTTPS,
>>    get their cookieauth cookie, run it up against the central auth hub
>>    to get their Internet ID, and then query that. Are there different
>>    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
>>    http://www1.umn.edu/is/cookieauth/
>>    Accessible anti-spam techniques
>>    http://webaim.org/blog/spam_free_accessible_forms/
>>    Good read on validation
>> http://www.smashingmagazine.com/2009/07/07/web-form-validation-best-practices-and-tutorials/
>>    --    Peter Wiringa
>>    Electronic Communications
>>    University Relations
>>    University of Minnesota
>>    (612) 625-3252
>>    [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
> http://www.sua.umn.edu/

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

[log in to unmask]