>2. Using AI is a "step 2: ???" solution, and the flaw with it is best exemplified by the columnist who bought a pregnancy book for a pregnant friend on Amazon

Flaws like this might exist right now, but that's really a "bug". It's a failure on our part (the software designers and engineers) to build a system that actually works for the human. So sometimes when we try to make our software smart, it ends up being [maddeningly] stupid. But again, this is only because we don't do our jobs right, not that they can't be done right.

So with a little more smarts from us, we could make a system that's a lot more flexible and allow for these sorts of things. We have to acknowledge that a user shouldn't have to fit our system exactly and we should allow for "Buying a friend some baby clothes but not have it think we have a child" cases by being smarter about how the system learns. We need to provide it with better context.

Doesn't "provide better context" just push the problem one turtle away? How could I communicate to the website that the item for which I'm shopping is for a friend, not for me, and that I don't want the current actions to figure into future adaptive behaviour? Perhaps a checkbox? But now we're adding interface, which we were trying to eliminate in the first place.

I suggest that this is an intractable problem just because there's a fundamental tension between ease and flexibility. 'Optimize for the common case' always seems like a good idea (and the AI suggestion is just 'allow past history to determine the common case'), but we all have different common cases, and this heuristic helps us not all when we don't want to execute the common case, which is the hardest part of the design problem anyway.

I agree with the idea, generally, that we need to be smarter about how things work for people. I think "No UI" is like "No SQL": An appropriate solution in a certain set of cases, but nothing like a general solution for all.

>Doesn't "provide better context" just push the problem one turtle away? How could I communicate to the website that the item for which I'm shopping is for a friend, not for me, and that I don't want the current actions to figure into future adaptive behaviour?

That's part of the implementation, again, I think. It would be silly for the implementation to treat just once instance of a behaviour so seriously. If the user buys it once, but then never shows any interest in such products again, then they should slowly be ranked less and less relevant. If the user instead continued to purchase or look at baby items, then the system could have more certainty of desire in them. Again, it's not just the products themselves, but the behaviour surrounding them. Temporal context is important, too.

I agree fully that just heaping on more interface for "special cases" is a bad idea. We just need to be smarter about...how our software is smart.

The funny thing is, in Amazon's case, there are multiple ways to do that - tell the website you're buying something as a gift during checkout, or when you get bad recommendations, click 'fix this recommendation'. Of course, even though I work there * , I never remember to do the former, and usually can't be bothered to do the latter ... and I reckon the majority of people don't know that either option exists (in a couple of cases I've even had people ask me why the option didn't exist!)

It's a pretty good case study: even though the UI is there, front and center (the 'fix this' link is usually right underneath recommendations), it doesn't get used because most users would rather do 'Step 1: get good recommendations' rather than 'Step 1: get mixed-quality recommendations; Step 2: take action to improve recommendations; Step 3: get good recommendations'.

* And, of course (standard disclaimer) I don't speak for or represent Amazon in any way...

> But now we're adding interface, which we were trying to eliminate in the first place.

camtarn already explains how you make this part of the natural interface. I'm going to address the apparent confusion you have in assuming that in removing the interface, you do not need to eliminate it. For example, in the article, the discussion about approaching the car should open the door does not mean that you remove the interface of lock and key.

> An appropriate solution in a certain set of cases, but nothing like a general solution for all.

And the article isn't advocating for the removal of all UIs. It even goes on to advocate certain UIs. Don't just read the headline. Take a few minutes and consider what's being said.

>> the columnist who bought a pregnancy book for a pregnant friend on Amazo

> that's really a "bug"

This thinking worries me a lot, especially when applied to what Google is heading for.

So now many people are removing all buttons and settings, because they think that every button or setting is a failure to guess the user's need.

The epitome of this move it probably Google Now, and I fear it is going to fail or to stink. My instance of Google Now tries to guess when I will drive back home and notify me with a traffic estimate: Until now, it was successfull and mildly useful once in 20 tries. So in fact, I have been spam-notified 19 times by Google itself! And me driving home has a relatively high predictability, compared to buying books, going out, etc.

I just read Thinking Fast and Slow for the second time, and the gist of it, in this context, is that the world is much less predictable than we think it is. If the Bayesian statistical approach or even simple formulas work better than intuition or experts in so many domains (financial, political forecasting, clinical diagnostic, etc), it doesn't mean it should be used, it means these domain have very low prediction validity. For instance, the only valid and proven prediction for next year stock price is "80% chance to be between -10% and +30% of current stock price", and this is useless common sense. Just as the only correct explanation for above the average earnings this year at any company is "below-average results last year produced lower expectations , and we are regressing to the mean".

