Assignment 7: Second Interactive Prototype
Introduction | Changes | HE Disagreements and Pending Fixes
Work Breakdown | SkillShop Second Interactive Prototype
The heuristic evaluation of Skillshop performed by the FAST group provided some helpful and positive feedback about our system and helped highlight areas of concern that needed to be addressed before further user testing can be performed. The current “second interactive” prototype takes most of the proposed changed into account and builds on the feedback that was given to us by the FAST group and class instructor.
We made many changes to our system in response to the feedback we received. As a disclaimer, some of these changes are still works in progress.
We noticed that the majority of problems were found within the “user registration” and “job posting” pages. In general, it appeared that the pages that required users to enter information into the system needed to be reworked. Labels were renamed when they were confusing and entire sections were revamped to make things easy and clear for the users.
One of the major changes we made was to change the way we represented our breadcrumbs. The breadcrumbs in the previous prototype did not give a clear indication of the page the user was on. The last breadcrumb was a link which misled the users and our team made the appropriate change. We also changed the format and adjusted the size of the text as suggested by the FAST team.
There were also many small errors like broken links and consistency issues plaguing the system that were corrected during the process of preparing the second interactive prototype. For example, on one page our system had users enter dates by using a pop-up calendar while on another page it prompted the user to enter the date in a text field. We went through all such issues, agreed on a standard and are currently working on making ensure that similar information is presented to the user in a more consistent format.
In addition, in some areas we have been held up due to difficulties in implementation. For example, ideally we would have liked our job results page to be a calendar that could link to pages where users could apply to jobs. Unfortunately, since we are using Google Calendar for our prototype, we are limited to the functionality provided by the Google’s service which doesn’t aloe for such interaction. We do have a standard results page but we are still working out exactly how to couple it with the calendar view.
HE Disagreements and Pending Fixes
While most of the issues presented in the heuristic evaluation were addressed in some form, some of these are still in progress due to either time constraints or implementation difficulties.
For example, we are in the process of providing error messages if users don’t input information for desired positions. We also agree that the placement of submit buttons should be changed to be below all information on the page, to avoid any confusion.
Another change that we plan to make is in the Calendar view. In order to be consistent throughout our project, we will decide on one time format. Currently we haven’t made this change since we are still working on the calendar implementation.
Another issue we are addressing is the lack of any kind of navigation away from the search results page when users either search for jobs or employees. We are resolving this by adding the navigation bar that is standard in the dashboard, which will offer users a way back to their starting point, should they decide to abandon that task. We will also be adding breadcrumbs to this page, as well as instructions.
Our group also disagrees with a few of the changes proposed by FAST. One such proposed change was to make the “business address” required for employer registration. The business address is currently not required because the system does not necessarily depend on that information for optimal performance. We decided to minimize on “required” field to lessen that load on potential users. For example, the business could be a catering business where events are not held at the “business address” and are thus of minimal importance to potential employees. But even catering businesses may want to have their office address posted for one reason or another (for potential employees to come by and pick up their checks perhaps) so we decided to leave it as an optional field.
Another proposed change was to move the calendar in the employer dashboard to the top of the page to make it more visible. We disagree with this change as it hides other more immediate, dynamic information that has a greater risk of being missed such as notification of new messages and the list of recent employees that either applied for a job or need feedback for a completed job. We also found from our manager interviewees that they liked the ordering of the items that appear on the page.
In the confirmation of the posting page, we don’t agree about changing the scrollbar to a drop down box since it essentially does the same thing. We don’t see the reason of making the switch. On the same page, the FAST teams were not sure about why we let the employees manage current employees as well as recruit new ones. Once we explained the scope of our project to them, they realized what we were trying to do and hence haven’t made the suggested changes.
On the jobseeker signup page, we have decided to leave the phrase “industry standard technology” to describe our privacy policy, as we feel that this is simply meant to be an overview, and not offer technical specifications. On the same page, we are going to keep the option of entering a default availability schedule, although we are experimenting with different implementations of a calendar format, and will leave the present one in place until the replacement is ready. The security question will remain optional, as this is another area where we feel it is not necessary to add to the user’s load.
On the job search page, we will leave the radius button, as more than one user in testing said that they liked the option.
On the employee search page, the problem of the calendar again appears, and will hopefully be resolved by the next version. We are aware that the current implementation of time reange searches is not yet ideal, and are testing several alternatives.
|
Saud Al Shamsi |
Debbie Cheng |
Alana Pechon |
Bindiya Jadhwani |
| Write-Up | 30% |
10% |
30% |
30% |
| Coding | 33% |
1% |
33% |
33% |
| Website | 0% |
10% |
90% |
0% |