Category Archives: Interface Design

The “Ethical Knob” Won’t Work

If the goal was to make a splash, they succeeded.

But if this is supposed to be a serious proposal, it’s positively idiotic.

This minth Giuseppe Contissa, Francesca Lagioia, and Giovanni Sartor of the Univerity of Bloogna published a description of “the ethical knob”, which adjusts the behavior of an automated vehicle.

Specifically, the “knob” is supposed to set a one-dimensional preference whether to maximally protect the user (i.e., the person setting it) or others. In the event of a catastrophic situation where life is almost certain to be lost, which lives should the robot car sacrifice?

Their paper is published in Artificial Intelligence and Law, and they have a rather legalistic approach. In the case of a human driver, there are legals standards of liability that may apply to such a catastrophe. In general, in the law, choosing to harm someone incurs liability, while inadvertant harm is less culpable.

Extending the principles to AI cars raises the likelihood that whoever programs the vehicle bears responsibility for its behavior, and possibly liability for choices made by his or her software logic. Assuming that software can correctly implement a range of choices (which is a fact not in evidence), the question is what should designers do?

The Bologna team suggests that the solution is to push the burden of the decision onto the “user”, via a simple, one-dimensional preference for how the ethical dilemma should be solved. Someone (the driver? the owner? the boss?) can choose “altruist”, “impartial”, or “egoist” bias in the life and death decision.

This idea has been met with considerable criticism, with good reason. It’s pretty obvious that most people would select egoist, creating both moral and safety issues.

I will add to the chorus.


For one thing, the semantics of this “knob” are hazy. They envision a simple, one-dimensional preference that is applied to a complex array of situations and behavior. Aside from the extremely likely prospect of imperfect implementation, it isn’t even clear what the preference means or how a programmer should implement the feature.

Even more important, it is impossible for the “user” to have any idea what the knob actually does, and therefore to understand what the choice actually means. It isn’t possible to make an informed decision, which renders the user’s choice morally empty and quite possibly legally moot.

If this feature is supposed to shield the user and programmer from liability, I doubt it will succeed. The implementation of the feature will surely be at issue. Pushing a pseudo-choice to the user will not insulate the implementer from liability for how the knob works, or any flaws in the implementation.  (“The car didn’t do what I told it to.”, says the defendant.)

The intentions of the user will also be at issue. If he chooses ‘egoist’, did he mean to kill the bystanders? Did he know it might have that effect? Ignorance of the effects of a choice is not a strong defense.

I’m also not sure exactly who gets to set this knob. The authors use the term “user”, and clearly envision one person who is legally and morally responsible for operating the vehicle. This is analogous to the driver of a vehicle.

However, the “user” is actually more of a passenger, and may well be hiring a ride. So who says who gets to set the knob? The rider? The owner of the vehicle? Someone’s legal department? The terms and conditions from the manufacturer? The rules of the road (i.e., the T&C of the highway)? Some combination of all of the above?

I would imagine there would be all sorts of financial shenanigans arising from such a featuer. Rental vehicles charging more for “egoist” settings, with the result that rich people are protected over poor people. Extra charges to enable the knob at all. Neighborhood safety rules that require “altruist” setting (except for wealthy or powerful people). Insurance companies charging more for different settings (though I’m not sure how their actuaries will find the relative risks). And so on.

Finally, the entire notion that this choice can be expressed in a one-dimensional scale, set in advance, is questionable. Setting aside what the settings mean, and how they should be implemented, the notion that they can be set once, in the abstract, is problematic.

For one thing, I would want this to be a context sensitive. If I have children in the car, that is a different case than if I am alone. If I am operating in a protected area near my home, that is a different case than riding through a wide open, “at your own risk” situation.

Second, game theory makes me want to have a setting to implement tit-for-tat strategy. If I am about to crash into someone set at ‘egoist’, then set me to ‘egoist’. If she is set to ‘altruist’, set me to ‘altruist’, too. And so on. (And, by the way, shouldn’t there be a visible indication on the outside so we know which vehicles are set to kill us and which ones aren’t?)

This whole thing is such a conceptual mess. It can’t possibly work.

