My take on NPR’s Glass story

NPR ran a story on distracted driving and legal challenges with Google Glass on All Things Considered

The piece highlights some of the legal issues, states proposing legislation that would mark wearing Glass on the road as distracted driving. Unfortunately, the politicians do not seem to understand Glass, and the Explorer that they interviewed was allowing himself to be distracted by Glass while driving, reading off Field Trips information and claiming that it was OK because the screen was transparent.

My personal view is that it is a lot easier to not be distracted by Glass than it is to not be distracted by your phone while driving. Where Glass allows you to quickly dismiss unnecessary information, where the phone requires more interaction to get and dismiss the same information. From there, it depends on what sort of information you’re getting. A lot of times, with an email or text message, Glass can read you aloud what the content is, so that you don’t need to look at the screen. Responding also does not require you to be looking at the screen.

The device can be either much less distracting, or as distracting as a phone, depending on how you use it. I think that the Glass team needs to tackle this problem head on, and make sure that Explorers have no illusions about what constitutes a distraction. They also need to do a better job of communicating all of these things to the public. Finally, they should add some APIs, for developers, around being able to determine if navigation mode is enabled. From there, developers might choose not to surface information, or delay information based on ETA. E.g., never me Field Trips, or news while driving.

Samsung Gear - how to fail at UX

These devices look interesting, and I’m very excited about smart wearables shipping with built-in heart rate monitors. However, it looks like Samsung has totally failed on the UX front. These things look incredibly cumbersome to interact with.

Specifically, in clip of setting the wallpaper, when the wallpaper is selected, why are they returning the user to the wallpaper selection screen, as opposed to going straight back to the home screen?

How many new gestures are we going to need to learn to change the wallpaper?

Viewing a text message requires the user to open up the notification, instead of delivering the content in the notification view, and presenting actions there. This means that you need two taps to start recording a response.

In the S-Voice demo, that’s about the most verbose voice interaction I’ve seen. The amount of back-and-forth required to send a text message is obnoxious. You have to issue a ‘send’ command to actually send out the message. Why are they making status messages look like text messages from the person you’re trying to communicate with?

The Fit’s screen is facing the wrong direction. Good luck reading it. You’d need to hold your arm straight out to not see the thing at a funny angle.

I’m certainly excited about the future of wearables, and I think Samsung has some good ideas here, but the execution seems sub-par. 

GlassGif - Notes for a live coding session using the GDK

This post is intended to serve as a guide to building a GDK app, and I will be using it as I build one live on stage. The code that will be discussed here is mostly UI, building the Activity and Fragments, as opposed to dealing with lower level stuff, or actually building GIFs. If you’re interested, the code for building GIFs is included in the library project that I’ll be using throughout, ReusableAndroidUtils. The finished, complete, working code for this project can be found here.

Video

Project setup (GDK, library projects)

Create a new project.

Select Gradle: Android Module, then give your project a name.

Create a package, then set the API levels to 15, and the ‘compile with’ section to GDK, API 15.

Let’s do a Blank Activity.

If gradle is yelling at you about local.properties, create local.properties file with the following:

sdk.dir=/Applications/IntelliJ IDEA 13.app/sdk/ 

Or, whatever location your Android SDK is installed at, then refresh Gradle.

You might need to re-select GDK. If your project is broken and not compiling. Highlight the module, and hit 'F4’ in Intellij/Android Studio.

Now the project should be building.

Hello world & run

Let’s start out by just running 'hello world’. I’m adding this as a module, instead of creating a new project. As such, the manifest is not set up correctly, and needs to be modified:

Make sure it runs.

Fullscreen & run

Update the manifest to change the app’s theme to be NoActionBar.Fullscreen:

Make sure it runs.

Voice launch & demo

Turn the activity into an immersion:

I found this great blog post on adding voice actions. Add the voice_launch.xml:

And the string to strings.xml:

Run, and test saying OK Glass, launch the app.

Image capture & demo

Refactor structure to make the fragment its own file, ImageGrabFrag. Now, we are going to add some code to deal with the camera. The Android documentation on the Camera APIs is quite useful. Here are a couple of StackOverflow discussions that might be helpful for common Camera problems.

Next, we need to add a SurfaceView to main fragment.

Now, we need to add a dependency on my library project, ReusableAndroidUtils, which contains a lot of helper code. To do this, clone the repo and import it as a module into your project. After you’ve imported it, update your build.gradle file to reflect the addition:

Next, I’m going to pull in a bunch of code for ImageGrabFrag. Here’s what we have at this stage for that file:

Finally, let’s update the manifest with the required permissions.

Copy that in, make sure it all compiles, and try running. At this point, you should get a garbled preview that looks all funky:

What’s happening here? Well, Glass requires some special parameters to initialize the camera properly. Take a look at the updated initCamera method:

Ok, almost there. Now, we just need to capture an image. Take note of the added takePicture() call at the end of initCamera(). When we initialize the camera now, we’re going to try taking a picture immediately. Now we are running into an odd issue.

Try launching the app from the IDE, then try launching it with a voice command. When you launch from your IDE or the command line, it should work. If you launch from a voice command, it will crash! There are a couple things that we need to change. First, there’s a race condition going on right now. We are currently initializing the camera after the SurfaceHolder has been initialized, which is good, because if that wasn’t initialized, the camera would fail to come up. However, when we launch with a voice command, the microphone is locked by the system, listening to our voice command. The Camera needs the mic to be unlocked, because we might be trying to record a video. Thus, we get a crash.

The error, specifically, is the following:

Camera﹕ Unknown message type 8192

There are several discussions about this issue floating around:

• [1]
• [2]
• [3]
• [4]
• [5]

The thing to do is to delay initializing the camera a bit:

Try running again, and it should work this time.

Multi-Image capture

This part’s simple. We just modify our image captured callback, and add a counter.

We’re also going to add a static list of files to the main activity, to keep track of them. We’ll need that later.

Combine to gif

Now we need another fragment. We’re going to do a really simple fragment transaction, and we’ll add an interface to help keep things clean. Here’s the interface:

We need a reference to it in the ImageGrabFrag:

Then we need to change what happens when we finish capturing our last photo:

Here’s the final version of the ImageGrabFrag, before we leave it:

Alright, time to add a new fragment. This one needs a layout, so here’s that:

And here’s the fragment that uses that layout:

While there is a fair bit of code here, what’s going on is pretty simple. We are kicking off an AsyncTask that iterates through the files, builds Bitmaps and adds those bitmaps to an ArrayList of Bitmaps. When that’s done, we can move on. Here’s a link to a StackOverflow discussion that explains how to build gifs.

For any of this to work, we need to actually do the fragment transactions. So, here is the updated Activity code:

Now we can run, and it will do stuff, but on Glass, it’s not going to be a very good experience. For one thing, you won’t have any idea what’s going on, as the user, while the gif is being built. For that, let’s do two things. First, we should keep the screen on. Update the Activity’s onCreate method:

Let’s also add a bit of eye candy to the fragment. I want to flip through the images as they’re being worked on. I also want a ProgressBar to be updated until the builder is finished.

Run it again, that’s a little better, right?

Static Card

First thing that I’d like to do is to insert a Card into the timeline with the image. Now, this works, but it’s not great. Currently, StaticCards are very simple. They do not offer much functionality at the moment, as the API is still being fleshed out. Hopefully soon it will be updated. For now though, let’s do what we can:

As a note, if you have not already, make sure that Gradle is set to build with the GDK:

Viewer

The StaticCard is OK, but not great for a viewer. We made a gif, not a single image. Let’s build a viewer. First thing is that we’ll add our last Fragment transaction method to the Activity.

The viewer itself is very simple. It’s just a WebView that is included in the library project. We don’t even need a layout for it!

There’s a bit of an issue with not being able to see the whole thing. I didn’t dig into figuring out how to fix that issue. There are other ways of getting gifs to display, but I couldn’t get them to work in a reasonable amount of time.

Getting the gif off Glass

This section almost warrants its own discussion, but basically the issue is this, without writing a bunch of code, and uploading the gif to your own server, there’s not really a nice, official way of sharing the gif. Ideally, that StaticCard that we created would support MenuItems, which would allow us to share out to other Glassware with a Share menu.

Luckily, I found this great blog post that provided a nice work-around. It describes how to share to Google Drive, and with only a few lines of code. Here’s the code:

It’s not the sort of thing that I’d feel comfortable releasing, however, it is enough to finish up here.

Wrap-up

GlassGifCamera code on GitHub.

Hacking Glass 101 - Video from the meetup

The following are videos from the Hacking Glass 101 meetup, held at Hacker Dojo on 2/18/2014.

My talk on Mirror API, Mirror from Android and node.js:

Here are some extra resources from my talk.

Demo of Play Chord GDK Glassware, by Tejas Lagvankar:

Lawrence had some technical difficulties with his GDK presentation, but here’s what he was able to cover:

Dave Martinez wrapped everything up for us:

Big thanks to Sergey Povzner for filming and uploading for us!

Mirroring Google Glass on your Desktop

http://neatocode.tumblr.com/post/49566072064/mirroring-google-glass

I’m using this for a talk I’m giving tonight. Very useful!

neatocode:

Google’s new wearable heads up display is being shipped out to the first wave of people who signed up to be testers and is showing up more and more at meetups and hackathons. Here’s how to display the output of Google Glass on a desktop or laptop. It’s extremely handy when presenting and demoing!

Mirror API for Google Glass

I’m giving a few talks on the Mirror API for Google Glass, and I needed to organize some thoughts on it. I figured that writing a blog post would a good way to do that.

Here is the slide deck for the shared content of my Mirror talks:

Since I don’t want to miss anything, I’m going to follow the structure of the slides in this post. What I am not going to do, is be consistent with languages. I’ll be bouncing between Java and JavaScript, with bits of Android flavored Java thrown in for good measure. It really just comes down to what I have code for right now in which language. The goal here is to discuss the concepts, and to get a good high-level view.

What is the Mirror API?

What is it?

The Mirror API is one API available for creating Glassware. The main other option is the GDK. Mirror is REST based, mostly done server-side; it pushes content to Glass, and may listen for Glass to respond. The GDK is client-side, and is similar to programming for Android. The general rule of thumb, is that if you can do what you need to do with Mirror, that’s the right choice. Mirror is a bit more constrained, and is likely to deliver a good user experience, without a lot of effort. It also allows Glass to manage execution in a battery friendly way.

What does it do?

Mirror handles push messages from servers, and responds as necessary to them. The basic case is that your server pushes a message to Glass, then the message displayed on Glass as a Timeline Card.

How does it work?

If you’re coming from the Android world then you might be familiar with GCM, and push messages. Mirror works using GCM, similar to how Android uses GCM.

You can send messages to Glass, and receive messages from Glass. Sending messages is much easier than receiving messages. On the sending side, all you need is a network connection, and the ability to do the OAuth dance. If you want to receive data from Glass, you’ll also need some way for Glass to reach you, via a callback URL.

What’s the flow?

Glass registers with Google’s servers, and then your server sends requests to Google’s servers, and Google’s servers communicate with Glass. You can send messages to Google’s servers, and you can receive messages back from Glass via callback URLs that you provide. With that, you can get a back and forth going.

SO MANY QUESTIONS?!?!?!

I know, there’s a lot here. We’ll try to step through as much as possible in this post.

Setting up

Before you do anything else, you’ll need to head over to the Google Developer Console, and register your app. Create a new app, turn on ‘Mirror API’, and turn off everything else. Then, go into the Credentials section, so that you can get your Client Id and Client Secret. This is outlined pretty clearly in the Glass Quick Start documentation.

OAuth

To communicate with Glass, you’ll first need to do do the OAuth dance. The user visits your website, and clicks a link that will ask them to authenticate with one of their Google accounts. It then asks for permission to update their Mirror Timeline. After that’s done, you’ll receive a request at the callback URL, with a code. The code needs to be exchanged for a token. Once you have the token, you can begin making authenticated requests. The token will expire, so you’ll need to be able to re-request it when it does.

Further reading in the Quick Start.

Timeline

The timeline is the collection of Cards that you have on Glass, starting from the latest, and going back into the past. It also includes pinned cards, and things happening 'in the future’, provided by Google Now.

Here’s a video explanation from the Glass Team:

Why a Timeline?

Well, you’d have to ask the Glass team, why exactly a Timeline, but I could venture a guess. One of Glass’s issues is that it is more difficult to navigate with. You can’t dive into apps like you can on your phone, at least not quickly and easily. There’s no 'Recent Apps’ section, no home screen and no launcher (well, except from the voice commands).

Launching apps with voice commands allows you to do things, as opposed to going to an app and poking around. For example, saying OK Glass, start a bike ride launches Strava into a mode where it immediately begins tracking me with GPS and giving me feedback on that tracking. It does not let me look at my history there.

