The Secret Lives of Stoves in Remote Australian Indigenous Communities

Author: Christian Tietz, University of Western Sydney, Australia

To cite this article

Tietz, Christian. “The Secret Lives of Stoves in Remote Australian Indigenous Communities.” Fusion Journal, no. 1, 2013.

Abstract

This is a practice based account of an unobtrusive experiment conducted as part of a federally funded national project from 2006-2011. As Design consultant I was engaged to investigate the short life expectancy of domestic electric cook stoves in Remote Indigenous Communities. The following account describes the putting in place of a follow up study to verify how the implemented design interventions performed in the field.

Product performance data and user feedback are, for Industrial Designers, essential and necessary information that inform their design process and future design interventions. But what if we haven’t got any of these avenues available, what if our users are not located within easy reach, what if they are in a setting so remote that it even has no mobile network reception? Then the designer is faced with an uncommon challenge, how to get the users or their things, in this case commercial stoves, to talk from afar?

This account highlights the intricacies and complexities of satellite field data logging in remote locations, where designers cross multiple communities of practice while negotiating complex communication issues between electronic components and humans related and unrelated. While technical issues are resolvable it is the social dimension and the strength of social connections that ultimately determine a projects success or failure.

Introduction

This is a practice-based account about the interplay between communities of practice and the practice of communities. It is the result of a sort of ‘Ethnography of the Thing’ conducted as part of a federally funded national project from 2006 – 2011 Fixing Houses for Better Health (FHBH) administrated by HealtHabitat p/l.

As Design consultant I was engaged to investigate the short life expectancy of domestic electric cook stoves in Australian Remote Indigenous Communities. The following account describes the actualisation of a follow-up study to verify how the implemented design interventions performed in the field.

Product performance data and user feedback are, for Industrial Designers, essential and necessary information that inform their design process and future design interventions. But what if our users are not located within easy reach, what if they are in a setting so remote that it doesn’t have mobile telephone network reception? How can we obtain relevant data?  To this end, the designer is faced with an uncommon challenge, how to get the users’ or more importantly their things, in this case ‘stoves’, to talk from afar?  This account highlights the intricacies and complexities of satellite field data logging in remote locations, where the designer has to cross multiple communities of practice while negotiating complex communication issues between electronic components and the complexity of human interaction. While technical issues are resolvable it is the social dimension and the strength of social connections that ultimately determined the projects outcome.

 The setting

Communities of Practice are people doing similar things, establishing a common vocabulary of activities, actions, processes and approaches towards their work, sharing a terminology, methodology and common understanding of what it is they do and how they go about it. This loosely is a community of practice.

 Moving in communities of practice, or social worlds that have conventions of use about materials, goods, standards, measurements, and so forth. It is expensive to work within a world and practice outside this set of standards; for many disciplines, (high energy physics, advance electronics research, nuclear medicine), nearly impossible  (Star 1991, p 41).

Designers are, perhaps uniquely, in a position were they work across different communities of practice. Designers, since the Industrial Revolution (and different to artists and crafts practitioners), don’t usually make the thing they conceive. Designers conceive ideas and communicate them by the relevant means required to the manufacturing industries. They then make the thing according to the documentation. Depending on the industry the designer is working with at the time, these requirements change as each has their own specific methods and practices. This puts the designer in a position where he or she has to be able to communicate across a range of manufacturing and associated or related communities in order to get his or her idea realised. The following account highlights the difficulties encountered by a designer working across a range of communities. Not only was it time consuming but also as Star points out, expensive — both in terms of time consumed and costs incurred.

However the communities of practice are in this account being set vis-à-vis practices of community.  Practices of community are the things that a community does. For example, cooking — a stove may be used for 3.5 – 6 hours a day (Tietz 2009). This is the practice of a particular community. It came about through the nature of the community and is not primarily driven by the practice as such, but by the material composition, the social circumstance and the physical environment in which a community may find itself.

