I have a wide span of skills and interests. I see and utilize the power of artificial intelligence in solving accessibility problems, yet openly learn and explore by collaborating with experts in design, sensing, fabrication, etc.
I love ideating, modeling, designing, coding, as well as prototyping.
面试反倒很顺利，甚至在被问到选校时几乎不假思索地脱口而出，“UW is my first choice.” 不知不觉半小时的面试聊了四十五分钟，聊得愉快到紧接着的下一场UMich面试全程都强打精神，兴味索然。
一月底二月初的那一两周是最难熬的。面试结束，杳无音讯。那周恰好是学校的春季招聘会，在周一与老板见面时甚至和老板提到我想第二天去招聘会投简历，免得被所有项目全拒之后找不到出路。前脚老板刚刚出了办公室的门，我正瘫在办公桌前的椅子上绝望地放空思考人生，手机又振了一下，“Congratulations! It is my pleasure to inform you that you have been recommended for admission to the Ph.D. program in Information Science at the University of Washington Information School for autumn 2020.”
高中毕业的暑假在复旦模联做了一个会场，虚构的国际论坛，起名为World Forum of Inclusive Education。讲特殊需求人群的教育，不过那时对这个领域知之甚少，只凭着兴趣和一腔热血，连设计代表们的身份也只能依靠网络上搜索得到的信息，硬着头皮现学现卖。却义无反顾地做了，倒也有点初生牛犊不怕虎的可爱。虽然后来没有继续做教育相关的方向，但accessibility却成了我过去两三年、今后五年或许十年甚至更久的重心。
申请季写PHS的时候为了回顾自己上大学前后的经历，翻出了本科申请时交给CMU的文书。在里面写，“I imagine that one day at CMU I will work together with Human-Computer Interaction Institute (HCII) researchers to dig deeper into the connection between humans interfacing with technology.” 我又写，“With our efforts and the new technological approaches we design, I hope that one day my blind friend [name hidden] and thousands of kids in such situations will touch the world in a brand-new way and truly relish their lives.”
In this project, I designed and prototyped a wearable musical instrument with Arduino - instead of pressing physical keys, you simply need to tap on finger tips to play music.
Motivation
Music has always been an vital part of many people’s lives. However, as many musical instruments such as guitars and pianos are always huge in volumn, it’s always cumbersome to carry them around.
Introduction
Invisible Piano is a project that allows users to “play music in the air”, by using one’s finger tips as the “piano keys”. When you tap on different fingers using your thumb, the device recognizes which finger was touched, and thus you can play wonderful music without using any huge musical instrument, but instead just with your body.
Implementation
This project was developed with an Arduino Nano. The ten “rings” to wear on a user’s fingers are each connected to the Arduino, with each thumb connected to ground and all other fingers each connected to a different analog input pin. The controller identifys which finger has been touched by looking at the different input voltage from all the fingers, and with some smoothing to avoid jumping around, plays the key corresponding to that finger.
至于授课质量与课业量，没有亲历过因此没有发言权，还请国内与美帝都呆过的朋友来解答。但可以肯定的是，T大不是唯一一所将自己放在fly bitch一栏的学校，或许也不是唯一一所配得上fly bitch的说法的——这张图早几年就在CMU的fb memes group见过，那时流传甚广，甚至以我一点粗浅的了解，HYP的课业量也未必就轻松，只是课内课外，看得见得看不见的，各有各的辛苦罢了（题外话，于是身边朋友们也就习惯于，不行自己学，万事有Google，入门不成踹门进）。
I took a big part in this 2-year long project as the second author of the paper, and contributed substantially in every phase of the project - from brainstorming, to the ideation and implementation of the computer vision pipeline, then to iterations and refinements, and finally technical evaluations and user study.
Motivation
Blind people frequently encounter inaccessible dynamic touchscreens in their everyday lives that are difficult, frustrating, and often impossible to use independently. Touchscreens are often the only way to control everything from coffee machines and payment terminals, to subway ticket machines and in-flight entertainment systems.
We identified two major challenges in using dynamic touchscreen interfaces for visually-impaired users:
As the visual user interfaces change, interactions often occur over multiple different screens, and it’s always hard for users to label certain parts of the interface using traditional methods.
It is easy to accidentally trigger interface actions while exploring the screen.
System Design
Constructing state diagram
StateLens uses a combination of Screen Detection, SURF and OCR to match the current video frame with reference states and decide whether to send to crowdsourcing pipeline and add it as new state.
Generating path from user-specified task
With user-specified task through conversational agent, StateLens generates a target (state, button) sequence to achieve the task.
Identifying current screen
StateLens uses SURF combined with detected user interaction points from camera to identify which state the user is currently on.
Providing guidance to complete task
Based on the detected state, StateLens reads out screen description and guide users to move their finger towards the target button.
Conversational Agent
The agent can be automatically generated from the state diagram of the interface and allows users to pre-specify the task to perform.
3D-Printed Accessories
The 3D-printed accessories allow users to explore touchscreen interfaces without accidentally triggering touches and then touch when they need to.
Results
In our technical evaluation, StateLens achieved a relatively stable error rate of 5% in identifying the current state. The matching time is also fairly stable for different sizes of interfaces around 0.2 seconds.
In our user study, users spent an average of 110.1 seconds to complete a task and the overall task completion rate was 94.7%. In subjective rating, users reported the StateLens app to be easy to learn (5.5/7), comfortable to use (5.6/7), and very useful (6.1/7). They also found the audio feedback was in real-time and accurate (6.1/7).
State diagram construction accuracy by interface
Matching scalability and robustness
For more details, please check out our paper and poster.
Rain Queen
In this project, we designed and prototyped a heat-sensitive drag queen camping technology with morphing materials. With both advocacy of inclusion and consideration for practical use in our design, we made a prototype of Rain Queen, which transforms from a regular cloth shape into a more dramatic look when the environment temperature increated.
Background
We got our inspiration from the drag queen persona Pattie Gonia @pattiegonia on Instagram, played by artist and photographer Wyn Wiley @wynwileyphoto. While most queer communities nowadays are concentrated in big cities, Pattie Gonia brings drags and advocacy from cities to outdoors and in the wild.
Introduction
When the environment temperature increases, a simple tendon structure turns this poncho dress into a more dramatically regal structure. The pulley system is reactive to a mechanical circuit, driven by our heat-responsive linear and bending actuators.
This rain queen design is not just a drag queen camping technology, but also an act of placing LGBTQ+ groups at the center of design through compassionate attention.
Water Collection
In addition to the drag queen camping idea, we also hoped to add some practical camping functionalities to this design - water collection. As the shape transformation is triggered, the morphing system changes from a dormant shirt’s shape to a regal water collecting vessel.
Morphing Mechanism
We hoped the drag queen “second skin” to have automatic shape transformation in response to the surrounding environment, thus we designed two types of morphing mechanisms responsive to temerature change - a linear actuator and a bending actuator.
The idea behind both actuators is that the state of the actuator is dependent on the amount of air in it. The the actuator is heated with the increas of temperature in the surrounding environment, the liquid sealed inside the actuator becomes vapor, thus increasing the amount of air inside of it, triggering the shape change of the actuator.
The bending actuator has a small air bag on each of the hinges, and each air bag contains a small amount of Novec 7100, an alcohol-similar liquid with a very low boiling temperature. When heated, the air bags are “blown up”, thus triggering the bending of the actuator.
Under the similar idea but with a different geometry, the linear actuator shrinks in length when more air is contained in the actuator.
Lorem ipsum dolor sit amet, usu cu alterum nominavi lobortis. At duo novum diceret. Tantas apeirian vix et, usu sanctus postulant inciderint ut, populo diceret necessitatibus in vim. Cu eum dicam feugiat noluisse.
Hebo 2.0
In this project, my teammates and I conducted extensive user research at the UPMC Falk clinic with patients after Mohr's Surgery, among which were mostly older adults. By understanding users' needs during the post-operative care process and in older adults using technologies in general, we came up with the design of a mobile post-operative care asssistant, Hebo 2.0.
Try out our interactive prototype!
Background
After a patient undergoes Mohs surgery, they typically have questions and concerns about their postoperative treatment. Before and after surgery they are given explicit instructions on how to care for themselves and also provided with an instruction sheet to take home with them. Unfortunately, many patients struggle to remember and to interpret the basic instructions that are provided to them. Therefore, patients require support from clinical staff over the phone or in the clinic to address common concerns. Moreover, staff members often have to dedicate significant portions of time to communicate information already provided to the patients.
Stakeholders
We created a stakeholder map dividing our stakeholders into several parties, based on their interactions with patients in post-operative care. The surgeon who carries out the surgery; UPMC staff who help patients change dressing, call patients for check-up and answer questions; patients’ immediate family, extended family, and friends and community who might take care of them during the post-operative process.
User Research
We did job shadowing and conducted interviews with both clinic staff and patients to better understand their needs and existing challenges in the process. To better understand their feelings, we included activities such as card sorting in our interview process.
We then came up with a journey map for nurses and patients, which helped us better understand the goals and needs of these stakeholders. We looked at the surgery procedure by the six phases: diagnosis, pre-surgery, during surgery, right after surgery, 48-hour post-surgery, one-week check-up and later. For each phase, we discussed patients’ emotions and thoughts, their tasks and touchpoints, in order to better understand each part of the surgery process and discover opportunities. Based on that, we used sticky notes to discover existing pain points in different phases of surgery, especially the post surgery phases.
To better understand patients’ experiences during post-operative care at home, specifically during the dressing change process, we did further empirical research and tried to change wound dressing for ourselves like patients after the Mohr’s surgery.
Takeaways from User Research
We summarized our takeaways from user research into the following key insights:
Patients need more help when they start with hands-on post-operative care on their own.
Patients need to be assured that what they are doing / feeling is normal.
Patients’ feelings and emotions affect their post-op decisions.
Patients want personalized care.
Visual representations and written out text are important for post-operative care for the predominant demographic of skin cancer patients.
Some patients hesitate to seek for help from family/staff due to personal reasons. (e.g. being too independent, not wanting to burden family, thinking they are probably fine)
Patients want immediate response to their questions while clinic staff don’t want their workflow to be interrupted.
Patients require simpler ways to find post-operative care dos and don’ts.
Storyboards
Lo-Fi Prototype
Mid-Fi Prototype
Iterations & Refinements
To test out our mid-fi prototype and improve the design, our team conducted three rounds of user testing in the UPMC Falk clinic. We tested the prototype with various different potential user groups of the assistant, including clinic staff (residential doctors, physician assistants, and nurses) as well as patients. During user testing, we set different scenarios for our users, including being discharged from the clinic, changing dressing at home for the first time, concerned about bleeding, and feeling pain.
Overall, we received very positive feedback during the three rounds of user testing in the clinic. Except for feedbacks on the design of the assistant, we’ve also put a lot of focus on the accuracy of medical terms and processes to ensure that the assistant gives correct instructions and suggestions, and received valuable feedback during user testing.
Based the feedback we received during user testing, our refinements mainly focused on:
Improving usability and accessibility of the app
Adding more feedforward and feedback to make the app more intuitive
Adding conversational features to allow hands-free interactions
Changing certain wordings to make sure medical terms and demonstrations are accurate
Having detailed stepwise breakdown of processes to guide users step by step, with explanations on each step
Establishing trust by giving encouraging feedback to users
Making action terms clearer and adding more error prevention features
Lorem ipsum dolor sit amet, usu cu alterum nominavi lobortis. At duo novum diceret. Tantas apeirian vix et, usu sanctus postulant inciderint ut, populo diceret necessitatibus in vim. Cu eum dicam feugiat noluisse.
In this project, we explored the speedup of parallalizing the LDA algorithm for text classification, by implementing multiple different versions of parallel LDA using OpenMPI, and testing out the performance with different synchronization policies and different numbers of processes.
Background
Latent Dirichlet Allocation (LDA) is a widely used algorithm in text classification, which clusters word occurrences into latent classes (i.e. topics) after iterations of parameter learning. As the sampling process is extremely computation-heavy for large data sets, we implemented parallel LDA in this project and experimented with its performance.
LDA at a Glance
Method
Parallel LDA workflow:
Split corpus by document
Each process runs local Gibbs sampling
Master gathers updates and send back to each process
Implementation
We implemented two variations of parallelism LDA using the OpenMPI library - the synchronous version and the asynchronous version. We also added staleness in our implementation.
Synchronous Parallel LDA: updates broadcasted to all processes
Asynchronous Parallel LDA: each process send local updates to master after a few iters, keep on sampling, and updates upon receiving new table
Results
Discussion
How does the parallelism scale?
Close to linear speedup until up to 6 procs, and gets smaller after but still achieves 9x with 16 procs.
What’s the tradeoff between log-likelihood & speed?
Learned parameters will be more “stale” as the staleness gets larger. This gets us faster speed, but sometimes might decrease the objective function (log-likelihood) as a tradeoff.
Speedup comparison of sync vs. async
We expected async version to be faster, but since there’s not much work imbalance in sync version, and for async the master takes on more work updating the tables based on messages from each process, the speedup for both are about the same.
Conclusion
Our implementation of parallel Latent Dirichlet Allocation achieves an overall good speedup compared to the sequential version. For future work, better asynchronous update rules might be designed for better work balance to further improve performance.
“I want all of our Jewish students to know that we love you.”
“Now more than ever we need to emphasize diversity and inclusion.”
“I want you to know that I’m here for you. WE are here for you.”
“….regardless of your race, belief, or political position. Because we are all humans: we all have someone or something we love; we all feel the pain of loss.”
“But we all know that life goes on, in many ways - that baby less than a mile away; and all of you.”
在Facebook上很多orientation staff里的朋友都在转募捐消息或是新闻报道，看到“No matter where you are from, we’re glad you’re our neighbor”的标语，松鼠山的路口雨中密集的人群和烛光，以及我最喜欢的OL引用的一篇评论中的某句，“…when we see someone in our communities who doesn’t look like us or think like us or pray like us, we still need to think: ‘us.’ We need to find ways to make all of us better off — respecting differences and seeking compromise.”
枪击发生的那条路就在三年里我去过无数次的松鼠山，很多朋友家的楼下几十几百米。在路上擦肩而过很多犹太人，而不过一个多月前我们的701犹太人教授还因为犹太新年给全班放了一次假。一切都是触手可及的，所以尤为震惊，尤为愤怒。“Screw your optics, I’m going in”, 我以为这是纳粹才说得出的话，做得出的事；川普一如既往地以暴制暴，“Those seeking their destruction, we will seek their destruction.” 而国内媒体新闻推送下的那些拍手叫好更教人心寒。
In this project, we explored means to "tell the story behind the scene" through AR. Developed using VuforiaSDK and Unity, this mobile app recognizes art works in the camera view and displays text descriptions of it, such as title, author, background, etc.
Motivation
When you walk into a museum, it may be very hard to understand the art works, especially if you don’t have much of an art background. The short descriptions by the art works are sometimes too small to read from far away, but you don’t want to block other people. What to do then?
Introduction
Scene is a project that helps users understand art works with simple and straightforward augmented reality assistance. It helps you understand art works by storing a big number of art work descriptions in the database. Whenever you point your phone camera to an art work, it matches with the art works in our database, and displays the descriptions as text floating above the art work on your screen. In this way, you can have a full view of the art work without having to walk very close to look at the descriptions on the wall.
Implementation
This project was developed using the Vuforia AR SDK. The on-screen interactions were created in Unity and C#. We used the Vuforia built-in image recognition feature to match with the pictures of art works we store in the database, and then display relevant text we grabbed from Wikipedia to the users.
In this project, my teammates and I designed a mobile app for the local non-profit warehouse Construction Junction. Through preliminary research and after identifying values and needs, utilizing multiple interactions design techniques to help with our brainstorming, we came up with a smart furniture retail app using augmented reality.
Background
Construction Junction is a large, non-profit warehouse in Pittsburgh, PA supplying surplus construction materials & appliances at reduced prices. Our goal for this project was to design a mobile app for Construction Junction utilizing unique features of smartphones such as camera and sensing.
Research
We found that Construction Junction was listed as one of only three reuse/recycle centers in Western PA. Thus, we learned that our app did not need to introduce a competitive edge to the business, but could focus on enhancing and promoting its core values of sustainability and education. This would become a key component of our long-term road map moving forward.
Our preliminary research also looked at who was involved with Construction Junction and how these different groups interacted with each other. We isolated employees/volunteers, customers/donors, and community/environmental groups. We noted that the primary thing these groups all had in common was the mission of promoting reusability of products and sustainability, and this helped guide the general theme of our design and our overall idea of forming a community around Construction Junction.
Ideation
Establishing Value Flows
Using the research we collected about Construction Junction, we began to investigate the interactions between different users and stakeholders to isolate opportunities for our intervention by creating value flow diagrams. We noticed that there are various different ways users can interact with the company (as donors, buyers, volunteers) and started to focus in on how we could improve users’ interactions with Construction Junction.
Challenging Assumptions
We started looking at what assumptions might exist around construction material shopping, and explored possible interventions our app could make by breaking these assumptions to improve the user experience. One important assumption we identified was that customers had to view the products in person to get an accurate idea of how they might fit into their space, which would become key to our proposed app.
Narrowing Problem Space
Based off our ideation process, our team isolated a huge opportunity in addressing how user’s browse for products online, and decided to approach the problem starting first with space and style constraints. This way, we can maximize the utility of the tool for users by filtering options by what can actually fit in their rooms and what will fit their style, rather than showing users the entire catalog.
Iteration and Refinements
To visualize how a CJ buyer would use our app, we each drew a complete flow of the app from creating a project to the wishlist. We focused on two native app features: the AR measuring tool and horizontal swipe to browse. Interestingly, we each had different visual style and emphasis in our low-fi prototype. We then chose screens from each design and combined them to become our final low-fi prototype.
From the low-fi prototype sketches, we narrowed down to 5 screens that highlight the flow of our app. Then we digitized the wireframe sketches and determined the details of the in-between steps. The process of digitizing our sketches helped us identify details we did not consider before. Because our app show inventory results based on user input, we realized a logical sequence is crucial to creating a smooth user experience and to generating useful, insightful data.
In this project, we researched on existing challenges in peer-to-peer furniture exchange, and designed a cross-platform application to address shipping problems during the process. My teammates and I first brainstormed ideas through collaborative sketching and storyboarding, then iteratively improved the design through various rounds of design critique and refinements.
Motivation
“I hate moving.”
Moving furnitures from one place to another has always been a suffer for both customers and sellers in furniture exchange, especially when neither the seller nor the customer has a car. We’ve seen a thousand times “pick-up only” desks or bookcases on Facebook sales pages, and decided to ignore even if they look decent - just because it’s hard to carry the furnitures home.
Literature Research
To get started with our design for the furniture exchange application, we first did some literature research on the topic.
By searching for some papers and articles on the furniture industry, we gained some basic understanding of the market, different roles involved in the exchange process, and the key factors of value creation during the process.
The pictures above both describe the furniture industry in different forms of representations, and are from the articles “The globalization of product markets and immiserizing growth: lessons from the South African furniture industry“ and “Value co-creation among retailers and consumers: New insights into the furniture market”. From these articles, we found some common key factors of the furniture industry under different contexts - one important factor is shipping / delivery, which is quite unique to furnitures compared to other types of products in market.
We also listed out a few of our competitors, including Ebay (as a general item exchange website), Facebook For Sale Groups, Craiglist, etc. These different competitors show different approaches of furniture exchange currently existing in the market, yet all have different advantages and disadvantages.
By comparing our competitors, we found that lots of successful furniture exchange systems are based on geographical locations. We also found some common existing problems:
Right now most furniture exchange websites look very similar to retail websites of other kinds of products, and do not address or emphasize special or important features for furnitures.
Shipping might be a big issue.
How Dispatch works to improve both customer and seller experience
Storyboard
Lo-Fidelity Prototype
First Iteration
During critique, we received some comments on our scenarios, the screen maps and the lo-fi wireframes:
Customers and sellers always seek for lower ship- ping price, and we need to add price information in our design.
Uber is already existing in market, and we need to figure out unique features of our design to make it stand out in the market.
Convenience is big concern for most customers and sellers, and our current design was not re- solving that problem perfectly.
Based on these critiques, we refined our design and made the below modifications:
We added the price page in the sketches.
We added more details in options for delivery and pickup: for example, the specific time of delivery.
We limited the scope of our design and started focusing mainly on the driver part because that’s the part that creates the most value.
Moodboard
Second Iteration
During the second round of critique, we received more comments on our design:
Some furnitures are too large and too heavy for one person to carry, so sometimes drivers need people to help with carrying the furniture.
Some furniture might not fit into all types of cars, especially smaller ones.
Sometimes people lie about being at home, so there’s a possiblity that the seller is not at home waiting for furniture pickup when the driver arrives, and it wastes a lot of time.
It would be helpful if people can schedule ahead.
Based on these critiques, we further improved our design.
When the user clicks on the route of delivery, it will expand to a page of furniture details, including the name, picture, color, dimensions, and weight.
On the product information page, the number of people required to carry the furniture will also be displayed, so that drivers will get prepared for carrying large furnitures. This information is inputted by the seller, and the seller need to pay extra fees for requiring extra people.
When someone registers to be a driver, he or she needs to enter the type of car he or she possesses. The app automaticaclly checks for the type of car required to deliver the furniture based on its dimensions, and will show a little green bar indicating that the driver’s car satisfies the requirement.
Jet.com is an e-commerce company founded in 2014 and later acquired by Walmart. During my summer internship at Jet.com (summer 2017), I designed and created the company’s first automated pipeline to analyze customer calls and emails and provide meaningful insights.
The pipeline first transforms audio files of customer call recordings into text transcripts through speech-to-text APIs, and preprocesses these text transcripts as well as customer emails by cleaning up the data and removing customers’ PII (personal identifiable information) from the text. Then it runs sentiment analysis and extracts keywords from the text, and identifies relevant products mentioned in the calls and emails. The above information for each customer call and email is automatically generated and stored to the company’s database, and can thus be used to generate summaries of products and issues mentioned in customer calls and emails over time.
Kara
In this project, my teammates and I designed a conversational user interface for meal ordering for a group of people, and can support various scenarios such as home parties, company meetings, field trips, etc.
Introduction
The name of our CUI product is “Kara“, which sounds like a name of a friend and is easy to pronounce.
To design a CUI that simplifies group ordering process, we first researched on existing CUIs on the market and explored various scenarios that people might use them. With our initial version of our group ordering CUI, we kept on doing experience prototyping and made storyboards to explore more user needs and added more features to our design.
Concept Video
Ecosystem Collection & Competitive Analysis
To better understand the current market, we did a competitive analysis by looked at four existing conversational UI products currently on the market: Google Home, Microsoft Cortana, Apple Siri, and Amazon Alexa.
We created a competitive analysis matrix that compares the unique features, strengths, weaknesses, speech recognition performance, and voice friendliness of the four CUI products. More closely related to our project, we also checked whether or not the four products support food ordering, and where do they order from.
It turned out that Microsoft Cortana and Apple Siri do not take food ordering at all, and Google Home and Amazon Alexa both only support a very limited range of restaurants, such as Domino’s.
We also looked at the currently existing CUIs and listed out their user flow as a reference for our food ordering CUI design.
Scenarios
We brainstormed on different scenarios where people might be needing our CUI to order food, and wrote a short story to describe the context for each of the scenarios. The scenarios we discussed about are as below.
A student working on his/her homework at school at midnight
A person working late at home
A party where a lot of people order to- gether
People working at a startup in a meeting ordering food
Patients in a hospital hoping to get food
Sick people who cannot get up easily
A person on a diet trying to control his/ her calories intake everyday
A person with a healthy lifestyle always asking for calories before eating
Someone allergic to a type of food who wants to avoid that ingredient
Someone craving for a certain type of dish, like Japanese food or Korean food
A person ordering food while in a car
With the information we got from our research, we decided to work on a CUI that takes group orders.
We name our CUI Kara, since it sounds like a name of a friend and is very easy to pronounce. We then listed out some activities that we want Kara to support.
Experience Prototyping
We went through experience prototyping to figure out more user needs that we didn’t discover in our design process. We asked a few other groups to act in our scenario and recorded what questions they asked and what confusion they had.
During experience prototypring, some people were confused about the food options - “Does it only have pizza ordering, or does it have something else?“; some people raised allergy problems and asked Kara to check for ingredients of food; some people asked for suggestions, like “How should I order?“ or more specific concerns like “I think there are too many chickens in the group meal.“
Critique & Refinements
Based on class critique, we refined our design and added some features that we didn’t consider.
Personality (being sassy, hahaha, that’s what I do)
Users not pronouncing correctly and Kara trying to find what they actually mean
Vegetarion option; allergy stuffs
More prompts when users are confused or forget what they are doing
Asking for something not on the menu causes Kara to look for other restaurants
Remind user after a minute in case they forget (hey, are you still there? Let me know when you want to continue with it, etc.)
If user doesn’t know exactly how many people are in the group, she uses the upper bound
Prepared to answer “stupid questions” (how do I pay)
Searching on Google for general questions (what is Yelp)/One-sentence description (what is this place)
Summarizing our findings in the experience protyping and during critique, we revised the range of activities we want Kara to support, added small talks to our design to make Kara more humorous, and included error handling in case Kara has difficulty handling user input.
Storyboard
Flowchart
To get prepared for the flowchart of our final design, we went through our refined pre-attentives and attentives, and listed out the utterances and responses for each attentive using stickers.
In the “order food“ attentive, we included multiple features of setting delivery time, recommending food types and restaurants, reminding of utensils, reminding of drinks, detecting change in location using GPS, etc.
三十一号那天下午一个人在Gates四楼吃盒饭，盘算着马上写些什么作业的时候，手机忽然响了。“Judy? There are flowers for you. I’ll be at CMU in a minute.” 挂了电话冲出大楼，楼外面下雨，雨很冷，又忘记穿外套，就淋着雨一路小跑到校门口，快递的小哥笑盈盈地捧着花，“Happy birthday.”
In this project, we designed a mobile app for parents to track their kids' safety on the way home, and I worked on the front end development of the app using Android Studio, as well as integrating other parts done by the other team members.
Motivation
Safety of kids on their way to school and on their way home has always been a big concern for parents. Our app provides a way for parents to track kids’ safety on their way using location of kids provided by the Google Maps API.
Implementation
We implemented the app using Android Studio and made use of the Google Maps API to retrive real-time location of users. Whenever a child starts walking home from school, they can click on the “start” button and we will send the location information of user to our back-end database. Based on the destination location entered by the user, we use the Google Maps API to provide an estimate of how much time is needed along the way. Our backend will send the parent an email when the walk starts or when the walk takes much longer than expected. We also designed a “help” button on the main page so that the kid can click on the button in case of emergency and our backend will immediately send an email to the parents to notify them.
我时常听人抱怨，“今天心情不好，因为上次的作业TA给我扣了两分不该扣的分”，抑或，“I did so bad in this exam and I’m dying with 251.” 大家在朋友圈里津津乐道那些所谓全美作业量最大最辛苦的大学排名，炫耀着卡梅无一例外地上榜，像是某种光宗耀祖值得称道的荣誉。
巴黎恐袭的那天晚上，朋友圈里除了祈福和报平安以外，就是流传着关于ISIS的攻击目标的传言，“Rome, London, and Washington DC will be next.” 紧接着是新闻说，ISIS在美国十五个州有潜伏的人手。正当大家强颜欢笑地安慰自己，匹兹堡这样没有存在感的小城市大约不会有人在意，匹兹堡市长又突然宣布继续接受叙利亚难民并愿意接受从宾州其他城市转移来的原有难民；德州警方发现疑似ISIS恐怖组织携枪进入某栋大楼被当场拦下。如此种种。
