Student Management Application

Document includes: Phase 1: Propunere Proiect Phase 2: Planul de lucru Phase 3: Descrierea si analiza taskurilor Phase 4: Prototip Phase 5: Scenarii Phase 6: Evaluarea prin parcurgere cognitive Phase 7: Evaluarea euristica Phase 8: Prototip versiunea 2 Phase 9: Evaluare Prototip

1. Project Proposal
1.1. Project Overview
Student Management Application is an easy to use software both by students/parents and school authorities. In most of the current school systems all the activities are done manually, and this is time consuming and costly. The proposed project deals with various activities related to the students. User module Student module Mark management

1.2. Project Goal

In the application one can register as a user and can be of two types, student and administrator. Administrator has the power to add new user and can edit and delete a user. A student can register as user and can add edit and delete his profile. The administrator can add, edit and delete marks for the students. All the users can see their marks. The goal of designing input data is to make entry easy, logical and free from errors, as much possible. The entering data for entry operators need to know the allocated space for each field; field sequence and which must match with that in the source document. The user interface should be as simple as possible, regarding the fact that it is used by various types of users.

1.3 Project description

The SMA will provide user interfaces for: Creating new users and adding them to a database Mark management: add/delete users marks and details; view marks Student registration, and possibility to edit student details Add new subject, delete subject and subject allocation

1.4 Working context

The application will be a desktop application. All users will need a username and a password in order to login. The front-end will be implemented in Java (Netbeans 6.0).

2. Working Plan
2.1 Users
The users which will test and review the application will be X and Y, both from software engineering master.

2.2 Plan
There will be some meetings between me and the users which will review the application. The goals of the user visits will be to capture the requirements for the system interface. There will be several meetings from which a list of features and sketches

will be obtained. Each user will have to provide a feedback for the features he would like to see implemented. In the end, all these features will create the user interface. The meetings will be scheduled as following: 1. 21.04.2012 - Review of the first draft/prototype, use cases feedback, additional suggestions 2. 05.05.2012 - User interface testing, progress review, reports overview 3. 13.05.2012 - Final user interface tests and overall feedback

3. Task Description and Analysis

The tasks that must be accomplished are the following: 1. Login to the application. Using a username and a password will be enough for someone to use the application. Based on the credentials the user will have the corresponding view (administrator view or student view). 2. Create new user and delete specific accounts. As an administrator the application will bring up the possibility to create a new user and will have to specify its type (Student or administrator). In case of the delete feature, the administrator will have to choose from a list, which users want to delete and confirm the command. 3. Student Registration. The system will offer the possibility to add a new student in the system and several inputs will be required. 4. The administrator of the system should be able to edit and add new subjects in the application. Beside this, every student will be evaluated twice a year, and its marks will be added in the application. 5. Each school employee will have the possibility to open several Windows applications directly from the SMA, without closing it. (ex. Open calculator and notepad from SMA).

4. Paper Prototype
This subchapter presents the paper prototype for my student management application, and consists of the sketches on paper of the following screens: Login Page:

Welcome Page for Administrators:

Welcome page for Students:

View for Student Mark List:

View for Student Details:

Create new User View for Administrators:

Add new discipline (subject) for Administrators:

Register New Student:

5. Scenarios
Task 1 User Login 1. The user views the initial Login Page when running the application 2. In the login are he can enter his username and password (credentials) 3. The user clicks login if they are introduced correct or cancel to try again 4. The user will be redirected to the corresponding view according to his/her credentials: administrator view or student view

Task 2 Create new user and delete specific accounts 1. The user performs the steps from Task 1 and the credentials must be for an administrator type 2. The logged administrator goes to Accounts menu and chooses the corresponding action to be performed (New User or Delete User) 3. The application will show the corresponding menu and has to provide the username, password, confirm password and type of the user that wants to be

created. In case of user delete the administrator has to provide the identification id of the user to be deleted and press the Delete button. 4. The user saves the new account in the database by pressing the Save button

