Recently in Software Development Category

Staff Database - Staff Expertise/Experience Tracking

| No Comments
Meeting Minutes from 4/5/2011 - 

Attendees: Eric Kroetsch, Mary Katherine O'Brien, Molly Portz, Myself

Purpose: Eric and Mary Katherine are leading the Staff Expertise and Research deliverable team with the mission "To explore existing staff expertise and research strengths". Eric contacted me when Gayle had mentioned we in Dean's Office/Dean's Office IT have been working on the GPS Alliance staff database. The deliverable team has developed a survey to administer to GPS Alliance staff and didn't want to duplicate effort if we were going to be surveying for similar information for staff expertise/experience in the staff database. GOOD CALL!

Question: What problem are we trying to solve?
  • Collect and share staff expertise in areas of research, work/education, and job function, allowing for formal and informal synergies to develop across all GPS Alliance units.
  • Collect and share relationships with students, staff, faculty, administration around the University. Define in general terms what that relationship is - what GPS Alliance initiative, project, interest to which it may pertain.

A word about collecting data...

While defining the requirements/specifics of this initiative, all involved in the project need to continually ask themselves "How will the data get used?"

It can be attractive to gather data because it is interesting, but to be fair to the people being asked to provide the data, the people asked to manage the data, the people asked to support the mechanisms that hold the data, etc., there should be defined, active purposes for the data collected.

"We might use it sometime" is not a good rationale. It can be added later if that is the case.


Staff expertise area - not a snapshot, but an ongoing system for displaying growing expertise.  Harness the collective research capacity (Molly).

Research Expertise > Work/Education Expertise > Job Function Expertise

How do each of us touch others at the University?  Relationship tracking with faculty, staff, students, and in what ways?  how we communicate with them?  how often do we meet with them?

Bios - explanation of experience, life, etc. (new staff focus?)

Educational Experience

Language Experience

Global Experience

Work Experience





How do we organize the data in main areas and what goes underneath?
Do the main areas coincide with central themes, pillars?

Basic Bio/Demo
Emergency Contact
Emergency Procedures (contact tree, any automation around emergency situations/scenarios)

Use Strategic Plan Deliverable team survey as a pilot?

After the meeting, Molly and I brainstormed a bit about what a page might look like in the Staff database that would be used for displaying staff expertise/experience information.


Example scenarios of use of "Who do you interact with?"

- Molly gets an inquiry from a faculty member or another institution about who works with faculty on custom programs

- Brook says "I interact with students in the same way Beth Insensee does - she with international students, I with domestic.  Why don't we do it together?"  This can be self-determined by staff in GPS Alliance if they have the information to connect with each other.

Adobe Saveable Forms

| No Comments
Generating saveable forms that can be emailed once completed by the constituent and either stored by GPS Alliance or forwarded on to a central unit for processing.

The latter includes many financial forms.

  • Traditional non-saveable forms that are written on and faxed back to GPS Alliance or directly to central unit.
  • Web form that sends form contents in an email to a pre-determined email address. 
  • Web form that connects to database, which stores information for processing and manipulation
  • Saveable PDF that will allow forms to be saved by the constituent and emailed to GPS Alliance or central unit (500 extractions - any usage of the data - allowed)
  • Workflow software (currently GPS Alliance is involved in the Workflow Consortium using WorkflowGen) which takes much more work than Adobe products, but allows for web forms to be built, backed by a database, integrated UofM authentication, and routing for all appropriate parties to the form process.

Adobe Licensing for Saveable forms:

