Difference: ApplicationProcessorRequirements (2 vs. 3)

Revision 32008-11-03 - KatieHuber

Line: 1 to 1
META TOPICPARENT name="ApplicationProcessor"

Requirements for Application Processor

  1. Core logic should be reusable for any number of individual activities; setting up a new activity should only require a modest amount of code-writing.
  2. Appearance should be somewhat customizable for each activity; there should be a choice of colors, logos, and decorative stuff. The overall layout does not need to be heavily customizable.
  3. The system needs to handle more input than can comfortably fit on one page.
    1. We could do multiple pages, but expandable drop-downs would be nicer.
    2. We do need to make sure that the applicant can save input a little at a time.
  4. There needs to be some sort of username/password setup so people can save their work and continue it at a later time.
    1. Password recovery should be provided.
  5. File attachments should be supported. Deleting them should also be supported.
  6. There should be a way for an applicant to mark an application as "abandoned" if they have decided not to apply after starting work.
  7. Reviewers should be able to:
    1. View an application on-screen
    2. Print an application in a compact, easily-read format
    3. Export application information to a spreadsheet or database
  8. Allow reviewers to add information to an application in special fields that would not be seen by applicants
  9. Provide links to information pages (open in another window?)
  10. Ready for full use for SMI and REU in November 2008
  11. Possible test use for conferences in September/October 2008
  12. Something to show by mid-August 2008

Update Aug 29 2008

We have definitely missed the "something to show by mid-August" plan. I propose we try to have the person's record part (name, contact info, password mgmt etc) done in September. A person's record should be linkable to any number of activities so the same person doesn't have to re-enter all that stuff for every conference.

The next step after that would be a template for readily creating a conference, which should not require a lot of data beyond the person's info.


Update Nov 3 2008

Notes from meetings with Bill and Mikki:
  1. Anonymous conference registration
    1. email address only
    2. one time login
  2. Confusion about the term Submit
  3. Somehow mark/warn users about required fields that need to be filled in
  4. Do not allow final submission until all fields deemed required are filled in
  5. "Save and Continue" buttons in addition to "save" button
  6. Give users option to "Report an Error" after application has been submitted
  7. Option to "Abandon" or "Withdraw" both active and submitted applications
  8. Number the pieces of the application
  9. Logout button

 -- SteveGaarder - 24 Jun 2008
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.