In this particular instance, remote Indigenous householders suffer from overcrowding. Their practice gets borne out of this. Therefore they have to use their stove more than for what it is designed and built. This is the peculiarity of this community.

The remote space in question is very different to the urban space more familiar to most of us because it has a lack of services, a lack of infrastructure, a lack of maintenance, and it also has a lack of fit-for-purpose equipment. In addition, a lack of functioning houses sees a surfeit of occupants resulting in chronic overcrowding.  Data and other observations in this field (Department of Families 2007), (Pholeros, Rainow et al. 1993) (Lea 2010) has shown that the following  is not unprecedented with these types of Indigenous communities, in Northern NSW, off the coast of Arnhem Land and in Central Australia. Arguably, they have similar practices due to their location in space but also because of the regime of practice by the community of bureaucrats that provide the equipment, provide the framework and set the parameters.

If the bureaucrats knowing is an act of participating in complex social learning systems as Etienne Wenger says in ‘Communities of Practice and Social Learning Systems’(Wenger 2000), then in this case we have un-knowing due to non-participation in these complex systems (Lea 2008).

The practices of this remote community might well be supported and unremarkable if the equipment supplied worked appropriately. But the equipment does not support the practice of cooking food by the remote community under examination. The equipment fails them; hence their cooking practices run the risk of being misinterpreted.

The practices are only noticeable because the equipment fails and the repeated equipment failure causes financial expenditure to a degree that is being noticed by housing managers and bureaucrats. However the internal learning and response system might not be able to interpret the recurring failure in such a way as to actually uncover the causes, hence the ongoing supply of stoves that are destined to fail the needs of the community.

What has gone wrong: how, where and why?

This is the question I have endeavored to answer.

I’ve identified what has gone wrong and I’ve identified why it’s gone wrong —

the ethnography of the Thing revealed this information. I did not interrogate the community and its practices. I interrogated the stove, which in turn revealed the effects of the practices of this community on the stove.

This ethnography of the thing is, as Wasson says, appealing to designers because it promises to reveal not just what consumers say they do but what they actually do, ‘It highlights the importance of learning about product use in the wild’ or in the field’. Wasson (2000) further states that there is a discrepancy between the designers imagined use and the everyday behaviors that the products are subjected to.

So instead of focusing on persons and visually capturing their interaction or their description of their interaction, I have simply recorded their use, their actual interaction with the stove. This approach has resulted in unadulterated use-data by enlisting data loggers on the stoves electricity circuit.

This project revealed the actual and detailed user interaction with a number of commercial electric cook stoves in remote domestic settings. Five commercial stoves were slightly modified (to suit the domestic power draw limitations) and installed in an inland Northern NSW Aboriginal community.  A number of international manufacturers were involved. Some were enthusiastic about the possibility of a new market niche opening up. A Spanish manufacturer, Fagor, air-freighted a custom built unit. A local manufacturer, Goldstein, cooperated by factory fitting some of the required internal wiring for the testing set up, an Italian stove company, Ilve, provided a free prototype unit and another international manufacturer, Electrolux, provided two units for testing at a slightly reduced cost.

The testing location was in Northern NSW and the testing period was about 9 months. The aim was to gather detailed user interaction with the stoves in their normal use setting.  This required the data logging of each individual hotplate element, oven element, oven temperature, oven door opening and closing count and oven door status recording (i.e. is the oven door open or closed at a given time).  However it turned out that a series of highly complex communication issues had to be resolved in order to implement this quantitative testing regime – only to be rendered useless due to a totally unexpected and mundane occurrence – real life in the community.

One Black Box Leads To Another

This research project started with the opening of one ‘Black Box’, the poor performance of upright domestic cook-stoves and the exploration of their short lifespan in Indigenous communities.  Now at the end of the project I am enclosing another ‘Black Box’ as I am concluding wiring up one of six commercial test stove to be installed in place of the usually specified upright domestic cook stove. These commercial stoves are being logged in a comprehensive manner, measuring each of the hotplates and oven elements KW draw during its use, logging the internal oven temperature and counting the door opening and closing cycles and logging the door status.