I really hope no one tries to implement it.


  1. Giuseppe Contissa, Francesca Lagioia, and Giovanni Sartor, The Ethical Knob: ethically-customisable automated vehicles and the law. Artificial Intelligence and Law, 25 (3):365-378, 2017/09/01 2017. https://doi.org/10.1007/s10506-017-9211-z

 

Robot Wednesday

Database of App UI Designs

This month Ranjitha Kumar and colleagues report on ‘Rico’, which is a large dataset of UI’s from published Android apps [1]. The dataset has tools to search the data for similar apps, and to use the data to autogenerate app code to follow ‘best practice’ determined by the sample. Ideally, this can aide designers to find examples to guide development.

The data itself was collected from apps from the Android app store (which has metadata, too). Screens and sequences of interactions were collected though a hybrid of crowdsourcing (human) and automated interaction.

The data was processed to extract the UI elements underlying each screen, a set of interaction paths sampled, and animations of transitions. The visual appearance is encoded in a 75 dimensional vector, which is used for searching an generating screens.

This approach lets a designer search by example, to find other that are UIs similar. Or a designer can sketch a UI, and find others that suggest ‘the rest’ of the elements for the screen, based on  similar apps.

The information encoded in this data set are a large sample of current designs, encapsulating something about current practice. The paper says this is ‘best practice’, though it actually is just ‘common’ practice not necessarily ‘best’.

It would be natural to link this dataset with empirical data about the quality of the product, e.g., user satisfaction, number of downloads, or revenue. Then, it would be possible to rank the instances and find the actual best practices.

The data is a snapshot of current practice, and it took a lot of effort to gather, The authors would like to improve the data gathering process so they can continuously update the dataset with new and upgraded apps. If they can indeed collect data over teim, they could create a dataset of historical trends in app design. This could reveal changes over time both functional and esthetic. And tt might be possible to observe UI ‘fads’ emerge and spread throughout the population of apps. That would be neat!

The project ultimately  aims to develop tools that help designers, e.g., to autogenerate code based on sketches and the knowledge encoded in the tool and dataset.

I’m a little concerned that this tool might be basically just copying what other people have done—leading designers toward the average. This may be fast and cheap, but it is no way to create outstanding products.  In my view, apps are already too similar to each other, due to the use of ubiquitous infrastructure such as standard cloud services APIs and other toolkits.

But this kind of data might actually be used to search for novel solutions. For example, the encoded designs might be used in the fashion of a genetic algorithm. A design is encoded, then the encoding is mutated and new designs generated. Or the encodings might be mixed or crossed with each other, generating a ‘mash up’ of two designs.  Many such mutations would not be viable, but you could generate lot’s of them and select the best few.  (I.e., evolutionary design.)

I don’t know how well this would work in the case, but the idea would be to search through the gaps in current practice, and to optimize current designs. Now that would be kind of cool!


  1. Biplab Deka, Zifeng Huang, Chad Franzen, Joshua Hibschman, Daniel Afergan, Yang Li, Jeffrey Nichols, and Ranjitha Kumar, Rico: A Mobile App Dataset for Building Data-Driven Design Applications (to appear), in Symposium on User Interface Software and Technology (UIST ’17). 2017: Qubec. http://ranjithakumar.net/resources/rico.pdf

Telepresence Robot – At the zoo

These days we see a lot of exciting stories about telepresence—specifically, live, remote operation of robots. From the deadly factual reports from the battlefields of South Asia through science fiction novels to endless videos from drone racing gamers, we see people conquering the world from their living room.

One of the emerging technologies is telepresence via a remote robot that resembles ‘an ipad on a segway’. These are intended for remote meetings and things like that. There is two way video, but the screen is mobile and under the command of the person on the other end. So you can move around, talk to people, look at things.

On the face of it, this technology is both amazing (how does it balance like that?) and ridiculous (who would want to interact with an ipad on wheels?) And, of course, many of the more expansive claims are dubious. It isn’t, and is never going to be, “just like being there”.

