Futures of text | Hacker News Reader

Futures of text

whoo.ps

69 pointswebmasterraj21 comments

This is beautiful and I want it (hell, that's the reason I'm writing my own personal assistant at the moment), but if deployed as an OS-level product, what we'll get will be an abomination.

You see, such full-integration service, to be as great as described here, would require cooperation of all the third parties in creating the best experience for user. And here already are two things that will not happen. First of all, cooperation involves moderation, and I doubt all (if most) companies will suddenly refrain from trying to take the interlinking pie for themselves. You'll see multiple services competing for the same actions, or trying to capture ever single possible interaction, no matter how irrelevant. And secondly, you'd have to have app developers actually care about user's experience, and not about monetizing them. They don't care now, so I don't see how they're going to suddenly start.

Again - the ideas presented in this post are awesome and I'd love to see them, but I don't have my hopes high. I see this as yet another dream that will be doomed by tragedy of commons. Game theory is a harsh mistress.

EDIT:

The article itself sort of hints towards that in the very introduction:

"but when I got to texting Bus Time I thought, “Thank god I don’t need to download another f------ app for this.”"

Well, exactly. It should all be already unified. But it isn't, because everyone thinks they're special and so important that the user needs their app.

Voice URLs would solve this problem. If we can adopt a semantic, human-readable linear standard for voice actions, then the user can choose which app to take action on the URL/command -- just like we do now on Android with http(s)/ftp/ssh protocol and URLs that match root app domains (i.e. choosing which app we want to open a twitter.com link).

I'm the author and I partly agree with you about yet another tragedy of the commons, though it has worked fairly well for share extensions. I have a few apps that are registered to handle photos when I bring up the share sheet that I'll never use in that context, so I moved them to the end of that line of extensions and also removed a bunch from appearing there. It works fairly well.

This app featured as an example of "friendliness" of chat-based interaction looks to me more like a "Clippy"-like communication

http://i2.cdn.turner.com/money/galleries/2009/technology/091...

than something I'd like to use every day.

A major problem with text based app interaction is learning the language and predictability.

If I've never seen "let's talk it out" as a feature, then I could innocently type this and see this weird thing that's using my data.

Add to this the NLP component, and suddenly there's a whole corpus of things I could say that accidentally trigger some action. Learning this corpus would be akin to learning a language, but without formal instructions (I still don't really know what Siri's full command set is).

I like a lot of the ideas (3rd party tool tip integration, ideas to improve the bus app, and Foursquare direct call outs) but I think a lot of this would be better in app form. The real issue is installing/uninstalling and unclear permissions models - a Wechat style lightweight app install system could alleviate a lot of that concern.

After all, why do I want an uber notification in Messenger, when I need to have the uber app to order the cab in the first place (that kind of tracking complexity and reliability requirements probably shouldn't just be a web view inside Messenger).

with all these fancy 80/20 implementations there's still an inevitable tacit knowledge aquisition phase where you stop giving it what it tells you it wants and start giving it what you know works for getting the information that you want.

it is for this reason that consistency of, and thorough/feature rich design are all that's needed.

treat it like an API. You can add in the fluff later but stop trying to fluff over the rough bits. Fix the rough bits, and you might find you don't even need the fluff.

I see this attitude among the elitist CS majors who can talk to you about how great the CLR is but are completely divorced from reality evidenced by their use of per-byte event-driven serialization routines instead of, you know, just copying the whole buffer contents at once to their processing buffer. The attitude then manifests as 'well it's only a few thousand bytes a second during communications'.

So I guess I need to come up with a way to market my no-nonsense design principles.

I find the idea of a minimal UI with intelligent agents working behind the curtain very intriguing. I also like the idea pf SMS as a channel input device for using such apps.

The line of thinking seems to be: Africa and Asia leapfrogged the desktop / laptop generation of computing and directly went for mobile. The younger generation in the Western world essentially is mobile-first. Apart from work (and even that might change for many job descriptions in the future) even most people in traditionally first-world countries don't even use desktop computers anymore. Hence, what we see in Africa and Asia right now essentially also is the future for Western countries.

In general, I think this is spot on. However, I also think many people get overly excited by the promises and possibilities of messaging apps. SMS-based apps in particular often are makeshift solutions for when there's no reliable Internet connectivity all the time but somewhat reliable cellular coverage.

The bus information example is a particularly good example of this. Sure, it's useful but many of the improvements mentioned in the article like linking to a specific resource for a specific bus line for easier future use can already be implemented today in websites. There's no reason why I couldn't use a mobile browser instead of a message app for accessing this kind of information. The problem is that most websites - public transport websites being a particularly notorious example - often are terrible from a UX point of view: User interfaces are needlessly complex and often barely usable at all.

Perhaps, the takeaway from this article also is that when designing websites and web-based UX we can learn a lot from the simpler interactions on mobile devices. Good design is all about embracing constraints. Perhaps applying those constraints from mobile messaging to designing websites is a good idea, too.

I don't know how it is on other networks, but SMS as a real-time communications channel is useless on Sprint. About 10% of all of my SMS take 15+ minutes to deliver.

To friends or business related texts? The short code system is a different system from the P2P. So any business should have better or different latency and deliverability than what you're describing.

Out of curiosity, why are you still with your carrier if they are performing that poorly?

This is to friends.

I am looking at switching, contract is up this fall. My wife uses a 32GB iPhone, so switching will be expensive hardware-wise for her ($150/$550 depending on contract/no-contract for 5s).

[edit]

Also, I have no reason to believe that the overall experience will be better with any of the other carriers. At this point I'm shopping completely on price as I have no reliable data that one carrier is better than another in my area.

A lot of people who read this post a few months latched too tightly onto the idea that SMS is somehow always a better interaction model than a UI. It's not. But there's a time and place where SMS is just the right way to notify someone or communicate with someone about something: http://whoo.ps/2015/05/27/what-sms-is-good-for

I'm surprised the author left out payments. SMS is the simplest way to facilitate non-POS transactions. We've built our company on that, kindrid.com.

What is the advantage to this over building a simple website? Unless I am misunderstanding it, it sounds like the author wants us to reinvent the wheel.

Waiting for NLP to get to the point where it has < .1% errors is going to take a long time (which would be minimum to get people to trust it). Instead a user friendly version of command line makes much more sense. User friendly like my mom could use it, not me.

Obviously that's easier said than done, but at least feasible, compared to a pure NLP solution.

consistent and thought-out, feature-rich design is all we really need to make interacting with the phone efficient.

none of the business heads understand how to get it right so they shoot for pie in the skie [hm, that was an interesting spelling mistake to make] alternatives because they prematurely dismissed what a master of design can accomplish because they balk at the salary.

Exactly. Command line is too far, so is pure sentiment-based NLP. In the middle I propose Voice URLs, a standard for linear voice actions -- rather than the JSON format that the current NLP services are using now. I'm right in the middle of the formal writeup but wanted to mention this to like-minded designers.

I'm curious to read more on this topic. Where will your writeup appear?

I will definitely post on HN, but you can also follow my username on Github. I will post to the community so that it will be a collaborative effort. Please feel free to contact me directly if this effort speaks to you.

This makes me think of Weebly's new SMS-based support chat feature, SimpleChat (http://simple.chat). SMS is a nice medium for support chat, instead of having to deal with another chat application. Really neat idea!

Why there is no Telegram with its API for intelligent chat bots in the reading list in this otherwise nice article?

Telegram bots came out after I wrote it

Reply on news.ycombinator.com