Things to be added to AppTrac

General:
- Possibly store user images and application icons on ftp or on a central computer (where the database resides).
- Put double slashes in application paths or read paths and add them on the fly if necessary.
- Database path, login and password should be stored in registry or config file, and read from there on launch.
- Log users out automatically after configurable inactivity period (stored in registry or config file) with an audiovisual message like “Are you still there?” dialog box and voice file.

Database:
- Get rid of application access field?
- Should user_active in apptracuser be nullable?
- Add some sample URLs to apptracapplication table.
- Ideally, the table should only store the URLs, and AppTrac should pick the default browser to launch them.

Exceptions:
- Get rid of any remaining dummy exceptions.
- Make sure all exceptions have messages.

Reports:
- Add Student Users Report: a list of all registered students, including ID, name and contact information.
- Add Student Activity Report: A list of all active students and a summary of their activity for a given time period.
- Add Application Utilization Report: Summary of overall time spent broken down by application.
- Add ability to send queries to database and display reports in lower pane (possibly replace lower pane with a table).
- Add abilities to save queries and reports.

Interface:
- AppTrac must remain in the front at all times (over Windows taskbar).
- When new application is launched, it should always be on top of AppTrac.
- Remove AppTrac from application selection and control lists.
- Exit button should only be available to admins after they login.
- When a list is shown, have first element selected by default.
- Remove “jdbc:mysql://” from connection string in database login screen.
- Make Password text box in database login screen a true password box (characters should appear as dots).
- Add checkbox to remember database password.
- Add checkbox to start with Windows.
- Display a list of available queries in ReportGeneratorGUI.
- Remove text area from ApplicationControlGUI.
- Add Browse button to ApplicationControlGUI to browse for application path (filter executables).
- Make Zip and State text boxes shorter and City longer in UserControlGUI.
- Add dropdown box for user_active field in UserControlGUI.
- Phones and zip code in UserControlGUI must have leading zeroes.
- When a field is blank in UserControlGUI, display empty field instead of a zero (possibly treat them as strings in the application and possibly in the database).
- Password text box should not appear in LoginScreenGUI by default (when no user is selected).
- Add dynamic search to LoginScreenGUI and UserControlGUI.
- Add avatars to user selection boxes in LoginScreenGUI and UserControlGUI.
- Add application icons to application selection boxes in ApplicationSelectorGUI and ApplicationControlGUI.
- Interface should adapt to resolution more easily, especially UserControlGUI.
- Expand controls to take up more space in some screens.
- Admin interface should be windowed and not full screen.
- Decrease font size, especially in admin interfaces.
- Log Off button should be in same absolute location on each screen.
- Database login screen should be same as other screens in its layout.
- Maybe use a different, more variable resolution-friendly layout.
- Add special key blocking.
- Add status bar and display various status messages there.

Check back often and expect this list to change.

Database MVC

When finish with all the code, ill add a Database MVC.  This will consist of database options.  Now that i think of it, we may want to consider saving some of the information in a .txt or a binary files.  This information that will be stored will be the database information (server name, default user name and passcode, etc…), this way when the admin has to change the database information, he/she could go through the gui, change its settings, it would be stored in a binary file, so when app trac loads it automatically loads the changed data base settings.  We may also want to consider duality (connecting to two databases at once, one on the local machine, the next on the server), this way if the network connection from a client/server breaks, the database on the computer will still keep track of the user’s data, but when the connection breaks, a “sql logger” can be loaded, store all quries, so when reconnectivity happens again, it will “update” the server database.  This is out of our scope currently, but definately something to consider in the longrun if time permits.

 

Myles

Notes Ideas And Requirements 1.4 Update

This is the document that contains the content of the first three documents, outlining our notes, ideas and requirements (basically, bits and pieces of information pertaining to this project). Additionally, this document contains notes from our meeting with the client after class on 03/06/08.

Notes Ideas And Requirements 1.4 Sklutovsky

Use Cases -> Classes,Sequence Diagrams

Im going to start the Use Cases conversion to the Classes. After I will do the Sequence Diagrams for them. Should have them done by tonight (Hopefully) And well discuss them over tommorrow’s meeting. Ill also start the presentation. I think all we really need to just do here is present out diagrams, so when i finish them ill get them into you guys.

RE: Reports and Other Screenshots

Then Khaiim added the following:

Administrator can change all data, add all types of users, and change all settings.

Staff can change all data, add student and volunteer users, and not change settings.