But we are learning that these systems can be fun and useful. The may be a reasonable augmentation for remote workers, not as good as being there, but better than just telcons. And, as Emily Dreyfus comments, a non representational body is sometimes an advantage.

Last year Sensei Evan Ackerman reported on an extensive field test of one of these telepresence sticks, called the Double 2. This test drive was an interesting test because he deliberately took it out of the intended environment, which stressed the technology in many ways. The experience is a reminder of the limitations of telepresence, but also gives insights into when it might work well.

First of all, he played with it across the continental US (from Maryland to Oregon) thousands of KM apart. Second, he took it outdoors, which it isn’t designed for at all. And he necessarily relied on whatever networks were available, which varied, and often had weak signals.

As part of the test, he went to the zoo and to the beach!

Walking the dog was impossible.

Overall, the system worked amazingly well, considering that it wasn’t designed for outdoor terrain and needs networking. He found it pretty good for standing still and chatting with people, but moving was difficult and stressful at times. Network latency and dropouts meant a loss of control, with possibly harmful results.

Initially skeptical, Sensei Evan recognized that the remote control has advantages.

I’m starting to see how a remote controlled robot can be totally different [than a laptop running Skype] . . . You don’t have to rely on others, or be the focus of attention. It’s not like a phone call or a meeting: you can just exist, remotely, and interact with people when you or they choose.

Whether or not it is “just like being there”, when it works well, there is a sense of agency and ease of use, at least compared to conventional vidoe conferencing.

This is an interesting observation. Not only does everybody need to get past the novelty, but it works best when you are cohabitating for considerable periods of time. Walking the dog, visiting the zoo—not so good. Hanging out with distant family—not so bad.

I note that the most advertised use case—a remote meeting—may be the weakest experience. A meeting has constrained movement, a relatively short time period, and often is tightly orchestrated.  This takes little advantage of the mobility and remote control capabilities. You may as well as well just do a video conference.

The better use is for extended collaboration and conversation. E.g., Dreyfus and others have used it for whole working days, with multiple meetings, conversations in the hall, and so on.  Once people get used to it, this might be the right use case.

