Each week there will be a set of readings that will prepare you for concepts covered in lecture. Submit a substantive yet succinct response that demonstrates you’ve done the reading onto bCourses. Reading responses are due before class on Thursday. Reading Response extra credit does not offset missed courses in participation grade. The -33%/day late policy does not apply to reading responses. Zero tolerance policy for late reading responses.
Reading responses are scored out of 2 points; getting a 2 means you received full credit. Reading responses are part of your Class Participation grade.
0 means you submitted late or didn't submit at all.
1 means you didn't completely answer the prompt.
2 means your response contributed much more to the discussion that just recapping/summarizing the readings.
Things that help push you towards a 3
The following are suggestions and don't automatically guarantee you a 3, it's just things that stand out when reading.
Getting a 3 is earning extra credit.
Describe a recent frustrating experience you have had interacting with a digital device or system. Discuss how following the design process outlined in the reading could have improved the design.
--------------------------------------------------------------------------------------------------------
This one is a longer response (again doesn't need to be this long).
Recently, I was advised by a friend of mine to use the iPhone app called “Plates”. The problem that Plates tries to solve is that people have a hard time splitting the bill equally at restaurants. Via a touch and drag UI, the Plates app allows you to add diners at your table, which show up as different colored plates on the screen, and then add menu items and drag them to the plates, to indicate which specific person should pay for that item. The app will then split the tax and tip proportionally/equally, so everyone knows what to pay. The experience with this app, however, was frustrating for several reasons.
Associating a person with a colored plate is a hard thing to do quickly and be able to recall. The app indicates which plate is you, but does not give any opportunity to name any of the other plates. Thus, when using the app, I found myself constantly forgetting which of the 8 plates corresponded to which of the 8 people at the table. This annoyance could have been easily subverted by a UI element for each plate representing the plate’s identity.This problem certainly could have been caught by coming up with alternative designs and testing the design with users: I can’t imagine any user splitting a bill of more than three people and not having this problem, and there are several other ways the diners can be represented (e.g. they could have photos of the diners or labels).
At the end of the bill-splitting flow in Plates, you can choose to drag plates together to combine two people’s bills: this is useful if one person chooses to cover the cost of one or more other people. The frustration in this section came from the fact that the UI does not allow you to drag plates away from a “plate group” once they’ve been dragged in. Because of this, I once dragged in the wrong plate and thus the entire utility of the app was lost because the totals were no longer correct. This problem certainly should have been addressed by evaluating the design-- real users must have had this problem, and if Plates had been able to see that and change it then I believe the problem would have been addressed very soon after release.
When splitting the tip of a dinner bill, everyone either pays proportional to what their share of the meal cost or splits a flat tip percentage of the total bill equally. While I was thinking about how the bill should be calculated by Plates, I figured that it would try to do equal tip splitting, but I thought that we should do it proportionally instead, since some of us had ordered alcohol and thus accounted for a large portion of the meal that I felt should be reflected in the tip. However, Plates makes no mention of splitting the tip either way, with no option to change it, and because I can’t do fast decimal multiplication in my head, I couldn’t immediately see how the tip was being calculated, and thus I wasn't sure that everyone was paying what they needed to. Tip splitting is certainly an important task that designers should have thought of when understanding their users and their users’ goals, and this problem could be fixed by establishing requirements based off of evaluating what users do when using the app.
I have always been an avid user of Snapchat but one thing that frustrates me is its user interface. Last week, I snapped a picture and sent it to the 15 members of my club. However it took an extremely long time to go through my entire friends list of 150+ people to select those 15 people because the friends list is sorted alphabetically. Today I wanted to do the same thing and was extremely frustrated that I had to repeat the entire process again.
In order to improve on this system we have to first figure out who is going to use this app. Most people using this app are teenagers and young adults. Most teenagers aren't going to have just a couple dozen of friends added; they're going to have hundreds. Recognizing this issue would make it necessary for an easy way to organize people on their list of friends. A representative task for this app would be for someone in this target demographic to snap a photo and send that photo to fifteen friends who are in the same club.
Next it would be best to plagiarize the way that Facebook sorts its messenger. Currently, Snapchat has three ways to sort your friends: best friends, most recent, and alphabetically. If you have 15 people to send your snap to, and only one person is on your best friend's list and one person is on your most recent list, then any of these methods are useless. The way Facebook allows you is through the following three ways: suggested friends, your own groups, and alphabetical. This method is much more intuitive, because if you wanted to send a picture to people from the same club, you could just make a group on Snapchat for that club, then snap the photo, select that group, and send it. Then the next time you want to send to the same group, you would not have to select each person individually again. Next using GOMS analysis and figuring out how many steps it would take for someone to add a group and send multiple photos to that group will verify the need for groups in the app.
I believe that adding a group function to the Snapchat friend list will surely make the lives of its users less frustrating and hopefully they do so in the future.
When entering a recurring event into Google Calendars, you’re able to choose how often you want an event to happen, daily, weekly, every weekday, whatever you want. These options are listed as a 7 checkboxes, one for each day. However, if you select all days M-F and try to update the days the event is supposed to recur, the checkboxes disappear and they show up as “Daily” instead. The only way to reassign the days is by deleting the event and creating a new event. Whoever designed the interface must have reasoned that switching to “Daily” makes it more convenient to easily view which days have been selected, which is true. However, it prevents the user from updating their preferences.
(This response would receive a 1 because it does not relate the user’s frustration to the design process referenced in the reading.)