Team D3 Teacher Support Software (TSS)

1. Team D3Teacher Support Software (TSS) Brad Johnson (DEN- Los Angeles), ID: 9876 Joe Vahabzadeh (DEN- Los Angeles), ID: 0157

2. Topic Description TSS is a software application which provides elementary teachers a tool to enter organize and store important student information as well as lesson plans and substitute teacher plans. Student information managed by this software system includes student personal information, grades, attendance and behavior. This important information can be utilized in parent/teacher conferences, report cards and teacher process improvement considerations. The simple user interface allows the teacher with an easy and time-saving means of inputting, maintaining and referencing important information. This application will allow the teacher summary data for particular students, categories (i.e. mathematics) and sub-categories (i.e. adding/subtracting).

3. Topic Description (Cont.) This application has been identified as a needed tool by a current 2nd grade elementary school teacher. Presently, teachers at her particular school rely on separate software systems (i.e. one grading, one attendance, etc.) or hand-written documents to manage this data. A new software system that integrates and stores all this important data is needed and it is assumed that teachers will be motivated and interested to use a tool that makes their jobs easier. It is hard for an engineer to believe, but currently most teachers at this particular school hand average the student grades. This practice is both time consuming and subject to user error. Development of this software system will provide teachers with a single application that allows them access to a wide range of useful information via a simple, easy to use and learn user interface.

4. System Requirements • The following system requirements have been identified for the TSS Software System

5. System Requirements (Cont.)

6. System Requirements (Cont.)

7. System Requirements (Cont.)

8. System Requirements (Cont.)

9. System Requirements (Cont.)

10. System Requirements (Cont.)

11. System Requirements (Cont.)

12. System Requirements (Cont.)

13. Navigation Map

14. User Profile

15. User Profile (Cont.)

16. User Profile (Cont.)

17. User Profile (Cont.)

18. Dialogue/Interaction Style User Psychology: **Note: The ORANGE Shaded Boxes with the Bolded Text represent our selections for the FIRST PASS **Note: The GREEN Shaded Boxes with the Bolded Text represent our selections for the SECOND PASS.

19. Dialogue/Interaction Style (Cont.) Knowledge & Experience:

20. Dialogue/Interaction Style (Cont.) Task Characteristics:

21. Dialogue/Interaction Style (Cont.) TOTALS The following table represents the results for each of the dialogue styles after the Second Pass was performed. SUMMARY Based on the analysis from the Matrices, the Menu and Fill-In Forms were the most applicable dialogue styles for our user and system interaction. Our team agrees with these results and we feel confident that implementing these types of dialogue styles in our system will be most appropriate for the type of user that will be using the system. Our team’s current direction will be to use a combination of Menu and Fill-In Form dialogue styles. Most of the system can be navigated via a Menu driven GUI, this will make things very easy for the user to navigate. It is also an efficient way to navigate through the system, so the user can be more productive than a system which used a Question & Answer Dialogue Style that may not be as efficient. Our system contains several areas where data entry will be needed. It is these areas of data entry as well as some data retrieval that will be handled mostly by the Fill-In Form dialogue style. This will make these areas of the system more user friendly than a system that chose to use a Direct Manipulation dialogue style as an example.

22. Task Analysis

23. Task Analysis (Cont.)

24. Task Analysis (Cont.)

25. Task Analysis (Cont.)

26. Task Analysis (Cont.)

27. Task Analysis (Cont.)

28. I/O Devices • Input Devices • Keyboard • For user entry into form fill-in fields • Mouse • For user selection of menu buttons and non-text entry fields • Output Devices • Monitor • For teacher to view system processing and selection options • Why • The following I/O devices have been selected because the intended environment for this software system is a typical elementary school classroom. The I/O devices selected are common devices that are found in most California elementary school classrooms.

29. Summary Style Guide • The general layout for displays for the TSS software is the following: Screen Header: Indication of where the user is Icon, student, or teacher Options/ Input Fields/ Output Fields Navigation Buttons

30. Icons/Symbols Used Log-in/New User Screens metaphor for entering the school Teacher tasks: Accessing lesson plans and substitute plans Student tasks: Accessing student personal information, student grade information, student attendance information, student behavior information

