For example, when designing mobile tools for placement learners the MPLAT Project ran into the well known problem of co-design. The technologists don't understand the domain well-enough to design an appropriate fit, but the domain-experts don't understand the technology well-enough to be truly innovative. I once heard this described as the Problem of the Robot Horse, a fictional scenario where scientists from the 1700's are asked what vehicle they would build with modern technology, and all they can think of are robot horses - because a horse is all that they are familiar with.
In MPLAT we developed an extensive co-design and co-deployment methodology to try and enable innovative but informed design. HCI is not the right name for this research, it's about new processes of system design that incorporates elements of HCI in its core, some other phrase is needed.In the FREMA project we experimented with a Semantic Wiki (a wiki where pages and links have types) to see if a community folksonomy (the set of types authors chose) would converge over time into anything resembling a designed ontology.
Through experimentation we showed that while creative interfaces helped authors, it was seeding the wiki that had the most significant effect on the quality of the emerging structure. This work was all about how communities expressed their knowledge, and how much they were aware of the process of knowledge construction. It certainly has elements of HCI to it, but again the term HCI doesn't capture it accurately.
As a final example consider the work we've done most recently on trying to redesign teaching and learning repositories, by examining how teaching repositories differ from research repositories, and exploring what elements of Web 2.0 design are most appropriate for them. Our more theoretical starting point led us to reject many of the commonly held beliefs about Learning Objects and repository design, resulting in a number of emerging repository installations that have a radically different feel to them (such as EdShare and HUMBox).
Once more our approach goes beyond interface design, and includes a number of more holistic factors, such as balancing the meta-data needs of the system with the tolerance of the users, and aligning the purpose and services of the software with potential users. If the term HCI is to broad to capture this, then what does?
This problem came to a head for me recently when I had to present our repository work at the first EdShare workshop. I needed to somehow express this process of aligning an information system with its users, in terms of both workflow and knowledge.
As a happy coincidence I happened to mention some of this work (in an entirely unrelated conversation) to Stephen Thomas from the School of Management, and he noted that it sounded a lot like ergonomics - the science of designing equipment (normally physical equipment) to fit the user. A few googles later and I had introduced myself to the discipline of Cognitive Ergonomics - the science of designing equipment to fit the mind - and the concept of Macroergonomics - a broad view of ergonomics that includes environmental and cultural factors.
So perhaps the work that we do is best described as a type of cognitive or Knowledge Ergonomics - the science of building knowledge structures and systems that fit the ways in which the users of those systems conceptualise, express, communicate, process and use knowledge.
In simpler words: building systems that better fit how people think.