Task 3 Student Registration 1. The student must be logged in, perform the steps from Task 1 and provide administrator credentials. 2. The user goes to Student Details Menu and chooses New Registration 3. The user must provide the information for the new student: admission no, phone, sex, age, religion, city 4. The user has the possibility to clear the fields if some input is not correct. 5. The user saves the new student by pressing the Save button.

Task 4 Add new subjects and marks 1. The user must log in by following the steps from Task 1. 2. The user chooses from the menu Options and Add subjects 3. The user will enter the code, name, credits, and type and if it has also a practical part. 4. The user will save the subject by pressing the Save button.

6. Cognitive Walkthrough
6.1 Walkthrough for each task
A cognitive evaluation on the interface prototype will be presented next, stepping through each step of the four scenarios presented above. At each step the following questions will be answered: Q1: Will the user be trying to produce the effect? Q2: Will the user see the correct control? Q3: Will the user see that the control produces the desired effect? Q4: Is there another control that the user might select instead of the correct one?

Q5: Will the user understand the feedback to proceed correctly?

Task 1 User Login The user would like to use the application. Although there are several types of users, the application should redirect them to the corresponding page according to their credentials, such that they are logged in as fast as possible. A1.Yes, since the first screen it will appear is related to username and password. A2.Yes, double clicking on the application is very common in everyday computer working. The username and password fields are separated, and no confusion is created. A3.Yes, after pressing the Login button it will be redirected to the corresponding screen according to the credentials used. In case the credentials are not correct a pop-up window will show an error message. A4.Dont see any confusion here, although there are two buttons, one for login and one for cancel in case the provided credentials are not correct and the user notices that. A5. Yes, since the pop-up window will appear in case of incorrect credentials.

Task2 - Create new user and delete specific accounts A1.Yes, he wants to create a new user, so he has to login in order to view that option. A2.Yes, he has to check in the menu the corresponding action and press the correct item. This will be revealed by its name. A3.Yes, since a new window will appear and will be asked to input the fields according to the new user desires. A4.Yes, he might choose another field, but using the cancel button, he will be able to get back to the initial menu and try again, although the page is self explainable and with a clear meaning, so no mistakes are possible here either. A5. The user will understand the feedback since a popup window will confirm that the new account has been successfully saved in the database. Task 3 Student Registration A1.Yes, he wants to register a new student.

A2.Yes, since in the menu there are corresponding self explainable entries. A3.Yes, since a new window will appear If the correct item is selected, asking for the information about the new student. A4.No, since all the entries are clearly explained according to the action they are meant to perform. A5.Yes, since a pop up window will appear and confirm that the new student is registered. Task 4 Add new subjects and marks A1.Yes, he wants to add a new subject. A2.Yes, he will see a menu, and will have to choose the correct action he wants to perform. A3.Yes, since a new window will appear, where he will have to insert the information about the subject he wants to create or about the mark he has to input. A4.No. There is no confusion possible. A5.Yes, he will see a success message.

6.2 Interface problems discovered

- The user cannot logout from the application, only close it. - The Add Entry and Edit Entry buttons can be confusing for some users. Some users could press Edit Entry when they actually wanted to add a new entry - The access time might be improved by adding visual effects on the buttons

6.3 Ideas for improving the interface

- create a general log out button visible in the main menu - change the names of the Add entry and Edit entry buttons to add new entry and edit existing entry - add a small picture on buttons and menu items for speeding up the access time in the application

7. Heuristic Evaluation Report

Together with the users of the system and the prototype of the application I will present a Nielsen-style evaluation using the first nine heuristics. Each heuristic, along with the outcome of running it on this project is presented below:

7.1. Visibility of system status

We have decided that the application should have a status bar for displaying feedback messages in order to increase the visibility. When accessing the application a welcome message should appear informing about the type of the user you are logged in (student or administrator).

7.2. Match between system and the real world.

All the labels used and button names are easily understood by students and teachers. No fancy words are used and all menu items are correctly labeled.

7.3 Use control and freedom

The users do not lack the option to go back or cancel the current operation. There is no logout button, this was corrected and a general log out menu entry was added such that any student or administrator will be able to logout to the initial screen.

7.4. Consistency and standards