Glass tends to operate on push rather than pull. Glassware surfaces information to you, as it becomes relevant. This ability allows Glass to become incredibly contextual, though we have only seen bits of this so far with Google Now. Imagine a contextual Glassware that keeps a todo list of all of your tasks, both work and home. It could surface a Card when you get to your office with the highest priority work tasks that you have for that day. On the weekend, after you’re awake, it could tell you that you need to get your car into the shop to get your smog check.

A typical category of Glassware today is news, which all work well with a push approach. Now, this is not terribly useful on Glass, as it’s difficult to consume, but there are some good ones that have figured out how to deliver the content in a way that is pleasant to consume on Glass (Unamo, and CNN), or to allow you to save it off to Pocket for picking up later (Winkfeed).

The timeline is semi-ephemeral. Your cards will stick around for 7 days, and will be lost after that. Before you get all clingy and nostalgic, consider that that information is 7 days old, and will not only be stale, but difficult to even scroll to at that point. I have rarely gone back more than a day in my history to dig for something that I saw, and that was usually for a photo. Cards are usually a view into a service, so the information is rarely lost to the ether. Instead of scrolling for a solid minute trying to find something, you can pull out your phone and go to the app on your phone. Like G+ Photos, Gmail or Hangouts. Apps like Strava don’t even put your recent rides in your timeline, you have to either go to the app or their website for history.

What are Cards?

Cards are the individual items in the timeline. Messages that you send from your server to Glass users typically end up as timeline cards on the user’s Glass. There are a number of basic actions, as well as custom actions, that users can take on cards, depending on what the card supports. How this works will become apparent once we look at the code.

How do I insert Cards into the Timeline?

Using the API, of course! Let’s look at how to do this in a couple of languages.

Java:

TimelineItem timelineItem = new TimelineItem();
timelineItem.setText("Hello World");
Mirror service = new Mirror.Builder(new NetHttpTransport(), new JsonFactory(), null).setApplicationName(appName).build();
service.timeline().insert(timelineItem).setOauthToken(token).execute();

JavaScript:

client
    .mirror.timeline.insert(
    {
        "text": "Hello world",
        "menuItems": [
            {"action": "DELETE"}
        ]
    }
)
.withAuthClient(oauth2Client)
.execute(function (err, data) {
    if (!!err)
        errorCallback(err);
    else
        successCallback(data);
});

Further reading in the Developer Guides, and Reference.

Locations

Location with Glass can mean one of two things, either you’re pushing a location to Glass, so that the user can use it to navigate somewhere. Or, you’re requesting the user’s location from Glass. The Field Trip Glassware subscribes to the user’s location so that it can let the user know about interesting things in the area.

Sending Locations to Glass

Sending locations is very simple. Basically, you send a timeline card with a location parameter, and add the NAVIGATION menu item.

JavaScript:

client
    .mirror.timeline.insert(
    {
        "text": "Let's meet at the Hacker Dojo!",
        "location": {
            "kind": "mirror#location",
            "latitude": 37.4028344,
            "longitude": -122.0496017,
            "displayName": "Hacker Dojo",
            "address": "599 Fairchild Dr, Mountain View, CA"
        },
        "menuItems": [
            {"action":"NAVIGATE"},
            {"action": "REPLY"},
            {"action": "DELETE"}
        ]
    }
)
    .withAuthClient(oauth2Client)
    .execute(function (err, data) {
        if (!!err)
            errorCallback(err);
        else
            successCallback(data);
    });

I’m using this right now for something very simple. In a Mirror/Android app that I’m working on, I can share locations from Maps to Glass, and then use Glass for navigation. Nothing is more annoying than having Glass on and then using your phone for navigation because the street is impossible to pronounce correctly.

Getting Locations from Glass

This is a little more tricky. First, you need to add a permission to your scope, https://www.googleapis.com/auth/glass.location. Getting locations back from Glass is going to require you to have a real server that is publicly accessible. It should also support SSL requests if you’re in production.

Here’s some code from the Java Quick Start that deals with handling location updates:

LOG.info("Notification of updated location");
Location location = MirrorClient.getMirror(credential).locations().get(notification.getItemId()).execute();

LOG.info("New location is " + location.getLatitude() + ", " + location.getLongitude());
MirrorClient.insertTimelineItem(
    credential, 
    new TimelineItem().setText("Java Quick Start says you are now at " 
        + location.getLatitude()
        + " by " + location.getLongitude())
    .setNotification(new NotificationConfig().setLevel("DEFAULT"))
    .setLocation(location).setMenuItems(Lists.newArrayList(new MenuItem().setAction("NAVIGATE"))));

