I just came across a call to arms by Kristina Höök, “A Cry for More Tech at CHI!” in Interactions this month. I was so glad to see her writing about this and I hope the article bears fruit. She talks about the ways in which technology can inspire design — I would argue also enable design — and why alternate forms of publications should be given archival value as one way of supporting tech research (such as videos, demos, etc). Imagine if videos at CHI were valued as much as videos at SIGGRAPH!

I don’t want to say much more because I hope you go and read what she had to say, but I will note that her sentiment doesn’t just apply to CHI. How about other conferences? And a question I’ve been asking myself recently — what can I do to encourage more tech in my own research group? The answer, I’ve discovered, is to uncover what technology research means to me. That I will say more about.

As I mentioned in a recent post about my sabbatical goals, I have spent some time recently trying to reposition myself. I am and will always be driven by real-world problems, usually ones that come out of personal experience. However, if that is the sole driving force in my work, why am I not a sociologist? Or a politician? Or a anthropologist? Why don’t I run a non-profit? Why am I a computer scientist? The answer that I keep coming around to is that I like to build re-usable solutions to problems, solutions that are (ideally) bigger than the problem I started with. In addition, I believe that technology has value in part because it can solve problems in new ways, sometimes better ways, if we are innovative about how we use it, rigorous, and willing to push the boundary of what technology is capable of. So I am also driven by a wish to build systems, hard systems, systems that do things that have not been done before or create new ways of doing things. In fact, when I look back over the technical work I’ve done, after years of trying (for every job search, tenure review, and so on) I think I finally have put my finger on the unifying theme in my work.

I have always, in some way or another, built what I think of now as data-driven interfaces. I’m certainly not the first person to use this term. Nor is it confined to my area (HCI). But to me it describes one of the most important roles that technology has to play in the world. Many of the most revolutionary impacts of technology have centered around its ability to show information (think of spreadsheets and visualization tools), share information (think of everything from email to the web to facebook) and process information (think of the work in context-aware and ubiquitous computing, machine learning, and so on). And my own inspiration has been similar — my honors thesis as an undergraduate centered around exposing what was going on inside of programs; my PhD work on managing the uncertainty that arises when recognizing sensed input; my PhD students have developed/are developing tools for building ambient and peripheral displays (a form of visualization), rapidly prototyping and field testing ubicomp apps (providing essential data about what information belongs in the application in the first place), measuring and predicting which users have difficulty with an interface (a type of information processing), handling uncertain input within the user interface toolkit, and sharing information about energy use in the home. Of course when you have a hammer, everything looks like a nail (and there’s many aspects of each of these projects that I left out so they would look more nail-shaped) but I do believe there’s a theme here.

Having recognized the theme, a natural question that I, as a toolkit builder, find myself asking is: What is hard about building these sorts of interfaces, especially in situations where we expect people to use the resulting applications. I think there are many unsolved problems, along the entire pipeline from deciding what data to use all the way through to acting on it in some way. Ideally, this should all be put together, in a fashion that scaffolds the process as much as possible and enables communication of constraints and other information from one end of the pipeline to other and back.

The idea of a pipeline for data-driven, interactive systems leads to a whole host of interesting questions I hope to begin answering. What should be communicated within the system? What should be communicated to the user? How does all of this change the way we construct toolkits at the input level? What about the output level? What abilities might we want to give end users with respect to data-driven interfaces? How do we help people build effective classifiers when they have not studied machine learning? How do we help people to select and integrate visualization techniques? What new sensors can we construct and what should we sense? When and how might we involve people (i.e. the crowd) in gathering, labeling, extracting features from, interpreting, even visualizing information? How do we trade this off with machines? And finally, how does the interactive nature of the end systems affect the way we should answer any of these questions?