All in all nine events are being logged in each of the six stoves installed — which sounds simple enough. However the process of designing, specifying, assembling and revising this seemingly simple setup turned out to be more complex than expected. An initial complicating factor was that the testing location is out of mobile coverage range which means the logging setup has to communicate via satellite and the resulting logging gear i.e. the transmitters, meters, sensors and power supply all had to be custom tailored to work with each other.

To build this network of recording and communicating devices required the design of a system represented by a wiring diagram that identified each devices relationship to another. This was quite easily done in an overall fashion. Yet the detail of which wire is connected to which terminal on either, the internal stove switches or the external sensors, meters, transmitters and resistors soon became deep computer and electrical engineering territory, a territory that an Industrial Designer is not customarily expertly equipped for. It presented a ‘landscape of practices’ (Wenger 1998, p.118) that had to be negotiated.

My design background helped in eventually producing a wiring diagram that in all its complexity was easy to read and clearly indicated where each wire has to go and what it does. I did this to the extent that the employed electrician thought I was an electrical engineer.  The diagram of course is an abstraction; it is quite another matter to then locate what is indicated on this diagram (which took numerous iterations to get right), physically on the stove or on the meters and sensors.

In order to identify the wires on the stoves the wiring diagrams of each stove were required, which the manufacturers were happy enough to supply.   I am now reading the manufacturers electrical specification drawings about the electrical configuration of the stove, interpreting them and relaying my own wiring diagram to them. Connecting new wires to the stove and then to each of the sensors and meters. I am on the periphery of the practice of describing electrical system configurations.  Each sensor also has its own wiring diagram and its own calibration procedure, in the case of the temperature thermocouple (required to obtain the oven temperature), describing the way it has to be wired up.

In the instance of the ‘CT’ transformer for example it was however no guarantee that these diagrams are complete or context specific. What might appear initially relatively unimportant can actually require a rigorous installation as otherwise the data can be inversed or erroneous.  Easy to overlook and seemingly minor details such as, ‘from which side does the wire enter and exit the loop through the current transformers’ is important. An issue that had to be first identified and then required follow-up phone calls to the supplier to help resolve. This demonstrates the level of latent knowledge that is expected to be known in this product community.

Each sensor is in fact another ‘Black Box’ that gets enlisted to become part of the bigger ‘Black Box’ that is the testing set-up. In case of the above-mentioned thermocouple no readings were obtainable.  At closer inspection, the temperature sensor had to be customised in order to be suitable for the intended use. Two big plug prongs at the end were removed and the lead wire was directly connected using the internal terminal blocks inside the sensor assembly instead of a female housing for the plug. The wires then connected to a Pt100 transmitter, which is in fact a detailed and precise instrument that has to be calibrated by hard soldering the PCB to calibrate the temperature range, which it is to measure. The temperature range can be specified from -180 to 500 Degrees Celsius in about 20 degree increments – a big range. As far as could be determined, the units supplied were preset, but no measurements were obtainable. This required some extensive troubleshooting.

Communication – Person and Sensor

Person-to-person
The sensors and the rough overall system design were supplied, but not installed, by an engineering consultant. This disconnect added a further dimension of communication to the mix.  The main protagonists I was talking to were: 1) the technical support persons that supplied the main transmitter unit (Halytech Spider) and the sub transmitters, 2) the before mentioned consultant, 3) the three various testing components suppliers, 4) the hotplate manufacturing company, 5) each of the four stove companies involved and their technical people (some of whom were in Spain), 6) the field technical adviser of the head contracting entity and 7) the electrician on the ground, 8) the community manager and 9) a field technical officer, 10) the community householders who participated in the trial, 11) the satellite service providers technical support team.

The above required me to communicate with lot of agents about the detailed intricacies of a testing setup. They were not simply different persons within the same or two different organisations, no, they all belonged to their own organisation and had in most cases multiple others attached to their position.

