Semester Final Reflection

When I first signed up for the class, I thought that I would be working on creating UIs and conducting A/B tests. Needless to say, I was far off. What I had not expected was that we would be creating entire user experiences, and alongside ID students. Being a part of this UX class has broadened my perspective about what is necessary to collaborate and build a successful, user-centric product, not simply an interface or app. It has incited me to question every decision made, and to make user-informed decisions whenever possible. Further, it has pressed me to research and figure out whether a technological feat is possible, and to communicate the reasons to someone from a non-CS background. Our class discussions about using machine learning (ML) as a design material remains one of the most interesting discussions I had in the first half of the semester. I had always seen ML as an additional feature to a product rather than an integral functionality in creating user-adaptive devices and software. I wonder how that discussion might have changed in light of recent Facebook privacy issues. Overall, this class has ripened my entrepreneurial spirit due to its focus on entire products, and cross-disciplinary interactions, not just focusing on the software implementation side.

As for the final project itself, I had not expected the breadth of experiences I would gain. Again, I thought I would just be implementing designs alongside the ID students. Probably one of the most daunting aspects about our final project for me was collecting user feedback. Finding parents to talk to and initiating the interviews did always incite some nervousness, but every parent I talked expressed extreme interest in Grocery Hop, and even shared that they thought it might be worthwhile to see it further after the class is done. That feedback really invigorated me and made me want to seek out what other parents thought. An unexpectedly difficult part about the project was trying providing the ID students the information they needed to help me implement the app. Since I was unfamiliar with both the programming language JavaScript and the framework React Native prior to this class, I was learning everything on the fly. Thus, I needed to learn how to implement components (or at least approximations of them) rather quickly, or otherwise spend a long time figuring out how to get exactly what I wanted. For example, it took me about 6 hours to understand how animations worked within React… just for a 5-second loading screen. In addition to that, I would sometimes have to contradict what I previously said to the ID people, as I was learning the technology more intimately. For example, separating the clickable and interactive components of a screen from the background, rather than having a single screen with everything already on it. So, I was able to become more knowledgeable about UIs and mobile app development along the way.

While in the end I never fully designed UIs, or conducted A/B tests on interfaces, I have witnessed myself grow in two valuable skills. First, working with new technologies has forced me to learn how to learn unfamiliar tech and concepts (and an estimation on how long it will take me), as well as troubleshooting my code which will inevitably never work the first time. Second, I have learned (more or less) how to go about building a concept into a product or future business, and who to recruit along the way. I definitely plan on putting these skills and knowledge to use in my future endeavors.

Reading #2 Response and Ethical Implications

AI as a New Design Material:

The author importantly notes that neural networks require huge amounts of learning data. Additionally, the data needs to be differential: both correct and incorrect so that the network learns the difference. I have seen many people make false assumptions about machine learning due to not understanding this principle. Due to the ubiquity of the buzz words, many equate ubiquity to its implementation. However, a great deal of work is involved which the author addresses such as defining correct solutions, time allotment to train and test the neural network, and immense data acquisition. You require twice the amount of data you might initially assume you need, not to mention that humans might have to prepare. The author notes some interesting solutions to this such as image recognition during a login screen, which I had not even considered to be for computer vision.

 

As a side note, another function for GPUs, which the author does not reference, is mining for bitcoins. Hence, with such high demand for GPUs concurrent with both AI and bitcoin especially, prices have become astronomical, with supply remaining intentionally low.

 

Back on track, another interesting concept the author notes is the magnitude of data tech companies harvest from people. They measure virtually all of your behaviors when you are using their products. This brushes on the principle of privacy; as more devices become sensors on our behaviors, to what extent these devices influence us when recommending our future behaviors, such as through advertisements or recommendations? It is interesting to see the author takes the approach that more machine learning is preferable. Clearly, the more data the better for the network, but the cost is people’s personal privacy. When one designs AI, one must also take into consideration the ethical implications involved. Are people consenting to the use of their information? Does profit emerge at the expense of privacy? Will nefarious actors use this information? The analogy to coffee brewing does not suffice. The author should have mentioned how designers must also take into consideration the security of the learning system they build. How are they preventing others from extracting the data? How might they prevent another machine from learning from the machine they taught? One might consider these scenarios when building the necessary infrastructure.

 

