Document
B a c k 





PRELIMINARY REPORT I:

ORAL TEXT LEARNING

Client:

Tuesday, January 23, 2001



  • Team Members:
  • Karen Parker:
  • Producer
  • Brianne Roth:
  • Administrator
  • Sean Rielly:
  • Director
  • Jason Howell:
  • Librarian
  • Sam Adu:
  • Quality Assurance/Tester


  • Overall Goal(s)
      Our goal as a team is to develop a stand-alone application to serve as a relay of information between an instructor and an editor. Our application will guide an instructor step by step to produce the needed files to generate a new lesson within the Foreign Language departmentís Oral Text Learning WEB site. The user will need to supply the editor with the following materials: a text file containing the native and English versions of the media, a displayable graphic, the audio or video source file, instructions, and copyright information. Our application will bundle these files in their appropriate format and store them in a temporary location until the editor can use these files to create a new lesson on the WEB site (www.unc.edu/FLRC).


  • Product Features
    • Required:
      • Simple, user-friendly GUI
      • Updateable
      • Behind the scene naming conventions
      • File transfer
      • Audio/video conversions
      • Ease of getting information from teacher to editor
      • Recommendations
      • Error checking
    • Fantasy:
      • Create vs. modify
      • Administrator menu
      • Security prompts
      • Email status to editor
      • Graphics preview


  • Interface ideas/thoughts (sketch)
    • The interface will be a simple as possible and user-friendly.
    • The overall design will contain a series of screens with directions and a next and back button.
    • The user will complete the tasks demanded on each screen and will then click next to move on to the next screen and the next task until all tasks have been completed.


  • Package Options
    • Plan A:
      • Include all features listed above.
    • Plan B:
      • Include all required features and some fantasy features such as the administrator menu and the create vs. modify menu.
    • Plan C:
      • Include only the required features.
    • Plan D:
      • Start stripping away some of the less important required features.


  • Critical Path
    • Plan A (all features):
      • Show stoppers in general
        • Learning time
        • Audio/Video conversions
        • Database support
        • Materials
      • Things to learn (assign)
        • GUI library
        • Audio/Video conversions
        • Databases
        • Email scripts
        • Security
      • Things to get/procure (assign)
        • Security
        • Audio/Video conversion library
        • Email scripts
        • Security scripts
      • Things to understand
        • Input vs. output


    • Plan B (all required features and some fantasy features):
      • Show stoppers in general
        • Learning time
        • Audio/Video conversions
        • Database support
        • Materials
      • Things to learn (assign)
        • GUI library
        • Audio/Video conversions
        • Databases
      • Things to get/procure (assign)
        • GUI library
        • Audio/Video conversion library
        • Email scripts
        • Security scripts
      • Things to understand
        • Input vs. output


    • Plan C (only required features):
      • Show stoppers in general
        • Learning time
        • Audio/Video conversions
        • Database support
        • Materials
      • Things to learn (assign)
        • GUI library
        • Audio/Video conversions
      • Things to get/procure (assign)
        • GUI library
        • Audio/Video conversion library
      • Things to understand
        • Input vs. output


    • Plan D (minimize required features):
      • Show stoppers in general
        • Learning time
        • Materials
      • Things to learn (assign)
        • GUI library
      • Things to get/procure (assign)
        • GUI library
      • Things to understand
        • Input vs. output


  • Fall-Back Options/Notes for CP Items
    • Fallback options are to reduce the number of features in our product. Some required features may have to be eliminated due to difficulty such as audio/video conversion. If this problem should arise, our application will require that the user supply the application with the correct format of media or some other format that will later be converted by the editor.


  • Schedules
    • The team will meet alone on Tuesdays at ~4:45-5pm. Occasionally there might be a meeting on Thursdays as well.
    • The team will meet with our client on Mondays at ~3pm in Dey Hall 103. These meetings should occur roughly bi-weekly (at a minimum) or more frequently as needed.
    • A preliminary schedule is as follows:
      • Learn GUI library and start implementing a simple user interface based on this GUI library.
      • Start developing the code for the text file and graphic file submission from the user to a temporary storage facility.
      • Begin testing and writing user manuals.
      • Learn about audio/video conversions.
      • Start developing the code for audio/video conversions.
      • Merge code together and continue testing and documentation.
B a c k