Group work and collaborators
This concept was developed during the first Social Robot Design session as part of Group 1. The purpose of the session was to explore an ill-defined social robot design case, select useful design methods, create an initial problem-space mindmap, identify possible building blocks, and translate the concept into an early functional breakdown and experimental approach.
The work fits the main direction of the course: the goal is not to immediately build a finished social robot, but to develop a tool or method that helps designers investigate what kind of robot interaction is needed in a specific context.
Collaborators:
Maurits Dijkman, Bianca Filip, Ewoud Janus, Emilia Pavel, Rebecca van der Lee, and Gijs Vis.
My contribution:
During the session, I contributed to defining the pet anxiety case, formulating the research question, discussing the selected design tools, creating the mindmaps, identifying possible building blocks, and developing the first experimental approach. After the session, I further developed the material for my individual portfolio by rewriting and structuring the text, improving the figure captions, making the design-tool focus more explicit, adding academic grounding, and reflecting on what the first brainstorm changed in the design direction.
1. Case description
Domestic pets, especially dogs and cats, can experience stress or separation-related anxiety when they are left alone, enter a new home, or encounter unfamiliar stimuli. For this session, we narrowed the case to the following working scenario:
A recently adopted dog lives with a student or young professional in a small apartment. The owner regularly leaves the home for several hours. During these absences, the dog may show anxiety-related behaviours such as pacing, vocalising, destructive behaviour, avoidance, or restlessness. The owner wants to support the dog, but does not know which type of interaction would help without increasing stress.
This is relevant for social robot design because the robot would not only need to perform a technical action, such as moving or dispensing a treat. It would also need to interact in a way that is understandable, safe, non-threatening, and adjustable to the individual animal. A movement, sound, smell, reward, or play gesture that is engaging for one animal might be frightening or overstimulating for another.
The direct user in this case is the pet, because the animal is the one experiencing the robot’s movement, sound, proximity, and interaction behaviour. The indirect users are the owner, the designer using the toolkit, and potentially an animal behaviour expert or veterinarian who may help interpret the animal’s response. This creates a specific design challenge: the system is designed by humans, bought or configured by humans, but experienced directly by a non-human user who cannot verbally explain its needs.
Because of this, our group did not frame the outcome as a single finished robot companion. Instead, we proposed a modular pet companion design toolkit. The toolkit would allow designers and pet owners to rapidly prototype, test, compare, and adapt different forms of pet-robot interaction. Possible modules include a treat dispenser, a moving tail, a toy movement mechanism, a speaker, a light module, a soft exterior, or a manually controlled puppeteering setup.
The aim is to discover which combinations of behaviour, movement, reward, embodiment, and interaction style may support play, comfort, or anxiety reduction for a specific pet, while also identifying which interactions should be avoided.
Research question:
How can a modular robotic design toolkit enable designers and pet owners to rapidly prototype pet-robot interactions that may help explore, compare, and reduce anxiety-related behaviours in domestic pets?
2. Visualisation of the case
Figure 1 shows the domestic context of the case: a pet alone in a home environment, the owner as an indirect stakeholder, and the robot/toolkit as a prototype for testing interaction possibilities. The figure makes clear that the problem is not simply "entertaining a pet," but exploring safe and adaptable interaction for a specific animal in a specific home context.
Figure 2 shows the stakeholder overview for the case. It shows the direct and indirect users: the pet as the direct user, the owner as caregiver and interpreter, the designer as toolkit user, and potentially an animal behaviour expert or veterinarian as an advisor. This helps clarify that the robot's value depends on both animal welfare and human interpretation.
Figure 1. Case overview: anxious pet at home.
Figure 2. Stakeholder overview.
TODO | Replace Figure 1 & Figure 2 with the correct versions (these are placeholders)
3. Quick literature check
To position the case academically, I looked at literature from two connected areas. The first area is adjacent-field literature on canine separation anxiety and animal behaviour. The second area is HRI/ACI-related literature on animal-computer interaction, animal-centred design, and robotic companions.
3.1 Adjacent-field literature: pet anxiety and animal behaviour
Ogata describes canine separation anxiety as an anxiety-related disorder that occurs when the owner is absent or perceived to be absent. This supports the case because the problem is not only technical or behavioural, but also emotional and context-dependent. It also suggests that a design intervention should not be presented as a universal cure.
Lenkei et al. show that separation-related behaviour in dogs can be associated with different inner states, including fear, panic, and frustration. This is important for the toolkit because it means that "anxious behaviour" should not be treated as one single category. A dog that is frustrated may need a different interaction from a dog that is fearful. For the design toolkit, this supports testing several interaction modes rather than assuming one robotic response will fit all cases.
Sargisson’s review suggests that behaviour modification, especially systematic desensitisation and counterconditioning, is an important treatment direction for canine separation-related problems. This influenced the design direction because the toolkit should not be framed as replacing behaviour therapy. Instead, it could support gradual, observable, and adjustable interaction routines. For example, a robot module could help test very small changes in movement, sound, or reward timing, while the owner or expert observes whether the animal remains calm.
Together, these sources show that pet anxiety is individual, gradual, and difficult to interpret from behaviour alone. Therefore, a modular toolkit is more appropriate than a fixed "one-size-fits-all" robot.
3.2 HRI and Animal-Computer Interaction (ACI) literature
Mancini's Animal-Computer Interaction manifesto argues that ACI studies interactions between animals and computing technologies in the contexts where animals normally live, act, and socialise. This directly supports the decision to design around the home environment rather than only around laboratory testing or owner expectations.
Mancini's work on animal-centred ethics is also important because it frames animal welfare as a central requirement in the design of interactive systems. For this project, that means the toolkit must include stop criteria, disengagement options, pet-safe materials, and careful observation of stress signals. The pet should not be forced to interact with the prototype.
Hirskyj-Douglas et al. review technologies in ACI and show that animal technologies include tangible, physical, haptic, wearable, scent-based, screen-based, and tracking systems. This supports the modular toolkit direction because our concept combines physical modules, sensing, movement, sound, light, reward, and possible smell-based interaction.
The DogPhone project by Hirskyj-Douglas et al. is especially relevant because it explores a dog-controlled video call device. The project raises questions about animal agency, power relations, and the difficulty of designing interfaces for animals. This influenced the toolkit by making animal choice an important design criterion: the pet should be able to approach, ignore, leave, or disengage from the robot.
Krueger et al. review human-dog relationships as a framework for human-robot attachment and robotic dog design. Although our concept is not primarily a robotic dog for humans, the paper is still useful because it shows how appearance and behaviour affect expectations and interpretation. For this project, it suggests that embodiment should be tested carefully: a dog-like or animal-like form may invite interaction, but it may also create misleading expectations.
A recent multispecies robotics example is Cat Royale, where cats interacted with a robotic arm in a designed environment. This example is useful because it shows that the design of the world around the robot matters as much as the robot itself. For the Pet Anxiety Toolkit, this means that the home layout, escape routes, safe zones, and owner involvement should be considered part of the prototype system.
3.3 Literature-based design implications
The literature leads to four design implications for the toolkit:
1. The robot should not be treated as a cure. It should be a design and testing tool for exploring interaction possibilities.
2. The animal's response must guide the design. Anxiety, fear, frustration, play, curiosity, and avoidance should not be grouped together too quickly.
3. The toolkit must support gradual testing. Small variations in movement, sound, reward, distance, and timing should be easy to compare.
4. Animal welfare must be built into the method. The pet should always be able to disengage, and the experiment should stop when stress signals appear.
4. Selection of useful design tools
During the session, we selected three method cards from the User Innovation Toolbox: Wizard of Oz, Hackathon, and Online Cohort Analysis. The selected cards are shown in Figure 3, while Figure 4 shows the explanatory back sides of the cards. These methods were used as starting points to discuss what each tool could teach us about the pet anxiety case. Together, the cards helped us move from a broad problem towards concrete design methods and supported the translation of each method into the pet-robot interaction context.
4.1 Wizard of Oz
Method:
Wizard of Oz is a prototyping method in which a system appears to behave autonomously, while a human manually controls some or all of its behaviour behind the scenes.
Application to the case:
Before building an autonomous pet robot, we can create a low-fidelity robot proxy and manually control its movement, sounds, lights, toy movements, or reward timing. This makes it possible to test interaction patterns without committing to a final hardware or software architecture.
What this method can reveal:
Wizard of Oz can reveal whether a pet approaches, avoids, ignores, or becomes stressed by specific behaviours. For example, a sudden movement may be frightening, while a slow and predictable movement may invite curiosity. A sound may attract attention in one animal but cause avoidance in another. These observations can be translated into design requirements for speed, distance, sound level, timing, and stop behaviour.
Why this is HRI-specific:
In this case, Wizard of Oz is not only used to fake technical functionality. It is used to explore social and embodied interaction before autonomy is built. This is important because pet-robot interaction depends on timing, movement quality, perceived safety, and the animal's ability to interpret the robot's behaviour.
4.2 Hackathon
Method:
A hackathon is a short and intensive collaborative design event where participants rapidly generate and prototype possible solutions.
Application to the case:
A one-day hackathon could bring together students, designers, engineers, and animal enthusiasts. Participants could use cardboard, Arduino components, sensors, servos, pet-safe materials, toys, and treats to prototype different toolkit modules.
What this method can reveal:
A hackathon could generate many module ideas in a short time. It could also expose practical constraints such as safety, durability, chewing hazards, material choice, hygiene, battery placement, and ease of use. The method would be useful for testing whether the toolkit is understandable to other designers, not only to the original group.
Why this is HRI-specific:
The value of the hackathon is not just rapid technical prototyping. It can reveal how different people imagine pet interaction, what assumptions they make about animal behaviour, and whether the toolkit structure helps them design more carefully.
4.3 Online Cohort Analysis
Method:
Cohort analysis compares groups of users or cases that share characteristics. In this project, it can be adapted to compare different groups of pets and owners.
Application to the case:
We could study different owner and pet groups through surveys, interviews, online forums, or short diaries. Possible cohorts include owners of rescue dogs, owners of young dogs, owners of older dogs, owners of indoor cats, owners of pets with known separation-related problems, and owners who already use interactive pet toys.
What this method can reveal:
This method could reveal common triggers, owner strategies, pet preferences, and recurring failure patterns in existing pet technologies. It could also help identify which behaviours owners interpret as stress, boredom, loneliness, or play.
Why this is HRI-specific:
The method helps connect animal behaviour, human interpretation, and technology design. Since pets cannot verbally report their experience, the toolkit must combine owner observations with visible animal behaviour and careful experimental design.
Figure 3. Selected User Innovation Toolbox cards - front side.
Figure 4. Selected User Innovation Toolbox cards - back side.
5. Mindmap of the problem space
As shown in Figure 5, the mindmap was structured around the central question: "How can I invite you to play?" From this starting point, we explored movement, sound, toys, light, smell, personality, companionship, helping, and training.
The mindmap helped us move from a broad problem, anxious pets at home, towards a more specific design direction: a modular toolkit for testing which types of interaction may feel playful, calming, engaging, or stressful for a specific pet. The most important insight from this mindmap was that "play" is not only an activity. It can also be a way of testing trust, approach behaviour, attention, comfort, and overstimulation.
However, the mindmap also shows a risk. Many ideas were based on what humans assume pets might like. Therefore, the next design step should not be to choose the most attractive idea, but to create a method for testing these assumptions safely.
Figure 5. Initial problem-space mindmap created during the group brainstorm. The mindmap explores how a robot could invite an animal to play through movement, sound, toys, light, smell, personality, and companionship.
6. Potential building blocks
The brainstorm was then translated into possible toolkit building blocks. These are not final design decisions, but modules that could be combined, removed, or tested separately. Figure 6 shows the initial mindmap from the group session, where ideas were clustered around interaction methods, sensory cues, play objects, personality, and emotional needs.
6.1 Main platform
The toolkit needs a stable base that can hold interchangeable modules. This could be a class robot platform, a small controlled mobile base, or a low-fidelity cardboard prototype in the first stage. The platform should include a safe enclosure for electronics and batteries.
Possible elements:
- Controlled base or course robot platform
- Sturdy chassis
- Arduino, Raspberry Pi, or similar microcontroller
- Battery pack in a safe enclosure
- Mounting points for modules
- Emergency stop or manual override
6.2 Actuators and movement
Movement is central to the interaction because pets may interpret speed, direction, distance, and unpredictability as playful or threatening.
Possible elements:
- Servo motors
- Moving tail
- Simple robotic arm or toy-moving mechanism
- Drivable base
- Rotating feather or string module
- Slow approach and retreat movement
- Vibration or small mechanical movement
6.3 Pet-facing modules
Pet-facing modules are the parts of the toolkit that the animal directly experiences.
Possible elements:
- Treat dispenser
- Laser pointer
- Ball or toy launcher
- Moving feather or tail module
- Speaker for simple sounds
- Light feedback module
- Soft or fur-covered exterior
- Smell module using familiar, safe scents
- Replaceable toy attachments
6.4 Sensor input
Sensors are needed to observe whether the pet approaches, avoids, interacts, vocalises, or ignores the robot.
Possible elements:
- Proximity sensor
- Camera for observing movement and distance
- Microphone for detecting barking, meowing, or other vocalisations
- Touch or contact sensor
- Accelerometer for detecting module movement
- Manual observation sheet for early tests
6.5 Materials and safety
Materials are important because pets may chew, scratch, push, lick, or avoid the prototype.
Possible elements:
- Cardboard for low-fidelity prototypes
- 3D-printed parts for later prototypes
- Pet-safe casing materials
- Soft textile or fur-like materials
- Washable surfaces
- Rounded edges
- Protected wires
- Non-toxic materials
- Treats and toys selected by the owner
Figure 6. Building-block brainstorm created during the group session. The mindmap explores different ways a robot could invite an animal to play, including movement, reward, toys, sound, smell, light, personality, and emotional needs such as anxiety, boredom, stress, and loneliness.
7. Functional breakdown
The functional breakdown describes what the toolkit needs to do at the level of functions rather than components.
7.1 Sense behaviour
The toolkit first needs to sense or record the pet's behaviour. This includes detecting proximity, movement, sound, touch, and interaction attempts. In early prototypes, sensing can be done partly by human observers instead of automated sensors.
Relevant observations include:
- Does the pet approach the robot?
- Does the pet avoid the robot?
- How long does the pet take to engage?
- Does the pet vocalise?
- Does the pet show stress signals?
- Does the pet disengage or leave?
- Does the pet return after the robot stops?
7.2 Interpret behaviour
The system or observer then needs to interpret the pet's state. The interpretation does not need to be perfect, but it should distinguish between at least the following states:
- Curious
- Playful
- Avoidant
- Stressed
- Overstimulated
- Inactive
- Comfortable
This step is important because the same visible behaviour may have different meanings. For example, barking can indicate excitement, frustration, fear, or demand behaviour. Therefore, interpretation should combine sensor data, owner knowledge, and visible body-language observations.
7.3 Select an interaction
Based on the observed behaviour, the toolkit should help select an interaction type. Possible interaction categories include:
- Play invitation
- Calm presence
- Reward
- Mirroring
- Slow approach
- Retreat
- Stop interaction
- Owner notification
The most important design decision is that "doing nothing" or stopping should be treated as a valid interaction outcome. If the pet avoids the robot or shows stress, the appropriate response may be to reduce stimulation or end the test.
7.4 Act through a module
The robot then acts through one or more modules. It could:
- Move slowly
- Move a toy
- Make a soft sound
- Show light feedback
- Dispense a treat
- Move a tail or feather
- Retreat from the pet
- Pause and remain still
The toolkit should make it easy to test these actions separately. This prevents us from changing too many variables at once.
7.5 Log and compare outcomes
The toolkit should support observation and comparison. This can be done through video, notes, sensor logs, or a simple observation sheet.
Possible measures:
- Time until approach
- Time spent near the robot
- Number of voluntary interactions
- Avoidance behaviour
- Stress signals
- Owner interpretation
- Whether the pet returns after disengaging
- Whether the pet accepts or ignores a reward
7.6 Adapt over time
Over time, the toolkit should help adapt the interaction to the specific pet. For example, it could store which movements caused avoidance, which modules invited approach, and which interaction timings worked best.
This is important because the literature suggests that pet anxiety and separation-related behaviours are individual and context-dependent. A useful toolkit should therefore support gradual iteration rather than one fixed robot behaviour.
7.7 Fail safely
The toolkit must fail safely. This means:
- Stop movement when the pet is too close
- Avoid overheating
- Protect batteries and wires
- Prevent chewing hazards
- Avoid sharp parts
- Use pet-safe materials
- Allow the pet to leave
- Stop the test when stress signals appear
Fail-safe behaviour is not only a technical requirement. It is also an ethical requirement because the animal is the direct user and cannot give verbal consent.
8. Potential experimental approach
The first experiment should be low-fidelity and focused on discovering interaction problems early. It should not yet test whether the robot "solves" pet anxiety. Instead, it should test whether the toolkit helps designers identify safe, understandable, and adjustable interaction possibilities.
8.1 Experiment 1: Bodystorming with fake robot and fake pet
The first experiment uses bodystorming and puppeteering. One team member acts as the pet, while another team member acts as the robot using a physical proxy such as cardboard, a simple wheeled object, or a robot-shaped prototype. Figure 7 shows an example of this low-fidelity setup, with 'Seal' acting as the animal and Maurits (me) using a physical proxy to explore pet-robot interaction. The aim is not to imitate animal behaviour perfectly, but to reveal possible interaction problems before testing with real animals.
We can test questions such as:
- Does the robot block the pet's path?
- Does the robot approach too directly?
- Is the movement too fast?
- Is the sound or light feedback too sudden?
- Does the robot create a safe exit route?
- Which interaction feels like play, and which feels like pressure?
- Where should the owner be during the interaction?
The rest of the group observes, films, and takes notes. This fits the course focus on fake robots, fake users, Wizard of Oz, puppeteering, and theatrical exercises as ways to explore robot behaviour before building a final system.
8.2 Experiment 2: Wizard of Oz with a low-fidelity robot proxy
The second experiment would use a fake or semi-functional robot controlled by a human. The robot proxy can test one variable at a time, such as movement speed, distance, toy movement, sound, or reward timing.
Possible test conditions:
- Still robot versus moving robot
- Slow movement versus fast movement
- Sound feedback versus no sound
- Treat reward versus toy movement
- Direct approach versus side approach
- Robot moves first versus pet initiates interaction
Observation criteria:
- Approach or avoidance
- Latency to interact
- Body posture
- Startle response
- Vocalisation
- Time spent near the robot
- Voluntary return after disengagement
- Owner interpretation
Stop criteria:
- The pet freezes, hides, trembles, growls, hisses, or repeatedly avoids the robot
- The pet tries to chew unsafe parts
- The pet becomes overexcited or rough
- The owner or observer judges the interaction as unsafe
- The robot cannot be controlled reliably
8.3 Experiment 3: First real-pet test under supervision
Only after the low-fidelity and Wizard of Oz tests should the toolkit be tested with a real pet. This test should be short, supervised, and designed around the animal's ability to disengage.
A possible first real-pet test could use only one module, such as a stationary treat dispenser or a slow toy movement module. The robot should not chase, corner, or surprise the animal. The pet should have a safe route away from the robot at all times.
The goal is not to prove that the robot reduces anxiety. The goal is to learn whether the toolkit helps designers observe, compare, and adjust interaction ideas safely.
Figure 7. Seal (left) and Maurits (right), demonstrating a low-fidelity physical proxy for animal behaviour in a bodystorming exercise.
9. Experimental planning over 14 weeks
Because the course runs over several weeks, the project should leave enough time for development, building, iteration, testing, measuring, and validation.
Weeks 1-3: Case study and gap identification
We define the pet anxiety case, collect literature, identify stakeholders, and explore the problem space through mindmaps and brainstorming. The goal is to understand which part of pet companion robot design is difficult and where a design toolkit could be useful.
Weeks 4-7: Tool development and early prototyping
We develop the modular toolkit concept further. This includes selecting possible modules, building low-fidelity prototypes, exploring Wizard of Oz or puppeteering setups, and testing simple interaction ideas such as movement, light, sound, treats, and toy-based behaviours.
Weeks 8-10: Application and evaluation
We apply the toolkit to the pet anxiety case. This means using the toolkit to test or compare different pet-robot interaction ideas. The evaluation should address both the design outcome and the tool quality:
- Did the toolkit help create a better interaction idea?
- Did the toolkit make assumptions visible?
- Was the toolkit usable by someone outside the group?
- Did it support safe and gradual testing?
- Did it help decide what not to build?
Weeks 11-12: Report and presentation
We document the design tool, case, experiments, design decisions, and results. The final presentation or demonstration should show the toolkit in action rather than only describing it.
Weeks 13-14: Buffer, refinement, and final portfolio work
These weeks can be used for final improvements, extra testing if needed, cleaning up documentation, refining visuals, and making sure the group work and individual portfolio clearly show process, contribution, literature grounding, and reflection.
10. Pitch slide
Although the updated assignment description does not explicitly require a pitch slide, the original pitch slide is included because it summarises the concept clearly.
Figure 8 shows the pitch slide for the Pet Anxiety Toolkit. It summarises the core idea of the concept: a modular robot companion toolkit that allows designers and pet owners to test different interaction modules for anxious pets. The original slide is also available on Canva: https://canva.link/el69kek0ztsmts0.
Figure 8. Pitch slide for the Pet Anxiety Toolkit (PAT), summarising the concept of a modular robot companion toolkit for testing different interaction modules for anxious pets.
11. Reflection
This first session changed the design direction from "What robot should be built for anxious pets?" to "How can designers find out which interaction a specific pet can safely understand and accept?" This is an important shift because anxiety-related behaviour is not the same for every pet. A fixed robot companion could easily become too general, too stimulating, or even frightening.
The most useful insight for me was that the robot does not need to be fully functional at the start. By using puppeteering, low-fidelity prototypes, and acted scenarios, important design constraints can already be discovered. These include movement speed, safe distance, escape routes, sound level, material safety, and whether a pet can choose to disengage.
The first brainstorm also made clear that many early ideas were based on human assumptions about play. For example, a laser pointer, moving tail, or treat dispenser may sound attractive from a designer's perspective, but each of these could have negative effects if used in the wrong way. A laser pointer might overstimulate some animals, sudden movement might startle them, and food rewards might distract from whether the pet is actually comfortable. Therefore, the toolkit should support testing one interaction variable at a time.
The main improvement for the next iteration is to make the observation protocol more precise. Instead of only asking whether the pet "likes" the robot, we should observe approach, avoidance, stress signals, voluntary disengagement, and whether the animal returns after the robot stops. This would make the toolkit more useful as a design method and not just as a collection of robot modules.
At this stage, the Pet Anxiety Toolkit is still an early concept. However, it already fits the course direction because it focuses on tools and methods for social robot design rather than immediately building a final robot. The toolkit could help designers compare different interaction possibilities, make assumptions visible, and develop pet-robot interactions in a safer and more animal-centred way.
12. References
Hirskyj-Douglas, I., Piitulainen, R., & Lucero, A. (2021). Forming the Dog Internet: Prototyping a Dog-to-Human Video Call Device. Proceedings of the ACM on Human-Computer Interaction, 5(ISS), Article 494. DOI: 10.1145/3488539
Hirskyj-Douglas, I., Pons, P., Read, J. C., & Jaen, J. (2018). Seven Years after the Manifesto: Literature Review and Research Directions for Technologies in Animal Computer Interaction. Multimodal Technologies and Interaction, 2(2), 30. DOI: 10.3390/mti2020030
Krueger, F., Mitchell, K. C., Deshpande, G., & Katz, J. S. (2021). Human-dog relationships as a working framework for exploring human-robot attachment: A multidisciplinary review. Animal Cognition, 24(2), 371-385. DOI: 10.1007/s10071-021-01472-w
Lenkei, R., Faragó, T., Bakos, V., & Pongrácz, P. (2021). Separation-related behavior of dogs shows association with their reactions to everyday situations that may elicit frustration or fear. Scientific Reports, 11, Article 19207. DOI: 10.1038/s41598-021-98526-3
Mancini, C. (2017). Towards an animal-centred ethics for Animal-Computer Interaction. International Journal of Human-Computer Studies, 98, 221-233. DOI: 10.1016/j.ijhcs.2016.04.008
Ogata, N. (2016). Separation anxiety in dogs: What progress has been made in our understanding of the most common behavioral problems in dogs? Journal of Veterinary Behavior, 16, 28-35. DOI: 10.1016/j.jveb.2016.02.005
Sargisson, R. J. (2014). Canine separation anxiety: Strategies for treatment and management. Veterinary Medicine: Research and Reports, 5, 143-151.
Schneiders, E., Benford, S., Chamberlain, A., Mancini, C., Castle-Green, S., Ngo, V., Farr, J. R., Adams, M., Tandavanitj, N., & Fischer, J. (2024). Designing Multispecies Worlds for Robots, Cats, and Humans. Proceedings of the CHI Conference on Human Factors in Computing Systems.