Please enable JavaScript.
Coggle requires JavaScript to display documents.
IA2 - Peer Mentor Manager - Coggle Diagram
IA2 - Peer Mentor Manager
Data
System data will be manipulated and managed through the use of a MySQL database
To reduce the risk of SQL injection attacks and to increase the ease of programming throughout the development of the system, the MeekroDB MySQL library will be utilised; MeekroDB will reduce the magnitude of code required to execute a SQL query, therefore simplifying the development process, also
Multiple SQL tables (outlined in the 'potential data design' mindmap) will be used to store and use data within the system
User interface
The user interface will be designed in such a way that reduces the number of separate pages users must navigate to. For example, through use of PHP $GET variables, users may be presented with responsive modals of differing functions within the same page, meaning they won't have to navigate to different pages. This user interface design increases the fluidity of a user's experience, therefore increasing the overall effectiveness of the solution, also
So as to reduce 'clutter' and visually displeasing aspects of the developed user interface, a simplistic, minimalist design will be employed
Potential PHP/HTML pages
Admin pages
Student pages
Mentor (Old Boy mentor) pages
In terms of colour scheme and visual aesthetics, the user interface will attempt to retain a degree of colour consistency between pages, so that the learnability and useability of the system may be increased. For example, if a particular button on one page is styled in a characteristic green colour, then this green colour shall also be employed within other pages
Generally, the design and style of the system should be consistent across pages, so as to increase the learnability of the system for users. For example, if a certain grid layout is employed on one page, and a similar page is required to display similar information (or even the same information), then the same grid layout should be used
Coding/programming, markup languages
MySQL - used to manage, store, and manipulate data within the system
PHP - used to implement algorithms, manipulate data, and create the system more generally
HTML - used to structure the user interface
Bootstrap, CSS - used to implement the desired stylistic design and aesthetic of the College (according to the College's style guide)
Javascript - used to create a responsive web application; used to implement interactive behaviour within the system
Limitations
Creating a system whereby both students and mentors may propose a session would entail a greater degree of development expertise and skills. To adequately develop the system, only student users are authorised to propose sessions, and mentors are only able to accept sessions
Verification of blue cards may prove difficult, given the fact that there are virtually no publicly accessible blue card databases by which mentor user's provided blue card details may be assessed. Therefore, the developed system will likely assume that the blue card details uploaded by mentors can be manually verified by the studies office of the College, which maintains overall responsibility for the Peer Mentor Manager system
For ease of development and data design, only one student will be allowed per tutoring session. Realistically, this limitation brings about a degree of inefficiency within the developed system, as - in a realistic implementation of the Peer Mentor Manager system - mentors are very much capable of tutoring multiple students in any given session (although this may not be the case for some mentors still)
Realistically, users (both students and mentors) should be able to review tutoring sessions that they have completed. Due to a lack of development expertise and temporal constraints, however, this system will not be implemented. This implementation means that the developed system will not necessarily provide the most effective services to users, as they will not be able to gauge which mentors and students are 'best' when proposing or accepting a tutoring session
Due to lack of experience in Javascript and jQuery languages, responsive elements within the developed system may be limited in number. This limitation likely means that users of the system will experience a less effective and useable user interface, therefore detracting from the overall effectiveness of the solution/system
Styling/theme/aesthetics
In order to ensure users are familiar with the Peer Mentor Manager system, St Joseph's College, Gregory Terrace's style guide will be considered throughout the design and development process
Active consideration of the St Joseph's College, Gregory Terrace style guide will also ensure consistency across different websites of the College, therefore increasing the learnability of the solution from a useability perspective
The user interface will adopt a minimalist, simplistic style, suitable for all demographics. Consequently, students (the youngest demographic) will experience the same degree of useability as, say, administrator users (presumably the oldest demographic)
Functionality
Since students are the stakeholder that best understands their tutoring and academic needs, they are able to propose a tutoring session (hereafter, 'session'), which can then be accepted by Old Boy mentors (mentors)
If a mentor is to accept a proposed session, the student user's dashboard will notify them, and display the newly-accepted session under the 'upcoming sessions' section of the page
When a mentor accepts a session, students could potentially receive an email, notifying them of the mentor's acceptance