It has been a while since I have last posted an update – this is because further development, consulting, and other class work has now become a bigger priority.
From the last entry, I had discussed the idea of the “competition in schools” idea with my client and Katrina Lynn from the Dunedin City Council. They mentioned some sort of workshop around my project would be a better idea than the competition in schools – as there is not enough time in planning and implementing it. With Sam’s expertise in sustainable education, I think this will be something realistic – as long as such a workshop will be able to demonstrate value from my project. With that in mind, I also mentioned formulating an initial survey with my client – they have informed me that time constraints (on their end) won’t allow them to assist me in survey creation, but are more than happy to have a look at any survey material I have done. They survey will be created and deployed in the middle of May (May 15th) – after the expected Robust Delivery of my project. They survey will see what levels of energy literacy are current amongst survey participants; and another survey will be taken after they have been through my project website (and workshop, if carried out). These surveys (and workshop feedback) will be important in meeting the goals mentioned in my current value proposition statement, which is:
“The City-Wide Energy Meter project has increased peoples’ knowledge of energy consumption and conservation, through open discussion and visual display of real-time energy use. This project has been in development since August 2013, with the Robust Delivery deployed in May 2014. Since the date of this deployment, energy literacy of survey participants has increased by 10%, compared to the initial energy awareness survey in May 2014.” - Revised 20/4/2014 (survey will now be taken after robust delivery)
On the 14th of April, I held a user testing session for my project site. I did not get enough participants as I would have hoped – because of some technical glitches with my project machine, but the feedback I did gain was very valuable. It was after these tests when I came across a “major” problem – I had earlier implemented ‘real-time’ display of statistics every second (using the previous half-hour’s rate of change, divided by 1800 seconds), but soon realized this was causing severe strain on the live server. After a chat with Tom Clark (a lecturer here at the polytechnic), I realized I was making the server do way too much work – I should be going some of the work to the browser. I’ve already got the PHP functionality in place, and the required AJAX calls coded – I just have to work on making a more efficient client-side solution. After this chat with Tom, I rolled back changes (so that stats display is updated every 30 minutes instead of every second).
After these issues were sorted out, I set about gaining population numbers for each area of Dunedin. With Sam’s help, we were able to grab the needed data from Excel spreadsheets – via importing them into Access, and performing the necessary queries. Because these population values only change every 5 years (in line with each subsequent census), I decided to hard-code these values as constants.
After these issues were mitigated, Sam Mann, Neville Auton, and I began working on what key messages my site should be communicating – to demonstrate value for the project. Messages initially discussed were:
- That’s a lot of MWh! Um what is a MWh?
- I understand that it is lot when made more tangible (lightbulb equivalents, coal, truckloads of coal, $ spent per person)
- I can explore simple patterns (temporal, spatial) how much does it go up on a cold day? How much is residential/industrial? Why might say, NEV use more/less than Waverley?
- What social implications are there? Can we see patterns of fuel poverty? Does Maori Hill go down on a public holiday but South Dunedin not?
- What might this mean for the future? What might a focus on efficiency mean? How much $ is being sent out of Dunedin? What might it mean for the city to have much less energy available?
I have nearly finished implementing the first two, I will be working on finishing these over the current 2 week Easter/Mid-Semester break. Some screenshots of my attempts are below:
I’ll be adding more information to each of these accordions in the very near future.
Below are some recommendations Sam has made for me to focus on over the mid-semester break:
I’ve been thinking about the site and have some thoughts of things to do before I send it out wider.
- Can you add $ as one of the equivalents to the front page. Just use the 25c rate (put in a footnote that “this is calculated on the basis of 25c per unit (250kwh?). It excludes some costs, particularly line charges, but note that some large scale users will be on a lower rate”.
- The sections of Dunedin needs a front end. Rather than dumping people into the sections and complicated analysis tools, let’s do the work for them. Lose the sections from the menu. Just go to a single page (see picture). Have a little graph icon that goes to the pre-populated graph for each area – from there let them modify what they are seeing with your analysis tools. An example of a front end could be like:
Skip the % residential column for now. Perhaps just put an asterisk by the south industrial zone to explain the crazy high use of a few hundred residents.
- Start to add to the about page a list of “how did we do that? FAQ”. Q: how did we calculate population for each area? Then we can simplify the main pages without needing all the background information.
A publically accessible link to the online test is at http://tools.pingdom.com/fpt/#!/cjYcHz/energymeter.ict.op.ac.nz.
Up until the project key messages were discussed, I had half of the Google Maps completed for each area of Dunedin. The map (which I will eventually be converting to Google Maps), can be seen in the Dunedin Zone Sub Coverage pdf file (about 10 MB). As the implementation of the key messages is more important, these will be worked on at a later date (definitely before the robust delivery – May 15th).
To do – day 222 to 235 (21st April to 4th May 2014)
- Complete implementations as discussed in ‘key messages’
- Complete front page accordions (lightbulbs, coal, iPhones, etc)
- Revise Functional Requirements for project (have been leaving this due to implementation of key messages)