This will really help enable contextual Glassware. You could imagine Starbucks Glassware that offers you a discounted coffee when you get near a Starbucks. Or a Dumb Starbucks Glassware that does the same thing, but claims to be an art installation.

Further reading in the Developer Guides, and Reference.

Menus

Menus are the actions that a user can take on a card. They make cards interactive. The most basic one is DELETE, which, obviously, allows the user to delete a card. Other useful actions are REPLY, READ_ALOUD, and NAVIGATE.

You can see menu items added to cards in previous examples. I will repeat the JavaScript navigation example here:

JavaScript:

client
    .mirror.timeline.insert(
    {
        "text": "Let's meet at the Hacker Dojo!",
        "location": {
            "kind": "mirror#location",
            "latitude": 37.4028344,
            "longitude": -122.0496017,
            "displayName": "Hacker Dojo",
            "address": "599 Fairchild Dr, Mountain View, CA"
        },
        "menuItems": [
            {"action":"NAVIGATE"},
            {"action": "REPLY"},
            {"action": "DELETE"}
        ]
    })
    .withAuthClient(oauth2Client)
    .execute(function (err, data) {
        if (!!err)
            errorCallback(err);
        else
            successCallback(data);
    });

The Card generated from the example should allow you to get directions to the Hacker Dojo. You can also add custom menus, like Winkfeed’s incredibly useful Save to Pocket menu item.

Further reading in the Developer Guides, and Reference.

Subscriptions

Subscriptions allow you to get data back from the user. This can happen automatically, if you’re subscribed to the user’s locations, or when the user takes some action on a card that is going to interact with your service. E.g., you can subscribe to INSERT, UPDATE, and DELETE notifications. You will also get notifications if you support the user replying to a card with REPLY.

In Java:

// Subscribe to timeline updates
MirrorClient.insertSubscription(credential, WebUtil.buildUrl(req, "/notify"), userId, "timeline");

Subscriptions require a server, and cannot be done with localhost. However, tools like ngrok may be used to get a publicly routable address for your localhost. I have heard that ngrok does not play nice with Java, but you might be able to find another tool that does.

Among other things, you can learn from these sorts of subscriptions. You can learn which types of Cards get deleted the most, for example. Subscriptions can also listen for custom menus, voice commands and locations. With Evernote, you can say, take a note and it will send the text of your note to the Evernote Glassware.

Further reading in the Developer Guides, and Reference.

Contacts

Another important type of subscription is subscribing for SHARE notifications. The SHARE action also involves Contacts.

Contacts are endpoints for content. They can be Glassware or people, though if they’re people, they are probably still really some sort of Glassware that maps to people. Sharing to Contacts allow your Glassware to receive content from other Glassware. You can insert a Contact into a user’s time like so (in JavaScript):

client
    .mirror.contacts.insert(
    {
        "id": "emil10001",
        "displayName": "emil10001",
        "iconUrl": "https://secure.gravatar.com/avatar/bc6e3312f288a4d00ba25500a2c8f6d9.png",
        "priority": 7,
        "acceptCommands": [
            {"type": "POST_AN_UPDATE"},
            {"type": "TAKE_A_NOTE"}
        ]
    })
    .withAuthClient(oauth2Client)
    .execute(function (err, data) {
        if (!!err)
            errorCallback(err);
        else
            successCallback(data);
    });

It’s obvious what you want people Contacts for, but what about Glassware contacts? Well, imagine sharing an email with Evernote, or a news item with Pocket. Now, consider that as the provider of the email or news item, you don’t need to provide the Evernote or Pocket integration yourself, you just need to allow sharing of that content. It’s a very powerful idea, analogous to Android’s powerful sharing functionality.

Further reading in the Developer Guides, and Reference.

Code Samples

I have three sample projects that I have been pulling code from for this post.

• A slightly modified Java Quick Start provided by the Glass Team
• My Android Mirror demo
• My node.js Mirror demo

Netflix (and Audible) on Glass!

Did you know that you could install regular Android apps on Glass? What’s more, some of them don’t crash immediately, and actually kind of work! This one’s pretty simple, here’s what you’re going to need:

• Google Glass
• Bluetooth keyboard and mouse
• Settings.apk
• Ability to get apks for whatever apps you want to install
• Android SDK installed
• Ability to build and install Android apps from source