All buttons, labels and menu entries are consistent in terms of color, position and meaning.

7.5 Error prevention

There are few places where the user can perform an action that leads to an error: Such an example is when trying to add a phone number that is not correct. For this situation a check field was created and a minimum size, to contain only numbers validation was added. Add more dropdown lists to prevent errors where possible: sex of a student (male/female).

7.6 Recognition rather than Recall

The application does not have long sequences of steps. Each action can be performed in 4 steps, using buttons and labels clearly stated. Each of these steps is clearly shown in the window title.

7.7 Flexibility and Efficiency of Use

The use of dropdown lists in case of semesters, years of study, sex, subjects, in order to minimize the possibility to errors. The possibility to use keyboard shortcuts should be implemented to help advanced users.

7.8 Aesthetic and Minimalist Design

The design is minimalist enough and simple. The aesthetics are considered satisfiable, most of the interactions are done in one step and straight forward.

7.9 Help Users Deal with Errors

In order to help users understand what went wrong with the system, the error messages should indicate the possible root cause. (ex. In case of unsuccessful login and caps lock is active, show this in a message, not just check credentials messages.).

Chapter 8 Prototype Version 2

In what follows one can find the first running prototype of my project. The prototype is presented below, along with a discussion of the issues that arose when implementing them. Some modifications occurred in the design of the interface. Some of them were triggered by implementation issues; others were demanded by the users in the earlier phases of heuristic analysis. Below, I present a series of snapshots of the application as it looks now, together with explanation of changes that were made, and descriptions of use cases.

The login page contains two input fields which are requesting for credentials. One of the users request was to create a more user friendly login page, and to complete this input by adding some images on the buttons. All this will be implemented in the next prototype. In this phase the user must choose between the two possibilities of logging in using the student and admin radio buttons: as student or as administrator and the application will grant access if the user is defined as specified in the database. The next picture represents the Student main page, as it looks for all the logged in users which are considered students in the database.

From this interface one can access the mark list or student details interfaces. In the mark list interface one student can view its marks separated for each semester and the overall result.

The next interface presents the view for student details. This can be used by any user in order to view specific details for his/her colleagues. The functionality implemented was to create the possibility to search for a user details, using any of the input fields. One can insert data for example in the fathers name input box, press the view button and all the others fields, will be updated.

Regarding the administrator views one will have the following interface after login.

Using the above presented menu an administrator has access to all the functionalities. Of course, there are multiple possible interactions: using the navigation menu entries and the keyboard shortcuts. When the user presses as an example CTRL+ S the User List with all the applications from the database will appear on the screen.

Chapter 9 Prototype Review

9.1 Plans for user testing
The users were able to view the first prototype implementation and had a two week time for testing. The two users had to offer feedback and to discuss about possible improvements which can be brought in the next prototype. The users were required to do the following steps: Start the application and login as both student and administrators Understand the information provided by the application Create a new user

Use the applications for both student and admin mode

These steps are required in order to have a start point regarding the following: - the speed in performing the requested tasks; the user intuition regarding the way to achieve a specific goal. The user will be permanently observed during the testing phase, and at any time if he gets into an block situation, he will be helped out of it.

9.2 A list of usability problems discovered with possible solutions

1. In the login page the user should not be requested to specify its login type credentials, and the application should do it by itself, such that a plus in speedup will be obtained. Possible solution: the backend system will check in the database for every possible input and will redirect the user by its type saved in the database. 2. The student details should consider more fields, such as: address, mother name, specialization, class. Possible solution: add more fields in the student view interface. 3. The possibility to view some other student marks should be added (in case that are not marked as private) in order to increase the competition spirit between students. Possible solution: add an interface when mark list option is chosen in order to select the student for which you want to display the results. 4. General logout button missing. Possible solution: create a new menu entry for logout option. 5. Tools which can be used by administrators are not enough. Possible solution: Add the Notepad entry in the tools menu. 6. Menu entries are not specific enough. Possible solution: add icons in the menu. 7. Keyboard short cuts are not intuitive. Possible solution: display each shortcut in the menu entry such that one user can use them after seeing them for a couple of times.