It seems that our roots in wearable virtual reality are coming back into vogue. On March 10 and 11, David Frerichs will be on a panel and giving a class at the Wearables Tech Conference in Santa Clara, CA. The panel is a gathering to discuss the upcoming impact of artificial reality. The class is about using voice-controlled avatars in wearable user experience design. If you are at the show, please be sure to check them out.
Filtering by Category: Blog
If CES 2015 proved anything, it's that the smart home market is a confused mess. Before you dive into the details of any solution, its important to have a high-level overview of the various components involved. Since Media Tuners supplies brands with a cloud platform, Web service licensing, mobile app development, firmware development, product planning, and project management, we have a fairly complete perspective on what's required in a home automation solution. The diagram below gives a good starting point. smart devices: the things in the Internet of Things, including light bulbs, switches, plugs, thermostats, smoke alarms, sensors, sprinkler controllers, and other devices. To be a smart device, it has to have some local processing power and some kind of connectivity to the outside world
mobile app: running on a smartphone, this is the primary control mechanism in modern systems. Ideally, the app will speak to devices directly, but in many systems, it must speak to a hub can speak the same radio language as the devices
hub: always-on device that translates commands to devices with proprietary radio formats and/or offers connectivity to the devices from outside the home
router: WiFi & Ethernet connectivity in the home and broadband access to the Internet.
cloud platform: a cluster of servers running on the Web directing traffic between home devices and the outside, including access to 3rd party Web services, backup, provisioning, automated & contextual actions, user account management, voice control, and other services
3rd party Web services: a wide range of data services which can be used for triggering events, sharing information, user context, radio and video content, weather, recommendations, and other services
The essentials of any solution are the smart devices and some sort of control mechanism. Recently, the control device of choice has become a mobile app running on iOS or Android smartphones. This (good) choice has specific consequences for the architecture of a smart home solution. Smartphones can only communicate via WiFi, Bluetooth, Bluetooth LE, or 4G. They don't natively speak Zigbee, Z-wave, or any of the other alternative radio protocols. So, for solutions that use Zigbee, Z-wave, or the like on the devices, a hub is required to allow the phone to talk to the devices. On the other hand, if the devices speak WiFi or Bluetooth LE, the phone can communicate with them directly and no hub is required.
A hub-less system has the obvious advantages of reduced system complexity and reduced cost. If the devices adopt WiFi natively, the system ends up being very flexible, but the cost benefit is eliminated due to the relatively high per-device cost of integrating WiFi when compared to the other radio technologies. That leaves Bluetooth LE (BTLE), which has a low per device cost and is native in the phone. Up until recently, BTLE was not as attractive due to its lack of mesh capability to extend the network, a problem that has been solved by CSRmesh with other vendors likely to follow suit soon.
A hub is also required if the system wishes to allow users to access the system from the outside world or allow Web services to interact with the system in realtime. In both of these cases, the system requires a cloud platform that the hub can connect to. This cloud platform can offer services as simple as firmware updates or as complex as off-board voice control and predictive modeling to automate home behaviors. As the cloud platform gets more complex, it typically will leverage 3rd party Web services to provide a more complete user experience.
Each component has hardware, software, and interface or protocols associated with it. So, for example, to create a smart light bulb that can be controlled both inside and outside the home and by automated Internet events, you need a hardware platform for the bulb, firmware to run on the bulb, a command protocol to run over the radio network to the bulb, mobile app software to run on the user's phone, a hardware platform for the hub, host application software to run on the hub, a RESTful or TCP socket interface to control the hub, a cloud platform hosting provider like Amazon, cloud platform software or software as a service, a RESTful or Websocket API to control the cloud platform, and licenses to various 3rd party Web services to flesh out the user experience.
It is important to note that while these components are all required, their form factors can vary significantly. For example, in the smart lighting example, a hub could just be a "super bulb" that speaks both WiFi and BTLE. Alternatively, the hub functionality could be blended into the home router or could be implemented as an app running on an old smartphone or tablet that is "always-on" at the house. There are many ways to implement these components, but they will all be present in the system in one form or another.
(photo courtesy of GigaOm) GigaOm reported yesterday that GM is abandoning its custom app strategy for MyLink. Good move. GM had fallen into the "App Trap," thinking they could keep up with mobile phones and have native "apps" in the car. As we have mentioned, before, trying to build out a custom app ecosystem in a car is a failing strategy. There is no way for cars to keep up with the pace and quality of apps on mobile phones.
However, that doesn't mean the MyLink platform or concept is bad. Just the contrary, by pushing the "apps" over to Google and Apple where they belong, GM can be freed up to create task-based, context driven experiences in the dash. Over time, these will end up getting used by drivers far more than apps since they are purpose built for solving specific problems for the driver.
For those who are in the app mindset, think of it as abandoning a multi-app strategy in favor of a single-app strategy. As Thilo Koslowski has said many times, the car is a unique mobile platform. We should focus on its capabilities and create new experiences, not just try to play catch-up with the mobile phone.
Now let's see if GM takes that next step and make their connected cars all they could be.
It's time to get real when it comes to putting apps on connected cars and TVs. That reality is about three hard, cold facts: 1. Your platform is tiny compared to mobile OS platforms 2. Your device is used differently than a mobile phone 3. Google and Apple want to turn your car or TV into a phone peripheral
Millions of cars or 10s of millions of TVs (even assuming 100% user connect rates) are a small potential user-base compared to 100s of millions of smartphones. Add to that the fact that mobile apps are designed to lock the user into staring at a tiny screen and you have a stark contrast between mobile apps and the rest of the CE device space.
Now these facts wouldn't be a problem, except that most connected car and TV makers seem to pretend that they don't exist. They create open platforms and expect that the top app brands will port to their environment complete with a new UX. They start competing API developer programs and expect that top app makers will integrate their connectivity API because, "of course the app maker want to be in our prestigious brand of car," forgetting that even willing app makers need to manage 6+ APIs, each with their own QA requirements and release cycles. This is before even mentioning the fact that the additional revenue the app maker might see from these efforts is far less than the investment required in development, ongoing maintenance, and QA.
The bottom line is that if your goal is simply to get 3rd parties to put apps on your platform, then you are already fighting a losing battle. Apps on your platform will always be released later and will most likely not be optimized for your platform's unique UX requirements. Users looking for their favorite app on your platform are sure to be disappointed eventually because your selection of compatible apps will always suffer in comparison to Google Play or the Apple App Store. In addition, having their favorite app on your platform doesn't give you a benefit of differentiation, it just brings you to parity. To put it simply, Pandora on HondaLink compared to Pandora on Ford SYNC AppLink does not help sell a Honda instead of a Ford.
Apple and Google both see this reality and are pushing their advantage. On the automotive side, Apple Siri 'Eyes-Free' provides some driver functionality and Google has multiple projects with increasing levels of automotive integration. On the TV side, Google Chromcast and Apple AirPlay let apps take over the screen. By embracing these methods, connected car and TV makers would end up having no differentiation or control where it matters most: the user relationship.
To avoid the app trap, connected car and TV makers must think about the problem in a different way.
The key is to realize that each device has its own unique use case and to build a connected experience optimized for that use case. In cars, the driver has the primary goal of getting from point A to point B safely while keeping in touch and being entertained on the way. On TVs, the viewer is seeking primarily a lean-back style of entertainment, often in a social setting. Both cases can be described in a task-driven language. In the car, I want to find a great coffee shop near my destination. I may prefer Yelp results, but my goal isn't to "use the Yelp app." On the TV, I want to share photos with my family. I may have those photos on Facebook, but my goal isn't to "use the Facebook app."
By defining the UX in terms of task, the device maker can focus on delivering a differentiated and compelling way for the user to accomplish that task. The device maker is now out of the "app trap" because they are no longer trying to provide every app under the sun. Instead they are using Internet services "in service" of a defined set of tasks well suited to the device's use case. The device no longer competes with the mobile phone for app time, rather it allows the user to interact with their favorite services away from the Web and phone in a way that adds to overall time spent with the service.
Technologically, the best way to achieve this task-driven model is using an aggregation platform like Media Tuners MT-One. MT-One allows connected car and TV makers to create task-driven user experiences without having to build a different app for each Web services and without having to predict which Web services people will want to complete their tasks 4 years down the road.
If connected car and TV makers want to succeed, they need to avoid the app trap. Don't let Apple and Google set the rules, change the rules to be in your favor. Use lessons learned from your long history of building unique value for your customers to build task-driven experiences that leverage the Internet. Then you will have happy customers and a new way of establishing a long term relationship with them.
Based on over 15 years of experience leveraging cloud services for consumer electronics, he will give insight into the specific benefits and difficulties facing auto, TV, and other device makers today as they work to bring the features of the cloud into their products.
Impact of the Cloud on the CE Industry Wednesday, January 8, 2014, 5:15-6 p.m. LVCC, North Hall N262
Hope to see you there!
With all the noise in the connected device space, it is important to remember that experience matters. It is one thing for a company to claim that they have a connected platform to suit your needs. It is quite another for them to actually deliver on the promise. As amazing as it sounds, the team at Media Tuners has been working to build Internet powered devices since 1999. Starting with the Sonicbox remote tuner, we then went on to work on such ground breaking products as the Philips FWi-1000 Internet radio.
Throughout that time, we have learned some key lessons. One of the most important is the need to create a win/win/win scenario for device makers, content providers, and consumers. In our experience, most people only address the needs of two of them. The reality is that if you don't address all three, the product will eventually collapse under its own economic imbalance.
Another important lesson is making sure that your device uses the Internet in a way that differentiates it, not just as a check-the-box feature. Otherwise, why should they buy your product over the competition?
The great news is that by working with Media Tuners, you not only get the benefit of our technology platform, but also of our expertise in licensing and business modeling to help you create a winning connected services business concept for your device.
Designing a connected dashboard for cars is an art of balance. How can we let in the deluge of digital services without jeopardizing the simplicity (and thereby safety and usability) of the dashboard UX? There are many aspects to this problem: touch/voice integration, task vs. app usage model, unified login, consistent screen layout, etc. Today I want to focus on customization as a key weapon in your battle to conquer clutter on the touch screen.
Customization of the home screen is the tool that will allow your user to migrate from newbies to power user without getting frustrated with your head unit. When we have a new user, clearly they don't know where to start. They will need to be presented with a set of generic choices and guided through them to get to their final desired activity. However, after awhile, drivers will pretty much get into a groove and have a core set of 4-7 activities that they do the vast majority of the time.
A well designed UX will allow those core activities to be at the driver's finger tips with one touch, pushing the more generic activities down the to the list. It's important to note, though, that cars can have more than one driver, so those customizations really need to be set on a per driver basis. One person's ideally optimized home screen can be a confusing mess to another driver.
Given the importance of per-user custom layouts, we designed into MT-One the ability to store custom layout information inside each driver's account on the cloud service. That way when the driver sits down, their home screen is right there waiting for them, enhancing functionality as well as safety. They have what they want, where they want it, at one touch.
Here is an automotive dashboard designed on top of MT-One. This first picture shows my default home screen. As you can see, the options are very generic, allowing the user to drill down through the various tasks to find what they want.
Since I drink inordinately large amounts of coffee, the first thing I end up doing is drilling down through the category menus in the business search to find coffee. Something that is OK to do the first time, but something of which I will quickly grow tired.
In this picture, the problem is solved. I have customized the home screen to have one touch access to search for coffee nearby using the Yelp service. Now as I am driving, instead of having to drill down through the menus to find a coffee shop, I just touch the one button and the search happens. Since the configuration is stored in the MT-One cloud, any car or device I log into will have this same starting layout.
Announced in January 2012, Scion has released the BeSpoke infotainment system with the first shipments of the new Scion FR-S sports model. While Media Tuners did not have a hand in the actual iPhone client software or the head-unit hardware, we did have a strong hand in Pioneer's Zypr API for voice-controlled Internet service mashups, which leverages our MT-One technology. In addition, this new deployment features our tuner2 internet radio service.
Sensis, a subsidiary of the Australian telcom company Telstra, announced today that it is working with Media Tuners to deploy SASi, a voice controlled Internet services platform for automotive and mobile applications. Leveraging MT-One, SASi will give drivers unified access to weather, social networking, traffic, local search, and other features.
Today Pioneer announced the production release of Zypr, the platform for aggregated Internet services. Built using MT-One technology, Media Tuners is proud to be part of a sea-change in the way the Internet is experienced on devices. In addition to the core, unique benefits of a unified, category based API and a complete voice services stack, Zypr has the added benefit of being totally free to developers and end users. In fact, Pioneer goes one step further and actually pays developers a share of revenue earned on their apps. This ad-supported model turns the economics of the automotive market on its head and opens a new door of rapid innovation.