Volunteers can add student users (not delete), View some data, and add some data (not delete).

Ideally, the Administrator is able to choose which groups can view, and change, and add to each field (as well as add new fields).

RE: Reports and Other Screenshots

Trishan responded to my question about permission levels with the following:

Between staff and volunteer, it’s a way of differentiating between a volunteer and a full time staff member at LVGH. In terms of permissions a volunteer wouldn’t have access to more sensitive information about a student such as social security number etc, while a staff member would. The administrator has authorization to do anything including adding/removing users, changing program settings etc…

Reports and Other Screenshots

This is the content of the e-mail from Khaiim, dated 02/21/08, which was forwarded by Trishan to team leaders. Regarding the three worker permission levels (read below), I e-miled a clarification request to Trishan. The 11 attachments are reports and various other screenshots.

Hi Trishan, this includes 2 reports that are complex, so 4 reports could be extrapolated from them.

Also included are screenshots of all the relevant Student keys.

Also included are all the fields that the LACES Database has, just to get an idea of the scope, but again, we are not concerned with most of this data, at least right now.

Major thoughts on requirements after reviewing with staff yesterday and today:

We need to know if a student is in the lab with a group, or not. One of the reasons is that attendance is taken in the classes, and we cannot count their hours twice (“double-dip”), especially when reporting to funding sources. We DO need to capture the hours, but we need to make sure we are not reporting class hours in the lab, as if they are non-class hours.

We need to track the program used (lexia, eurotalk, firefox), at the least, and at the most the activity/title within the program, as well as the scores (vowels level 1 unit 5 80%, gmail.com, funbrain.com “grammar gorillas”). We would like to track multiple activities in one session, which was not feasible before (if a student spends 10 minutes on email, then 20 on lexia, and 30 on ellis).

Related to the first issue above, we need to switch from “group” to “individual” hours if a student was in the lab with a teacher from 10 to 12, but remains in the lab after class.

We need to have a way to automatically log off, or force user to confirm info after a (changeable) set number of minutes. For example are you [name]? still with a group? Administrators should also have the option to set a time at which all users are logged off (for example 9 pm), and an optional time at which computers are reset or shut down.

There should be 4 different levels of permission: Student, Volunteer, Staff, Administrator 

The best model for the type of data that will be most useful to us is the laces screenshot “LacesGroupHours”, except that Type, would be more like Program name, and there would be more fields as described above. 

Will send another email soon.

Attachments (11):

Another App-Trac mockup

Here is a mock up created of the “Kiosk-mode” splash screen. More mock up’s will be created in the future. This mock up features a list of the user names currently in the system. When a user name is selected, their person image is displayed on the left hand side. Upon verification that this image is the one they picked for their login, they can proceed to log in via the button below the image. In the bottom right hand corner is a “lock” to be used for admin access only. The idea of the lock is to always have immediate access at any kiosk rather then logging in as admin from another computer. This idea may not be the route to take but will be taken into further consideration at a later time.

Notes Ideas And Requirements 1.3 Update

This is the document that contains the content of the first two documents, outlining our notes, ideas and requirements (basically, bits and pieces of information pertaining to this project).

Notes Ideas And Requirements 1.3 Sklutovsky

Use Case Scenarios

Below are the three Use Case Scenario’s that D3 came up with. They will be incorporated into the SRS revision.

Use Case Scenario 1: New User Arrives

1. Users comes in
2. User asks volunteer where to begin
3. Volunteer creates new account
4. Central DB is updated
5. User logs into App-Trac
6. Central DB is updated
7. User accesses an application
8. User quits the application
9. Repeat Steps 7-9 or Proceed to Step 11
10. User logs out of App-Trac
11. Central DB is updated

 

Use Case Scenario 2: Existing User Arrives

1. Users comes in
2. User logs into App-Trac
3. Central DB is updated
4. User accesses an application
5. User quits the application
6. Central DB is updated
7. Repeat Steps 4-6 or Proceed to Step 8
8. User logs out of App-Trac
9. Central DB is updated

 

Use Case Scenario 3: Administrator Adds Application

1. Administrator logs onto App-Trac
2. Administrator goes to Add/Remove Application Section of App-Trac
3. Administrator chooses the program(s) he/she wishes to Add
4. Repeat 3 and 4 until done choosing applications to add
5. Administrator logs out of App-Trac.

Word Document: UseCaseScenarios 1.0 Padilla