A holistic approach to product development
Tamapotchi note #8
It has been a few weeks since my last Tamapotchi note, but meanwhile I have been working on various aspects of the smart flower pot. Here’s a brief update on the latest developments.
Lesson: Don’t drink and demo
After short-circuiting my first working prototype during a demo I had to replace my Blend Micro board with a new one. Since this was the most expensive part on the breadboard I have been more careful since then. Keep in mind: Use a reliable power source, don’t let wires connect unless they ought to, and just don’t demonstrate the prototype when you’ve had a few beers (whoops).
After replacing the board I quickly had the prototype up and running again. The board reads the light, temperature and moisture sensors values, maps these to a state (0=too low, 1=OK, 2=too high) using predefined thresholds and sends the three statusses to a smartphone app over Bluetooth.
The next round
Now I had this first roundtrip working it was time to take it all one step further. The Tamapotchi can’t be connected to a smartphone or the internet all day; that would require an energy-draining WiFi or Bluetooth connection or a wire, and I don’t want any of those. I also knew that when you connect to the pot with your smartphone, you wouldn’t be interested in the current sensor readings (which are shown now), you need a summary of all readings since you last connected. So the pot would be able to say something like: “My roots have been dry for 2 days, now I’d like some water.” Or: “During the day I get some daylight, but not quite enough.” This kind of behaviour requires sensor readings to be stored in the pot itself.
Somehow I didn’t get the board to transfer 10 (days) * 24 (one reading every hour) * 3 (3 sensors) readings over Bluetooth within an acceptable timeframe. Maybe it is because I’m using Bluetooth Low Energy, or maybe I’m just doing it wrong. Anyway, it’s mildly frustrating.
I believe developing multiple aspects of a product simultaneously and thus taking interdependencies into account, improves its overall quality. Because of that, and because I was (just mildly) frustrated over Bluetooth not doing what I needed, I started on the design of the Tamapotchi pot itself. I had a rough sketch on which I based the first model in Google’s SketchUp. SketchUp is not really intended for product design, but it is the only 3d tool I know (and can afford). And adding a rendering plugin (I used TwilightV2) will get you more than decent results. Besides the actual 3d modelling, which is a pain, tweaking the materials and lighting to create a great looking picture of the product was great fun.
I turned the 3d model over to my industrial designer friend Remko to research the technical details of it. That’s when I found out SketchUp apparently only knows about ‘surfaces’ and nothing about ‘solids’. Imagine a cube; SketchUp will only be able to model a hollow cube, because it only describes the 6 surfaces of it. Other 3d tools can also fill the cube with virtual matter, making it solid. You can imagine the importance of this when 3d printing the model.
Remko had some other questions as well. How do all electronic components fit in? Does the battery compartment close watertight? Is the model manifold? What kind of materials and production techniques could we use? What would be the costs of manufacturing this? And more.
Give the plant a voice
I left Remko to deal with these questions and got on with the Phonegap/Cordova app. Until this point it only showed the status code representing the current sensor readings. Because I wanted to develop the app design along with the rest of the product (remember: the holistic approach) I added some styling and sound effects to transform it into a decent-enough app prototype. I knew using sound in web projects is not straighforward, so I was glad to find out Cordova has a media plugin that handles all the hard work. Okay, the app is still very rudimentary, but I’ve given the plant a voice. Literally.
My holistic approach might not be the most efficient way of developing a product; working on so many aspects simultaneously makes for slow progression. But like evolution in nature, this design process seems to thrive and be driven by variation. When I’m out of UI design inspiration, I just do some coding. When I’m bored of fiddling with serial communication over Bluetooth, I turn to 3d design. Also, decisions in one part of the process often spark ideas for other parts. Like the sound effect that made me rethink the form factor of the pot. Whether this means that I’ve created an infinite loop of pointless creativity, time will tell.