Sensor-to-sensor
The sensors connect to a meter (Rail 310), the meter also has an interface, it has to be set up, calibrated and tested. The meter comes with it’s own wiring diagram, explaining how it has to be connected and powered. The meter is another ‘Black Box’, however it has a LCD screen and as such is designed to be interacted with. Compared to other parts of the testing equipment, like the temperature probe and its transmitter where no such interface exists.  The meters then lead to the transmitter (the Spider unit), the ‘Spider’ is a more complicated instrument not only with its own wiring diagram but with its own 72 page manual, LCD screen and set up instructions, and its team of support personnel to guide and assist when problems occur.

The set up of the Spider unit required the installation of a new modem, configuration of the modem with the satellite service provider, extending the range of the Spider unit to accept the additional transmitters and respective sensors/probes and then configuring the new transmitters to the Spider unit itself. This required the setting up and naming each transmitter within the Spider unit protocol and making sure that it actually refers to the input that is being transmitted i.e. left rear hotplate and that the measurement is in KW (there are a range of other options) and not anything else, and the time interval. So the path of information is from the left rear hotplate switch on the stove via the CT (Hobut 104) current transformer to the meter (Rail 310) to the field transmitter (WTIXB) to the main transmitting unit (Spider) to the router (Netgear) via the satellite uplink providers IT infrastructure (Haboursat), their wholesale provider (Optus) to my Internet Service Provider (Beagle) and then finally my Internet browser (Safari), to download a .csv data file into the spreadsheet (Microsoft XL).

All these connections have to be aligned so that the information about the left rear hotplate use in the house end up in the right column of the .csv file of my spreadsheet on my desktop. In case of the door sensor and the oven temperature there is one more step from the sub transmitter (Wavesense) to the Spider unit.

Besides the main transmitter there are two other sub-transmitters (Wavesense 0-5V and 4-20mA ) that have to be configured to connect to the main transmitter, both are different. Amazingly no external identification of the different transmitters is provided! This of course complicated matters severely since both not only look identical but perform different functions and also look identical to a third unit (Waveflow) which is part of this transmitter family. All have different ratings and also the internal wire colours as indicated in the larger (Spider) transmitter manual have different functions!

Because of this initially unknown identical appearance it took considerable time to determine that a persisting fault with these particular transmitters was because a wrong unit was used. The supplier confirmed that these components are not labelled to identify the product explicitly. Product identification is provided only through the box in which it the units are packaged and not the individual units.  As I received these units through a consultant the original packaging was not included. As was eventually discovered, different cable colour is used to help determine the unit type, white for one, black for another.

A power supply is also required to power the sensors and meters. The different sensors and meters all require different voltages and currents in order to work.  Due to the setup having to be literally placed inside a box for ease of installation in the house, all these varying power levels have to come from one source that is then regulated with the help of transformers and resistors to suit the various requirements of each component.

This required a wiring diagram indicating which resistor has to be placed were in order to supply the right level of power to the right device. Resistors come in all sorts of sizes and ratings (K = the rating) for an electrical engineer this is nothing new, for the designer trying to set up this experiment, it was.

The world of electronic components had to be entered into in even greater detail as resistors are not a pre-packaged kind of item like say the temperature probe, the temperature transmitter, the door counter or door status probes, they were all products (‘Black Boxes’) that were made up of other components, but a resistors is a pretty much un-dividable unit, a basic raw electronic building block and it comes in a great many detailed variations. Two different sort of resistors had to be used a 1K and a 4.7K resistor.

Mechanical aspects

By comparison, the easy part was placing the sensors and wires inside the stoves, this required a partial disassembling of the stoves. The location of existing sensors, say for the oven thermometer, had to be located and the new additional sensor was inserted through the same opening. The door status and door count sensors had to be installed at the oven door. The status sensor could be attached to the inside door frame quite discreetly, while the door counter required modifying the oven chassis by drilling a 13mm hole to push the counter through from behind and fixing it to the frame with lock nuts.

