(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 4: Contrast and discuss the enrolment input form (PRF) with the enrolment university interface.)
This assignment that I am discussing about deals with a very important issue, above all – consistency. This is supposed to be a significant matter especially with regards to input and output user interfaces.
In creating a graphical user interface especially from the manual type and accustomed use to an automated system, the developer has to be particular with the input and output fields. This is because the user(s) may already became familiar to the old format and introducing him or her to the new user interface with a completely new look may lead to confusion which may end up to the uselessness of the system. The user, of course, has developed a habitual inclination in using the old format, especially if he or she has been using it for a long period of time. Beginning to use a brand-new yet same system functionality (although an improved one) with a different although intact input look and form will have a significant effect on the momentum of the work. Worse, the user who can not grasp the functionality at once will find the user interface complicated and most likely refuse to use and learn about it.
The idea led me to examine this aspect of the two important items being deliberated here – the enrolment input form or what is commonly called as the Pre – Registration Form (PRF), and the enrolment university interface or Student Records Information System (SRIS). The PRF is what the students need to secure during the advising part in the enrolment process before the college secretaries and/or administrative staff encode the filled-in entries into the SRIS. Basically, the elements within the Pre - Registration Form are also contained in the Student Records Information System, in which it covers more features and functionality. In simple analogy, the format used in the PRF and the user interface coordinates therefore it is important that it should be parallel since promptness of the processes involving the information matters a lot.
I reviewed the appearance of the PRF and here is how it looks like:
Notice what kinds of information are being asked directly from the student and how each are located in the form.
Now let us check a sample screen shot from the SRIS:
Take a look at the data fields and their placements. The SRIS contains almost all the basic information that is directly written by the student into the PRF. But what is really noticeable, when graphical user interface is being highly dealt with, is that there are some elements that are not parallel in position. The enrolled units table however, is placed in the similar manner, in a way that is easy and convenient to browse, except for the columns that are mismatched from the original (based from paper) position.
In the PRF, I could only say a reasonable explanation why there is an entry field for the Address and Address of Employer if employed. Maybe this is to check whether the students is currently working and studying at the same time – a thing that needs to be checked as far as allowed units are concerned. Instead of asking directly of a choice between ‘working student?’ and not, it is quite straightforward to ask the address of the employer so if the student is validly working, the name and address of the employer would prove it. There is, however, no field for it in the SRIS, which made me think of why such entry is included in the PRF where the most basic information is asked and not in the automated system where a more comprehensive data is stored.
There is no field for Civil Status in the PRF while in the SRIS there is.
There is more than one Section fields in the PRF and none in the SRIS, only Class. I think the Section entry in the upper part of the PRF is the general information about where the student belongs and the fields corresponding to the subjects and/or units enrolled corresponds as to where the students fits in during classes of the subjects. But the student would not know firsthand the section(s) he or she will be unless the professor(s) of the related subject(s) will arrange the schedule and class list.
The separate data fields for Semester and School Year to be enrolled in the PRF is being coupled in a selection dropdown in the SRIS. This data has to be explicitly identified by the student upon filling up the PRF and the encoder will just have to choose from a pre-loaded selection for speedy browsing.
I found the Scholarship field from the PRF missing in the SRIS. I do not know where this part fits in the automated system but the encoder asks the student an approved scholarship card to prove the said information.
Other data in the SRIS such as Contact, Email Address, Parents, and Religion cannot be found in the PRF.Well, this information is not necessarily required for the student to fill in again every enrollment period (PRF filling up process). I understand that the SRIS contains most if not all the records about the student so as expected, it has more data and information.
The noticeable thing here is, the data that is being asked in the PRF do not have close locations in the SRIS. The ID number for example, is being regarded as a main item in the SRIS since it is located above (and being asked first) before the name. It is, however, opposite in the PRF when the name is regarded as a key thing. As an IT student, I am aware of the role of primary keys in various systems, therefore I understand why it is significantly ‘above’ and ‘before’ the Name field in the SRIS.
Another thing that made me raise an eyebrow is the SRIS’ Desired Career data field. If the purpose is to know what the student certainly aspires for, I think this data entry is more appropriate in the Guidance Office system (well, this is just my opinion based on the aforementioned reason).
In my general point of view, the university enrolment interface is a more wide-ranging system which fits to its description – Student Records Information System. Basically, it contains the fundamental information about the student enrolling in the university. It also contains both the data that is asked from the student (those types of data that are, and might be, constantly changing especially every enrollment period – temporary data) and those which are kept for a long time to be modified or permanent data.
Factors that are significantly important when it comes to these things are consistency and parallelism. As what I’ve said in my first statements, the primary users of the (automated) system shall not have a hard time in familiarizing the data input fields from the manual form. This will have impact on the work and response time. Thus, I would like to emphasize the value of parallelism in this case. The position also matters aside from the types of information being asked. This will define the usability of a good user interface.
I would like to recommend this article from a blog I found which talks about the characteristics of successful user interfaces by Dmitry Fadeyev. It contains the basic characteristics that I’ve been looking for in a UI.
http://www.usabilitypost.com/2009/04/15/8-characteristics-of-successful-user-interfaces/
Acknowledgment:
Dmitry Fadeyev, 2009, 8 Characteristics Of Successful User Interfaces, Usability Post
Microsoft Encarta Dictionaries
Credits go to Ms. Joan Rose Dandoy for the image of the SRIS
In creating a graphical user interface especially from the manual type and accustomed use to an automated system, the developer has to be particular with the input and output fields. This is because the user(s) may already became familiar to the old format and introducing him or her to the new user interface with a completely new look may lead to confusion which may end up to the uselessness of the system. The user, of course, has developed a habitual inclination in using the old format, especially if he or she has been using it for a long period of time. Beginning to use a brand-new yet same system functionality (although an improved one) with a different although intact input look and form will have a significant effect on the momentum of the work. Worse, the user who can not grasp the functionality at once will find the user interface complicated and most likely refuse to use and learn about it.
The idea led me to examine this aspect of the two important items being deliberated here – the enrolment input form or what is commonly called as the Pre – Registration Form (PRF), and the enrolment university interface or Student Records Information System (SRIS). The PRF is what the students need to secure during the advising part in the enrolment process before the college secretaries and/or administrative staff encode the filled-in entries into the SRIS. Basically, the elements within the Pre - Registration Form are also contained in the Student Records Information System, in which it covers more features and functionality. In simple analogy, the format used in the PRF and the user interface coordinates therefore it is important that it should be parallel since promptness of the processes involving the information matters a lot.
I reviewed the appearance of the PRF and here is how it looks like:
Notice what kinds of information are being asked directly from the student and how each are located in the form.
Now let us check a sample screen shot from the SRIS:
Take a look at the data fields and their placements. The SRIS contains almost all the basic information that is directly written by the student into the PRF. But what is really noticeable, when graphical user interface is being highly dealt with, is that there are some elements that are not parallel in position. The enrolled units table however, is placed in the similar manner, in a way that is easy and convenient to browse, except for the columns that are mismatched from the original (based from paper) position.
In the PRF, I could only say a reasonable explanation why there is an entry field for the Address and Address of Employer if employed. Maybe this is to check whether the students is currently working and studying at the same time – a thing that needs to be checked as far as allowed units are concerned. Instead of asking directly of a choice between ‘working student?’ and not, it is quite straightforward to ask the address of the employer so if the student is validly working, the name and address of the employer would prove it. There is, however, no field for it in the SRIS, which made me think of why such entry is included in the PRF where the most basic information is asked and not in the automated system where a more comprehensive data is stored.
There is no field for Civil Status in the PRF while in the SRIS there is.
There is more than one Section fields in the PRF and none in the SRIS, only Class. I think the Section entry in the upper part of the PRF is the general information about where the student belongs and the fields corresponding to the subjects and/or units enrolled corresponds as to where the students fits in during classes of the subjects. But the student would not know firsthand the section(s) he or she will be unless the professor(s) of the related subject(s) will arrange the schedule and class list.
The separate data fields for Semester and School Year to be enrolled in the PRF is being coupled in a selection dropdown in the SRIS. This data has to be explicitly identified by the student upon filling up the PRF and the encoder will just have to choose from a pre-loaded selection for speedy browsing.
I found the Scholarship field from the PRF missing in the SRIS. I do not know where this part fits in the automated system but the encoder asks the student an approved scholarship card to prove the said information.
Other data in the SRIS such as Contact, Email Address, Parents, and Religion cannot be found in the PRF.Well, this information is not necessarily required for the student to fill in again every enrollment period (PRF filling up process). I understand that the SRIS contains most if not all the records about the student so as expected, it has more data and information.
The noticeable thing here is, the data that is being asked in the PRF do not have close locations in the SRIS. The ID number for example, is being regarded as a main item in the SRIS since it is located above (and being asked first) before the name. It is, however, opposite in the PRF when the name is regarded as a key thing. As an IT student, I am aware of the role of primary keys in various systems, therefore I understand why it is significantly ‘above’ and ‘before’ the Name field in the SRIS.
Another thing that made me raise an eyebrow is the SRIS’ Desired Career data field. If the purpose is to know what the student certainly aspires for, I think this data entry is more appropriate in the Guidance Office system (well, this is just my opinion based on the aforementioned reason).
In my general point of view, the university enrolment interface is a more wide-ranging system which fits to its description – Student Records Information System. Basically, it contains the fundamental information about the student enrolling in the university. It also contains both the data that is asked from the student (those types of data that are, and might be, constantly changing especially every enrollment period – temporary data) and those which are kept for a long time to be modified or permanent data.
Factors that are significantly important when it comes to these things are consistency and parallelism. As what I’ve said in my first statements, the primary users of the (automated) system shall not have a hard time in familiarizing the data input fields from the manual form. This will have impact on the work and response time. Thus, I would like to emphasize the value of parallelism in this case. The position also matters aside from the types of information being asked. This will define the usability of a good user interface.
I would like to recommend this article from a blog I found which talks about the characteristics of successful user interfaces by Dmitry Fadeyev. It contains the basic characteristics that I’ve been looking for in a UI.
http://www.usabilitypost.com/2009/04/15/8-characteristics-of-successful-user-interfaces/
Acknowledgment:
Dmitry Fadeyev, 2009, 8 Characteristics Of Successful User Interfaces, Usability Post
Microsoft Encarta Dictionaries
Credits go to Ms. Joan Rose Dandoy for the image of the SRIS
