5.4. Designing the Graphical User Interface (GUI)

Both the desktop and mobile variants of my solution will be using a graphical user interface to allow the users to easily interact with it. Labels will be used throughout to annotate the functions of both applications and their objects.

5.4.1 – Designing the Graphical User Interface (GUI)

The desktop application’s GUI will be separated into four Windows Forms, which will enable the backend of the proposed solution to be implemented using C#. The initial Form will be the Login form, as shown below:

The two GroupBoxes will separate the two input sections for the user – their personal information and the database information (which can be maintained after the application is quit with the use of a checkbox). The data can be input via textboxes, and a button shall be used either when the user clicks on it or when they press the ‘enter’ key while writing in a textbox. Should the information provided be correct, he form will be hidden for the next form to appear.

The administrator Form will be by far the most complex and will include access to most functions of the developed solution. A TabControl will allow for separation of all these functions in a more cohesive and less complex matter. ListBoxes will be available to present appropriate information to the Administrators in every Tab.

The Absences Tab – the initial tab that is presented to administrators and secretaries. Objects like a DateTimePicker, a NumericUpDown (accepting only appropriate periods 1-7) and a ComboBox will be populated beforehand with all groups added to the database. These will allow the logged in user to fine-tune their search for absences recorded for any given period, date (both required) and group (optional). The button “Display Absent Students” will populate the ListBox with any absent students selected and all their associated information for quick access.

The Students Management Tab – used by administrators and secretaries to manage students in the database. The ListBox can display all the students recorded with the upper right button or the button on the left-hand-side can be used in combination with the ComboBox to present students from only specific groups.

The Calendar Management Tab – used by Administrators only to manage the dates for which absences can be recorded. The GroupBox “Add semester” and its inhabitant DateTimePickers and TextBox let administrators add new semesters, or dates for which absences can be recorded. The ListBox will already be populated with any semesters already added, and after selecting one administrators can click on the “Remove Semester and Associated Dates” button to remove all dates, associated absences and the semester in general from the database.

The Groups Management Tab – Used by Administrators and Secretaries to manage the groups students are separated into. Groups must be added through the “Add Group” Groupbox where only the group name is required in the singular TextBox before the button below it is clicked to submit to the database. The GroupBox below will let the logged in user to change the “group” property in students from one group to another, enabling student promotion once a school year is over. Once again, ComboBoxes in this group will already be populated with all groups in the database. After selecting a group from the ListBox users can click on the “Delete Group and All Member Students” to delete both the group and all students in that group.

The Users Management Tab – Used by Administrators only to manage users and their permissions. The ListBox will already be populated with all users found in the database, and after selecting one administrators can click on the “Upload Schedule” button to insert the user’s timetable into the database through a popup window asking for a .csv file. Additionally, administrators can reset the password of any user after selecting them and clicking on the “Change Password” button. Moreover, they can assign them as heads of groups after selecting them and a group from the ComboBox (already populated with all groups in the database) and clicking on the “Assign Group” button. Finally after selecting the user administrators may delete them and all their associated data (like timetables) from the database. Clicking on the “Register a New User” button will cause another form to pop up for the registration of new users.

The Lessons Management Tab – Used by Administrators only to add and remove lessons, used later in creating timetables for users. The GroupBox “Add Lesson” contains two TextBoxes where users can enter the numerical lesson ID and the lesson name before clicking on the button below to add the lesson to the database. The ListBox on the left will be automatically updated after the logged in user makes changes, and a lesson has to be selected before they can delete it and all associated data from the database (like timetables that include it) by clicking on the “Delete Lesson” button.

Designing the Administrator Form rose the concern of taking up additional storage space by having an almost identical Form for Secretary use only. To avoid this and optimise storage, the TabControl event SelectedIndexChanged, which is fired every time the user clicks on a tab will be supplemented with additional code that checks the role of the currently logged in user. If they are a Secretary, selecting the tabs “Lessons Management”, “Users Management” or “Dates Management” will only output an error MessageBox and not present the tabs to the Logged-In Secretary. Secretaries will have to be informed about this feature through the user’s manual so the error is expected.

ListBoxes featured throughout the administrator form will either present information by user’s requests (for example the ListBox found in the Absences tab will be empty until the user requests for data to be presented) or get data right when a user logs in (for example the ListBox found in the Users Management tab will already be presenting the latest information on all users recorded in the database). GroupBoxes and ListBoxes will dynamically update once a user makes changes, for example if they remove a group.

A limitation of this approach is that one Administrator and one Secretary should only be logged in simultaneously at all times, even though the code does not secure this fact. This is because if one desktop user makes changes, for example, in the users the ListBox on the other logged-in user’s Form will not dynamically update until they make changes themselves or log out and log in again.

To make changes to an entity (for example change a User’s password), it must be first selected in the ListBox and then the appropriate button should be clicked on to alter the entity. It will be made clear in the user’s manual which buttons require a selected entity first. As a rule, elements organised into GroupBoxes will not require an element to be selected first.

5.4.2 – Designing the Mobile Graphical User Interface (GUI)

The mobile application will consist of three pages: The Log In page is a ContentPage consisting of a welcoming label followed by four Entries (the equivalent of TextBoxes in WindowsForms) for users to enter their username, password, database address and password. These will be annotated with text within which will disappear as the user selects an entry. A button will be the final object which will be annotated “Log In” and will let the user submit their information. These will all be part of a Stack Layout, as shown below:

The Main Tabbed Page, will be separated into three tabs: The attendance tab will consist of a ContentPage. On top, a Frame will greet the currently logged in user (since someone must be logged in to view this page). A label underneath will describe the steps needed for the user to take the register, under which there will be a ListView which must already include the user’s schedule for the day if any exists. After selecting the period for which they want to take the register, they must push the button below.

The Feed tab will be a ContentPage which will consist of a Frame as a title for the page and a ListView that will be used to gather updates posted by administrators and secretaries. This will be updated per user’s request by scrolling down (the known “pull to refresh”) and when the application is launched after a user has logged in.

Finally, the Settings tab will consist of a ContentPage which will include a title frame and a Stack Layout. The Stack will hold a label to annotate the “Change Password” section, followed by three Entries: The current password, the new password and the repetition of the new password entry. A button concludes this section which will submit the user’s changes to the database should the input information be correct. Next, a label will annotate the use of the final button, which will only be used when the user wants to log out.

The supplementary attendance-taking page will slide in after the user presses the “Take Attendance” button and will also be a ContentPage which will consist of a ListView. Its header will include a button to let the user go back to the Main Page (especially useful in the iOS platform which doesn’t have a back button built in). The list will populate automatically based on the user’s selection from the Picker with the appropriate full names of students the user wants to take the register for. On the right-hand-side checkboxes allocated to each student will indicate whether the student is marked present or absent. The button on the ListView’s footer will allow the user to submit the updated register after they have marked the students as present/absent.

Adobe XD was used to design the mobile application since the pages will have to be implemented with code; unlike WinForms, controls cannot be dragged and dropped to visualise the program in the IDE.