Challenges for Working with Machine Learning as a Design Material:

I appreciate that the authors note that unfamiliarity with ML is a source of apprehension to integrating ML. I sympathize due to my own unfamiliarity. I have not been exposed to machine learning in my CS curriculum, as the class has a few prerequisites and is not required, and as such understand that while ML grows in pertinence, curriculum always has to catch up rather than pioneer. Thus, a solution I find interesting is that classes such as these are integrating ML rather than dedicating an entire semester to parse its inner workings.

 

The authors also briefly mention an interesting field that could have many ML applications: medicine. The article specifically mentions detection of depression. Personally, I have seen many interesting projects try to address condition detection with intelligent systems. One such project involved an Xbox Kinect and Microsoft’s Azure cloud services. A user would pace back and forth a certain number of times to detect, if I remember correctly, stroke or some other kinds of brain injuries. In reference to the first article, this is another example of gaming technology influencing the capability of other non-entertainment fields.

 

Another interesting topic the authors discuss is the comfortability. Again, we should also consider the expense of pandering to the consumer. What if the machine learns to perpetuate culturally insensitive behaviors? What if, as in the case of Microsoft, the machine learns to be racist? The machine has a potential to encourage or reinforce societal degradations. Further, should we then be obligated to train out such behaviors, even if users are more complacent with a machine that matches their behaviors?

Ideas for Final Project

Group Members: Kylie, Defne, Vince, Ganesh

Sensing Infrastructure:

  • Wake-up sound system
  • Air refreshment / light systems
  • Water waste / general waste diminishing
  • Parking lot availability detection and prediction, with mobile app
  • Wait-time approximation sensor & predictor for dining halls

Retail 2.0:

  • People get paid for delivering groceries
  • Virtual dress rooms for size/ups – trial
    • Mixed Reality app that lets you see shoes for sale with 360 degrees, and next to your foot for size (could apply to other apparel as well)
  • System where you can scan as you shop and check out with a tab
  • Mixed Reality real-time text translations for international travelers or foreigners
  • Mixed Reality grocery store item locator

Sharing Transaction Economies:

  • Restaurant split payment
  • A better coupon app/deals etc.
  • Public Transportation Bitcoin
  • Mobile app instead of Facebook page for rides back home

Reading Response #1: January 26, Enjoying Experience

The “Making Sense of Experience” article paraphrases philosopher Bakhtin, saying, “experience… is incurably social, plural, and perspectival.” They discuss how this applies to loyalty on the internet to specific sites. Bakhtin somewhat addresses this as ‘perspectival’, and it might fit underneath the spatio-temporal thread, but more emphasis should also be placed on what I will call ‘comparative’. One might define personality as a collection of accrued experiences and thoughts. With a personal database of experience, better known as memories, a person will decide what to pursue based off of those previous experiences. In other words, each new experience is compared to previous ones. What is different? What is new? What is interesting? What is familiar? Did I like it or not last time? This aspect is rather obvious when creating new products; a user always brings their previous emotions to a new experience in accordance with a similar experience. Thus, while the article did mention this in its Appropriation section, it should have taken this more into account when discussing philosophy about experiences. For example, if I like using Facebook, starting to use Twitter would be related to enjoying Facebook, and then I investigate if Twitter has a novel functionality. If so, I might find it worth my time; if not, I would stick to Facebook. Thus, I am inherently comparing Twitter to Facebook in my experience of the two sites.

 

In “The Engineering of Experience” article, I greatly appreciate how the author talks in the concrete. If we look at the reading of articles as a human experience, one of the most exhausting and annoying ways to present information is to discuss the abstract… and then remain in the abstract. People like to sense what you are talking about; I want to be able to easily imagine and picture what you are discussing. Further, when I interface with someone’s writing, I want to be able to understand it without having to re-read it. I found the experience of reading this article much more pleasurable compared to the other because it was presented more concretely (with examples) and logically (with intuitive structure and descriptive headings). Most do not actually want to wade through ambiguous terms and convoluted sentences. I like how the author presents the user experience as a conversation, since the article itself comes across conversational as well. The author took the time to consider the user of his article.

 

 

