This week has been a really weird one so far in regards to the pacing of the work so far.
Monday consisted of finishing my metal front face by sanding it down and filling it in with metal resin and this horrible smelling epoxy clay that reeked of rotten eggs and bodily functions. Whilst it felt like a slow day, it was an important one, with all the sanding almost done and only the drilling of holes left to do in these metal pieces. For the pole, I have in place the holder that enhances the stability between metal and concrete. I need to time the completion of my concrete cast correctly – I’ve tried it three times so far, and it is clear to see that placing the metal straight into the mould means that the pole barely budges. However, with electronics going into the pole, I will need to figure out how to work that in with the mould.
The rest of the night was spent coding, at which point I realised how to download a JSON file (yeah, I don’t know either) of tweets to my Raspberry Pi’s main directory. The only issue with that is that a main Python script cannot read that, meaning I need to convert it into something that allows a conference of data between the two. This seemed like an insurmountable task. The data file has about 40 lines of code for one single tweet, and when I want to extract only the text of the tweet, I felt that I needed some coding wizardry to pull it off.
Step in, Dr Thomas Janssens. I left my code with him on Tuesday morning for us to chat about it later that evening, so in the meantime, I got to work with other tasks. I had a meeting with Ryan on Tuesday afternoon, where we spoke about the remaining challenges of the year and how I will finish up the product. One interesting point that we spoke about was the hashtags that the user writes in to their tweets. I worried that potentially having 24 libraries of hashtags (say if there was 8 signposts in Dundee) would be a bit overwhelming for my users, but at the end of the day, Ryan and I agreed that there was nothing much to do about that. What I do need to worry about, however, is the naming of these hashtags. They need to be a nice addition to the user’s Twitter stream – it can’t be a messy code of jibberish.
If Twitter is the cocktail party of the internet, then hashtags are the conversation piece. No one wants to have an arbitrary conversation about a mash up of vowels and consonants. So how can I make this an appealing conversation for both users and potential contributors?
It all comes down to legibility. The hashtag needs to mean something, so surely inserting the name of the product as the starting point, and then perhaps something like an airport departures board, like GLA (Glasgow) to JFK (JFK New York). This seems like the clear option – tweets need to be short, so perhaps a 12-15 character hashtag to allow as much room as possible for the rest of the tweet. Presuming that each location is symbolised in 3 characters, as well as the hashtag symbol, the name of the product probably needs to be about 5-8 characters. So, in short, I need a short name that fits in with the native language of Twitter. Gary Vaynerchuk talks about this quite well in his book, “Jab, Jab, Jab, Right Hook”. In the book, he talks about how how content needs to be native to the platform – it might be good to examine trending tweets and look at the similarities in how others convey this information.
In thinking about how the name can be native to Twitter, and not simply some random word to do with cycling, it reminds me of Bruce Sterling’s book ‘Shaping Things’ where he talks about what he refers to as Spimes. I think I’ve mentioned them before, but to recap, Spimes are a natural continuation of the products that we know today. What makes this iteration of products different is it’s existence in the digital space as well as the physical. Sterling gives the example of a product that doesn’t need to be created until it is actually required by a user, a much more sustainable, viable option to pre-made, perhaps not consumed bottles.
In relation to my product, it reminded me of how my signpost will interact in the digital space and not just on the streets of Dundee. The name, in this case, is probably more important to this product’s digital identity and how users interact with it socially online. If the call to action is embedded in a hashtag, then surely it makes sense to incorporate the name into this hashtag functionality. Whilst the hashtag in a name of a product may be a bit overdone and a bit cheesy, I have a feeling that it could be justifiable in this case for the reasons above.
On Tuesday evening I spoke with Thomas about my code and he gave me a few pointers for how he would approach the challenge of extracting tweets and storing them in a library. Unfortunately, he doesn’t think I’ll be able to keep an active file of streamed tweets, meaning that when someone tweets the device, that tweet won’t be automatically stored onto the product as it can’t run more than one function at a time. This can be bypassed, however, by simply downloading the tweets to the device at intervals throughout the day (say at the degree show) to update the JSON file. Even better, I can use the Raspberry Pi without a monitor, so that interaction will be seamless.
With Thomas’ advice, the coding went late into the night. I was absolutely delighted when I figured out how to write an extraction of JSON data to print on my thermal printer. Also, by calling the function [‘text’] and [‘user’][‘screen_name’], I can limit these searches to the tweet and the username of the tweeter. I debated with myself over including the username of the tweet, and I can think of two good reasons for it. Firstly, by receiving a print out of a tweet, you may see that @jthomasmitchell (follow him if you haven’t already folks) has recommended you go to Camperdown Park for a great event on today. What if you could just pull your phone out of your pocket and engage with him a bit more about the event and maybe even make a connection with a stranger?
Also, adding the name to the signpost adds an identity to the user who tweeted it. This product could gain a particularly interesting form of digital vandalisation, with anyone with a Twitter account potentially adding offensive material to the content that the signpost produces. I can imagine negating tweets with swear words is a fairly simple task, but perhaps also ensuring that people owe up to their tweets can claim a bit of ownership with the content supplied by the product.
One problem raised by the coding is that JSON files can’t contain more than one tweet, otherwise the code gets mixed up and won’t print any tweets at all. I found a way around that using a plug in from StackOverflow, so now instead of getting no tweets, the file will print all of tweets present on the library (limited to the entities of username and tweet content). So now, I have to work out how exactly to create a random selection of 3 tweets from the JSON. I feel that having accomplished what I have so far, it will be relatively easy to overcome, and with a further check in with Thomas in the coming days I should be able to have the Twitter functionality down in the coming days, leaving standard, manageable electronics to work out after.
Finally, I decided to have a crack at the turning sign head after nailing down a lot of the more pressing problems. By using a pole embedded in concrete with two 3D printed parts to act as the holder, I began to worry that the weight of the sign head would inhibit the servo’s ability to move. I was right; the servo initially didn’t move, as I could hear it turning between the two 3D printed parts. I realised that the join between servo and 3D object weren’t secure enough, with the servo turning but the surface just rubbing and not moving. After securing it in, I came up with two theories as to why the servo didn’t work.
The weight distribution of the arrow meant that the servo was leaning down to one side in the pole and was therefore too heavy to turn. It’s not that the arrow was too heavy – I put loads of random, heavier objects into a mug and balanced them in the same position as the arrow on top of the servo, and because the spread of the objects was greater than the arrow, the tension overall was reduced and meant the servo could turn. Its important, then, to draft up a new 3D printed holder for the arrow that holds the arrow nearer the middle of the acrylic, rather than right at the end.
I also realised that the two 3D printed parts don’t combine together well. Whilst they touch, surface to surface, on the inside face, it may be wise to remove this contact, or at least limit this. The added friction simply makes it too difficult for the servo to spin, and you can feel the motor roll over when it tries to overcome the friction. By altering the 3D printed part a bit, I will be able to work out these two problems quite easily.
Once these two issues are completely resolved, it really is almost a case of assembling the product. Whilst I’m remaining optimistic, there is still a lot of work left to do – but the clock is ticking down and I feel like I’m getting there!