Assignment #8 Report
Behavioral Change (TooGather) Julian
Mathis Chin Guan
Steven
王晨宇
Section 1: Problem and Solution Overview
A whole semester or even an entire undergraduate/graduate career can go by without much interaction between students in classes. Students miss out on valuable learning when they do not answer or ask questions. Our app gives students the opportunity to digitally voice their thoughts and in the process join the ranks of interactive members. The Q&A part of the app allows for a livelier classroom. Long gone are the days when students would refrain from participating.
Section 2: Tasks and Final Interface Solutions
• The three chosen tasks are search/keyword, Q&A and lost. The search function evolved from its more undeveloped stage—the ‘keyword.’ Equipped with these tasks, students can employ them to make greater depth hacking into their
educational endeavors. Join hands with other students, the educational advancement is made effortless.
• Simple Task: Search
• This task was added because students need a way to quickly pull out relevant information. In typing a word, students are instantly shown a definition as well as other material. Quickly scanning over the findings, allows students to increase
course coverage in a matter of seconds. As an added bonus, highlighting of key parts further eases the reading content.
• Medium Task: Lost
• This feature was added to assist students help regain track in their studies. With great precision, the app shows where the user has missing knowledge. By looking into their respective learning gaps, students are able to get an understanding where they’d like to focus their attention. Future functions would allow for communication with staff members.
• Complex Task: Q&A
• This task is the bread-‐and-‐butter of the app. Through this task, students act as lubricant to their wheel of learning. Being stuck is no longer much of a problem.
The ability to ask as many questions allows for students to seek as much knowledge to their heart’s content.
Section 3: Design Evolution
• All task designs started with the low-‐fidelity. It had the simplest demonstration to the user. For the medium task (lost), a flat line took in time points that were not necessarily indicative of low understanding. Our approach was to then take these several points into account (high and low learning) and derive an overall
representation. However, it made little sense to include numerical calculations that resided in between the rises so instead we targeted areas in the medium-‐fi. The design for the med-‐fi was further upgraded to include only those cases where clear lack of understanding was the case. This resulted in better read of percentages. For the high-‐fi, the group decided to include a button for brainstorming and another one for findings. These then complemented the percentages so that users could readily then find pertinent topics. As for the complex task, we started with numbering the questions and had a palette that was not as rich. To add some sleek to the design, we decided that the medium design’s display would benefit from an interface that excluded numbers to minimize distraction. We also instead decided on a color scheme that compartmentalized the questions into their corresponding theme. In the high-‐fi, whole sections related to same color. As for the simplest task, we
initially started with keypoints/keywords and these were few in number. The initial design was not ideal for the inclusion of several keywords. Instead, we decided to have a design that could fit many more questions and allow for flexibility, hence the search feature in the medium fidelity. However, we needed a way to have this be tied back to discussions. For the high fidelity we kept the search, but provided clear separation between the search function and the keyword (only keypoint is shown).
One limitation to the medium and high fidelity is that the user will need to know the keyword in advance since they are not being displayed. However, we think that the freedom to explore ought not to be compromised.
Section 4: Major Usability Problems Addressed
Level Fix Rationale C1=Compare
&
C2.A=Contrast (after)
4 Simplify Layout Separating and
removing parts as well as adding white space gave a simpler look to the style. The states are clearer.
C1: The function procedure remains intact.
C2: Less on screen does not overwhelm some users.
3 Visibility of Status -Centralizing C1: Headers and main
wording, enlarging lettering and adding blue coloring
facilitates recognition.
-Removal of some parts to the app, reduces the need to display the process
parts are found in both.
C2: Fewer lettering allows for other
buttons to be included in the header region.
4 User Control -The beauty of
simplification is that it fixes many problems.
It’s straightforward.
Also, as a result the edit and delete parts are more easily exposed.
C1: Search is functional.
C2: Separation of search and result screens.
3 Efficiency of Use -Same line of thinking
as the above. Because it’s simple (the
keyboard pops out when button is
tapped), this resolves our problem.
C1: Button usage for keyboard popping.
C2: Keyboard triggers are different.
4 Unexpected Displays -Simplicity does have
several perks! Took care of this one too.
C1: Overlap in meaningful displays.
C2: Display reduction.
Our heuristic results indicate that we have 46 violations. Of these, 20 of them are severity 3 &
4, eight are severity of 2, twelve are severity 1 and lastly 6 were severity of zero. A few of the labels were incorrect while others could be included under a similar deficit. We thus came up with about 13 fixes.
Category Count Errors
[H2-‐4: Consistency] 4 Navigational scheme not
clear due to inconsistent throughout
[H2-‐1: Visibility of Status] 5 Show user where they are in the task process
[H2-‐3: User Control] 2 User edit/delete/search
limitations
[H2-‐7: Efficiency of Use] 1 Extra steps (keyboard)
[H2-‐2: Match Sys & World ] 1 Unexpected displays
Section 5: Prototype Implementation
• The tools we utilized were DroidDraw, Android Studio, Android Phone and Google.
They were used as follows:
o Android Studio: Allowed functionality testing of our prototype. The preview feature expedited the work since it provided real-‐time implementation of our work. The auto-‐complete further accelerated the process.
o Android Phone: The preview feature of this software is a bit off. The compiling of it to a phone is more convenient than a virtual phone device.
o Even though the documentary was helpful, it did not give direct methods to some android coding techniques.
• The tools limitations are as follows:
o DroidDraw: Enabled the drawing of the layout, but did not help much in the coding part; the transferring and revising of the codes proved to be difficult which resulted in our departure from its usage. Instead, we finalized our work in the Android Studio.
• Wizard of Oz special feature:
o Several attempts were made to append the content into the design.
• Hard-‐coded Data:
o Keywords, questions and comments were hard-‐coded. Components requiring a database system had them implemented to make the system easy to manage.
• A few additional features we could include are as follows:
o The search function is limited in operation due to the unfinished back-‐end engineering. The use of a database would be much more convenient than having to hard code the feature in our high-‐fi prototype. We also do not have the question ranking in operation.
Section 6: Summary
Based on our findings, students in various classes find themselves hesitant to participate in discussion due in part to uncertainty since the crossfire of miscalculations or
misunderstandings can be costly. To avoid spillage and possible collateral damage into other parts of their student life, many resort to a camouflaging approach (not
participating, etc.). Remaining in this state is not effective, but the chameleon’s way
provides much safety and comfort. Loss of identity can ensue. Our app acts as an enabler for interaction while giving privacy to our users and in such way the design for the
classroom experiences more ‘natural interaction.’ Students can instead focus on learning with little distraction. Our iterations in the design of the app have also tapped into the
‘proactivity’ branch of ubiquitous computing. Further work would allow the team to interview several more participants to eliminate any undesirable conflicts. The team hopes that through our efforts, we have developed an app that can assist students in their learning.
