Roxanne Baril-Bédard & Sean Harkin
A small wooden box fitting a Wifi connected derivative of the old “Magic 8 Ball” novelty item. At the press of a button the unit randomly chooses a text based bit of “advice” from a handmade API containing an ample vocabulary, for a possibility of 203’112’000 unique answers. After having downloading the JSON, the device can work offline.
It’s meant to be cryptic and mysterious, so to have the user try to interpret what the oracle means, much like seers of the old days. Users, pretty much anyone with an interest in the mysterious, can ask advices during the day whenever they hesitate between options. This device needs to be portable so to be able to keep asking it question throughout the day.
Due to the requirement of being portable, we wanted to design the device to be as small as possible. Although we wanted the final design to be small enough to fit on a key-chain, we had to compromise time and component size. The device is still small enough to be easily portable and is very light-weight.
We want to test how useful the esoteric advice received from the Oracle is in everyday settings, and understand the limitations of the device.
final Bill of Materials (spreadsheet including costs & suppliers)
final circuit diagram
Day One (Monday, November 27)
Discussion in class regarding form and function of the project. Two ideas seemed to fit the group’s vision:
- A derivative of the “Fitbit” wearable fitness/exercise monitor, but with included timers designed to help with HIIT type training and reps.
- A derivative of the novelty “Magic 8 Ball” which would pull “advice” or “answers” from random API sites and display them on a small (and wearable or “keychainable”) OLED screen.
After some back-and-forth, the simplicity of the “Magic 8 Ball” application appealed to all three of us and we decided to go with that. Team to meet tomorrow approximately 16:00.
Day Two (Tuesday, November 28)
Roxanne having gone to Creatron to pick up the required OLED FeatherWings, extra stackable headers in case of need and order the batteries we soldered the assemblies and downloaded and installed the required libraries (Adafruit_SSD1306 and Adafruit_GFX) then ran the example code provided on the Learn Adafruit site (https://learn.adafruit.com/adafruit-oled-featherwing/usage). Sean then successfully tested the battery we’ve chosen to use (being the only one with a battery so far). We have also decided that there should be a “no internet available” subroutine that would draw from a preset array of “answers” (see below). i.e. – if the “Guru” is connected to the web, it draws from a random selection of API’s for its answers. If no internet connection is available, then it draws from its preset array.
Roxanne tried some of the available fonts to see what could work best. Most were too big for the screen. They also figured out how to wipe the screen from previous answer.
Roxanne: Trying to get io.adafruit working with the board
First follow this tutorial to update ssl certificate
Also install libraries: ArduinoHttpClient, Adafruit MQTT, Adafruit IO Arduino
Trying to make this tutorial work, had to ask Nick for help because it is not explicit you have to have the ssl certificate for both ArduinoHttpClient and Adafruit MQTT libraries so the compiler would not work (rather frustratingly).
Tried to make this tutorial work so we’d be connected via wifi to the internet https://learn.adafruit.com/adafruit-io-basics-digital-input/overview
Success! Able to send stuff from the arduino to io.adafruit, albeit random number but the bridge is working !
Got it working with a slider and a button, sending value on press. Getting there !
Nick says adafruit io is not useful, so most of the things succeeded today served nothing. Instead, we must look for tutorial make Http client, point it to web address, take json message, put it in a json object.
Sean: We also spent some time working on the back-up option of preloaded responses on the feather. We already had the basic functionality of a display screen asking if you need advice, being able to push 1 of the 3 buttons and getting a different response.
From here, we wanted to build a basic random function where any button push would pull from a list of responses
Day 1 Build: The original idea was to build the casing from wood. We enjoyed the idea of a little wooden box you carry around and ask for advice, as well as the contrast of the organic wood with the digital OLED screen. However when Sean went to build, he ran into some issues:
- The wood we had available was mostly ply, and mostly low-grade (3-4 ply)
- Even if we were to source better materials, the time constraints of the build would not allow for the quality we are initially pictured for our product.
Tomorrow, we will either begin 3d printing the prototype cases or use acrylic. If we are unable to create the 3 casings tomorrow in sufficient time, Sean can quickly build another 2 ply cases for testing purposes – with some work they could be to a fair standard before presentation.
At last week’s class, Kate suggested that we remove the last answer from the screen after a certain amount of time, which seemed like a great idea to encourage interactivity with the user. Despite some small hiccups, we got this functionality into the code.
Day 2 of build went well. Sean had access to the Ultimaker, meaning he began printing a version. Even if we do not have time to print 3, he thought it might be interesting to see an example of how the MK1 case design might look printed.
Sean also experimented with some different materials. First of all he tried some acrylic. Although it was easy to work with and joints were easy using the adhesive bond, it shared the weakness of the plywood being too brittle. Although there is little-to-no worry of it splintering or fracturing, I was cautious of components snapping during prolonged use. While I was waiting on the print, we decided to return to wood. We found some MDF in the workshop and began working. It was also around 1/4inch thickness but seemed to work well. With some help from the esteemed Reza, Sean was able to build a fairly well crafted box. He will return in the morning to complete the lid and then all we have to do is upload the final version of the code and begin testing.
Roxanne set out to figure out a way to get the feather to be able to make request to the server. After many hours of code, the feather is able to connect to the raw json file on their github. They used a JSON written using the visual tool Tracery (http://www.brightspiral.com/tracery/).
We didn’t succeed in splitting one string array into many strings so that it would create a sentence structure from the origin array as featured in tracery structure. Since we did not succeed, we hardcoded the sentence structure instead, telling the program from which array to pull a random phrase. Doing so, the advice sentence is always created according to the same pattern.
We also had problem with the server address because we put the JSON on github and it was hard for the feather to connected to a protected https server. We resolved it by using the website rawgit.com .
Sean finished the box today with some help from Reza. The 3d print, although functional, had a less pleasing aesthetic feel. He continued working with the MDF casings as these seemed to be the most stable and easy to work with. Originally we had planned to use a simple dowel lid which could be pulled off for maintenance and repair, but Reza suggested and helped build a magnetic lid – less stable but much easier to get access to the internal components. Similarly, we had thought of using rubber or foam for the button, however Reza suggested adding some contrast with the wood in the form of colourful acrylic. With the addition of some hot glue – which acts as suspension – the button works effectively and consistently.
Overall, we were fairly happy with the final product shape. Going forward, we would definitely want to print our own board in-order to cut down to a more convenient size – namely something which could attach easily to a keychain and be unobtrusive in a user’s pocket or bag.
Roxanne was finishing up the code and making the JSON create more interesting sentences. With all of the vocabulary they added, there is a total of 203’112’000 possible unique advices. When writing their code, they were really inspired by oracles sur as the Yi Ching, so their new sentences are more mystical than goofy.
You have to not let go the answer vis-a-vis death . You’ll get hurt.
Have you tried not to see life and them . Who cares.
Have you tried to fight your mom vis-a-vis life … but it’s a waste of time.
I know! Just implement her with love . Alea jacta es!
You could always not say the advice concerning her … LOL
User Testing Materials
user testing plan
No extra supplies needed, possibly just a short time to recharge the battery during testing sessions. We also should not require any repair materials.
Testing will be recorded through a combination of photographs, video and journaling.
There may be some deviation in the recording methods, as they will be dependant on where they are while testing the product. However, we will aim to be as consistent as possible.
As of today, we’re planning on testing Wednesday, or possibly Thursday depending on build-time.
Since our devices are not in constant use, our plan is to test for 24 hours, using the device whenever we need to make a decision or need advice. The users (us) will make our own interpretations of the advice given and will record this process of interpretation and outcome.
The testing will be conducted during day-to-day activities. We will most likely be independent when testing, as the devices do not require interaction.
The debrief will be held as a discussion/write up session after testing, and before our blog-post is submitted.
The user photo/video journal will be added to the blog post, along with comments from the users.
link to end-of-session report forms
photos, video, or other media gathered in the field
summary of the testing process
We set out to use the device for a day to see how useful it would be and to propose its advice to other people we were to be interacting with.
For Sean’s testing period, he spent around 20 hours testing the device on any and all sorts of decisions he made during this time. He also conducted mini-user testing in a social environment when he asked friends and passers-by to test the device. Due to the short amount of testing time we had available, we were unable to hand the devices off to users for prolonged user testing, thus only being able to conduct these ourselves.
reflections on your findings
The results of the user testing were interesting, though mostly proved what we already knew. Some users took to the philosophical and mysterious overtones of the experience very well, however a lot of the users did not seem to understand their role in the interpretation of the advice. This is not necessarily a weakness of the product as much as evidence that we have a specific target market.
References & Related Works
Adafruit Feather M0 WiFi with ATWINC1500: Updating SSL Certificates: https://learn.adafruit.com/adafruit-feather-m0-wifi-atwinc1500/updating-ssl-certificates
ArduinoJson: Manual: http://arduinojson.org/doc/
What and where are the stack and heap?: https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap
WiFi101 Library: https://www.arduino.cc/en/Reference/WiFi101
Arduino HTTP Client library: https://github.com/arduino-libraries/ArduinoHttpClient