I’m not going to post links to apps’ apks, because that’s not cool. You’ll need to figure that bit out yourselves. (Hint, use a rooted phone.)

Start off by putting your device into debug mode, if you haven’t already. Next, grab Settings.apk and install it on Glass.

adb install Settings.apk

After that, clone, compile and install Glass Launcher from GitHub. If you aren’t familiar with how to do this, try the following:

git clone git@github.com:justindriggers/Glass-Launcher.git
cd Glass-Launcher
ant debug
adb install bin/*.apk 

Disclaimer, I don’t build from the command-line, so YMMV with the above commands. Also, probably specify the actual apk instead of *.apk, I’m just not sure what it’s name is going to be once compiled.

After you have both Glass Launcher and Settings installed, try using Glass Launcher to launch the Settings app. You can use the touchpad to highlight and select different elements. You should be able to navigate into the Bluetooth settings, and pair your keyboard and mouse. Get those set up now.

Download and install an app that you want, like Netflix or Audible. Now you can use the keyboard to log into your account on Netflix or Audible. So far, so good. For Netflix, this is really all you need. If you want to use Audible, you’ll need to get the mouse out in order to select the title that you want to download. You’ll also need to use the mouse to start playing a title initially, but once you have something in your ‘currently playing’ section, you can get by with just the touchpad.

All set! Now you can enjoy your books and movies right on Glass!

Google Glass with stereo earbuds. My new stereo earbuds came in today, and I’m pretty excited about them.

The stereo earbuds are the single biggest improvement I’ve seen in Glass so far. The bone conduction speaker was interesting, but inaudible in most normal situations. This is going to allow me to actually use Glass for several different things that while possible, was impractical before, like using it as a headset for calling, listening to music and being able to actually hear directions.

One missing feature is a2dp. I would love to see support for the bluetooth a2dp client profile on Glass. There are a lot of apps on phones that I use, like Audible, that do not have Glassware yet, and will likely take a while getting there. It would be nice to be able to use Glass with my new stereo earbuds to listen to any audio coming from my phone.

If I could do this, I could actually use my new Glass earbuds on my daily bike commute, but as it is, I still need to use the wired earbuds, since I listen to Audible books on my ride. I saw at least one other Explorer asking for this on G+.

In terms of comfort, I’ve worn them for about an hour and a half so far, listening to music, and had to give them a rest. They aren’t terribly comfortable, so I’m hoping that the tips are easily replaceable.

Connecting to a captive portal on Glass

I figured out a work-around for wifi networks that have a specific type of captive portal. I’m actually at an Informal Glass Office Hours right now at the Hacker Dojo, who happen to have a captive portal. The Hacker Dojo’s wifi is set up such that you can connect to their network, then when you visit the Dojo’s web page, it redirects you to the captive portal, where all you need to do is click the ‘agree’ button. If your captive portal requires you to log in or type something, it won’t work.

If you happen to be at the Hacker Dojo, or a similar place where the captive portal is easy to reach, and only requires you to click an 'agree’ button, here are the steps to take:

1. While tethered, or on your own connection, search for “hacker dojo”, make sure that the web page shows up in the results
2. Connect to the wifi
3. Visit the “hacker dojo” search results bundle, and open the hackerdojo.com card, then open webpage
4. Scroll down to the 'agree and continue’ button, and click it
5. …
6. Profit!

Replace “hacker dojo” with whatever network you are trying to connect to. Some networks will redirect you from any page, so the initial search doesn’t matter as much. Hope this helps!

Update

The redirect should work for any non-HTTPS page. So, as long as you have a search result for an insecure page, you should be good to go. I didn’t realize that because Gmail, Google, G+ and Facebook are all HTTPS, and that’s where I usually start my browsing.

Kaiser Permanente Administrators barged into my exam room

Executive Summary

I had three hospital administrators barge in on me in an exam room the other day. I feel that this was inappropriate, and that the situation could have been handled in a more professional manner.

I had submitted the following as a complaint to Kaiser, which they claim they respond to within two business days. That was two weeks ago. I was not going to publish this if they had responded even within two weeks. Below is the complaint that I had submitted, as it was written a couple weeks ago.

Actual Complaint Filed

Yesterday, I visited the Kaiser Permanente facility on Homestead and Lawrence in Santa Clara, CA for a doctor’s appointment. I was wearing Google Glass, as I always do, and when I checked in, the receptionist asked me about Glass, and informed me that I was not allowed to take pictures, or record video while in the hospital. I said of course, that’s not something that I would do anyway. Then, I sat down in a chair and was called in about 15 minutes later. I had my basic measurements taken, and was escorted into the exam room, where some information was entered, and I was asked to take off my shirt, and put on a hospital gown.

After waiting a bit for the doctor, I heard a knock on the door, and then three hospital administrators entered. (I don’t remember who they were, or what their titles were, but I’m sure it wouldn’t be hard for you to figure out.) They were polite, but looked uncomfortable, and I couldn’t really figure out why they were there at first. I was not pleased that they were paying me a visit in my exam room in the first place, and immediately started to wonder if this was typical procedure, for hospital administrators to enter patient exam rooms when they are half-dressed to come in for a chat? Then they started asking me about Glass, and I understood why they were there.

That conversation was basically one of the administrators explained that there was a privacy policy at Kaiser, that said that nobody’s allowed to take any photos or videos while there. She asked if the receptionist had explained this to me, and I said that he had mentioned something along those lines. She then asked if they could hold my device until I was done. I declined, and asked if they routinely confiscate patient’s smart phones when they walk in the door, and I noted that she had an iPhone, with a camera on it. I explained that you don’t do that, because you assume that people have some common sense about these sorts of things, that they won’t go around snapping photos in a hospital. I also explained that the current crop of Glass Explorers are all quite sensitive to this issue as well, since we are all very aware of people’s concerns about the device. She seemed to agree, and they left.

I’m not upset about the conversation. It’s totally reasonable for people to raise concerns about new technology. However, I do have a couple of things that I am upset about. First, it seemed inappropriate for the administrators to barge in on me in the exam room when I was half dressed. It made me feel vulnerable and intimidated by your staff. Second, I don’t like it when companies (that I give thousands of dollars to annually) treat me like a potential criminal instead of a paying customer who they care about. I especially don’t like it when there seems to be a basic distrust of me, in that situation, when I am entrusting your organization with my life.

Regarding the first issue, I can see at least two better ways of handling the situation. First, they could have phoned the desk, and had me wait outside until the admins could come down and meet me in the waiting area. This would have been fairly easy to do, how hard is it to make a phone call? Second, they could have waited until my exam was over, and had a nurse come in and inform me that I would need to speak to them on my way out.

I don’t really have a good fix for the second issue, I have big problems with companies that treat their customers like criminals, especially when they attempt to violate those customer’s rights (4th amendment to the Constitution, unreasonable search and seizure). Again, a conversation is fine, asking me to remove Glass while in the hospital would have been reasonable as well (which I’ll be doing from now on anyways). Attempting to confiscate my property using intimidation is not OK.

What I want

I would like an apology.

I would also like to know if it is hospital policy for administrators to enter patients’ exam rooms for things like this, or whether you try to address these sorts of things in a way that doesn’t put your patients in a situation where they’re feeling vulnerable and intimidated by your staff?

As far as Google Glass goes, this is something that your organization is going to need to figure out. This incident occurred in Silicon Valley, where you will start seeing more and more people coming in the doors with wearable devices, some less obvious than Glass. You will also likely have doctors in the near future wearing Glass. You may even issue Glass to your staff, since some of the most interesting Glassware being written about are for medical applications. People are doing truly amazing things in that space, and I’m sure you won’t want to be missing out on that.

Update

Two things. First, I received a letter from Kaiser stating that they would be sending me a letter within 30 days on the issue.

Second, after getting some opinions, and talking to people, I realize that this was probably a situation where I could have shown some more tact while walking into the hospital. I probably should have removed Glass prior to walking in, regardless of what was actually required or enforceable. I do remove Glass whenever I go into a hospital now, again, because it’s the tactful thing to do. I still think that the situation was handled poorly by the administrators, and that they could have found a better way to communicate with me than barging in on me in the exam room.

Additionally, it’s been interesting reading different people’s opinions on Glass in this situation. Some people are railing against me, saying that this is an obvious privacy violation on my part. Others seem to think it’s more similar to a smartphone, and that I shouldn’t have been bothered. I think I’ll hold onto this one as a conversation starter.

Update 2

I had failed to include this detail previously, but when I was called out of the patient area, I removed Glass, and put it in my shirt (just like I do when I use a public restroom). When I was in the area where patients are being interacted with, Glass was not on my head, and the camera was not exposed. When the admins came, Glass was sitting with the rest of my belongings, not on my head.