Locating the active side of the internal stove cam switch to run the cable through the CV unit also required some trial and error. Finding the active oven element wire was harder; as for it to show a current draw the thermometer had to be engaged at the same time as the oven switch.  All of this was based on an original evidence based experiment design. The premise that to measure a Thing is to gain knowledge about its use and performance to a level of detail qualitative approaches could not reveal.  Examination of the above will show that the easy to devise, harder to document (wiring diagram) was even harder to implement.

Two measuring functions, oven temperature and door status were deleted from the testing regime due to the inability to resolve the testing requirements (hard soldering the transmitter PCB for each stove, inserting individual transistors into the sensor power supply) within the timeframe, budget (meanwhile increased by 60%) and available expertise. A hill too high to climb, in this ‘landscape of practises’(Wenger 1999). A decision was made that the remaining seven data points per stove would still provide enough feedback to ascertain the stove performance and its use in the field.

Disassembling the stove, finding sensor location points, wiring in the sensors and connecting the meters to the transmitters was all done before even a single stove is placed inside a house (its field testing environment) or even one single byte of field data is obtained and sent to my computer – (it was only one aspect of this project – the preparation for the data gathering side of it).

Data transmission – Communication continued?

The data from each stove is sent via two transmitters per stove from a suitable location on top of or within the house to the local base unit – the Spider unit. From there the data gets sent every day, 1 hour after midnight, to my computer via a satellite connection.

To implement this automatic report sending, a technical field officer accompanied me on my first trip to get the Spider unit upgraded to handle the increased transmitters reporting to it and also to install a new modem so that the existing satellite uplink can be used without interfering with the community’s communications.

The Spider unit was configured to connect via the new modem to the Internet provider’s infrastructure and send the data on its way. Once all the transmitters were installed and confirmed their communication to the base unit, I could also see the base unit on my laptop, via its IP address. It looked as if all parties, components and IP provider aligned nicely — ready for the appliance use documentation to take place.

It appeared that my ‘peripheral participation’ had navigated this ‘landscape of practices’ successfully (Smith 2003). Had the bumbling idiot amongst sages succeeded and achieved alignment? (Wenger 2000)(p:228)

However once back in the office, about 800 km’s from the field site, no data reports arrived. Numerous phone calls to the Spider base unit supplier established that there might be a fault with the unit. Its operating system was remotely upgraded to the latest version. But still no reports arrived. Meanwhile the staff obtained some data through an in-build history function in the Spider unit and converted this data manually into clean and well laid out .xls data files. For the moment a stopgap measure, but due to its time consuming nature, one not sustainable for the long run.

Once the specialist computer engineer returned from his holiday we were able to pursue this matter further. Phone calls and enquiries to the satellite provider found the problem with the Mail-server of the satellite link providers wholesaler not recognising the public IP from the Spider base unit as belonging to the Haboursat (satellite provider) client base.   Therefore it requires a log-in each time a transmission is attempted, which due to the Spider unit’s programming, it can’t provide. Resulting in a block on Port 25 at the Optus mail server.

The IP provider (Haboursat) is now talking to their wholesaler (Optus) to see whether they can adjust their system to make the Spider IP part of their network.

The technicians from both companies are in dialogue:

 “to fully resolve your issue, as I believe it is indeed possible without authentication. Although our connection goes through Optus we do not provide Optus usernames. We have our own domain (Harboursat). Will keep you posted. But Optus will be adamant about those trace route and telnet test results.”

Communication is held up due to mail server and user configuration problems, which were unexpected. Now we are trying to solve Internet authentication procedures in order to get the stove field data to appear on the desktop. These two communities are not in the same landscape.

At this point it might be worthwhile to recall that we have been communicating with a range of highly skilled experts and professionals.  The back up plan developed with the Spider unit’s technician was to open an internet account with the wholesaler (Optus) and then to remotely provide the Spider unit with these new account login details in order for the data to travel from the field unit through their mail-server eventually to my office computer. I proceeded to open a dial up account with Optus to get a username and password to enable access to the Optus network. This information was installed in the Spider unit for it to talk to and send the data on the network.

