Archive for the ‘User Experience’ Category
5 Observations on IoT and Physical Web
Scott Jensen introduced The Physical Web project in October 2014. It was a result of Scott’s thinking on this subject even before he joined Google (in his own words – his thinking boiled down to 10 minutes in this TEDx video). The “launch” was covered by several blogs and being categorized as an IoT standard! It is a neat idea. I can see why Google would want to promote it whose business model is based on searching, indexing the entire web. This discussion has strong similarities to the subject of Native vs. Web Apps (for a great summary – read John Gruber’s post – summarized nicely here.). URL for Everything on the same topic (using URLs for Things/IoT) by Duncan Cragg recently led to a Twitter conversation, and it triggered my observations on this subject.
Let’s dig deeper.
#1. It is about Category of Devices, not individual things
The motivation for Physical Web is “interaction on demand” and given the number of connected devices – “each new device will require its own application just isn’t realistic”. The following reproduced from the Physical Web’s webpage:
The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device – a vending machine, a poster, a toy, a bus stop, a rental car – and not have to download an app first. Everything should be just a tap away.
(BTW Wasn’t the QR Code – incidentally at a point of time – the answer to this? It wasn’t for Smart Devices but rather for small businesses – the concept was similar being able to go the right web page and find out more, get more information. How well did that work?)
In the examples above – barring the example of a toy – rest of them are to be encountered outside of your own home network. Bear in mind the notion that each device needs an application is absurd. The right comparison is not individual devices – an application will serve a category of devices. So while there would be trillions of devices connected – at any given point of time a consumer would be interested in interacting with a “category” – not all the bus stops but bus stops in a given city. Bus stops are a great idea to be connected.
#2. App-less Interaction Complicates the UX
Let’s think through the process continuing with the bus stop as an example. First you need to have a Bluetooth Beacon, that is advertising the URL. My SmartPhone needs to support BLE (which soon all of Smartphones will), and in a mode to listen to the Beacon. The Beacon would notify me when I am around the bus stop or physically launch into discovery mode (and hopefully it does not get drowned in the many other notifications fighting for my attention). Now I can navigate to the web page and discover information about bus arrivals. And next time I am at the bus stop – the theory goes I will bookmark the web page. Now think about the UX as you keep interacting and bookmarking this pages! Solving the app problem with URLs/Web Pages gives birth to another discovery problem (going by the same argument if you have many devices you want to interact with – you will end up having many bookmarks).
#3. Connecting and Discovering is just the start, the real challenge is in the System
Let’s look at the same example from another perspective – that of the Transport authority responsible for the Bus Stop. As I always say – Connectivity is a small step in unlocking value. The transport authority now has to integrate its scheduling/logistics backend into the Bus Stop so that the arrival time can be communicated. And the buses need to be equipped with real time tracking and two way communication (Fleet Management) to provide status on where they are, and what time they will arrive. If the Transport Authority is going to implement this system – it will be foolish for them to make discovery and interaction ad-hoc….
The City Mayor along with the Transport Authority would be touting the Connected Travel experience. At the very least they probably be using strategic real estate on that bus stop to advertise how to use their app – the citizen would not need discovery! Not to mention a native apps with QR Codes to download would be mentioned prominently – an app would be drop in the bucket if not in the ocean compared to the challenge of making the entire system work together.
#4. Separate the Data from the UI
Serving “web pages” implies some notion of the User Interface is embedded in the device – and that makes the support after launch harder. Any bugs or potential challenges with the UI will have to addressed. [Duncan’s URL for Everything is one step better in this respect]
#5. Use Cases should drive the approach
The Physical Web project cites another example of paying at the Vending Machine or renting a car:
How does this change things?
Once any smart device can have a web address, the entire overhead of an app seems a bit backward. The Physical Web approach unlocks tiny use cases that would never be practical:
- A bus stop tells you the next bus arrival
- Parking meters and vending machines all work the same way, letting you pay quickly and easily
- Any store, no matter how small, can offer an online experience when you walk in
- A ZipCar broadcasts a signup page, allowing you to immediately drive away
I don’t think so. Why would I want to pay through a complicated process of web pages or even find out that I can pay through URLs? A Vending Machine company is more likely to invest in supporting Apple Pay or Google Wallet, and it will make sure that each of its machine when it supports those payments is advertized loud and clear.
For a store to advertise it’s online presence – does it really need to be connected? If the business owner is digitally savvy – she probably has a website already, or a Facebook page or a Twitter handle.
Final Thoughts:
I am not against the premise of the Physical Web “standard” (to leverage Beacons, URLs and Web Apps for interaction in IoT). The argument in favor of using Physical Web starts losing value once viewed in the context of the system or the entire IoT solution. I am reminded of relentless drive by Steve Jobs on Simplicity – simplicity also means avoid complicated steps.
User Interfaces & Interactions
Swype: Re-Inventing the Keyboard
A good read, a mix of the personal and how @Swype was created.
In the 1990s, Kushler invented a cell phone technology called T9, which helped launch the text messaging phenomenon. And before that, he developed a once dominant language input gizmo for the disabled.
Now Kushler, 58, is rethinking the keyboard again with Swype.
In the 1990s, Kushler invented a cell phone technology called T9, which helped launch the text messaging phenomenon. And before that, he developed a once dominant language input gizmo for the disabled.
Now Kushler, 58, is rethinking the keyboard again with Swype.
With phones’ small screens, typing can be a chore. Even the most adept BlackBerry typists can’t compete with Swype’s efficiency.
Kushler resembles a sage, with white hair, a more-salt-than-pepper beard and a warm smile. He speaks slowly and carefully.
Apple, too, took an early interest in Swype. The companies have had at least two meetings, one as recently as a few months ago, McSherry said.
“Swype is maybe 97% accurate,” Kushler said. “Getting that last little bit of accuracy improvement is going to depend on more intelligence about narrowing down — well, what are the words that make sense in the context?”
How Prototyping and-or Beta Improves Success
I left my last post on the note of importance of prototyping. I would argue “prototyping” was always important but thanks technology advances such as Cloud Computing & Web 2.0 have made it accessible. The Lean Startup Movement promotes the idea of betas and early prototypes.
1. Software, especially Web-based, is easy to prototype, and no-brainer to implement as a part of company or product evolution. Aza Raskin, creative lead for Firefox, posted an excellent slide deck on the advantages of prototyping.
2. Consumers have embraced the concept of Beta, products introduced with minimal but most important features: Google has made the concept of a product in “Beta” very popular and acceptable.
3. Investors, Bloggers have endorsed the idea of “prototyping” – finding customers early on, as an example, Vivek Wadhwa recently wrote about “looking before you leap” and talked about a startup that has been experimenting & prototyping for 14 months.
5+1 Reasons: Why Nokia N900 is not up to the mark
Nokia, once an industry leader in smartphones, is lagging behind the competition. They seem to be one of those companies who have not been able to get their arms around good user experience and software. With the N900 powered by the Maemo 5 OS they attempted to break the stranglehold, here are the reasons why it is a failure:
1. Screen orientation is limited to landscape except when in phone mode – the N900 retails for $549 at the US Site – for that they could have done a better job making use of the onboard accelerometer
2. Touch Screen Navigation is challenging. Scrolling with fingers on the menu/program screen leads to launching of apps inadvertently – this happened to me enough where I have to keep the stylus in my hand while trying to hold the phone with both hands. Of course – NO multi-touch interactivity!
3. Application Discovery is a pain for the average consumer. The application manager will search catalogs (or repositories) and the catalogs are provided by multiple parties. You have to set this up and that implies first finding out about them!
4. My search on the default application catalogs failed to produce popular applications for Twitter, FourSquare, Pandora and so on.
5. Future of App Ecosystem is murky. Nokia is merging Maemo with Intel’s Moblin effort into something known as MeeGo.
And the bonus reason – the device does not seem to be stable. Three months into it – it simply stopped powering on! I had to send it in (fortunately it was in warranty period!). I got it back yesterday – the reason cited, and I quote from the later that was sent to me:
All Things CC: 