To get feedback from outside experts, I spoke with two professionals in the web-development realm. Laurel Malenke is a project manager and designer with the B-certified company SuperHumane. Jeff Faller is a UX designer and developer with Pearson Education.
I spoke with Jeff a few weeks ago about the design and layout of the site. He talked me through how to do an effective user test so that I can better see how people will interact with the site. We talked about A/B testing for different designs and menu systems, and he agrees that my menu system and site navigation need work. We also discussed the graphic design of the site. He reminded me that I don’t need to reinvent the wheel—if I really want a functional end product, I should look into using current standards for web design (hamburger nav, headings, above/below crease content, link and button appearances, etc.) Looking at my previous ideas for the graphic design, he responded that he thought it was too much and the design would pull attention away from the content. I have incorporated this feedback by scaling down my graphic design a lot and looking to inspiration like National Geographic for ideas on how to format text and images. In addition, I am still working on my menu system, and hope to be able to test it soon.
Laurel was in San Francisco for the last three weeks and arrived home on Tuesday of this week. I will be meeting with her on Friday and look forward to hearing what she has to say. I’ll update this blog post with her feedback, once I have it.
Update: Meeting with Laurel was fantastic and terrible, all at the same time. She had some fantastic ideas to cure my navigation problems on the site, but man, they are not going to be easy to implement. Her two main thoughts were that I should use a top bar navigation system that shows all of the main, narrative based stories as titles with a blurb that slide back and forth. Second, I should use “margin notes” to both spice up the graphic appearance of my stories and to connect with an action item and a learn more item right next to the text. This means that if people get bored, they have something else to do very large and visible rather than having to scroll all the way to the bottom of the story. However, I again find myself a little lost on how to implement this. I’ve got a few ideas, but I’m not sold on any of them yet.
Laurel also listened to the trouble I was having with firebase and has offered me a contact within her company to help! She said she can’t guarantee that he will know exactly what to do with firebase, but he is their back end developer, so he might be able to point me in the right direction. I’m speaking to him via zoom next Tuesday. On that call, I’d like to ask:
Do you know of a way to connect Firebase and google docs?
If not, how should I go about styling text within Firebase?
Do you have any suggestions for how to connect stories within Firebase?
Do you think Firebase is the way to go? I really don’t to make a new html page for each piece of text.
More… I’ll keep brainstorming and add questions as I come across them.
The final thing that Laurel said was that this website relies on delivering a highly emotional message. The graphic design and user experience is the vehicle for that message, so I need to focus time and energy on that side of things as well.
Overall, it was a very productive meeting that has given me a lot to think about and work on.
I reached out to one of my mentors, Prof. David Schall, last week and he got back pretty quickly. We met last Monday and chatted about how the project was going. He thinks that the physical component is really interesting and is pretty key to the project. He suggested that rather than using candles (a fire hazard in a forest), I should use little solar LED lights or LEDs powered by watch batteries. I’m not sure what I think of this idea. I think having the lantern in any form is more important than needing the lantern to light up, and I feel about as bad leaving LEDs or watch batteries in the woods as I do about introducing a potential fire hazard. In addition, I agree that the lanterns are cool, but the website is the minimum viable product. I don’t want to sink too much time into the physical component when I know that it will come at the cost of the digital product. I can laser cut quickly enough, but wiring up a bunch of LEDs is going to be a far greater time commitment. Prof. Schall pointed out that I need to put in much more time on the CSS to make the site look nice. That way, when I showed it to people, they had something to react to. This is a super good point (especially before I meet with Laurel, who is a UX expert). He also said that he didn’t know anything about backend (darn), but had heard that Firebase was probably the way to go (yay).
I also reached out an met with Annie Bruns. She and I chatted about the concept and navigation on the site for a while. We agree that the experience could be better for users if I develop a more intuitive and complete menu system or use breadcrumbs. Otherwise, with the non-linear nature and lack of a search bar, it might be really difficult for users to find content that they have found before and would like to find again. Annie also agrees that the lanterns/physical component of the project is one of the most compelling parts and thinks that I shouldn’t give up on it, if at all possible. Finally, she gave me a great reference site that I can use to collect more facts for Yggdrasil.
Refresher: last week, I wanted to work on the categories pages, get mentor feedback from Annie and get in touch with Laurel, and get some stories in the firebase so I don’t have to test with storystory and story5.
Where am I now?
I did get the previously listed things finished, but I’m not feeling very good about this at the moment. This week, I really need to put in some hours on refining things and getting to a more comfortable spot. I feel like I am perpetually behind… Arg. Next week is 50%, so it is a big one. Luckily, I don’t have much going on this weekend, so I’m thinking some serious project hours are necessary.
Right now, the category template page looks like this:
I’m struggling a bit with my footer, but that can be a later problem.
I did chat with prof. Annie Bruns, though I’m not sure it was the world’s most productive meeting. She did help me find a new source for some of the facts which is interesting, and we talked a little about the progress of the site. She agrees that the lantern is pretty neat, but should be the last priority. Annie also noted that the non-linear nature of the stories could be trouble and I agree—especially if viewers have a hard time getting back to where they want to go.
I really hope that Laurel and I have set a time—we are chatting on Friday, I think (if everything goes as expected in both of our schedules…). I’m looking forward to seeing what she has to say, but since she is a user testing expert, I would like to have a more polished looking product to show her. So:
What do I want to have done by next week (50%)?
I want three pages that are beautiful and polished (by friday, actually) to show to Laurel. These will be 1. home, 2. a category home page, and 3. a story. This is going to take work because I’m struggling with formatting the text I put into firebase, but figuring that out is priority one. This will also just involve a little polishing of CSS and working out a few bugs (looking at you, thumbnail images and footer). Another high priority that I will have worked out by next week is the connections. I’m not sure yet what form they will take, but I need them to be working (at least vaguely) by the 50% mark.
I would also like to have a digital prototype of the lantern. If everyone thinks this is so important (and I don’t disagree), I need to get moving on it. This will take the form of an adobe illustrator file, likely.
Finally, as always, I’d like to continue chugging away at editing and writing the stories, facts, and tips (and interview those last few folks, if they EVER respond to emails… This is the problem with interviewing people who really like to travel/have adventures. They are almost always off running rampant somewhere.)
Refresher: Last week, my primary goal was to create a CSS outline/wireframe, get in contact with my mentors and schedule times to talk, and start the very long process of editing and reaching out to my story sources for feedback and images (if possible).
Where am I now?
Panicking! The fifty percent mark is NEXT WEEK! (Oh, it isn’t. Thank goodness! 50% is in two weeks from today. Phew.) Honestly, I don’t think I’m in that bad of shape. I think 50% seems manageable to get to by next week. Still though, that is a pretty scary proposition. This week, I feel like I made a good amount of progress. I spent most of my time working away at the CSS (we all know how that goes. CSS is such a time drain). I also learned how to make a sticky nav with CSS and jQuery, which is pretty neat. It has a bit of a bug, which is that it “snaps” or like… vanishes at a certain point before reappearing. Which I’m not a huge fan of. But I’m sure I can figure it out!
I also wrote more stories and began collecting the “facts and tips” in earnest. I need to put my head down and get those written up as well. It’ll be a LOT less work than the full stories since it’ll just be a snippet of text and then a link out to some other resource, but there are a lot of them, so I need to get moving.
This week, I also sent some emails and got in touch with some folks. One of the emails came back with bad news (one of the people I’ve been trying to interview for months is going to Saudi Arabia for two weeks, leaving…tomorrow. Neat.), but one was a success. I reached out to one of my “mentors,” Prof. David Schall, and he got back pretty quickly. We met on Monday and chatted about how the project was going. He thinks that the physical component is really interesting and is pretty key to the project (arg. To some extent I agree, but also the website is the MVP). He also suggested that I put in much more time on the CSS to make it look nice. That way, when I showed it to people, they had something to react to. This is a super good point (especially before I meet with Laurel!). He also said that he didn’t know anything about backend (darn), but had heard that Firebase was probably the way to go (yay!).
Where do I want to be next week?
I’m going to bullet out some goals. Not saying ALL of these are going to be done next week, but this is what is on my mind (not in order of priority).
Editing and reaching out to story folks for images
Talk to Lillie, Hank, Gail, for more stories (not necessary, but would be cool)
Consider writing my own stories?
Write up the tips and facts section
Create a logo and “phrase” for the project
Collect images and start optimizing them for the web
Figure out how the tags/connections are going to work (this is probably priority one… Not sure why I haven’t noticed this rather massive logical whole before…)
Make CSS look nicer and put it on all the pages
Meet with Laurel and see what she thinks
Meet with Annie and see what she thinks
Start the lantern/box and figure out what exactly would be on that (thinking this is still a later problem)
Populate the categories page and figure out if I’m generating “features” on the home page or not (also high priority)
Ok, now I’m feeling a little freaked. This feels like a chunky amount of work. Alright, well, break it down. What is feasible to get done by next week?
I know I’m meeting with Annie on Thursday, and I have been in touch with Laurel about meeting next week, so that is good in terms of mentor feedback.
I’d also like to focus my time on the categories pages this week. I want to build them out pretty much completely—this is make sure that the story titles are generating, and then do the CSS so it looks the way I want. This is going to be a lot of work, but I think it’ll really help push me up to that 50% mark. Also, I’d like to continue with the editing/review process. It would be awesome to have one set of stories finished and polished by next week, so I can start testing with those in firebase instead of my placeholders, story5 and storystory. Finally, I’ll probably spend some time writing up the fact snippets.
Refresher: Last week I set out to answer a few questions about Firebase, build a prototype, write more, and build a github.
Where am I now?
Great question, that. Where do I feel like I am? Wandering around, blind, in the woods of this utterly bewildering project. I had no idea how completely unprepared I was to do this until I started trying to do it and realized I didn’t even know what to google. That being said, this week actually didn’t go poorly. I’m just wondering a few things about the scope of this project (I’ll talk about that later).
So, the questions I wanted to answer last week were:
Can Firebase store images? If so, how?
How am I tagging the stories with a unique id? When does that happen?
How challenging is it to create a search bar? Is that something I can do AND make communicate with Firebase via JavaScript?
Is Firebase really the best database for a project like this? How does National Geographic do it? Or the Washington Post? Or any article based website?
And the answers are:
Firebase storage! It works with Google storage and I can make it work with this project too. I built a prototype, just to be sure. Integrating it into the main code of the project is a goal for next week.
The unique id is the story name. Because I am the only one that manages the backend, I think this’ll work (and Firebase will catch if I try to double up ids). The ids will be created as I feed the stories in to Firebase via their content management site. The unique id is the key to getting the story to pull up when I click the link. This is where the majority of my hours went this week, and I learned a lot of new things (thanks, Stack Overflow).
My instructor and I decided this should be a later sort of problem. But I did do a quick google, and it seems very possible.
Maybe not the best, but I can get it to work, which is what counts!
Beyond that, I did write more stories, found some facts, and have set up my github. I want to show off my Javascript for the home page and how calling the stories works. This was my first time working with two external JS files within the same project, but it is definitely the way to go.
Here is the JS for the home page:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
It doesn’t look crazy complicated, but let me tell you, figuring out the # thing on the link and that I needed all the rest of the code in the story.js file was an absolute nightmare.
Here is the story.js file:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
In contact with a lot more people, I guess. Mentor feedback round one is coming up fast, so I need to get in contact with Prof. Schall and my external mentor, Laurel with SuperHumane. I also need to edit and send my stories to the people who gave them to me to make sure that they are OK with what I’ve written. Part of that process is also asking them for images, so I don’t just have to lean on stock photos.
Next week, I also want to get the CSS wireframe on my homepage finished. I’m super not sold on the current headers for the sections in this project, so maybe fine tune on that. I will also be figuring out a way to connect the images to the particular stories and displaying them on the story pages.
That feels like more than way too much work, but the 50% mark is in three weeks (cue very loud internal scream), so I need to get cooking.
Oh also, note that I’m currently debating the value of the physical component of the project. It is really cool, however, I don’t know how feasible it is in the first way I imagined it. That being said, my instructor had a really good idea to just scale it back rather than completely giving up. So I think I’m going to think more along those lines than surrendering it. Also, scaling it back means that I could create more with less wood, which could be interesting. Stay posted on how this component of Yggdrasil changes.
A quick refresher: last week, I set out to draft half of the stories, complete the interviews (if possible), research what I wanted to do with the style, and create an html template for the site.
Where am I now?
Most of the things I set out to accomplish have been achieved, with one large exception. I do not have the interviews complete due to a scheduling error and the fact that I gave myself a minor concussion and couldn’t drive to meet the interviewee. She is out of the country this weekend, but I’m hoping that next weekend works out better. In the meantime, I’ve thought of several more story “types” that I’d like to collect, and a few more people that I could interview, so in that area I’ve actually got more work now than I did last week.
Okay, on to the things I actually did do! I have drafted around half of the stories that I’ve collected at this point. They live here. I’m pretty happy with the voice and content, though I imagine it’ll change between sections and stories.
I also created an html template. I suspect it will be a living document, so as I continue to refine what, exactly, this site is, it will also grow and change. At the moment, I have home, about, fact and story category home, and story pages. I will set up a github next week, but for now, here is the home and fact category pages:
Home
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
<!– home includes logo, featured story, map if I can make one?, aside with sections and tags, top bar with home, about, featured, search if I can make one, footer with contact, sources? –>
<!– But I love splash pages so much… so lets try and see how it goes. –>
<div class="homeSplash">
<h1>The Yggdrasil Project</h1>
<p class="headerText">Lorem ipsum dolor sit amet, consectetur adipisicing elit. Neque maxime sint sequi, dicta, animi odit itaque omnis numquam dolore perspiciatis porro, ducimus laboriosam vel ipsum reprehenderit exercitationem beatae officia at?</p>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
<!–The purpose of this page is to display a list of links that go to the articles in this category. It will primarily be generated by JS. –>
<div class="storyNav">
<h1>The Yggdrasil Project</h1>
<nav>
<ul>
<li><a href="homt.html">Home</a></li>
<li><a href="about.html">About</a></li>
<li><a href="featured.html">Featured</a></li>
</ul>
</nav>
</div>
<!– maybe have an aside with a featured section? Also, I'm feeling like you should be able to view a category page from anywhere on the site. So should that be in an aside?–>
<main>
<h2>Articles on: The Facts of Climate Change</h2>
<p>dolor sit amet, consectetur adipisicing elit. Voluptatum nulla, beatae reiciendis quia eius, harum iusto autem fugiat reprehenderit possimus ab tenetur magnam, adipisci numquam totam corporis eveniet laborum aliquam?</p>
<!– article titles would be listed here. I'm thinking the best way to do this might be in the site, so add the article to the list every time you add through the form?
So a static list in the JS that is just article titles and can link out to articles? Use flexbox to style?–>
This week, I spent a lot of time researching what I would want my style and CSS to look like. I decided that, for the sake of usability, I should go with something more modern and sleek rather than artsy. This will allow users to better nativage the site and remain focused on the content, rather than the style. Right now, I am getting a lot of inspiration from National Geographic, and I built my html template with this in mind.
Where do I want to be by next week?
Creating the html template last week made me acutely aware of the fact that a lot of my success hinges on being able to call content from Firebase and display it. This leaves me with a few questions that I absolutely need to answer before I go any further.
Can Firebase store images? If so, how?
How am I tagging the stories with a unique id? When does that happen?
How challenging is it to create a search bar? Is that something I can do AND make communicate with Firebase via JavaScript?
Is Firebase really the best database for a project like this? How does National Geographic do it? Or the Washington Post? Or any article based website?
All of these questions will require some research and testing, so that is what I will be doing next week. I will create several fake articles and make sure that I can use Firebase to call the correct article when the link is clicked. I will also research the images issue. By the next check in, I want to be 100% sure that Firebase is the right database for this project.
I’ll also continue drafting my stories—I would love to have all of the drafts written by next week. I’ll also begin collecting “facts” and determine what, exactly, that is going to look like on the site. I think it’ll probably be a blurb of text, image, and link to an external source.
My final goal for next week is to set up a github. This is both for the process blog and because my computer is essentially on its last legs. I would be so devastated if my computer died and I lost everything.
Well, not as far as I thought I would be—but this is only to be expected after coming back from break. That being said, I did do some stuff! I finished several interviews and have very detailed notes, and I have another couple of interviews scheduled. At this point, I think I have enough material to write a fairly substantial body of stories (yay!).
I didn’t do much work on the code over the break, but I did update the access permissions on the Firebase database to better reflect this stage in development. I’ll have to change them again when I am ready to put the site up, but for the moment, the permissions need to remain open. I have a very rough html framework, and some preliminary functions written in JavaScript that cover around 20% of the functionality of the site (but a very vital 20%).
In terms of the style and design, I actually regressed. I don’t think that I am sold on my original design at all—actually I don’t like it and don’t think it makes much sense. I think I’m going to be playing with the design of the site for a few weeks. I don’t know if I want to do something more traditional and clean, or something that is a little more artsy and unique and could better communicate the connections/meaning in the site.
Where do I want to be by next week?
By next week, I want to have the html framework finished. I also want half of the stories to be drafted (five stories at around 500-1,000 words) and, if possible, the rest of the interviews completed. I also want to do some research on designs and get closer to settling on something solid. If I am looking at being “artsy” I should start generating graphics for the CSS in week three, because that will take forever.
Looking Further Forward
Week 2: html framework finished, 1/2 stories drafted, all interviews complete.
Week 4: Firebase operation finished and integrated with HTML, lantern design finalized
Week 5: lantern prototype printed, CSS begun…
What is 50%?
Right now, I think 50% looks like having the lantern prototype printed, the Firebase set up and working, the CSS design finished and roughly implemented, the HTML framework for the site complete, and the externally collected stories written up and housed in Firebase for testing.
What is 90%?
By the 90% mark, I want all JS done, all stories, facts, and articles collected and in Firebase. I also want all of the lanterns to be printed and locations to be planned. The CSS should be perfect for Chrome at this point, and the mobile version should look professional (though not perfect). Essentially, I want the site to be completely finished so I can focus on getting it to be fully functional online and make sure that it looks good on a number of different browsers and mobile.
What is 100%?
The site will be live online, look good on mobile, and work on all browsers. It will house and display all stories, facts, and articles with a professional and creative design. The Firebase will call the correct story when the story title is clicked, and images will be displayed depending on the story. The lanterns will be laser cut, painted if necessary, and placed in the chosen location.
I think that this project went pretty well, considering what our objective were to begin with. Sophie Foster and I said that we wanted to create a digital version of an advent calendar, and we did. I’m not going to say that it was easy, but I think it worked better than either of us anticipated. Normally, I feel like when I plan out projects, I overlook something, or some javascript or css doesn’t do what I want. However, in this project, I think pretty much everything actually went to plan. I thought that we would be able to use flexbox for the css arrangement, and we could. We thought that the particular organization of our components would work, and it did. That is sort of how the entire project went (which is a really lovely change from the normal sort of situation). We did have a touch of trouble figuring out how to do the design of the site, but that was mostly because our thoughts on design differ a bit. I think I found the font pretty unreadable when it was over layed on the tree, and I think Sophie thought I was just blind (which is a little true. I don’t do well with low contrast). It is possible that we could have added more (we talked about adding a little flurry of snow that fell when you opened a box, or adding a song to play in the background) but I was against it. I thought that sort of stuff would become annoying for a user really fast and feel like cheap design. Also, if we wanted to stick to the model that the physical advent calendars set, they don’t have sounds or snow. We compromised and went with a single bell tone when you opened a fact. In critique, our professor and some classmates mentioned that we could have used circles instead of rectangles and “rotated” the tree to show new days, which I think would have been a nice touch. The tree was actually sort of an unplanned addition—we knew we wanted a background image, but we didn’t know it would be a tree, so I don’t think it even occurred to us to make the boxes into ornaments. If I were to redo this exact project, trying to make the tree “rotate” or the facts into ornaments to offer a little more dynamic movement for the user would definitely be high priority.
That being said, I don’t think I would choose to do this project again. I’m happy it came together so well, but I don’t know how thrilled I am with the final product. It is fine, but only fine. I don’t think that we could have pushed the advent calendar idea that much harder, which leads me to say that if I were actually to completely redo the one-page react app project, I wouldn’t choose to do an advent calendar. It doesn’t have enough moving parts to deserve to use react—react was nice to use, but not necessary. I guess advent calendars are a little more static and boring than I remember from my childhood (maybe because an online app cannot give you chocolate, which is honestly the only reason to have an advent calendar).
The site is more responsive than I had hoped, which is nice, and I think the aesthetic is fairly honest to the idea. The components make logical sense, and we passed state up effectively, so I think overall I’d call the project a success.
We didn’t use any code sources, but our fact and image sources are below:
Physical making projects never fail to surprise me in their ability to throw up sudden and unexpected problems. Everything will go smoothly all semester, then, the moment you say the word “project” (especially “final project”) the world suddenly explodes. This project was no exception to that rule. We (Sophie Foster and myself) wanted to create a music box that used hardware and p5js to replicate the analog music boxes that we remember from our childhood. Beginning this project, I was thinking about the music box that my grandmother had to hold her jewelry. It had the traditional dancer on the top, who spun and the music played when the user turned a crank. We used a potentiometer and knob instead of a crank, but the same general interaction principals hold true. The user can turn the potentiometer, which controls the speed of the continuous servo and the music playback rate through p5.js. They can also touch the copper pad (a capacitive touch sensor) next to the potentiometer to control the neopixels.
Now, to address how things actually happened—I’ll talk about the hardware first, then the software (start bad and end on a better note). Prototyping went pretty well. We breadboarded the circuit and made a mockup for the enclosure.
Here is a video of our prototype working (p.s. the video is actually horizontal. I don’t know why the preview is vertical):
Then, we laser cut the enclosure and attachments. I’m really proud of the way it turned out. I love the laser scorch marks on the wood and the way that the font and engraving turned out.
And the inside of the enclosure looks like this:
You may notice that we are using a breadboard, and you would be correct. We started on a breadboard, then moved to creating a breakout board.
Our breakout board was going pretty well—I had everything soldered to it and had successfully tested the board with the arduino.
Everything worked—yay! That is, everything worked until I tried to plug it in a second time and the power wire promptly broke out. Once the power wire broke, it was like the board had been given free reign to fall to pieces. I replaced the power wire, but must have crossed some solder somewhere, because it immediately shorted. This was very sad and frustrating, and because we were getting a little concerned and running out of spare parts (I had just soldered half of them to a breakout board…), we decided to move back to something a little less permanent (especially because of the neopixels. See below). From this experience, I learned that I really need to practice my soldering if I want to create products that consistently work. This lesson was compounded in our experience with neopixels.
Between us, Sophie and I were sure we had enough neopixels. Woe is me, we did not. Above is the image of all of the neopixels we soldered, had working, and then broke (the little copper pads would rip off the neopixel almost immediately. Or, something would shift despite the hot glue when we moved it into the enclosure and it would short.)
We FINALLY got two strands of neopixels working, but alas, it was a short lived success.
This lead to the most frightening experience of the project for me. I was cleaning up the enclosure, taping wires and such, and then plugged in the box to test the code for the final time. And it killed my computer. Yup. I plugged in the box and it gave me a scary warning—”USB ports disabled until device drawing too much power is unplugged”. I guess I didn’t unplug it fast enough, because my laptop promptly went black. Possibly worse, the Arduino didn’t light up. Like not at all—not even the flashing lights to tell you that you have a short. I pretty much promptly burst into tears (not actually, but I did say some curse words in the BTU). So, after recovering my computer, I did some googling and found out that probably it was just a short and probably I didn’t just fry the entire arduino. Fingers crossed. I searched and searched for the short, but it was not to be found. Thus, I ripped up the entire circuit (yay, breadboards) and started from scratch. The moment I plugged in the second neopixel strand, the board shorted. Looking at the neopixel, I couldn’t see anything wrong, but as I pulled off the hot glue to take a closer look at the solder, one of the copper pads tore off. Naturally. That was our last spare neopixel strip, so we are doing the best we can with four neopixels rather than eight. BUT this was the last of the disasters. We got everything cleaned up, plugged in, and tested. Below is the circuit in the process of rebuilding. This is what I knew worked 100% of the time.
The software side of things was much more successful. We used playback rate in p5.js to control the speed of the music, and the arduino code handled most of the rest. Basically, arduino maps the potentiometer to the speed and rotation of the servo motor, and also maps to a value between .01 and 4 for (using a handwritten map to float function) to send to p5 for the playback rate. The capacitive touch sensor hardware is very simple—it is just a fold of copper tape around a fanned out stranded wire that leads to a 10K resistor (the larger the better). The sensor connects to pins four and seven, so when a user touches the sensor, the resistance goes down and the neopixels iterate through a cycle. One issue we encountered is that people apparently differ greatly in how capacitive they are. For example, I could make the touch sensor record values up to 1,200, while Sophie was usually around 700. We decided more sensitive was better, so we mapped from 0 to 800 to change the lights.
This is the p5.js code:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
It took a bit and was a touch of a struggle, but we got it working! The enclosure is my favorite part by far, but I think the overall effect can be nice as well.
Another prototype! Yay! You can never have too many prototypes. Just kidding. Yes, you can, and I think I’m getting close. BUT this is an important one. It’s full name is: do I actually have the technical knowledge to write the code needed to make this website a success? (I call it “Form to Firebase” because its full name is too long.) I have a paper look/feel prototype, a look/feel and role/interaction prototype, and this. This is arm number three of the triangle and arguably the most important. It is my implementation prototype. Form to Firebase seeks to address a very important question: can I use Firebase, a database management system, to store the text for the stories and facts? The alternatives that I thought of to using Firebase are:
1. creating an html page for every single story and linking it to a star (please no—this cannot be the answer)
2. using an array in React to store the text and display each node (this is not a single page web app… So why am I using React?)
3. using a JS library to open each story in a shadow box or pop-up window (I hate pop-up windows. Also, it feels super clunky to link a pop-up to another pop-up, so the connection between the stories and the utopias would have to change).
I don’t love any of these alternatives, so the point of this prototype was to make sure that I am pointed in the right direction with using Firebase to store the stories.
This prototype was a lot more difficult to create than I thought it was going to be, so I’m definitely glad that I started it now. It revealed a few issues with Firebase that I’ll need to innovate a bit to solve, but overall, I think it functions well enough to be successfully adapted. Please forgive the fact that it is extremely ugly—the focus of the prototype was to test out my ability to use the database management system to this end, not to make something nice looking.
[still images of box]
Ally's Process Blog 