Kamerad
KAMERA-D
Helping people preserve their everyday moments while staying in the moment
Tools
Arduino, Cura, CSS, HTML, JavaScript, Node.js, Rhinoceros 3D, 3D Printing
Methodologies
design research, product research, futures wheel, surveys, online polls, interviews, affinity diagrams, empathy maps, as-is scenarios, ideation, moodboard, field study, diary study
Chapter I: Discovery
Theme
There has been a growing dissonance in people’s relationships with photography, especially in how and why they take photos. The dilemma of choosing between capturing the moment and being in the moment has become a modern predicament. Oftentimes, the moment is even modified using filters and photo manipulation tools to subjectively appear prettier, happier, and better. The ritual of photo-taking is changing at an exponential pace, which has drastically affected how people view and experience reality through the photos they take, see, and share. Thus, the challenge has now become a question of how to build a bridge between preserving the moment as it is and enjoying that moment.
Research Question
How can people who want to preserve their everyday moments through photos do so while staying “in the moment”?
- How will the user’s privacy and autonomy be respected?
- How can candid or natural-looking photos that best represent
reality be taken? - How can social media users avoid the pressures from social media to attain a certain beauty standard or lifestyle?
Product Research
To learn from how others have attempted to (1) address the ritual of memory preservation through photos and (2) allow the user the stay in the moment, I collected and analyzed six products that were developed during the 21st century. This analysis aims to study each product, including what went well and what went awry during and after development, in order to learn from the past and apply these learnings during the ideation phase. In the interest of concision, only three product analyses will be presented in this page. The other analyses are available upon request.
Google Clip
Google Clip is a discontinued product from Google, which was originally released in 2017 after three years of development. It is a clip-on stationary camera that has a built-in machine learning tool to “capture and view more of the spontaneous moments with the people and pets who matter to [the user].” Although Google Clip is a camera designed with a clip, this device is not typically worn, but clipped or propped up on objects or furniture. Some positive aspects about the Google Clip include the fact that that it does not require the user to connect to the Internet to use it. That means the user will feel more secure and certain that his/her photos will not be used by the company or any third-parties in any way. Google Clip also has the ability to recognize faces and automatically start recording thereafter. This feature is useful as it means more time spent with loved ones and less time fumbling around with a camera. Also, the fact that it is typically clipped or propped up on furniture means that everyone – including the user – can be included in the frame. Some negatives about the Google Clip include the fact that people can see right away that it looks like and is a camera, which makes it difficult to capture good candid photos. Moreover, Google Clip is a stationary camera, which means that unless it is moved via human intervention or otherwise, it will stay in place and only take photos of the same scene throughout the day. There were also other user complaints about the Google Clip, including its poor image quality, lack of sound in its video clips, and unpredictability.
Narrative Clip
The first Narrative Clip, which was originally developed by a Swedish developing company called Memoto (now called Narrative), was launched in 2013. It is a wearable camera that can take photos at a set interval. The photos can then be accessed using the camera’s accompanying cloud storage application. Although the first Narrative Clip is no longer available in stores, its successor, the Narrative Clip 2, may be purchased from the developer’s online store as of writing. The Narrative Clip has its share of positive qualities, including the fact that it is hands-free and can take photos automatically. That means the user no longer needs to think about whether to take a photograph or not, nor does the user need to press the shutter button to take photos. In essence, the user will be free to “live in the moment” while having this device take photos for him/her. Despite its many positive qualities, the Narrative Clip is far from perfect. One of its main problems is that it still looks like a camera, which can either make others uneasy due to the feeling of constantly being watched and/or photographed, or make it difficult to capture natural candid photos. Furthermore, the Narrative Clip being always attached to the user means that the user will almost always be invisible in the photos taken by the Narrative Clip. There are also privacy concerns regarding the way photos are taken and transferred to the accompanying application online. According to Narrative’s Terms of Service, by submitting content to Narrative’s platform, the user is granting Narrative the license and right to “use, host, store, reproduce, modify, create derivative works… [and] perform analysis on aggregated, anonymized versions” of the user’s content “for business or statistical purposes.” The content the user submits may also be made available to other companies, organizations, or individuals that are affiliated with Narrative.
61N
61N, a type of wearable camera developed by 61N Team in Seoul, South Korea, started out as a Kickstarter project in 2017 but was later discontinued shortly after its release in 2019. This wearable camera takes photos at an interval, which the user can modify. It also automatically transfers photos to 61N’s cloud, which can be accessed through the camera’s accompanying phone application. 61N’s strength lies in its well-thought-out design that makes it look more like a piece of jewelry than a camera. It is something that one would perhaps be more comfortable in wearing, as well as something that would be able to take better candid photos given its more discrete appearance. However, it can also pose problems regarding consent to be photographed. Like the aforementioned Narrative Clip, 61N is mainly hands-free and can take and transfer photographs automatically. However, the fact that 61N can automatically take and send photos to the cloud can create a lot of privacy issues. The person wearing the camera will also almost always never be in the photos taken.
Synthesis
To better make sense of the products chosen for this study, I developed a Cartesian coordinate system. The y-axis represents how “hands-on” a product is, that is, how much human intervention the product needs to work. This axis addresses a part of the research question that asks how people can take photos while staying in the moment. On the other hand, the x-axis represents the severity of the product’s privacy concerns. This axis addresses the key question that asks how the user’s privacy and autonomy can be respected. As seen in the Cartesian plane, the products with the lowest privacy concerns include the Pet’s Eye View Camera. Unlike those with higher privacy concerns like the Narrative Clip, the former does not need to connect to the Internet to function or to transfer photos to the product’s chosen cloud computing service. Instead, it relies on its internal storage to store the photos securely, which in turn ensures the user’s privacy. Products that do not demand too much human intervention to function tend to be those that are wearable and automatically take photos at a set interval, such as the SenseCam, the Pet’s Eye View Camera, and the Narrative Clip. In essence, this product analysis suggests that for a camera-type product to not be overly reliant on human operation while also respecting the users’ privacy, the product needs to be wearable and/ or be able to automatically take photos at a set interval, as well as not require Internet connection to work or save photographs.
Chapter II: Primary Research
Survey
From May 12, 2022 to May 16, 2022, I conducted an online survey that 52 respondents completed (see Appendix A for a copy of the survey questions). Surveys are useful for quickly gathering user insights while simultaneously accomplishing other work, so the survey was completed early and aggressively distributed on numerous online platforms, such as Facebook, WhatsApp, and Reddit.
Online Polls
To supplement the quantitative data that I gathered from the survey I previously conducted, I also conducted two online polls, which are just single questions designed to quickly gather inputs from a random sample of users on the American social news site and forum, Reddit.
Interviews
A deeper understanding of my user group is imperative to properly ideate on a product. To this end, I conducted four semi-structured interviews, each interview lasting between 15 and 20 minutes. To retain the participant’s trust while also being able to best research and analyze the data as a one-man team, I gave each participant a consent form, which they would have to read and sign prior to the interview. This consent form discloses that though the interview session will be recorded, the recording will be destroyed upon transcription and all identifying or identified information will not be kept with the data. These interviews were conducted online via Zoom, Discord, and Facebook Messenger. To ensure clearer communication between myself and the participants, I chose to conduct the interviews in either English or Tagalog. The latter was of course later translated to English.
Synthesis
To synthesize the qualitative research results, four affinity diagrams were created out of a conglomeration of data from the surveys’ qualitative results and the interviews. After, to gain a better insight develop more empathy towards the users, I
created an empathy map. This diagram will help distill all the information and data gathered into one place. The insights gathered from the affinity diagrams and empathy map were used to create an as-is scenario, which will help in understanding the user’s typical journey in the present scenario. What is he/she doing, thinking, and feeling when he/she takes photos?
Chapter III: IDEATION
Five goals were first laid out at the beginning of the ideation phase. These goals are to be realized in most of the ideas generated:
- Preserve memories through photos
- Allow the user to stay in the moment
- Respect the user’s privacy and autonomy
- Take photos that best represent reality
- Help the user avoid social media pressures
To determine which idea was the most feasible, my class voted on which idea they liked and disliked the most. The third idea, Kamera-d, won by a landslide. So, I decided to go with that idea and worked on some concepts.
Chapter IV: CONCEPTUALIZATION
I decided on a design that appears trustworthy, friend-like, and cute, as trust and privacy were some of the common themes in my research on photo-taking and ubiquitous domestic appliances.
Trustworthy
In the survey conducted, 48% of survey participants get someone from the group to take their photo, while 25% of survey participants take selfies. This finding implies that most participants would rather have someone they trust (i.e., a friend from the group or themselves) take their photo. Thus, trust is a major factor in anticipating whether or not a person would be comfortable in having his/her photos taken.
Friend-Like
Having candid photos of someone taken can either make that person happy or very uncomfortable. Some responses from the survey indicate that people are usually more comfortable with candid photos if the photographer is a family member or a friend.
Cute
When one thinks about cameras that constantly observes and automatically takes photos of people, what does this camera usually look like? Many would possibly think of George Orwell’s Big Brother, Jeremy Bentham’s Panopticon, or even Mark Zuckerberg’s face. These images imply surveillance, which can be intimidating for people who are concerned about their privacies. “Cuteness” is known to reduce the intimidation factor of objects, which can make the user more likely to accept the object. If something is cute, the user is not only buying the object, but he/she is also adopting it. The relationship between the user and the object will become more intimate, and the user will feel the need to take care of and even love the object. The user may even begin considering the object as a part of the family. In essence, having a cute design will increase the possibility that the user trusts, buys, and brings home the object.27
Initially, a more animalistic design in the form of a rabbit was proposed. However, upon receiving feedback, I realized that a rabbit is not the most suitable candidate for a photo-taking device, as rabbits are known for their acute sense of hearing and not their sight.
I then began playing with the idea of a frog-like design, as frogs are known for their huge eyes and impeccable eyesight. Moreover, because of the recognizability of the frog’s life cycle, frogs are also symbols of change – something photos can very easily document and highlight. To confirm my animal of choice, I decided to create an online poll on Reddit that asks people what they think about frogs. Out of the 4,748 respondents, 44% thought of frogs as “friends,” which also feeds into the friend-like requirement of the design. However, upon further reading, I realized that an animal design may not be the best choice for my prototype, as there is “evidence that lifelike forms might be inappropriate for domestic technologies.” This evidence points to the possibility that lifelike forms like animals can decrease a person’s intimate response to an object, while a non-lifelike form increases it.
In a systematic study of cute objects, it has been found that rounded objects, objects with curved shapes, and blue objects (if the object is rounded) are considered to be the cutest. So, if the final design is to be non-lifelike, at the very least it has to be rounded and possibly also have blue accents if the entire object cannot be blue. Previous research on the frog is not to be discarded, though, as frog-like elements can still be discreetly added to the design.
Chapter V: Prototyping
Programming: Frontend & Backend
Kamera-d’s software was programmed in HTML, CSS, and JavaScript for the frontend and Node.js for the backend. The reason JavaScript was chosen as the primary programming language for this software was so that the following Application Programming Interfaces (APIs) and libraries can be used, which are crucial to Kamera-d and its functions:
- Face Recognition API is an API developed by Vincent Mühler, a developer from Berlin, Germany. It can detect and recognize faces and emotions, among other things.
- SightEngine is an image moderation API that can be used to estimate image quality and detect different elements in an image, such nudity and gore.
- Johnny-Five, initially created by American developer Rick Waldron in 2012, makes use of Node.js to allow the programming of Arduino boards using the JavaScript language. By programming Kamera-d’s Arduino board using JavaScript and in Visual Studio Code instead of in Arduino’s official IDE using C++, it would become immensely easier for the board to communicate with the other APIs used in this project, all of which were written for JavaScript applications.
- OLED-JS is a library for Johnny-Five that provides support for I2C/SPI-compatible OLED screens.
- Node-Pixel is a library for Johnny-Five that allows the user to control addressable LEDs using Johnny-Five and Firmata.
A webpage was roughly designed and created using HTML, CSS, and JavaScript. I chose to host the page on a local server with the help of the cross-platform application, Ngrok. Although the user should not be able to see this webpage in the final iteration of Kamera-d, this webpage is useful for development purposes and for showcasing in exhibitions how Kamera-d thinks. This webpage hosts all the images Kamera-d has taken throughout the day and compiles them in a slideshow.
Furthermore, through this webpage and with all the proper browser permissions, all the photos taken will be automatically downloaded onto the computer that is connected to Kamera-d, which is useful for analytical purposes and for saving the images in case of an Internet disruption. It is also possible to see in this website what Kamera-d sees, as well as how Kamera-d is estimating the emotions of the people present in the camera frame.
3D CAD Modelling
Before modelling the prototype, paper prototyping with scrap paper and cardboard was first done to ensure that the sizes were appropriate prior to diving into the 3D modelling process.
Using the CAD software Rhinoceros 3D, I rendered the 3D model for the case, always making sure that the case is appropriately sized to fit all the product’s physical components and wires. As such, paper prototyping was done beforehand to ensure that the sizes were correct. Another factor I kept in mind was keeping the prototype ’s size small enough to reduce printing time as much as possible, as well as comfortable enough for the user to hold and place on small surfaces. Kamera-d’s final model is 300mm x 250mm x 200mm.
Worth noting are sections of Kamera-d’s walls that are thinner than the rest of its body. These sections are located on Kamera-d’s left and right sides, as well as on Kamera-d’s head. For reference, these walls are about as thin as regular A4-sized paper, which, upon careful testing, was the thinnest Kamera-d’s walls can be without compromising sturdiness. These walls are thick enough to fortify Kamera-d’s body, but also thin enough for users to be able to interact with capacitive touch sensors that are glued behind them.
3D Printing
Kamera-d’s 3D components were all printed using the Anycubic i3 Mega Pro 3D printer. However, due to the printer’s limited working area of roughly 210mm x 210mm x 203mm, Kamera-d’s model had to be split into eight parts to fit the printer. Each part was then one by one printed. Printing all these parts took approximately 145 hours and 40 minutes (excluding time set aside for printer setup, calibration, and frequent bed leveling).
- Upper-Left Portion: ~35 hours
- Upper-Right Portion: ~35 hours
- Bottom-Left Portion: ~35 hours
- Bottom-Right Portion: ~35 hours
- Top Hinge: ~2 hours
- Bottom Hinge: ~3 hours
- Hinge Pin #1: ~20 minutes
- Hinge Pin #2: ~20 minutes
After printing, each part was glued to one another using a hot glue gun, paying close attention to the hinges so that Kamera-d would still be able to open and close properly.
A Look at the Moving Parts
These parts allow Kamera-d to make noises, respond to touch, observe its surroundings, light up, display information, and even press an instant camera’s shutter button.
Under the hood, an Arduino Uno microcontroller board was used and connected to numerous devices, including:
- WS2812B Individually-Addressable RGB NeoPixel Strip LEDs (55x)
- SG90 Micro Servo Motor (1x)
- TTP223B Capacitive Touch Sensor (3x)
- Power Supply Module (1x)
- Piezo Speaker (1x)
- SH1106 1.3 Inch OLED Display (1x)
- Logitech C270 HD Webcam (1x)
- Power Bank (1x) – Connected to the power supply module using a 5V USB to DC 5V power cable
- Instant camera (1x)
Chapter VI: Interaction Flow
Kamera-d was also tested for its usability using the diary study and field study methods. More information on this is available upon request.
Chapter VII: Limitations
Kamera-d has two primary limitations that need to be recognized, including that Kamera-d’s system employs artificial intelligence (AI) and that Kamera-d is still at a very early development stage.
Artificial Intelligence
The two main APIs that drive Kamera-d are Mühler’s Face Recognition API and the SightEngine API, which are both AI APIs. That means the current limitations of AIs apply as well to Kamera-d (at least, in the time of Kamera-d’s development in the year 2022). AI, being a product of humans, is also prone to bias. This bias mostly comes from the data creation stage in the AI’s pipeline, which includes data collection, annotation, training, and consumption. When data sets are created by, for example, scraping websites like Imgur and Reddit, sampling bias may occur. Sampling bias happens when certain instances are collected more than others, thus overrepresenting these instances. As a result, the data collected either becomes unrealistic or even prejudicial, such as when the photos that are fed into an algorithm are overwhelmingly those of light-skinned people.
Technical Limitations
Because this prototype is still at a very early stage of development, there are also limitations in how it is currently used. For example, in its current iteration, Kamera-d requires to be connected to a computer to work. This is because Kamera-d’s software was programmed primarily using JavaScript and Node.js, which is executed via a webpage and a server.
The second limitation is brought upon by using an instant camera to print out the photos. Due to difficulties in finding or developing a printer that directly prints polaroid-style images via commands from Arduino, an instant camera was instead used. What happens here is, a screen is placed a few centimeters above the instant camera’s lens. If a picture is ready to be taken, Kamera-d chooses the “best” photo to be taken through a set of conditionals. This photo is shown on the screen and a small servo motor moves to push the instant camera’s shutter button to take a photo of the screen with the photo. Of course, due to the small focal range between the camera and the screen, this approach only creates blurry images that do not improve in quality over time, which does not align with Kamera-d’s original concept. A solution in which the system, camera, photo storage, and printer are all in one device and can talk to each other would have been more optimal.
Accessibility is also a large issue in Kamera-d’s design. Kamera-d’s reliance on colours and lack of animations for visual feedback makes Kamera-d a bit inaccessible for those with colourblindness. It would have been possible to add animations to the NeoPixel lights. However, because of a limitation imposed by the Johnny-Five and Node-Pixel libraries, which allow Arduino devices to be programmed with Node.js, light animations have become more difficult to implement without overloading the payload in Node.js.