61–70 of 93 posts
Yeah, right. At some point on that curve the UI would grow arms and make me my favorite breakfast every morning. Objects in the world are innately limited by the causes they have in their origin. An pear tree can only ever produce pears unless what are encoded in its seed are changed.
True, you do need to worry about the engineering and stats and this might be close to solved for some trivial problems.
Yes you also need to worry about the interactions between AI and "normal" people and this is nowhere near solved even for trivial problems but its been slowly improving for decades.
The biggest problem is debugging interactions between AI and "AB-normal" people. How should the AI react when rubbed up against a OCD person, or a psychopath, or a developmentally disabled enduser?
This I believe to be the fundamental failure mode for AI in enduser products, probably enforced by the greedy legal system. If you ignore the most vulnerable members of the population you knowingly released a product that kills them, thats not going to turn out well. Or you can hyperoptimize it such that your lawnmower is better at dealing with psychopaths than the smartest human, in which case its hyperregulated by the medical system up to unaffordable cost.
Earlier quoted context omitted.
That could happen, but really that would be a "bug", not an inherent problem with the design. That would be the developer's job to fix.
I disagree that this would be a bug. It's a design flaw that cannot be corrected by fixing bugs. It's analogous to security flaws. If there is a flaw in the design, no amount of bug fixing will make the system secure, unless that 'bug fixing' changes the design.
The way I look at it is, yes the software should keep a history of user behaviour and base its actions off that, but there must be feedback involved, either explicit or implicit. This way, if I gave some input to the system once but then never did so again, the likelyhood that one event should affect the future would diminish over time.
There could be trickiness around "Bubbles" (like a Search bubble, where it only recommends to you things it thinks you'd like, and never shows you other things). I think those are problematic and should be dealt with. But I don't think that means it's impossible to fix. It's just something that needs to be thought through. I don't have an answer for it right now but that doesn't mean there isn't an answer.
Earlier quoted context omitted.
I disagree that this would be a bug. It's a design flaw that cannot be corrected by fixing bugs. It's analogous to security flaws. If there is a flaw in the design, no amount of bug fixing will make the system secure, unless that 'bug fixing' changes the design.
Can you explain why you think it's an inherent flaw in the design? The way I look at it is, yes the software should keep a history of user behaviour and base its actions off that, but there must be feedback involved, either explicit or implicit. This way, if I gave some input to the system once but then never did so again, the likelyhood that one event should affect the future would diminish over time. There could be…
Your statement is what I mean. "Thinking things through" should be done during design. Once you have built system, its much harder to compensate for design flaws.
Programming is not designing. Designing is not programming. Fixing bugs is not designing.
You have to design into the UI system a means for it to compensate for changes in user behavior. You don't want a system that takes many uses to train. At the same time you don't want a system that is trained by a single use. For me this is the crux of the problem.
The happy medium that automatically detects deviations from a user's 'normal' behavior _and_ takes the correct action is very hard to design, as it involves AI fuzzy logic.
Earlier quoted context omitted.
Can you explain why you think it's an inherent flaw in the design? The way I look at it is, yes the software should keep a history of user behaviour and base its actions off that, but there must be feedback involved, either explicit or implicit. This way, if I gave some input to the system once but then never did so again, the likelyhood that one event should affect the future would diminish over time. There could be…
> It's just something that needs to be thought through. Your statement is what I mean. "Thinking things through" should be done during design. Once you have built system, its much harder to compensate for design flaws. Programming is not designing. Designing is not programming. Fixing bugs is not designing. You have to design into the UI system a means for it to compensate for changes in user behavior. You don't want…
I agree with this fully. This is something that would need to be solved before building such a system.
A great example of a system which learns from history, but which also supports changes in behaviour is: http://worrydream.com/MagicInk/#engineering_inference_from_h...
The linked example is specific to one application, but he continues to detail what he thinks would make for a general solution.
The best interface is hiding all the steps of a complex process and saying you did away with the interface. No steps = easy to debug when it goes wrong. You just point at it and loudly whine: "It's not working!" then nobody fixes it because all the back end is "magic".
One things that came to mind when reading your comment was some of my frustration using OS X. When an app in OS X or OS X itself stops working you don't get a blue screen or a "this application has crashed" error - it just stops working. Many of my friends would have the false illusion that OS X is much more stable than Windows 7 because they see less error messages.
Details are available in logfiles; anyone who has a use for those details most likely knows where to find them. The end user can't do anything with memory addresses, etc. so it makes sense that they don't seem them.
You do not need to unlock your phone or navigate to the Wallet app, and you don't need to select the credit card to use at payment time. Also worth noting is that tap-and-pay works even without a data connection.
The real lessons to learn from this are: people are paranoid about paying for things ("how will my phone know to make a payment if I'm not in the app?"), and people don't read documentation (the first few times you use Wallet, it's explained exactly how you make a payment).
One last thing to think about: creepiness. As a society, we have the technology to predict exactly what you are going to buy and when, and we can use cameras to recognize your face. So if you usually buy a latte every morning, the coffee shop could just make it in advance, and you could walk into the store and pick it up. The security tape would see your face picking up your coffee, and automatically deduct the money from your account. But I'm guessing that the HN crowd, despite their desire for convenience and technology, would hate that for privacy concerns. Do you really want your coffee shop tracking your every move? Who will they share that information with?
(Why is the complete lack of an interface creepy? Because nothing else we do is completely lacking in interface; usually you do something to get a result -- doing nothing to get the same result is weird.)
The Google Wallet flow they describe is not correct. All you need to do is have the screen on (not unlocked) and hold the phone near the NFC reader. If you're not recently-authenticated, you need to type your PIN. That's it. You do not need to unlock your phone or navigate to the Wallet app, and you don't need to select the credit card to use at payment time. Also worth noting is that tap-and-pay works even without a…
I have two criticisms of the article: 1. Every story is a 'just so' story where the way the system works is exactly the way the user wants the system to work. Great, it's like putting a button front and center on your app and the user wants to push that button and look! It's right there! Awesome. Except I don't want to push that button, I want to push the other button that's now hidden away because the designer is st…
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.
While having no interface is a nice idea, I think that there's also something to be said for "Make common things easy, rare things possible." That is, it's great to try to eliminate the need for an interface, but you can't assume or even expect that you'll always succeed, so you have to have an interface anyway. Also, a lot of famous security vulnerabilities like the fact that Windows will execute things on a memory…
Yeah, if the proposed payment flow was ever implemented there would be abuses, there's a limit to how much interaction you can hide away. Especially in payments at the /very least/ there has to be some form of approval and usually there needs to be a payment method selection. No interface is nice but some things have to have interaction you can't magic away.