Kylie’s & Vince’s Wallet Prototypes

Initial research into our target users indicated contrasting use cases. User #1 currently has a phone-wallet with a front-folding screen cover and an adhesively attached card holder on the back. User #1 expressed interest in maintaining additional screen protection with some sort of front-folding flap, keeping a wallet that doubles as a phone case, increased space for cards and cash, and having card storage encased rather than open. User #1 also suggested having a zipper-based approach to encasing the phone and extra storage.

In contrast, User #2 uses a thin, doubled-sided wallet pouch separate from the phone case. User #2 highly prefers the wallet separate from the phone case for a variety of reasons. User #2 expressed similar interests in increased storage, such as room for cash. User #2 also expressed mild interest also in incorporating some way to store keys.

Compiling the two users into a single list of requirements, we concluded our wallet needs:

  1. Adaptability: The phone-wallet should be able to convert between a wallet, a phone case, and a hybrid of both. The user should be able to choose the functionality of the product. To satisfy both use cases, this feature is of utmost importance.
  2. Storage: The phone-wallet should have above-average storage options. This will be able to accommodate cash in addition to multiple cards.
  3. Concealment: The phone-wallet should avoid having sensitive information and cash visible to others when closed.

Here is a compilation of brainstormed sketches coupled with chosen designs highlighted in blue:

Kylie & Vince Wallet Designs

Sketch Compilation

Prototype #1: Zipper Clutch

This slideshow requires JavaScript.

In the sketch compilation, its sketches are the second from the top on the left, and the second from the top on the right. While not implemented in the prototype, a zipper would encompass the entire perimeter of the phone, excluding the hinge. The left flap provides storage for multiple cards or folded cash, in addition to a pocket underneath the phone sleeve. The phone sleeve is made of clear plastic. If the user wishes to not use the plastic sleeve for a phone, it is also a great option for additional storage, such as a pre-existing card holder, but especially for identification such as a driver’s license. Finally, the zipper provides the concealment, but in a rush, the user could also place items freely in the middle of the wallet-case and zip it up. This case is more geared towards User #1, but also fully satisfies the functionality for User #2.

Prototype #2: Slide & Snap

This slideshow requires JavaScript.

In the sketch compilation, its sketches are located on the upper right and upper left. The defining feature of this design is that the phone case is a shell with rails on the left to attach a detachable left cover with card slots. This allows the user to detach the wallet functionality from the phone case functionality at will. Attachment/Detachment would be a similar process to a Joy-Con for the Nintendo Switch console. The left cover also has a pocket on the outer edge, with a zipper to provide concealment and additional storage for cash or keys (seen in the second picture).

Prototype #3: Accordion

This slideshow requires JavaScript.

In the sketch compilation, this is the bottom-most sketch. The modular, detachable approach introduced in the Slide & Snap inspired us to take a similar approach, but with attention the back of the phone. There will be a shell phone case similarly to Slide & Snap, but rails or a cutout slot will be on the back (as seen in picture 2). The wallet portion will be an accordion folder with partitions on the inside. The prototype uses a top flap instead of a clasp (originally shown in the sketch) to close and open the accordion. This will help avoid accidental openings of the accordion, and it also conceals. The accordion is great for storage because it expands with more insertions. Plus, it can expand to hold cash or keys. Note that the accordion is not hinged on the bottom, but rather has an adjusting bottom edge (as seen in picture 4). Since it is detachable, the wallet functionality can be separated from the phone case. The attachment mechanism could also have the accordion double as a belt-attachable wallet. Screen protection could be addressed with raised case edges, or another attachment as a left flap.
Future Iteration:

We believe there is promise in the modular detachments, which allows adaptability to a wide variety of users. Thus, future investigations will most likely look at different combinations of Prototypes #2 & #3 and additional permutations.