It did so for one day (Friday 15/10/10, 02:06am). For the next two days however no data was sent, reason unknown. The technicians were contacted again and that night a report was sent. Reliability of ‘automatic’ transmission had not quite yet been established, however throughout the week it would show whether it can send data for a few days in a row.

Collecting data about how stoves are used in remote Aboriginal communities is now caught up in internet protocol procedures set up primarily for consumers and not specialist uses like non-PC interfaces automatically sending data and requiring very detailed and specific IT knowledge to troubleshoot — resulting in yet another party enlisted in the network and the process of providing new facts.

Breaks in Communication

The data stream did eventually prove to be reasonably steady from the 12^th of October to the 16^th November when a break was encountered till the 1^st of December followed by another interruption till the 23^rd of December with an outage after that.

Attempts to reach the community manager failed due to the Christmas holiday season and my being away from October till December 21. Attempts via alternative contact details directly in the user community revealed that one particular phone had been disconnected and another was not answered and the third allowed me to leave my contact details, but no call was ever returned. Emails sent out were not returned. There was no way to find out.

Further attempts to gain on the ground feedback via the regional electrician contracted to install the stoves, revealed that the community was at the time, due to flooding, not accessible by road. Also it was not possible to access the field location from the community manager’s office in the adjacent community, due to these same floods.

Communications with the satellite link provider seemed to pinpoint the problem to the modem connection in the field location. This could be a possible power outage or disconnection from the power circuit.  Halytech, the Spider unit manufacturer also confirmed that the unit can currently not be accessed and also was not able to provide any explanation as to why the data stream from the unit was not contiguous. The transmitter unit sits in a locked cabinet and has a back up battery, which is good as long as there is mobile 3G reception as then it can indeed operate independently and transmit data. However once we leave the field of mobile network reception and become reliant on satellite transmission we then become also reliant on power being available at all times in order to power the modem to communicate with the satellite. Once the modem power is shut off the whole system goes down. There is some ‘on board’ storage on the Spider unit that can capture data for a few days in instances like this but not for prolonged periods of relatively high increment measurements (a reading every three minutes).

Contact

Having made contact with the community manager, we had a look at the shed where the data transmitter is located. The RCD in the consumer switchboard had tripped. He reset the circuit breaker and noted an old air conditioning unit came on. Apparently when this air conditioning unit, located inside the same room as the sealed transmission box, is on for prolonged periods it gets too hot and short-circuits the system.

This was certainly not within any of my considerations or those of the initial consultants or any other party involved in the testing set up design and implementation. It appeared that someone went in the shed/office turned on the air conditioning unit and simply forgot to turn it off. After some time this tripped the circuit breaker and therefore power to the modem was lost.

The community manager confirmed that the office should have been locked, preventing this kind of event from occurring. However there must have been more than the supposed one single key in circulation, unbeknown to the community manager. The fact that the office provides phone and internet access could perhaps also play a role in the undisclosed access.

Data management

I could access the Spider unit to download some 30,000 data points.

Once this information arrives on my computer it is in .csv format.

Bringing us to the beginning of the data management aspect of this use data gathering exercise. Here we try to assemble the story of the thing as told via the collected data from its use.

The files are to arrive each day (one hour after midnight – my specification) and through a rule in my email program the files will automatically go into a dedicated folder. In this folder they will accumulate until the end of the data-gathering period. Occasionally I have a look at a file just to make sure it is all in order.

All these separate files then have to be combined into one master file that will hold all the data of the entire testing period, estimated to be about 10.5 million data points. XL has a limit of about 84,000 rows, if there are more rows of data it doesn’t work well anymore. This means that the simple amount of raw data now requires a new program, able to handle large files of this size. In order to combine all the files easily they all need to have the same nomenclature applied, something that might not seem of major consideration at the start, considering that a simple spelling error or additional space is sufficient to mangle things up.   Then this file has to be ‘washed’, the superfluous information needs to be removed.

