Hacker News Reader

> I'm going to say that using phones as a standard appliance interface is potentially a huge UI improvement

I couldn't disagree more. Phones UIs tend to be pretty terrible (the good ones just rise to "not terrible"), and I certainly don't want the various devices I use to have one. That's why I will not buy devices that require it.

compared to applicance controls?

The limited hardware almost guarantees a poor experience, and of course no consistency whatsoever across appliances.

Sure, 3 buttons is ok just to set the time perhaps, but quickly becomes unusable with more complex requirements - and then you get crappy lcd screens, and custom menu systems, etc. even bad apps are usually better.

I get what you're implying, and I think it's a valid approach (connected). But so is the converse (unconnected).

The connected can be controlled by apps or heck, APIs, perhaps offers full flexibility etc. However, what guarantees the controlling app is going to keep being updated? What if there's a wi-fi vulnerability in a few years? What if there are calls to company servers that go offline? What if you phone is off and you want to quickly set the time?

The unconnected can be controlled by a physical unchanging interface. It offers few extra features, its buttons will wear and break, etc. But it probably will function just fine in 10 years time, is probably extremely easy -- and less time consuming in total to set. I disagree the experience will be poor or inconsistent -- those products usually obey a common language of household appliances that works well enough. Physical buttons are usually very responsive and easy to use. There is not much to go wrong.

The ultimate measures here are probably net productivity (time wasted on clock and setting time), cognitive load, and robustness. If you have specific timing requirements maybe the networked clock is for you, but for most people I'd say the good old digital clock is probably still easily best.

Maybe in the future the digital infrastructure will be standardized and simplified enough that more appliances will become connected, but the real value of 'iot-enabling' is still quite low for most objects.

Remember, newer or more flexible isn't necessarily better (even for very complex systems: see UNIX philosophy).

It's a clock. You only need three buttons. Heck, my watch gets away with one. If you need more buttons, add more buttons - the clock won't get new features, so just add whatever buttons you need for the features it has.

It's not "just a clock" if it has wifi. If he just wantted a 3-button dumb clock that's what he should buy.

I'm generalising to more complex appliances, but no, just adding buttons doesn't do it (quite apart from more points of failure), even for a clock - how would you set multiple alarms, say one for you, one for your partner, with different times each day of the week. do you have 2 buttons for each day, or what? Of course, in reality you end up with modes, and menus , and a crappy custom UI.

Multiply this by every gadget in the house, and a full UI remote (be it phone, tablet or specialised wireless touch-screen remote) becomes an attractive option.

> compared to applicance controls?

Well, it depends on the appliance. Some really are terrible. But on the whole, I think appliance controls tend to be more usable than smartphone interfaces.

Maybe if there were some standard protocol for a device to offer controls to nearby phones. (Perhaps HTML-based, but it would be nice to have a more semantic, scriptable layer, perhaps in addition.)

As it is, every device has its own bespoke iOS app and Android app. The apps’ user interfaces usually suck, but you could say the same about the buttons. More importantly, at least on the iOS side, apps need continual maintenance to avoid breakage on new devices or OS versions, ranging from quick updates for new screen sizes to the dreaded 32-to-64-bit transition. But that maintenance is likely to stop being provided as soon as the manufacturer is focused on their next thing, turning the device into a ticking time bomb of future unusability. With an unrepairable device, at least you only run into the problem if something breaks!

Yes this is exctly what I'd like to see, an appliance protocol of some kind. People can then write their own apps if they want. Maybe just REST endpoints -I've seen web servers of sorts crammed into avr chips, so it should be feasible with all but the most limited devices.

App rot is a problem no doubt but do apps break quicker than the crappy hardware UI? I'm not so sure. probablty on iOS that's true.

I don't remember ever having to replace an appliance due to broken buttons or screens. Phones, on the other hand...

The only kind of hardware buttons I seem to be able to regularly break are the microswitches in mice. They used to last forever, and I think I still have an optical mouse from early 2000s that has perfectly working switches (but tracking & malfunction speed aren't comparable to any modern mouse). The switches in modern mice tend to develop problems in a year or two.

Yes, they do.

I have a Casio clock on my nightstand, it must be from before 2000, if not from before 1995. The display segments are failing, but apart from that: No button broke yet, calendar is still working, so is the alarm.

REST is a poor choice. Use any popular binary RPC protocol over Bluetooth/USB and don't add unnecessary complexity.

This would be OK, but only if the devices allow you to completely disable the network-facing controls.

You mean the (approximately) three "weird" buttons to adjust date and time?

No, no and again no. The future were I need a smartphone to set my clock is not a good one for me, however you put it.

the clock could come with cheap (and replaceble) IR remote for your button fetish - no need for that on the clock itself - buttons are nearly always the first point of failure IMHO, closely followed by screens.

Also you need to learn to use whatever limited UI /menus they've managed to cram into such limiting UI hardware, rather than the whole richness and usability of an app.

Not so bad for an alarm clock perhaps - until it has multiple daily//weekly alarms with custom sounds, custom snooze schedule, custom lighting profile, etc, etc - ah but a reason it doesn't have any of this stuff is because it would be too difficult to cram into a 3-button UI.

Anyway, a limited hardware UI is also much more problematic for many other appliances. Better just to do away with it completely (saving cost, improving reliability) and use a phone or cheap tablet which are ubiquitous these dayss, or even a new market for cheap dedicated universal smart remotes.

PS downvoting me (twice!) because you don't agree wiith my point is fairly childish I think, and should be reserved for insulting , nonsensical and troll posts, etc. IMHO.

I'm confused. Are you suggesting that you know that I downvoted your comment? Twice? How should I achieve that you recon?

> BUT, if this is done correctly (eg wave nfc phone near your clock

Then, not only do you need a smartphone to operate an alarm clock, you also need it to have NFC.

"Also those screens and buttons are always the first to break, and are totally unrepairable"

How is a phone better? When your app "breaks" from code rot and you can't upgrade it, or run it on your new device, you're in the same boat.

Knowing how these devices are produced, what do you think are the chances of having one done well vs. done badly?

In theory you make a good point, but in the real world we just aren't that lucky.

Instead of NFC, one can use Bluetooth that is present in most phones.

A good future is abolishing the time switches.