I previously posted a piece about HCI4D, where I mentioned a real life situation, that I randomly discovered through a friend of mine, where a little of HCI4D work could really make the difference.
I am talking about a “water problem” who is currently affecting one of the many rural villages located in South-East Asia. Thanks to the stories, and pictures, I could obtain also from different sources this time, I decided immediately to work on a personal small home project, and blog about it. I wanted to put down a detailed initial plan and implementation proposal for the introduction of some piece of technology which may enable a transparent management of the aqueduct, and the service provided.
Keeping it accurate to the reality, I started working out the assumptions, and requirements, and I ran straight into one of the most delicate aspects of this kind of projects: politics, and similar. I do not have enough knowledge, nor authority, to talk about political decisions, behaviours, or making assumptions that concern them. At the same time, I do not want disclose possible sensitive information that may compromise people and environment involved in this situation. For these reasons, I will develop this post around this quite common issue, in the context of a generic rural village in South-East Asia.
I decided to call my approach to this issue “Naive-HCI4D”, and the first point of being naive is the fact that I am comfortably sit on a couch at home, with a hot cup of coffee, while outside it is chucking it down. Real HCI4D requires field research, and observations, that I cannot physically perform, at the moment. Although, I am engineering the requirements and assumptions based on the stories from the field I received.
Secondly, HCI4D research should be performed in team, to have bigger coverage and better brainstorming on the various items involved in the planning. However, this is a one-man-show. It is only me, the data I received, my pen and a notebook. (Yes, I often have an analogue-first approach, because sketching, and handwriting help me to focus more.) Brainstorming on my own might do, but I have not other crucial point of views, and even less objections.
Finally, I am still learning about this field, and it makes me definitely naive towards some decisions or conclusions, using the power of assumptions to its maximum. However, I am trying to keep a concrete level of feasibility, in an assumed realistically available budget.
From my handwriting, the very first point I wrote down is the scope of the project: understanding why water is not reaching the village through the existing and operating duct.
Pretty straight forward. Just being able to tell the status of the aqueduct and its branches, and promptly verify when either the level, or the pressure of water are not enough. This will enable a transparent communication of the situation between authorities and villagers on this matter.
A solution currently on place is to deliver water to the village via not-very-regularly scheduled trucks. This “emergency” plan, might be planned more efficiently if there is an “early” notification that, for example, the pressure in the duct started decreasing. Am I right?
I assume the villagers want to get properly informed about the water situation, for both calling in the trucks, and organising the distribution.
I am aware of the presence of electricity in the area that can serve the sensors and monitoring terminal. Alternatively, if it was not available, it would have been possible to introduce solar panels, or other sources of renewable energy to supply the required power. Moreover, I know the aqueduct is already in place and, assumed comfortably accessible to install said sensors.
What it is probably needed for this simplified approach to the problem, are sensors that capture the water level, and sensors that capture the pressure in the duct. Sensors will have unique ID, so that they identify a specific point in the system. These devices will be connected to a computer terminal that can either do just real time monitoring, or also storing the captured data. The first case is, of course, the simpler: it requires just an interface that process the stream of data from the sensors, and displays its status in a easy-to-understand fashion. The second case can be more interesting, and opens also to Data Science. On top of the real-time monitoring, storing the information captured by the sensors, enables the possibility to perform statistics, and maybe forecast on the aqueduct status. The information of water level, and pressure, are not massive piece of data, but depending on the desired frequency, a storage unit can be added to the monitoring terminal. Alternatively, this data can be sent to the cloud, and made them available even widely. Anyone interested in these kind of information?
This is a very simple diagram of how the system might look like:
Considering the current cost of sensors, terminals, other materials, and storage, it seems quite possible to estimate costs, and budget. I will not do that, if not this approach wouldn’t be “naive”.
When I talked about the sensor, I limited the choice to level, and pressure of the water. Do you remember it? It is just above. However, this seems a pretty scalable solution, isn’t it?
What about introducing sensors that tracks the parameters of the water, such as Turbidity, Temperature, pH, and Coliform. Wouldn’t be interesting? This will increase the complexity of the system, but it would give a great added value.
What about attaching a meteorological station to the system? This will collect its own data, that can be matched against the information from other sensors, enabling the possibility of identifying patterns. What if specific weather conditions are actually impacting the efficiency of the aqueduct? Finally, there might be a proper answer. Through my personal and hands-on experience, a basic meteorological stations/sensors are not an expensive addition for such system.
One more thing, what about collecting rain water, or store upfront into tanks, so that there is a local reserve? In this case, technology should be definitely introduced to monitor the quality, and quantity of the water. This specific implementation probably requires constant maintenance, and disinfection of tanks and their content. To the naive myself, that sounds like opening job opportunities.
Remember that nothing in this post is absolute truth, but, without too much effort, are feasible ideas, and doable approaches to this kind of issues. However, everything is open for discussion. The more debate, the better. This was my take on a Naive-HCI4D approach. Now, what would you do?