Did any of you see this tweet from Scott Jehl last May? It got quite a bit of traction for something near and dear to this conference: test your site speed
I only have a modest little WP site but I try…. My theme is responsive, I’ve created a child theme to simplify the layout to make it clean and simple. I’m doing so little right? My speed index should be….. 5100????? I was devastated. How could I ever have coffee with Steve Souders again?
So rolled up my sleeves, brought to Chrome Dev Tools and found out that WP is kind of stupid when it comes to thumbnail images. So I rolled up my sleeves, fixed a few things, made my pages static (I don’t blog often) and…
I was able to get my speed index down to 2354!!! I was pretty excited. If a UX designer can do this, I think most folks could.
But even though page render is a CRITICAL issue, is it the only one facing us as a community? What does SPEED actually mean? Those of you that have been around for awhile know that UX designers used to be called UI designers. We switched because we didn’t want to focus just on the Interface but the entire Xperience. What is the speed not of the page, the interface, but the entire experience? For example, how do someone GET to my page?
Most likely they got it from a search, or possible a social site linking to it
And that page was linked from another page. And it keeps going: ITS TURTLES ALL THE WAY DOWN. We’re living in a virtual world of pages and as long as we never leave, JUST worrying about page speed is fine. If everyone does their part, we’ll b fine
But where ARE people when they load web pages?
Its easy to answer this as a desktop vs mobile but that’s the device question, I’m curious as to WHERE?
Are they home? At a retail store? Can the store itself become a link? really, WHERE are they when they are getting to your site? We usually don’t even imagine what a website could be if it could be invoked from a physical location
It’s slowly dawning on all of us that the web isn’t just a virtual world. We’re not sitting in the dark flitting from one network node to the next. We all exist the the real, physical world. And the web web could have huge potential here. There have even been some misguided attempts to bring the web into our world. And people seem understand, at some level, the potential value, but they just can’t get past the ham fisted nature of these attempts
Have you all seen this tumbler? It’s been around for 3 years and as you can see,
it’s pretty active
But all can feel the value the web could bring to physical objects. But it’s not possible. We all see this with new smart devices, the can’t use the web, each and every one of them has their own native app. Some on on one platform, some on another, but rarely both for the simple reason that the costs are two high to port it.
But how does this scale. We can come now but if we believe in Moore’s Law at all, it will be 3 this year 9 the next and 30 the following year.
There are many things that native apps are great at, but keeping up the the exponential explosion of smart hardware isn’t one of them.
The super power of the web is that anything is just a tap, a click, a selection away. It’s interaction on demand. This seems like a pretty useful thing to have for smart devices. Why can’t the web be of use here?
The web, and it’s standards bodies, usually focuses on the DOM, the white rectangle where all of the content goes. This rectangle is indeed amazing, and getting better all the time.
But what about that address bar at the top? Has it really changed all that much in the last 25 years? We’ve done a bit with auto complete but we are still asking users to type to go anywhere. What’s wrong with this picture? We have taken the most amazing rendering engine on the planet and strapped a damn command line UI on top of it! Every other mobile app today is taking advantage of the sensors in mobile phones, why can’t the browser do that as well?
Why can’t we have something like this? Here is an example of how this could work
The solution is “The Physical Web” a way to bridge physical devices and the web. At it’s core, its a simple means for devices, like a zip car, to broadcast a URL so any web enabled device can detect that URL and use it. Everything gains a web page. This unlocks the super power of the web and makes instant interaction possible. You completely remove the need to manage apps and most importantly, it’s so simple and light weight that it encourages new riskers products that wouldn’t have been considered before.
The flow is from the device to the phone to the cloud. It’s just the web, we’re trying to get users there as quickly as possible. But I get the same two questions every time: What’s the difference from a QRCode and what about SPAM?
In a sense we’re trying to create two clouds of things. The first is a cloud of standard devices that broadcast urls the exact way. We’ve started talking to the W3C about standardizing this packet so everything broadcasts URLs in exactly the same way.
However, the devices that listen can be broad and varied, just like browsers are today. They can try different ways of ranking, compete on that difference even. There can be wild variability there, as longs as all of the devices are broadcasting the same way.
But let’s be clear: the Physical Web is JUST getting the URL to the phone, all of the hard work is done in the cloud and using web sockets to talk to the device.
Now it’s true that this scenario requires connectivity through the cloud. This leads to my next question: isn’t that too complex/expensive? What most people don’t appreciate is the plummeting size/cost of GSM modems. This allows devices to arrive fully configured and on a private network, with no configuration by the user.
In a world where each device has it’s own connectively, the Physical Web makes it easy to discover each other and connect.
But by being built on the web, we just get better as the web gets better. Here is an example using ServiceWorker
our time horizon for innovation has become weeks not decades, we forget that the delta between netscape and Gmail was 10 years. It takes time for systems to build and mature.
The Physical Web started off, like many Chrome projects as and open source experiment. We’ve been amazed by the response, we are one of the top github repos at Google.
We’re very happy that both Opera and FirefoxOS are showing interest.
BTW, we are in Chrome for iOS right now! If you turn on the Chrome TodayView widget, you can be using the Physical Web right now. We hope to be shipping on Android in the near future.
We started off wanting to use the Physical Web for controlling complex devices but realized that smaller use cases were more interesting. This gets ever more interesting for personal uses: broadcasting your slides, finding your dog, or having more information in a “For Sale” sign.
But just as the web got better and better tools to express yourself (HTML pages to Blogger to Twitter) We expect the same things to happen with the Physical Web
Native apps are great, they’ll always have a role. Much like the “long tail” of the web, we see the same thing applying to devices. Each of these uses cases are moderately useful but taken together, they imply a long tail of interaction, where any user can walk up to any device and interact with it. This opens up a huge new interactive ability that products can use.
The Physical Web is a Speed Issue - Velocity 2015
The Physical Web is a speed issu
Velocity - October 2015