

Futures of text - webmasterraj
http://whoo.ps/2015/02/23/futures-of-text

======
TeMPOraL
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.

~~~
libovness
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.

------
acqq
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...](http://i2.cdn.turner.com/money/galleries/2009/technology/0910/gallery.microsoft_windows_gaffes/images/clippy.jpg)

than something I'd like to use every day.

------
obblekk
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).

~~~
rancur
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.

------
BjoernKW
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.

~~~
aidenn0
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.

~~~
mikesabat
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?

~~~
aidenn0
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.

------
lcusack
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.

------
ihuman
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.

------
webmasterraj
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.

~~~
rancur
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.

~~~
doublerebel
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.

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

~~~
doublerebel
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.

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

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

~~~
libovness
Telegram bots came out after I wrote it

