Please download these, follow the instructions outlined in the manual.
Test1
Test2
Test3
Test4
Settings page
User Manual
The feedback we received during the low fidelity prototyping phase proved extremely beneficial in guiding us towards a computer prototype. These changes were implemented to the best of our ability taking into account time constraints and technical feasibility. We have highlighted below some of the evolutions our design has taken.
Removed color only and sound only notifications
During post test feedback on the low-priority prototype we overwhelmingly received opinions that just sound or color was not enough. The users believed that more information was necessary to better aid them in distinguishing notifications. Per their suggestions we removed any notifications that operated solely on sound or color and instead, the notifications have information about the sender and content of the message.
Moved to prototype with upper right corner rectangular notifications
Overall we found that among the different prototypes we tested the one users preferred, and responded to better was having the small rectangular notifications in the upper right hand corner. This we believe is in part that it is intuitive (or familiar) since many desktops notifications appear similarly. They are also able to grab user's attention while not distracting them too much from the task at hand.
Added pictures to notifications
In order to alleviate short term recall, or exploit pictorial memory, we decided to add profile pictures to the notifications. This provides an additional visual cue to the user of who is messaging them, enabling even less interaction time if necessary, or on the flip side notifying them better of a high priority message.
Removed the live preview in notifications settings page
In part due to the technical feasibility, users felt it unnecessary bells and whistles to show a live preview of the notification. This they state was because it is quite straightforward since the notification setting is quite familiar.
Cross Platform Compatibility
We were initially planning on using javascript, however we went with Java. This is because we wanted to create code that was used with Java's virtual machine which lends to a wider breadth of Operating System compatibility (i.e. Windows and Mac).
As stated in our project proposal, our user population is composed of Slack users that belong to several discussion groups. The subject should experience that they often receive too many Slack notifications and that they would like to be able to personalize their notification system. The user will want to prioritize some messages over other messages and be notified about some specific messages and not about every message they receives. Our three user segments are the Prioritizer, the Distracted and the Logged Off. When choosing subjects, it is important to take into account the reason why the user wants to personalize the notification system. It is better to find users that want to use this notification system for different reasons. For example, is it because the person testing the system belongs to a work discussion group and a friend discussion group and only wants to have work related notification while at work? Or is it because the person testing the system has several discussion groups with different groups of friends and only want to be notified when there is a message of a special friend?
The usability goals we had during the low fidelity prototype still hold during the computer prototype however some of the measurements have been changed to reflect the design changes implemented and to take into account the different natures of a paper vs computer prototype.
The system should effectively indicate notification priority
Quantitative measurement: To determine priority we will count the number of times the test subject says "Respond", click the x on the notification and ignore the notification. These numbers will then be compared in two experimental procedures, one where the notifications will be with color, the other where the notifications will include everything else but color. We present the colourless notifications first. This way we will be able to determine if the user is able to distinguish priority better when our system, which includes colors, is in place.
The system should be easily comprehensible
Quantitative measurement: This will be two part, first we can count the number of subjects that have a problem in setting up notifications (see who can navigate without help). This will also be somewhat observational, based on observing reasonable confusion or hesitation when using the system. In addition we will include questions regarding comprehensibility in the post test questionnaire and informal discussion.
The system should save the user time
Quantitative measurement: This can be measure two fold. Count the number of test subjects that do not change their behavior when the system is on (i.e. interacting the same way with every message), this indicates the user would not benefit from the system, not saving them time. In addition the ratio of interactions with notifications should be measured. This is an indirect measurement of saving time since ideally they respond only to the high priority notifications.
The system should be highly customizable
Qualitative measurement: We would answer this goal post test. This would be in the form of asking the user something of the form "When using the system in the future which of the features would you need (ex. Color/ sound/ animation)?". This would give us an idea whether or not we are getting close to what the user would define as highly customizable while also providing us information on improvements we can implement in the final prototype.
The system should be used and adopted
Quantitative measurement: We would answer this goal post test. Questions of the form "If a message priority customization was available for Slack how likely would you be to use it? (on a scale of 1 - 5)" We would preface this question with a short description of what the goal of our notification system is. Given the nature of the project and constraints we have it is difficult to properly convey the entire system, hindering the possible feedback that we may receive.
Please use the Observer Sheet to report information about the studies you conduct. We appreciate your contribution to the development of our system. We created identical google docs to the forms above to expediate and simplify the process of reporting. Since the google docs are registered under Caroline, Juliette and Thomas' accounts, we will receive the responses automatically.
Observer Sheet
Pre-Test Questionaire
Post-Test Questionaire
As it is the first time the computer prototype is being tested, we expect that you might encounter some usability problems with the system, but hopefully just small problems that will still let you run the test correctly and obtain results. All the problems that you will encounter while doing the test are really important for the improvement of our system so please do not forget to write about all these problems.
Utilizing the feedback gained from the experiments, we will better design the Notification system to meet our user's needs. From the insights the experimenters will provide us, we will have empirical evidence to justify our future design decisions.
In addition to conducting user testing of the prototype we would like to set forth a usability evaluation to be conducted by each member of the evaluation team. We would ask you to follow some standards to ensure the proper evaluation of the system in question. Most importantly please conduct each evaluation separately, only after the evaluation is conducted and recorded do we ask you to come together as a group to share/discuss your findings. It is up to you how you perform the evaluation however we ask that you familiarize yourself with our system beforehand to get a general understanding of its functions and how it works. Then we would ask you to follow the specific heuristics set in Nielsen’s list, reproduced below with how we believe they relate to our product in the "Justification" portion. We ask you to keep in mind that this is a prototype therefore not all functionality is implemented and design is not quite finished.
Visibility of system status: "The system should always keep users informed about what is going on, through appropriate feedback within reasonable time."
Justification: The user should be aware of what this system does and by opening the settings page, he will be aware of the meaning of every color-sound-content combinations.
Match between system and the real world: "The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order."
Justification: The aim of this project is to help the user prioritize his Slack messages. If the new settings do not help the user for this task , the system has failed in helping the user benefit from our notification system.
User control and freedom: "Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo."
Justification: The user has all the freedom he wants to choose the color-sound-content combination and can add/drop settings for different discussions/persons/subject. In addition the user can intuitively interact with the notifications.
Consistency and standards: "Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions."
Justification: On the setting page, it is necessary that all the actions that can be made are different. If not, the system will fail as two different types of notifications can be represented by the same color-sound-content combinations.
Error prevention: "Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action."
Justification: No error prevention is currently present in our prototype as we believe there is currently not enough functionality and no clear places to implement error prevention.
Recognition rather than recall: "Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate."
Justification: The user itself is choosing its preference and there are not many choices to make. The fact of having three choices to make (sound, color, content) will help the user in remembering what type of settings corresponds to what notification. When receiving a notification, the user will know what priority the message belongs to without having to look at the setting page.
Flexibility and efficiency of use: "Accelerators - unseen by the novice user - may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions."
Justification: The system is designed to provide users with notification customization, this inherently provides flexibility to a more experienced user who can set these notifications to further increase his productivity.
Aesthetic and minimalist design: "Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility."
Justification: The user should be able to easily access all parts of the system without compromising the experience. This is shown by the simple flows, and familiar interfaces that contain only pertinent information.
Help users recognize, diagnose, and recover from errors: "Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution."
Justification: No error messages are currently present in our prototype as we believe there is currently not enough functionality and no clear places to implement error messages.
Help and documentation:"Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large."
Justification: Every user of the system will receive the User Manual to understand how the system works. This user manual should be clear and concise in helping the user familiarize themselves with and set up the system.