The current file format provides the performance data in rows and not columns, which makes it more difficult to read. In order to be comparatively evaluated, the data has to be reformatted. After the reformatting, the data is then able to provide means, averages, median and outliers and so on that can be evaluated, graphed and massaged to show the ‘truth’.

Networks

This experiment highlights that this process of investigation and the required communication to get the machines to talk to each other is enlisting a number of different networks and communities of practice. The designer is initially outside these communities of practice and through his or her work enlists them as a matter of getting this experiment implemented. Thereby bringing these communities together and forming a new community of practice, one of which he or she also has now become a part. A community that is able to communicate and demonstrate the use experienced by the stove.

The above highlights the enormous complexity of the task and the requirement of complex systems to assist in carrying it out. The depth of some of the immersion into other fields of practice was not initially anticipated, nor the intricacies associated with them.

To configure these diverse networks to work together in a productive manner was a highly intensive exercise as entirely different elements, components, standards, practices, software programs and communication protocols needed to be syncronised and brought into alignment for a prolonged time to work in harmony not only over the testing period but also for the data management, evaluation and presentation phase.

Summary

Communities of practice

‘Moving in communities of practice, that have conventions of use about materials, goods, standards, measurements, and so forth. It is expensive to work within a world and practice outside this set of standards’ (Star 1991, p 41)

Stars quote supports my observation that it is not impossible but certainly considerably complex to ‘daisy chain’ together this array of diverse communities of practice.

Commercial stoves manufacturers have a problem to envisage non-commercial use of their stove. Their assumption is that all elements have to be on all the time as one might reasonably expect in a commercial environment. This is in contrast with the domestic stove manufacturers were the stove is explicitly configured not only to not be on all the time but also only ever to be partly used.

As designers we are moving across a range of ‘communities of practice’ and are engaging with a wide variety of practitioners from different fields. Being outsiders to most of them we are not intricately familiar with their conventions, not entrenched in their codes of practice, nor constrained by the rules and values of their community. This makes it easier for new or different approaches to be found. As the outsider we ask questions and see connections that insiders might find hard to envisage.

In order to find out whether the suggested solution meets the newly established use requirements, I had to engage with, in this instance a range of communities of practice.

The practices of the computer engineer, the internet service provider, the data logging equipment provider, the electrician installing the logging gear, the commercial stove manufacturer and so on; all inhabiting their own worlds, dealing with issue relating to their close knit framework and which commonly don’t contain the range of communities that I’ve been trying to daisy chain together.

While I’ve chipped away at the high-end technical stuff to create an alignment of communication channels that send data about the stove-top hotplate temperature from the stove all the way through the ‘air’ onto my laptop and finally into a spreadsheet program, it is the daily practices of someone from the target community that unexpectedly derailed the entire technical line up that has been patched together.

A remote community member comes into the shed (which houses also the satellite transmission equipment and the modem), switches on the air-con, has a cup of tea, sits down, browses a bit of the internet and eventually walks out but did not switch off the air-con as they left. Because this is the only line of power into this shed, and the air-con unit is old, due to the economic circumstances of the community being remote, not being wealthy, the air-con overheats, the overheating triggers the RCD, the RCD disconnects the power supply.

The shed is now without power. As a result of this I am now disempowered too. The information that I fought so hard to extract, this flow of information, this data stream is power, because it makes the argument whether the stoves are performing or not, is now interrupted, is turned off.

I am not receiving the data, I have no power, the power has been disconnected.

Daily life in remote communities and the designer that comes in to set up his system to supply him or her with information about their practices, in order to enable, observe and evaluate these practices, can’t by the very nature of his or her position (coming in trying to set this up), be aware of what goes on in the community. Indeed it is the whole point of not interrupting, not disturbing, not to actually take part but to let it happen. Yet exactly this ongoing happeningness creates the problem.  There is a paradox, I don’t want to disturb, I want to observe yet the very thing I want to observe disrupts that which I want to gather – the data about their stove use practices.

