Space Constraints
Posted: March 26th, 2006 | 1 Comment »Toilet paper holder integrated into a bathtub due to space constraints
Toilet paper holder integrated into a bathtub due to space constraints
United Nations guerilla marketing in BCN. “Would you drink that water? Thousands of people do not have the choice”.
My baggage got lost in my regular GVA-BCN commute. At my airport arrival, the ground handling staff first asked me if I had written my name on the luggage. During 4 days, nobody knew where it was, and it was delivered to me the 5th day. Interestingly, the usual bar codes on the baggage label got overwritten by hand. Apparently, as soon as my belonging left the standard baggage handling procedure, it got uniquely handled by humans using analogical means. Since humans handle exceptions, the elected support was handwriting on paper. The fail-over technique – me handwriting my name on the baggage – is also based on analogical support. Is this the best/cheapest way to handle exceptions? Digital means (bar codes or RFID) can show limits in interfacing with us, especially when we need to take over the control of the system to correct the errors.
On an average, airlines globally spend as much as $1.6 billion a year on mishandled baggage (source). Around 14 baggages over 1000 are lost and 85% of this lost baggages never find their owner. The big source of error is actually the airport hourly baggage processing limit that is sometimes reached. Bar code reading systems slow this process because around 15 percent of bar codes printed onto the labels placed on checked-in luggage are not properly read automatically. The introduction of RFID is supposed to improve the situation as around 99 percent of RFIDed baggage are read automatically. However will RFID improve the exception handling? A damaged basic RFID will provide 0 data, while a paper label sometimes deliver clues (visual affordance). Attaching handwritten personal information on the belonging will probably become more important.
Update Dec 2006: A story that goes into my analysis: Qantas: proud promoters of worst-practice baggage RFID tracking
Relation to my thesis: Example of the limits of digitalization in exception handling and source of uncertainty.
The research bible On research methods, by Järvinen Pertti; Opinpaja Oy 2004, is very resourceful to me in understanding the research process, selecting a research approach and applying design-science research.
There are four possible purpose of science, namely to describe, the explain, to predict and to control. However, we shall not restrict to them, because they do not cover the study off whether we can or cannot build a new artifact. The purpose of such a study can be understanding the system, its re-engineering and evaluation.
In How to select an appropriate research method in ergonomic studies?, Jarvinen provides a taxonomy of research methods.
My research ideas tends to study their utility as innovation by means of building and evaluation. In building a new innovation, utility aspects are striven and a particular development method is applied. In evaluation of the innovation, the realized final state is compared with the desired goal state, and maybe some criteria are used and some measurements performed. This process is called design science. The goal of design-science research is utility (while behavioral-science research aims at truth).
Research-science research is about answering the questions: Can we build a certain innovation and how useful is a particular innovation? The research questions contains verbs like: build, change, improve, enhance, maintain, extend, correct, adjust, introduce.
“The mission of design science is to develop knowledge for the design and realization of, i.e. to solve construction problem, or to be used in the improvement of the performance of existing entities, i.e. to solve improvement problems”, in other words, to implement some innovation.
The mission of design-science can also be seen as to develop design knowledge.
Design knowledge concerns “three designs: an object-design, the design of the intervention or of the artifact; a realization-design, i.e. the plan of the implementation of the intervention or for the actual building of the artifact; and a process-design, i.e. the professional’s own plan for the problem solving cycle, or, put differently, the method to be used to design the solution to the problem.
The design sciences are not too much interested in what is, but more in what can be.
The integral outcome of both construction and improvement is called a technological rule. Construction has four outcomes (construct, models, methods and instantiations) and two research approaches (build and evaluate).
A technological rule is defined as a chunk of general knowledge, linking an intervention or artifact with a desired outcome or performance in a certain field of application.
A major breakthrough rule occurred with the testing of the technological rule and then grounding on scientific knowledge.
Guidelines as requirements for effective design-science research are:
Design-Science Research guidelines from Alan R. Hevner, Salvatore T. March, Jinsoo Park, Sudha Ram: Design Science in Information Systems Research. MIS Quarterly 28(1): (2004)
The building process
Building is a process of constructing an artifact/innovation for a specific purpose. Early in the process extracting multiple case study is a good research practice to uncover technological rules already used in practice. In the developing multiple case study, the technological rules are developed and tested by researchers in close collaboration with the people in the field and often in the context of application. Following a reflective cycle,after each case, the researcher develops knowledge that can be transferred to similar context on the basis of reflection and cross-case analysis.
Design science products are of four types:
Constructs: or concepts from the vocabulary or language of a domain
Model: a set of propositions or statements expression relationships among constructs
Method: a set of steps (an algorithm or guidelines) used to perform a task
Instantiation: the realization of an artifact in its environment
The purpose of of the construction process is to achieve a movement from the initial state to the goal state (part of the specification process). The descriptive model of the initial state may need to capture the structure of reality in order to be a useful representation. The normative model of the goal state represents how things how to be.
A practitioner ought to describe the building process in detail, argue the selections and explain the decision. The originality of the solution and its superiority to the known solution must also be demonstrated.
The evaluation of the construction results
The research contribution lies on the novelty of the artifact and in the persuasiveness of the claims that is it effective. Evaluation is a process of determining how well the built artifact performs. It the research outcome is totally new, the actual performance evaluation is not required at this stage. When the old outcome exists, significant differences between the old construct, model, method or instantiation and the new one.
Metrics are needed in the evaluate activity to define what the research is trying to accomplish. Proposed universal metrics target all types of artifacs (i.e. constructs, models, methods and instantiation):
Once metrics are developed, empirical work may be necessary to perform the evaluation. Constructs, models, methods and instantiations must be exercised within their environments. Often this means obtaining a subject group to do the exercising. Often multiple constructs, models, methods or instantiations are studies and compared.
Action Research
Action Research assumes that both building and evaluating sub-processes closely belong to the same process. It is the production of knowledge to guide practice, with the modification of a given reality occurring as part of the research process itself.
Relation to my thesis: I better understand how I should formulate my research questions and the process to answer them. Design-science research, in its building phase, has many similarities with engineering that I am familiar with (understanding of the initial state, requirements settings, definition of the goal state, instantiation, technological selection, iterative process, fast prototyping, … ). I am less aware of a scientific evaluation process.
As part of my investigation that explores the people perception of discrepancies in the context of collaboration supported by ubiquitous environments, my object-design should aims at improving the individual and group performance in and real-world uncertain ubicomp systems. First I will need to understand uncertainty from the literature and my own experiments (set the initial state), then build case studies (i.e. set the goal state to reach, different approaches and contexts), test field and evaluate them.
Starting in April, I’ll be teaching assistant for a 10-weeks User Interface Design course given to UPF undergraduate students. I’ll be in charge of the labs and hopefully be lecturing week 8 on UI design in the context of ubicomp.
Objectives:
This course gives students in software engineering an adequate base for the design and prototyping of user interface. They will be exposed to the relation between the human-user and the computer (device, graphical elements, …). They will understand the engineering process of design. Student will learn:
The objective of the labs are to practically learn how to design and evaluate the prototype of an interface by using the techniques and methodologies of interface design.
Week 1
Theory: Introduction. The quality of an interface and its evaluation; user-centered design
Lab: Preparatory work: select an interface to design, and one similar that already exists
Week 2
Theory: The quality of an interface quality and the evaluation; user-centered design (cont.). Contextual design methodology
Lab: Development of a user questionnaire; evaluation of a similar interface; preparation of the results analysis.
Week 3
Theory: Contextual design methodology (cont.), User-centered design methodology
Lab: Contextual design, observe the user at work, contextual survey, work modeling. Contextual requirements
Week 4:
Theory: User-centered design methodology. Variety of interfaces.
Lab: Apply the user-centered design methodology: Model of the role, task and content. Keystroke-Level Model. Usage requirements according the user’s task and system responses.
Week 5:
Theory: Variety of interfaces (cont.)
Lab: Model of the proposed design and application of measures. Choose between the design alternatives. Qualitative criteria: the user’s cognitive workload.
Week 6:
Theory: Variety of interfaces (cont.)
Lab: Design the first prototype of the interface. Adapt to work with compromise. Use of prototyping tools.
Week 7:
Theory: Evaluation revisited. Tools for interface programming
Lab: Design development (cont.)
Week 8:
Theory: Future aspects of user interface design
Lab: Experimental evaluation of the design
Week 9:
Theory: Project (tutoring)
Lab: Project (tutoring)
Week 10:
Theory: Project presentation
Lab: Project presentation
As part of my doctoral school course on web retrieval and data mining, Hugo Zaragoz (now at Yahoo! Research) gave a crash course on machine learning in the context of data mining. A few notes:
Machine learning could be inspiring in the context of ubicomp systems. For example in improving context detection. However one current challenge is “unsupervised learning”, that is when the features of the target result are not known and only assumed (that’s often the case in uncontrolled ubicomp system). There are 4 major way to handle uncertain information:
For model validation, it is important not to test the model with the data used for training the model.
Relation to my thesis: Machine learning is certainly a way for systems to become more context-aware and make less errors. As I might end-up modeling uncertainty in the context of collaboration in a ubicomp system, I got a few clues on how to properly validate a model (not mixing training set of data with test sets).
Bell, M., Chalmers, M., Barkhuus, L., Hall, M., Sherwood, S., Brown, B., Rowland, D., Benford, S., Capra, M., and Hampshire, A., “Interweaving Mobile Games with Everyday life“. In Proceedings of CHI 2006, Montreal, Canada. Forthcoming.
This paper presents a new seamful-designed location-based game called Feeding Yoshi in which the coverage and security of WiFi are integrated in the gameplay. Seamful design emerged from early ubicomp studies that raised the issues around the impact of variation or uncertainty with regard to location and network connectivity. These experiments were mainly small scaled in terms of area and duration. Feeding Yoshi plans to be large-scale and longitudinal to understand how ubiquitous computing experience actually fits with other activities.
As Weiser put it, “the unit of design should be social people, in their environment, plus your device”. We suggest that Yoshi provides an example of how this can be approached, in that many of players’ action and strategies were specific to the characteristics of the wireless access points and PDA’s networking users and interpreted on the basis of their experience and understanding of this wider context.
There is a great quote mentioning the different capabilities of 2 similar devices or as Nicolas puts it as the The uniqueness capabilities of pervasive devices.
Players also became aware of some technical features that we were only vaguely aware of ourselves. In one case, a player became aware—and angry about—the fact that his PDA’s 802.11 antenna had a significantly lower sensitivity than his team–mates’, even though they were using the same model of PDA.
We noticed similar “uniqueness of device” during our CatchBob! experiments. Similar TabletPC, similar context, similar hardware and software, had different sensitive. In the end of the experiments we knew which ones behaved better than others based in their history of connectivity issues. Uniqueness of device should actually be integrated in seamful scenarios.
Relation to my thesis: In the context of everyday computing, it become now important to set large-scale experiments. Time and area are the easiest scale to play with. I plan to work on these 2 scales also. People and devices scales are harder to deplay and support therefor mainly left on the side by most ubicomp field experiments. However with still a low-scale set of devices, the uniqueness of devices could be noticed. We often mention the heterogeneity of models of devices in ubicomp, while failing to precise that this heterogeneity exists in devices exiting the same factory line.
G. D. Abowd, E. D. Mynatt, “Charting Past, Present and Future Research in Ubiquitous Computing“, ACM Transactions on Computer-Human Interaction, 7(1):29-58, March 2000.
This is Abowd et al. seminal paper that addresses the challenges of HCI in ubicomp and presents the notion of “everyday computing” that requires to design for continuous interaction by addressing the needs of interruption and resumption of interaction. Everyday computing focusses on scaling interaction with respect to time.
Requirements for critical-mass acceptance and collaboration imply scaling with respect to people. A final dimension, time, presents new challenges for scaling a system.
It promotes informal and unstructured activities typical of much of our everyday lives.
The objective is to understand how everyday tasks can be better supported, and how they are altered by the introduction of ubiquitous technologies.
The real goal for ubicomp is to provide many single-activity interactions that together promote a unified and continuous interaction between humans and computational services.
Ubicomp research implicit goal in the context of HCI has been to assist everyday life and not overwhelming it. Current accomplishments range in scale and in size from “inch-scale” personal devices to “yard-scale” shared devices. 3 themes of challenges remain:
These three themes moves ubicomp more into the realm of everyday computing characterized by continuously present, integrative and unobtrusive interaction.
Natural interfaces come with the problem of new type of user input mistakes. Systems must assume that errors will occur and provide ways to handle it. Error handling is nothing new. Research areas include error reduction (elimination of errors is probably not achievable), error discovery (techniques include thresholding of confidence measures, historical statistics, and explicit rules specification) and reusable infrastructure for error correction.
Sensing technologies are not 100% reliable and deterministic. However
Combining measure from multiple sources could increase the confidence value for a particular interpretation.
Designing for everyday computing requires addressing these feature of informal, daily actvities:
Some HCI research directions in everyday computing include
We are still in the early premises of evaluating ubicomp systems and the coevolution with us. Social implications of technologies will often come after people invent new, unforeseen, uses of these technologies.
In order to understand the impact of ubiquitous computing on everyday life, we navigate a delicate balance between prediction of how novel technologies will serve a real human need and observation of authentic use and subsequent coevolution of human activitie and novel technologies. Carroll, J. M., and M. B. Rosson. “Deliberated Evolution: Stalking the View Matcher in Design Space“. Human-Computer Interaction, Vol. 6, 281-318, 1991
Main evaluation challenges include:
Other more recent article on that subject from the same authors: The Human Experience in Ubicomp
A ppt presentation summarizing this article.
Relation to my thesis: Addressing the need to scale in space, the number of devices and people using a system. Scale is implicit in the definiton of ubicomp research. Mention to the errors of human inputs to the system and how it is close to impossible to avoid them. I guess that part of the uncertainty in collaboration supported by ubicomp system does not uniquely come from technical limitations and failure but also bad user inputs. Errors must be assumed. A high-level goal of my thesis is to understand how everyday tasks can be better supported, and how they are altered by the introduction of ubiquitous technologies. I am aware that in the evaluation of my experiment platforms, there is a need to build a compelling story, form the end-users’ perspective (finding a human need). I plan to deploy the platform in authentic settings according to the scaling dimensions that characterize ubicomp systems, that is device, space, people and time.
The San Francisco Bay Area thrives on tides. It profits from low tides to reinvent itself as innovation hub. However, with the emergence of competing creative region, business and government officials face challenges that could be overlooked in the past. Baby boomers are retiring, workers are getting squeezed out by the high cost of living and foreign professionals are moving back home. High cost of living and the obstacles raised by U.S. immigration policies and factors are the obvious factors to reduce the regional quality of life. Interestingly now, measures to attract new creative brainiacs is to capitalize more on the home-grown workforce. That is investing in lower education and training programs to reduce education and social gaps. Boldly put: “if teachers and firefighters can’t live in the region, then you’re not offering a very attractive region to the engineers who are thinking of moving here”. The SJ Mercury News has an article on it: Bay Area brain drain, lack of affordable housing, education gaps, stunting economic grows.
MeHere is a networked GPS tracker for Google Maps and Google Earth. It integrates with Google Earth’s Network Link, allowing to see others move around in realtime.
Relation to my thesis: An example of system that allows real-time, real-world location-awareness. Similar to campus-based my MapMe.