15.12 Acrobat Pro and Acrobat Pro Extended Feature. 15.12.1 Definitions. "Deploy" means to deliver or otherwise make available, directly or indirectly, by any means, an Extended Document to one or more recipients. "Extended Document" means a Portable Document Format file manipulated by Acrobat Pro or Acrobat Pro Extended Software to enable the ability to locally save documents with filled-in PDF forms.
15.12.2 If the Software includes Acrobat Pro or Acrobat Pro Extended, the Software includes enabling technology that allows you to enable PDF documents with certain features through the use of a digital credential located within the Software ("Key"). You agree not to access, attempt to access, control, disable, remove, use or distribute the Key for any purpose.
15.12.3 For any unique Extended Document, you may only either (a) Deploy such Extended Document to an unlimited number of unique recipients but shall not extract information from more than five hundred (500) unique instances of such Extended Document or any hardcopy representation of such Extended Document containing filled form fields; or (b) Deploy such Extended Document to no more than five hundred (500) unique recipients without limits on the number of times you may extract information from such Extended Document returned to you filled-in by such Recipients. Notwithstanding anything herein to the contrary, obtaining additional licenses to use Acrobat Pro or Acrobat Pro Extended shall not increase the foregoing limits (that is, the foregoing limits are the aggregate total limits regardless of how many additional licenses to use Acrobat Pro or Acrobat Pro Extended you may have obtained).

Explanation: (from in August 2010)

Standard allows you to create forms but only other Acrobat users can fill them in and save the data, and if your users are all working in Acrobat, there are no limits on how many responses you can process.

If you're using Acrobat Pro and are using Reader-extended forms, then to be specific there are (and can be) no limits on the actions of the [/u]user[u] as they're not bound by the Acrobat EULA. An unlimited number of people can open and fill in the form, and an unlimited number of them can submit the data back to you.

[b]However[/b] if the recipient list exceeds 500 people, you are only permitted to extract information from 500 of those replies. If there are less than 500 recipients in total (and you must of course know this in advance) they can each keep sending you the same form data over and over again, which means you could end up with thousands of extracted datasets.

In the context of Acrobat, "extract" means either to reload the FDF data into Acrobat to see the fields populated in your copy of the PDF, or to take the data directly and use them without Acrobat (including human or machine reading of printouts, faxes, etc). Anything whereby you get access to what they typed in the fields.

Remember that this is a per-document limit; so if you send out ten different surveys, you could process responses from 5000 users in total (some of whom can overlap) - which is the typical way people will handle things like a PDF form on a website (when your 500th user emails in their data, delete it, upload a new form and start again from zero).

We know the wording of 15.12 is ambiguous, so there is opportunity for interpretation; however to work beyond the 15.12.3 limits on a unique document you would need to purchase the server-based Adobe LiveCycle product.

Meeting with Rick Huebsch - Minutes/Notes

| No Comments
Some quick notes (mostly so I remember what we discussed).

We discussed 3 projects:

1.  Resource Library -- software based "check out" system for managing various resources.  Database + Filemaker software front end.  Useful for anyone that has resources to check out.  Could be shrink-wrapped with brief manual for do-it-yourself installation and configuration.

***(Christopher Stordalen edits):  This solution has PHP front-end with FileMaker database backend.  Administration interface is in FileMaker and web front-end is strictly public facing

2.  Incident Database -- special purpose incident database with communication, incident tracking, secure login, reporting, and a few other features.  Filemaker, PHP front-end, client-server DB architecture currently.  Not as general purpose but higher value for those that need it.  "Risk" in hosting (SaaS model) at UMN for others due to HR/Privacy security issues.  Value in software + consulting.

***(Christopher Stordalen edits):  This solution is currently FileMaker database only.  The desire is to build a PHP front-end.  Administration interface is yet to be determined whether it will be web-based or Filemaker-based or a bit of both.

3.  Student-case-tracking shadow database for Study Abroad programs -- process/lifecycle and DB layout and reporting for managing a Study Abroad program, where central HR/Accounting systems (PeopleSoft, etc) are not customized for the Study Abroad program.  

For each of the 3 projects, we need to:

A.  describe both a "full commercialization" and "light commercialization" model

B.  do some quantification of the income opportunity:  X possible customers, Y% market share (5%), and Z price.

C.  determine costs -- both one-time and recurring -- for supporting a given commercialization model

Once we have this data in hand (and feel free to email/call me anytime along the way if you have questions), we can together determine the best path to get this technology into the customer's hands.

About this Archive

This page is an archive of recent entries in the Software Development category.

Project Management is the previous category.

Software Sales is the next category.

Find recent content on the main index or look in the archives to find all content.