31. Colors/Fonts/Other • The TSS utilizes the default Java Swing look-and-feel • All text is black • Backgrounds are gray • The primary colors on the screens are gray, white and black

32. Screen Prototypes: Log-in Screen Note: The following screen was developed by writing and executing Java Swing code

33. Log-in Screen Explanation • Header to indicate current location in the system • Use of front of school graphic to visually indicate entry into a school atmosphere/software program • Required use of username and password for entry, since student data should be private • Allow a new user to create a user name and password for entry into the system • Kind warnings for failed attempts of entry

34. Log-in Screen Explanation (Cont.) Log-in Screen Real Estate Usage

35. New User Note: The following screen was developed by writing and executing Java Swing code

36. New User Screen Explanation • Header to indicate current location in the system • Use of front of school graphic to visually indicate entry into a school atmosphere/software program • Required use of username and password for entry, since student data should be private • Require user to enter password twice in order to assure the user has entered the password correctly • Kind warnings for attempts to use a username that is already in use

37. Screen Prototypes:Main Screen Note: The following screen was developed by writing and executing Java Swing code

38. Main Screen Explanation • Navigation via categories in the middle of the screen (2) • Graphics/Illustrations somewhere between 5-15% of the screen. We are slightly above that at around 17%. (2) • Black body text color (2) • White/gray background color (2) • Navigation buttons are easy to understand and user (3) • Added “Take Roll” option as shortcut (will be used daily) to remove need to navigate 2 additional levels Main Screen Real Estate Usage • No Horizontal Scrolling Required (1) • Page length less than 2 pages (less than 1 page) (2) (1) Per J. Neilsen "The Top 10 Mistakes of 2002", (2) Per "Recommended Homepage Design", (3) Per "So Much Better Checklist"

39. Take Roll Note: The following screen was developed by writing and executing Java Swing code

40. Take Roll Explanation • Header to indicate current location in the system • Student icon to indicate that student data is being accessed • Simple interface to allow the teacher to quickly and easily take roll each day • Student’s names ordered alphabetically • Default setting to mark students present to minimize user input needed • Input format specified to decrease user input format errors

41. Student Information Menu Note: The following screen was developed by writing and executing Java Swing code

42. Student Information Screen Explanation Student Info Menu Screen Real Estate Usage • Header to indicate current location in the system • Student icon to indicate that student data is being accessed • Consistent graphics/icon images will also allow a graphic indication of what area of the system the user is currently in • Consistent exit button location (bottom of the screen) • Follows Navigation Map

43. Student Information Screen Explanation (cont.) Student Information Screen • Allow navigation to previous screen Per user analysis and dialogue styles analysis • Utilizing simple interfaces (buttons) to allow user navigation • Using clear descriptions of navigation destinations • Attempting to make system very simple to use and understand

44. Access Student Personal Information Note: The following screen was developed by writing and executing Java Swing code

45. Student Personal Information Explanation • Header to indicate current location in the system • Student icon to indicate that student data is being accessed • Form labels placed immediately next to entry fields to ease input understanding • Input format specified to decrease errors in input format

46. Access Lesson Plans Note: The following screen was developed by writing and executing Java Swing code

47. Lesson Plans Explanation • Header to indicate current location in the system • Teacher desk icon to indicate that teacher data is being accessed • Easy drop-down menu for subject entry • Input format specified to decrease errors in input format

48. Access Substitute Plans Note: The following screen was developed by writing and executing Java Swing code

49. Substitute Plans Explanation • Header to indicate current location in the system • Teacher desk icon to indicate that teacher data is being accessed • Input format specified to decrease errors in input format

50. Comments/Issues/Complaints/Assumptions • Tools Used or Planned to Use • The TSS system will be developed using Java Swing • Fulfills platform independence requirement • Team members have experience in Java programming • Lessons Learned • “Know Thy User” • Many of our uncertainties have been resolved by simply asking our potential end user • Plans for the rest of the semester • Continue work on prototype • Consider use of additional icons • Apply knowledge gained in the class to our project