This practical wisdom of how to go about it is, as Loftus says, difficult if not impossible to articulate. It can not be learned from a book (Loftus, p.43). From the account presented, it appears that it could most likely not have been pre-empted.

The circumstances and event, which brought about the operating environment, were unique and unforeseeable.

Loftus again,

“If we think of Wittgenstein’s expression of “understanding … ‘how to go on’” (1958 #154) as the ability to use the stories of practice in such a way that we now know what to do in certain situations, then such stories are clearly powerful resources provided by the community of practice. These stories provide people with examples of what might be possible in a range of situations where uncertainty and complexity are the norm. Stories of practice are important elements of a community that enable practitioners to deal with what Schön (1983, 1987) described as the ‘swampy lowland’ of professional practice (1987, p.1). The reality of professional practice is that there can be a great deal of uncertainty with problems not found in any textbook. These stories are social resources for community members to navigate their way through such swampy lowlands”.(Loftus, p.44)

Practice of community is also a result of what is available for the community to work with, engage with and have access to. It is in a way prescribed onto them but it also another way of the community trying to make the best out of the resources available to it. For example the stove is clearly a highly valued and important item because of the use that it is experiencing. Therefore people in that community are trying to make best use of what they’ve got. They are responding to the physical material environment to the fixtures, fittings and appliances available to them. They respond to what they have and how well it performs. They are not a result of primarily socio-culturally driven actions, like traditions and heritage.

They are actions driven out of practicality, driven out of a need relating to the performance of the thing rather than enacting ‘traditional’ cultural practices.

Practices of a community can develop as a response of what is available to them rather than traditional cultural practices.  The difference between Communities of Practice where the (professional) practice is the center, the commonality around which the community gathers and Practices of Community in which the center is not the practice as such but the community and the communities location, geographically, socio-economically, culturally and so on. In the first the focus is on how we do something, in the other the focus is in response to what is available to us within the physical community.

References

Latour, B. 1987, Science in action, Harvard University Press, Cambridge Massachusetts.

Department of Families, C. S. a. I. A. National Indigenous Housing Guide. Canberra, Commonwealth of Australia. 2007

Lea, T. Bureaucrats and Bleeding Hearts, Indigenous Health in Northern Australia. Sydney, UNSW Press. 2008

Lea, T.  “This Is Not a Pipe: The Treacheries of Indigenous Housing”. Public Culture 22.1 (2010): 187-209.

Loftus, S. Exploring Communities of Practice, Landscapes Boundaries and Identities. Education For Practice Institute, Charles Sturt University, Parramatta, NSW, Australia.

Pholeros, P., S. Rainow, et al. Housing for Health, Towards a Healthy Living Environment for Aboriginal Australia. Newport Beach, HealtHabitat. 1993

Smith, M. K.. Communities of practice, the encyclopedia of informal education, infed. 2003

Star, S. L. Power, technology and the phenomenology of conventions: on being allergic to onions. London, Routledge 1991.

Tietz, C.  “Stirring Appetites in design: A User Centred Product Design Approach to Improve Environmental Healh in Remote Indigenous Australia”. Design Principles & Practices: An International Journal 3.5 (2009): 105-119.

Wasson, C.  “Ethnography in the field of design”. Human Organization 59.4 (2000): 12.

Wenger, E.  Communities of Practice: Learning, meaning and identity. Cambridge, UK, Cambridge University Press, 1999.

Wenger, E.. “Communities of practice and social learning systems”. Organization 7.2 (2000): 27.

Author Biography

Christian Tietz is a lecturer in Industrial Design at the University of Western Sydney, Australia.  Christian is Director of Designlab Oceania p/l and the National R&D Manager of Healthabitat.  He is a winning team member of the 2011 UN World Habitiat Award and is interested in healthy living environment design and remote area design.