Moreover, if some few things are to be found predictable in my life, I probably would not want to be recalled of this saddening fact. Suppose you are hiking next week-end in the mountain nearby. If a Google Now thingy tells me, two hours before leaving, that I should not forget my socks, it will give me the same feeling as a caring and annoying mother: "Yes Mom, call you there; No Mom, I'll not forget to wash me hands..." Who did like this when a teenager?

So, either personal life events are not predictable, or they should not be predicted because most people would rather keep the illusion they are in control.

What technology need to do is to empower users with helpful (or funny) tools. When I am treking somewhere in nowhere land, I feel empowered to be able to pull a satellite map and GPS positioning from my phone, and I use it whether I'm a bit lost or I just want to check the road again. But I really really would hate it if the next Google map would detect from my speed that I am hesitating, and pop a "Just turn left after the next oaktree to get back to your car, you sucker".

Google's new trend is in parenting its user, I am not sure it is the correct move.

> the world is much less predictable than we think it is

I don't know anyone who thinks the world is predictable. Anyone. Your problem is scope. The world is not predictable. But small pieces are. And the world is made up of many, many small pieces. The challenge is discovering those small pieces. Not all are obvious.

And those pieces which we have discovered we can predict at a reasonable level, we ignore.

Take automatic doors at the entrance of stores. We approach the entrance, the door recognizes this, and the doors open. This is predication. We are predicting that someone approaching in a particular area will most likely want to enter the store, so we prepare by opening the door. This isn't 100%, but it's an overwhelmingly effective prediction.

> Who did like this when a teenager?

I'm not a teenager anymore though, so your reasoning doesn't follow. Your upset that if you are lost, and you want to find your way back, Google will, maybe, tell you?

Seems like your problem is personal, and frankly, a bit selfish. It's easily solved by not using the tools that you do no want to use.

Bret Victor's The Magic Ink gives some good starting points for applying context to make software smarter: http://worrydream.com/MagicInk/

Yep, I'd already linked to it twice already in this comment thread! I agree fully.

>It strongly implies there's a hallowed land where every use case is obvious and accounted for

That land might not exist, but for every problem we try to solve, we should search for that land relentlessly, as if it did actually exist. It's a not a framework, not means to an end, it's a goal, an end in itself.

1. What if I don't want my car to unlock when I approach it?

Disable it and choose to use the smart phone app. They are not mutually exclusive, and you've already used services just like this. Automatic doors that open as you approach them at a store? And when they aren't powered, you can still open them manually. Bad implementations won't open if they aren't powered.

2. it is best exemplified

If that's your best example, I feel bad. It's merely a flaw in the system, easily resolved. It's the powered door that won't open without power.

Designing these intelligent interactions is not easy. And dealing with exceptions is challenging. They are, after all, exceptions. But don't assume that designing these interactions should account for every exception. Rather, it should make normal easy and make exceptional resolvable.

I am wondering if the unix shell is the no UI approach to the first problem. The unix shell doesn't provide a discoverable, nice interface. On the other hand, it is a minimalist interface which caters the task "Manipulate files in a multitude of ways" very well.

A CLI is not graphical, but still a user interface - and a very opaque one, you can't use it at all without any prior knowledge. It's the complete opposite of the ideal interface in this context.

I've found the CLI on Cisco routers (and some other, non-Cisco routers) to be very discoverable. At any point, you can type a '?' (even on a half-typed command) and get a list of commands/options with descriptions. Okay, it's a summary, and it helps to have some context, but it's not opaque as a Unix command line.

Then there was Lotus, which (at the time it was written) driven by a text-based command line. Type '/', and the cursor would drop to the penultimate line; a list of valid commands/options would appear on the bottom line. You could either type the command/option, or use the arrow/tab keys to select it. And as you typed, the bottom line would change to always list valid options (or a description of what to type next, like "(type a number)").

Heck, even VMS had an extensive help system available at the command line (type 'help'---it was interactive). Please don't judge all CLIs by Unix and MS-DOS.

Don't judge all CLIs by Unix or MS-DOS.

But isn't that the point?

Being presented with a blue screen in WordPerfect is a minimal interface, but to do anything you have to learn how to use it. You have to learn how to get the menus up and etc.

And while good design is important, and tends to reduce interface clutter, it's also important to let users have easy access to the stuff they need.

Reducing the interface to what users need is a tricky skill, and risks angering power users. (Google dropping + to force inclusion is a notable example.)

With the Amazon example, just remember that they don't show you product suggestions for help you, they are showing them to sell more product.

If on average the technique works across the entire customer base, then they will apply it.

While it would certainly be better if they were more accurate in that fringe case as well, if it would take 4x the effort to eek out a 20% improvement, that might not be a good trade off for them.