I might note that this is also an interesting observation to apply to the growing interest in Virtual Reality, including shared and remote VR environments.  If a key benefit of the telepresence robot is moving naturally through the environment, then what is the VR experience going to be like?  It might be “natural” interactions, but it will be within a virtual environment.  And if everyone is coming in virtually, then there is no “natural” intereaction at all (or rather, the digital is overlaid on the (to be ignored) physical environments. There will be lots of control, but will there be “ease”?  We’ll have to see.


  1. Evan Ackerman, Double 2 Review: Trying Stuff You Maybe Shouldn’t With a Telepresence Robot, in IEEE Spectrum – Automation. 2016. http://spectrum.ieee.org/automaton/robotics/home-robots/double-2-review-telepresence-robot

 

Robot Wednesday

Facebook’s AI Led Astray By Human Behavior

I don’t follow the roiling waters of online advertising giant Facebook. Having moved fast and broke things, they are now thrashing around trying to fix stuff that they broke.

This month a team of researchers at Facebook released some findings from yet another study [3]. Specifically, the experiments (which don’t seem to have been reviewed by an Institutional Review Board) are trying to build simple AI’s that can “bargain” with humans. This task requires good-enough natural language to communicate with the carbon-based life form, and enough of a model of the situation to effectively reach a deal.

Their technical approach is to use machine learning so that bots can learn by example. Specifically, they use a collection of human-human negotiations, and tried to analyze the behavior to discover algorithms to replicate human-like interactions.

With preposterous amounts of computing power, who knows? It might work.

Unfortunately, the results were less than stunning.

Glancing at the conclusions in the paper, the good news is that method was able to learn “goal maximizing” instead of “likelihood maximizing” behaviors. This is neat, though given the constrained context (we know that the parties are negotiating) it’s less than miraculous.

The resulting bots aren’t completely satisfactory, though. For one thing these machine intelligences are, well, pretty mechanical. Specifically, they are obsessive and aggressive, “negotiating harder” than other bots.  Also, the conversation generated by the bots  made sense at the sentence level, but consecutive sentences did not necessarily make sense. (The examples sound rather “Presidential” to me.)

But the headline finding was that the silicon-based entities picked up some evil, deceptive tactics from their carbon-based role models. Sigh. It’s not necessarily “lying” (despite Wired magazine [1]), but, in line with “negotiating harder”, the bots learned questionable tactics that probably are really used by the humans exemplars.   (Again, this rhetoric certainly sounds Presidential to me.)

The hazards of trying to model human behavior–you might succeed too well!

I’m not surprised that this turned out to be a difficult task.

People have been trying to make bots to negotiate since the dawn of computing. The fact that we are not up to our eyeballs in NegotiBots™ suggests that this ain’t easy to do. And the versions we have seen in online markets are, well, peculiar.

One question raised by this study is, what is a good dataset to learn from? This study used a reasonably sized sample, but it was a convenience sample: people* recruited from Amazon Mechanical Turk. Easy to get, but are they representative? And what is the target population that you’d like to emulate?

(* We assume they were all people, but how would you know?)

I don’t really know.

But at least some of the results (e.g., learning aggressive and borderline dishonest tactics) may reflect the natural behavior of Mechanical Turk workers more than normal humans. This is a critical question if this technology is ever to be deployed. It will be necessary to make sure that it is learning culturally correct behavior for the cultures that it is to be deployed in.

I will add a personal note. I really don’t want to have to ‘negotiate’ with bots (or humans), thank you very much. The deployment of fixed prices was a great advance in retail marketing [2], and it is a mistake to go backwards from this approach.


  1. Liat Clark, Facebook teaches bots how to negotiate. They learn to lie instead. Wired.com.June 16 2017, http://www.wired.co.uk/article/facebook-teaches-bots-how-to-negotiate-and-lie
  2. Steven Johnson, Wonderland: How Play Made the Modern World, New York, Riverhead Books, 2016.
  3. Mike Lewis, Denis Yarats, Yann N Dauphin, Devi Parikh, and Dhruv Batra, Deal or No Deal? End-to-End Learning for Negotiation Dialogues. eorint, 2017. https://arxiv.org/abs/1706.05125v1

 

Animastage: Tangible Interactive Display

From MIT Media Lab Tangible Media folks, an odd little interactive display: Animastage [2].

The idea is “Hands-on Animated Craft on Pin-based Shape Displays”, i.e., a system that lets you create animated 3D puppet like scenes that move.

The underlying technology is from earlier TML projects [1], which were inspired by player pianos and other pre-digital technologies. This particular system is heavily influenced by puppetry

The creator makes scenes and puppets, and places them on the pin surface. The vertical movement of the pins pushes the figure like a puppet. Programming the actuators animates the scene.

The neatest effect is the “Invisible String Control”, in which the animator wiggles his or her fingers and the animation responds as if they were connected by a string. This effect uses hand tracking via a Leap Motion camera, which is mapped to the actuators.

This effect is far, far more interesting for a viewer than the other more complicated animations.

I was immediately struck by the fact that this effect mainly works—and draws our attention—because the viewer fills in the story from imagination.

The finger motions aren’t necessarily related to the animation in an obvious way (which is also true of marionettes), and we can’t really tell if the hand movements are leading or following the animation. But what we clearly see is the hands controlling the puppets.

This is a general principle of visual interaction: humans unconsciously construct stories and fill in ambiguity form their own imagination. In this case, the design makes good use of this principle, creating a very compelling and entertaining illusion from the simplest parts.


  1. Hiroshi Ishii, Daniel Leithinger, Sean Follmer, Amit Zoran, Philipp Schoessler, and Jared Counts, TRANSFORM: Embodiment of “Radical Atoms” at Milano Design Week, in Proceedings of the 33rd Annual ACM Conference Extended Abstracts on Human Factors in Computing Systems. 2015, ACM: Seoul, Republic of Korea. p. 687-694.
  2. Ken Nakagaki, Udayan Umapathi, Daniel Leithinger, and Hiroshi Ishii, AnimaStage: Hands-on Animated Craft on Pin-based Shape Displays, in Deisgn of Interactive Displays (DIS). 2017: Edinburgh, . https://tangible-fmp.mit.edu/publishedmedia/Papers/636-OTEyO/Published/PDF

CuddleBits: Much More Than Meets The Eye

Paul Bucci and colleagues from University of British Colombia report this month on Cuddlebots, “simple 1-DOF robots” that “can express affect” [1] As Evan Ackerman says, “build your own tribble!” (Why hasn’t there been a zillion Tribble analogs on the market???)

This caught my eye just because they are cute. Then I looked at the paper presented this month at CHI. Whoa! There’s a lot of interesting stuff here.[1]

First of all, this is a minimalist, “how low can we go” challenge. Many social robots have focused on adding many, many degrees of freedom, for example, to simulate human facial expressions as faithfully as possible. This project goes the other way, trying to create social bonds with only one DOF.

“This seems plausible: humans have a powerful ability to anthropomorphize, easily constructing narratives and ascribing complex emotions to non-human entities.” (p. 3681)

In this case, the robot has programmable “breathing” motions (highly salient in emotional relationships among humans and other species). The challenge is, of course, that emotion is a multidimensional phenomenon, so how can different emotions be expressed with just breathing? And, assuming they can be created, will these patterns be “read” correctly by a human?

This is a great piece of work. They developed theoretical understanding of “relationships between robot behaviour control parameters, and robot-expressed emotion”, which makes possible a DIY “kit” for creating the robots – a theory of Tribbleology, and a factory for fabbing Tribbles!

I mark their grade card with the comment, “Shows mastery of subject”.

As already noted, the design is “naturalistic”, but not patterned after any specific animal. That said, the results are, of course, Tribbleoids, a fictional life form (with notorious psychological attraction).

The paper discusses their design methods and design patterns. They make it all sound so simple, “We iterated on mechanical form until satisfied with the prototypes’ tactility and expressive possibilities of movement.” This statement understates the immense skill of the designers to be able to quickly “iterate” these physical designs.

The team fiddled with design tools that were not originally intended for programming robots. The goal was to be able to generate patterns of “breathing”, basically sine waves, that could drive the robots. This isn’t the kind of motion needed for most robots, but it is what haptics and vocal mapping tools do.

Several studies were done to investigate the expressiveness of the robots, and how people perceived them. The results are complicated, and did not yield any completely clear cut design principles. This isn’t terribly surprising, considering the limited repertoire of the robots. Clearly, the ability to iterate is the key to creating satisfying robots. I don’t think there is going to be a general theory of emotion.

I have to say that the authors are extremely hung up on trying to represent human emotions in these simple robots. I guess that might be useful, but I’m not interested in that per se. I just want to create attractive robots that people like.

One of the interesting things to think about is the psychological process that assigns emotion to these inanimate objects at all. As they say, humans anthropomorphize, and create their own implicit story. It’s no wonder that limited and ambiguous behavior of the robots isn’t clearly read by the humans: they each have their own imaginary story, and there are lots of other factors.

For example, they noted that variables other than the mechanics and motion While people recognized the same general emotions, “we were much more inclined to baby a small FlexiBit over the larger one.” That is, the size of the robot elicited different behaviors from the humans, even with the same design and behavior from the robot.

The researchers are tempted to add more DOF, or perhaps “layer” several 1-DOF systems. This might be an interesting experiment to do, and it might lead to some kind of additive “behavior blocks”. Who knows

Also, if you are adding one more “DOF”, I would suggest adding simple vocalizations, purring and squealing. This is not an original, this is what was done in “The Trouble With Tribbles” (1967) [2].


  1. Paul Bucci, Xi Laura Cang, Anasazi Valair, David Marino, Lucia Tseng, Merel Jung, Jussi Rantala, Oliver S. Schneider, and Karon E. MacLean, Sketching CuddleBits: Coupled Prototyping of Body and Behaviour for an Affective Robot Pet, in Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems. 2017, ACM: Denver, Colorado, USA. p. 3681-3692.
  2. Joseph Pevney, The Trouble With Tribbles, in Star Trek. 1967.

 

Robot Wednesday