Android Wear UX

I saw the news today about WhatsApp releasing a beta version of their app with Android Wear support. It got me thinking about what makes for a good experience, especially on wearables. This is something that I do think about quite a bit, but I haven’t written a lot about.

One thing that popped into my head was that my co-worker and I had solved some of the same problems on our app, Talkray, that WhatsApp is trying to address. While I don’t have much insight into WhatsApp’s design process, I can talk a bit about what we looked at when we were working on Talkray’s Android Wear support. I actually presented on this last week, here’s a video of that.

Design Principles

The Android Wear design documentation provides some guidelines on how to create a great experience on Wear:

  • Focus on not stopping the user and all else will follow (5 second rule)
  • Design for big gestures
  • Think about stream cards first
  • Do one thing, really fast
  • Design for the corner of the eye
  • Don’t be a constant shoulder tapper

Talkray on Android Wear

If you haven’t heard of us before, Talkray is a calling and messaging app. Talkray has had Android Wear support since Wear launched. There were two basic things that we wanted to be able to do from the watch. First, was to be able to answer incoming calls. The other thing was to be able to quickly respond to incoming messages. We came up with two basic ways of responding to messages, a canned auto reply and a voice reply.

Considerations

We took into account a few basic considerations when designing the UX for our wearable app. First and foremost, we wanted to have very, very quick interactions, as short and simple as possible. There’s a 5-second rule that shows up in Google’s documentation for Android Wear, and that is that if you force the user to interact with you on a watch for more than five seconds, they might as well have pulled out their phone.

There were several other things that we thought about too, like the fact that Wear is going to be a small screen, with limited interaction capabilities. We didn’t want to make the user read or think, as much as possible. We also wanted to make it safer to use while driving, since we know that people do text and drive, even though they shouldn’t. I realize that it’s a bit controversial to say that, but I felt that if we could cut down the interaction enough, we could give people something that would allow them to quickly and easily respond to messages without pulling their attention away from the task at hand.

Auto Reply

The first thing that we give users is a button to send a canned response to a message. This is actually a bit interesting in that it uses Activity Recognition to figure out what you’re doing and respond intelligently. E.g., if you’re driving, it will say that you’re driving and can’t talk right now.

We considered giving multiple choices for canned responses, but felt that doing so would require too much interaction, and would defeat the purpose. There’s literally only one thing to do here if you want to send a canned response. No thinking, just hit the button and you’re done.

Voice Reply

For anything beyond the canned response, we figured that people should be able to say what they want. However, after a year of using Glass, I know that when I see the speech to text running, it distracts me from just saying what I want to say, and I start thinking about what I’m reading. This is really bad for two reasons, first, it pulls my attention into the watch. Second, it distracts me from delivering the information that I want to get across.

Providing a voice-only message, that records the actual audio and sends that, means that I don’t need to think about what the machine thinks that I’m saying, the other person should be able to hear it and figure out what I’m saying based on the audio.

The one big down-side to this is that the current crop of watches don’t have speakers. This means that while we are encouraging people to send audio messages, they won’t be able to receive them. While not ideal, we felt that this was acceptable, though there may be room for improvement here.


Last, night, I gave a talk on the Android Wear SDK at Hacker Dojo. It was listed in a couple meetup groups, and we had about a hundred people show up for the event! The large event room in the Dojo was packed! The main focus of the talk was on UX and data syncing between the phone and the watch.

Video

Slides

Hearty.io

I also announced a little project that I’ve been working on, Hearty.io. I’ll write more about this later, but here’s how you can check it out:

git clone --recursive https://github.com/emil10001/Hearty.io.git

Thanks for all those who came out, it was a lot of fun!

Here’s a bonus photo that I found on the meetup page. Thanks to whoever posted it!


The results are in. We have a series of videos of most of the presentations, captured by John Scott.

First place: Calligraphr

Calligraphr improves the Chinese calligraphy learning experience with augmented reality. The project interactive character animations on a piece of real paper. User can simply trace down the character with a brush pen.

Second place: Outcome Tracker

Outcome is an application for Glass that allows you to access information about a client easily and check off any objectives you want them to achieve during your meeting. The easy to use interface allows you to view client info at a glance and read more if needed. Separate tasks are represented by individual cards that can then be checked off. Safety and emergency contact info is also available for those whom have clients with allergies, disabilities, etc.

Third place: TripExplorer

TripExplore allows you to create scavenger hunts to discover knowledge in fun and interactive ways. Currently the app points you to objects of interest using augmented reality on Google Glass and upon nearing, introduces a fact about an object The app also pops a question that requires studying/examining the object at hand.

Entangled’s pick: GlassRoom

GlassRoom is a teacher’s tool to get student involved in class without picking popsicle sticks out of a cup or names out of a hat. It also tracks student performance by subject and can provide analytics with time that can help in determining weaknesses and strengths of students!

Other presentations

You can find all of the submissions for the event on ChallengePost. Here are all of the presentation videos that I have from the event:


About three months ago, I decided it would be a good idea to run a hackathon. I suppose that I thought that it would be fun, and that I’d probably learn something, since I had never run one of these before. The truth is, I had not attended that many hackathons either. No matter, I was decided.

About

This post is going to give an outline of what went into the planning, mainly different details and considerations. Check out my post on the story if you’re interested in some of the initial planning and decisions. I couldn’t have done this without the help of a bunch of people. Please see my THANK YOU! post for who contributed to the event, and what they did.

Dates and times

When I originally had this idea, I booked the large event room at Hacker Dojo. We would have been able to use the space from 7pm-10pm on Friday and 8am-10pm Saturday and Sunday, though we would have ended at 6 or 7pm on Sunday. We ended up going with 24 hours straight from Friday night at 7pm to Saturday at 7pm, and holding it in San Francisco.

The whole weekend version seemed as it would have allowed things to be a little more relaxed, and not quite as pressed for time. In practice, we would have been just as for pressed for time, though being able to get sleep in between would have been helpful. I’m not sure that one would have worked out better than the other, and in the 24 hour model, we had most teams finish and submit something.

I’m not entirely sure that the location much of a difference. While we had initially hoped to grab attention from I/O attendees, the GDG leaders summit was closer to our event, and several of our attendees were in town for that (as well as I/O). Maybe the next one will be the weekend before the GDE summit.

Venue

There are several reasons that it is important to get this figured out first. First, obviously, you need to hold the event somewhere, and you need to be able to tell people where they’re going to go for the events. Second, for us, we knew that people would be traveling to the area, and the sooner we could let them know about our event, the better. Finally, again, you can’t hold an event nowhere, well, you could, I guess, but it would be a different thing, and that’s not what we’re talking about here.

The venue was chosen by our primary sponsor. I had initially booked Hacker Dojo, but we wanted something in San Francisco, and they were excited about Galvanize. Since the sponsor was taking care of the venue, I didn’t get too involved in that decision. The venue ended up costing $3k, and while Entangled paid for that, the money could have gone to other things, like prizes.

In retrospect, the space was the easy part, and we could have likely gotten a cheaper, larger space. We actually had several offers for a venue from several different people. Here are a few other considerations when looking for a venue:

  • insurance coverage
  • security
  • registering
  • cleaning
  • power outlets
  • WiFi
  • tables
  • find out about kick-out time
  • sleeping rules
  • white boards or flip charts
  • food storage, refrigerators
  • coffee maker

Lawrence warned, “take nothing for granted, especially without a big corporation to host”. It turns out that our paying a decent amount for the space bought us most of the things that we wanted. We still needed to rent tables, and get our own insurance, but they did have security, a cleaning staff, and allowed us to hack there all night.

The people who worked at the space were also great, and I have no real complaints. They actually stayed most of the night to help with issues. One team did have issues with certain ports being filtered on the internet, but they were able to work around that.

For us, it was certainly a trade-off, where we spent more money than I would have liked, but I also had a little less that I needed to be concerned about. Then again, we needed to rent tables, and convert a working space ourselves, then convert it back at the end. In terms of planning, the fact that our sponsor was so gung-ho about it, and that they were just sort of handling it, meant one less thing for me to take care of, and that was a huge plus.

I’m going to quickly respond to each of my points with what our solutions were:

  • insurance coverage
    • I bought event insurance online for $125 
  • security
    • the space had security
  • registering
    • we had organizers at the door checking people in
    • we required people to have bought tickets on Eventbrite before coming
  • cleaning
    • the space mostly took care of this, but I hired a TaskRabbit for the final cleanup
  • power outlets
    • the space provided plenty
  • WiFi
    • the space had adequate WiFi
  • tables
    • we actually had to rent these
  • find out about kick-out time
    • we were good for the full 24 hours
  • sleeping rules
    • we told people who asked to book a room if they wanted sleep, but napping was fine
    • in practice, there were a couple couches and dark, quiet corners that people slept in
    • I took a few short naps overnight
  • white boards or flip charts
    • the space had these
  • food storage, refrigerators
    • there was enough space to store all the non-perishables
    • we used a cooler and bought ice to chill drinks
  • coffee maker
    • the space had one, and one of our organizers brought one
    • we also purchased coffee from Starbucks on Saturday morning
    • there were tons of energy drinks

Schedule

You’ll need to have a schedule, and I wanted to give something tentative when I posted the event. There were some minor tweaks over the course of planning, like giving more time for presentations, but it’s fairly close to the original. If you don’t have a schedule, you’ll have no idea how you’re doing, and whether or not you’ll actually be able to finish the event on time. If you’re doing 24 hours straight like we were, finishing on time is fairly important, because everybody will be very tired at the end of it.

6/20

  • 7:00pm
    • Meet & Greet
    • Start forming teams
  • 7:30pm
    • Announcements
    • Brief talks
  • 8:30pm
    • Finalize Teams
  • 9:00pm
    • Start Hacking!

6/21

  • 3:30pm
    • Demo work to judges
  • 5:30pm
    • Judges deliberate
  • 6:00pm
    • Winner announced!
    • Get packed up
  • 7:00pm
    • Event is over

We somehow managed to stick to this schedule. The only real issue was that we didn’t give enough time for team formation. There were several teams with three or four participants, and several people who wanted to join teams. We should have carved out time for the entire group to do pitches, and had a more organized team formation effort.

As for how we stayed on schedule, Allen helped quite a bit with that. It was mostly just a matter of announcing a warning, then announcing what was going on, and making sure that everyone followed up on that. When we needed to convert the theater from presentation to work mode, then back, we just asked people for help, and then the organizers started working. Once they saw us working, they all pitched in, and it took us about 10-15 minutes to flip the room inside out.

One oversight was that we should have made more time for team formation. We should have also made it a little more explicit, giving partial teams a chance to do pitches that everyone hears, and let people know how many they can take on. This would have helped a bunch of people, and we just didn’t think this through ahead of time.

Helpers

We probably had about 15 people helping out with various aspects of the event. Your needs may vary, but you will need people there. We broke up the 24 hours into shifts and had several helpers there during each shift. Don’t put yourself in the position of being the only one there, you need help!

Food

The food came nearly entirely from Costco. We used Google Shopping Express to deliver all of the food that wasn’t prepared/fresh, and then one of our organizers went on food runs to pick up the rest. Here’s a link to a detailed food budget and inventory.

One decision that we made was not to provide alcohol. This was primarily pragmatic, as we were holding a 24 hour hackathon, and alcohol tends to make people sleepy, or at least me. I also wanted to provide food for dinner on Friday that would energize people, as opposed to making them full and sleepy, but I wasn’t in charge of Friday’s dinner.

We had a cooler available, and filled it with ice, soda, and energy drinks. There was space for us to stack the boxes of stuff that we had delivered from Costco. We also had an organizer do a Costco run on Friday night, to get food for breakfast on Saturday, since Costco doesn’t open until 10am. There were some perishables that had to be taken to someone’s home overnight, since we didn’t really have access to a refrigerator. The bagels and muffins were mostly fine, though some people started getting into them overnight.

On the question of caffeine, we had two 12 cup coffee brewers. I think that we really only needed one of those. I had forgotten to bring filters, but luckily one of the brewers had a reusable nylon filter. The thing is though, when it’s hot out, and you have lots of energy drinks available, people are probbaly going to go more for the Red Bulls than coffee. What’s more, we bought several boxes of brewed Starbucks coffee for Saturday morning, and those did get used up. In the morning, people are going to want coffee, and it’s good to have a bunch ready to drink.

SWAG

It was important for us to be able to give something to every attendee, especially since we were charging a fair amount for tickets. We went back and forth on this, and came up with a couple of ideas, water bottles and t-shirts. We were initially split on the decision, so I posted a SurveyMonkey poll, and landed on t-shirts. The Glass team also provided some cool swag, small Google Glass branded notebooks and stickers.

For the t-shirts, I put in an order for nearly 150 shirts of various sizes. Some on the very small end, and some on the very large end, with the bulk of them evenly distributed between small and extra large. Here’s our order details:

  • Type: Gildan Ultra Cotton T-shirt - Cherry Red, single color graphic on front
  • Quantities (Y is youth):
    • YM: 2
    • YL: 2
    • YXL: 10
    • S: 30
    • M: 30
    • L: 30
    • XL: 30
    • XXL: 10
  • Total quantity: 144
  • Cost: $936.00

Prizes

Nearly all of the prizes came from sponsors. I was able to use about $500 from ticket sales for prize money, but everything else was from sponsors. The following is a break-down of all of the prizes.

First

  • $6,500 value
  • $1000 cash
  • up to 5 HTC One (M7) phones (one per team member)
  • Metaio SDK ($3500 value)

Second

  • $3,675 value
  • $1000 cash
  • 2 tickets to Wearable Technologies Conference ($890 value each)
  • 1 ticket to GGDevCon ($895 value)

Third

  • $500 cash

Entangled’s Pick

  • $500 cash

Sponsors

Entangled Ventures was the first to step up, and basically underwrite the event. They secured a great venue, as well as contributing prize money. We wouldn’t have had much of an event without Entangled. Thank you, Entangled!

The Google Glass team paid for the food for the event. Having the food covered was a huge help, as it freed up ticket sales to go to other things like swag and prizes. It also gave me some assurance that no matter what the ticket sales ended up being, we would be able to feed people. Additionally, they provided some really cool Glass swag, that everybody loved! Thank you, Google!

Metaio also pitched in for food, taking care of dinner on Friday night and enough energy drinks to plow through the entire 24 hour event. They also offered an SDK as a prize, and gave out an SDK to a participant during the event. Thank you, Metaio!

HTC offered HTC One phones to each of the members of the winning team. In addition to prizes, Dario was on-site to help out during the event. Thank you, HTC!

Wearable Technologies Conference contributed prizes, in the form of two tickets to their conference, as well as a cash prize. Thank you, Wearable Technologies Conference!

GGDevCon offered a ticket to their conference as a prize. Thank you, GGDevCon!

NotionKit gave all of our participants access to their beta tools for prototyping and previewing Glassware. Thank you, NotionKit!

Budget

This is our complete budget, broken down by sponsor, as well as totals.

Tickets

  • funnel (where did buyers come from)
  • graph of sales
  • promotions & effectiveness
    • free codes
    • discount codes
    • both used to help see where sales were coming from
    • what should we have done?
  • price-points
  • what this paid for
  • what we thought this would pay for

Let’s look at some Eventbrite data.

Total Ticket Sales

This is a graph of the total ticket sales from when we first posted to when we stopped selling tickets. The last couple of days are a little skewed because I introduced a free ‘Spectator’ type.

Ticket Sales by Type

This chart shows the gross amounts that each ticket type brought in.

This is a more detailed look, showing how many of each type were sold, and what was not sold.

Here’s what was leftover, after sales ended.

Promotional Efforts

This shows a breakdown of the traffic that came through Eventbrite’s channels. You can see that it only accounts for roughly 10% of sales.

Here, we see the discount codes that I generated. These were typically generated such that each group that I shared with got their own code.

Finally, here are the access codes, that are used to unlock hidden ticket types. Some of these were for participants, some for helpers and organizers. Again, I generated individual access codes for various promotional efforts.

Logistics

The logistics of the food worked out fairly well, though timing was a little tricky, given the heavy traffic in San Francisco. Make sure that you take into account all of the time that it’s going to take to drive over there and back, and do whatever needs to be done at the place to pay. Plan on sending someone over with enough time to return when you want the food or supplies there.

As for supplies, make sure to have markers, pens, pencils, paper, whiteboards and whatever else you think will be useful to participants. You’ll probably want to have name-tags, and those are very easy to print straight from Eventbrite. We didn’t have paper or whiteboards, and that was a bit of an issue.

Check-in can be done with the Eventbrite check-in app, but you will need a few people to pull this off. People will also trickle in over a few hours, and if you want to make sure to check everyone in, you will need someone at the door that entire time. We had two people, and it mostly worked out. Also, badges help this a lot. Pro-tip: there’s an Avery badge that comes with sleeves and lanyards.

I hired a TaskRabbit person to come and help clean up after the event. This was totally worth the hundred dollars.

Hangers-on

There were a couple of people asking for free tickets, a couple people showing up at the event without tickets, a spectator telling participants he was a judge, and a potential sponsors who we didn’t hear from after not allowing them an email list. There will be people who try to take advantage.

The thing that I tried to keep in mind was that I should be fair. I should be fair to the participants, and I should be fair to the sponsors. I was not going to let people in at the last minute, because the other participants were responsible enough to handle the tickets at the appropriate time. If I had found the guy pretending to be a judge, I would have thrown him out.

As far as the sponsor wanting an email list, it would not have been fair to the other sponsors, or to the participants to give that out. I didn’t want my people spammed forever because we thought we needed a couple bucks.

Tools

Here’s a list of the main tools that we used in planning and executing the event:

  • Eventbrite
  • Github/Bitbucket
  • Google Docs
  • Google Shopping Express
  • ChallengePost

I would absolutely use most of these again. Eventbrite made the a lot of things really easy for us, and I would definitely use them again. Google Shopping Express was a huge help; I use that service a lot anyways. Google Docs made the organizing and judging much more sane, no surprise there. Github/Bitbucket were used by teams who added me to do a code-review at the end of the event.

The one issue that I had was with ChallengePost. They have been very good about getting in touch and taking feedback. Hopefully the issues that I experienced will be addressed. While I may use them again, here were the issues that I had with them:

  • There were 5 teams who were unable to submit anything. I’d like to be able to get them into the submissions section.
  • While creating the event, I didn’t realize that I needed ChallengePost support to push the event live. I had initially thought that I was good to go after a first pass, until one of my organizers told me that it was not live.
  • While setting up the event, there were a bunch of required fields that I didn’t necessarily want to fill in immediately, like the judges, because it wasn’t clear what the outcome would be, or it was earlier than I wanted to announce that information. There also appeared to be repeated information blocks, or blocks that sounded more or less the same.
  • When signing up for the event, people were having issues adding people to their team. There appeared to be a UI for that that flickered out of existence in about a half second. This confused a number of people. When people sign up for an event/challenge, they should be able to form a team at that time.
  • The timing was really difficult to deal with on ChallengePost. I had to specify explicit times that were only at one hour intervals, where certain features were locked out based on the time. This was incredibly frustrating, and made the tool difficult to use for me, as the organizer, and difficult for the judges.
  • The judges were confused because until the judging started, there was no clear path for them to associate themselves with my event as a judge. This confused everyone including me.
  • There’s probably more that I don’t quite remember now.

I’m not trying to slam ChallengePost here, again they were very pro-active in terms of contacting me, and doing their best to make sure that we had a good experience. These are simply weak spots to watch out for.

Rules

Teams

  • A team is limited to 1-5 members
  • All teams must have a Team Lead
  • Team Lead is the sole point of contact with organizers
  • Glassware presentations are led team lead
  • Any prizes won will be given to the team lead, to be distributed to the team
  • No remote team members
  • Limited outside consulting is ok, no code commits

Tools

  • Teams will use BitBucket, GitHub, or similar version control tool for code collaboration
  • Teams will register themselves on ChallengePost

Only the actual work done during the hackathon should be considered.

  • Teams are to add John (or another organizer) to their project on GitHub/BitBucket
  • Organizer does cursory code review during presentation
  • Check for commits by non-members, commits before the start of the event, after pencils down

Judging criteria

  • Completeness/polish
  • Glassware UX
  • Difficulty
  • Does it solve a problem?
  • How big is the problem?
  • Is it a good solution?
  • Would it make a good product?

Participants will be scored by a point system

  • Judges will use ChallengePost for voting
  • Teams will be tracked on ChallengePost

We had some other soft rules, like the people probably shouldn’t expect to sleep overnight. Our philosophy was that if people ask, tell them no, and then let them do what they want. You can’t control everything, and people are usually pretty good about respecting the boundaries. I’m not sure how well this method would scale.

Judges

You should get more judges than you think you’ll need, because one or two of them might bail. We had two of our original line-up not able to make it. We were able to replace one, and go without the other. I feel like we had representative judges, one with more educational background, two with education technology, and one with Glass specific expertise. Given that this was a Glass hackathon for building education solutions, I think it was a good balance.

Once again, I would like to thank all of our judges, for carving out the better part of their Saturday to come and watch presentations, deal with technical issues, and work out who the favorites were. Thank you, Kim Jacobson, Josh Salcman, Allen Firstenberg, and Kevin Adler!

Pitches

We gave each team 5 minutes to present, then an additional time for Q&A. The pitches that teams made at the end would have benefited from a bit of advice. Start with telling us what you did, and showing us a demo, then explain the problem afterwords. Five minutes is not a lot of time, so you need to get to the point quickly, and get the demo out of the way - if you do a live demo at all. Live demos are good, but they can, and do, go wrong. Oh, and if you have two team members, have one start talking, and the other setting up the demo - if it isn’t set up before coming on stage. Try to do an elevator pitch, and then use the rest of the time to build your case for why this matters. We had a lot of teams get to the end of the 5 minutes, just starting to set up their demo.

If you don’t finish your project, that’s no big deal, 24 hours is not a lot of time. However, don’t make excuses, and go on and on about why you didn’t finish. Instead, talk about what you were able to get done, and where you planned on going. Finishing isn’t the only metric for judging, but if all you focus on is how you didn’t finish, then it will cast a shadow on your entire presentation.

If you’re an organizer, a good idea might be to find an alarm clock that you set up on stage so that the presenters can see how much time they have. When you’re coming up with the length of time allowed for pitches, consider that each team is going to take a couple minutes setting up and tearing down, and that each team will have some Q&A time. It may not be smart to bound the Q&A, since the judges might have lots of questions for one team, and very few for another.

Lessons Learned

Honestly, everything went really well. Next time around I would probably start pushing on ticket sales earlier in the process. I would also try to make connections with press, and really try to get them there. Another big missed opportunity was that we didn’t organize anything about posting content during and after the event. Having a hashtag for people to use when posting pictures would have been really nice. Probably the biggest thing, that we lucked out on, was recording the pitches. John Scott was recording them all, and gave me what he had, but this should have been an explicit effort that we made. I should have asked for slide decks from everyone.

Conclusion

The above was a detailed account of my experience. Here are two other sources that might provide some good additional information:


About three months ago, I decided it would be a good idea to run a hackathon. I suppose that I thought that it would be fun, and that I’d probably learn something, since I had never run one of these before. The truth is, I had not attended that many hackathons either. No matter, I was decided. This post discusses how the event planning got on its feet initially.

The story.

I reached out to a couple friends, who run the Smart Glass Innovators meetup with me. I had two things that I wanted to focus on, Google Glass, and the weekend before Google I/O. Then, I mentioned the idea to my friend Kevin Adler, who was instantly excited about it and started brainstorming ideas with me. The first thing that we decided was that education technology would fit as a theme, along with Glass. He thought that his company, Entangled Ventures might be a good fit as a sponsor, I agreed, and after running it by Lawrence Wong and Joseph Wei, we had our theme nailed down.

I had initially booked space at Hacker Dojo for June 20-22, but Kevin suggested moving it to the city. This was an idea that came up a lot with the meetup, plus, that’s where I/O happens, so I figured that it was probably a smart move. Kevin went to work finding an additional space, and convincing his partners at Entangled Ventures to sponsor us. Kevin found us a space, and from there we were off to the races.

People

The next step was to gather up organizers. Luckily, I know a lot of great people, who all organize events like this. I pinged everybody and created a list of organizers who were all excited about helping out. The primary organizers all provided lots of helpful input, and were instrumental in figuring out all of the details that end up making or breaking an event. Then we had some people who were more active at the event itself, giving up large chunks of time to be available for helping with either technical questions, doing food runs, and making sure that there was coffee.

We also had some good support from Galvanize, which made my life easier, by being there for almost all of the event, and helping out with logistics issues like an occasional WiFi issue, keeping the place relatively clean, and making sure there was music or AV help when we needed it.

I wrote a whole THANK YOU! post about all the people involved.

Planning

The planning was not taken lightly. I have a handful of email threads that total around 200 emails, as well as two conference calls with the organizers, and additional calls with individual organizers. We used Google Docs to organize our thoughts, flesh out a concrete plan for everything, and assign tasks. The budget was there, as was info about the space, sponsors, everything. One of my goals with the planning of this event was to be as transparent and up-front with everyone as possible. I wanted to do my best to avoid any politics, drama, or in-fighting that might have resulted from a lack of clear communication. I think the communication helped, along with the fact that, again, I was working with a great group of people.

The planning started about three months before the event. The major pieces were in place after about the first month, then over the next couple of weeks we grew the sponsorship to a place where I wasn’t constantly worrying about paying for food. Then the detailed planning took the final month and a half. The detailed planning was the most time consuming, because that’s really when all the little things needed to get done. I was unable to work on any other side-projects in that time, which was difficult for me.

The first thing to nail down was the venue. I had initially booked a space at Hacker Dojo, where we typically hold Smart Glass Innovators events. After talking it over with Kevin, Lawrence, and Joseph, we determined that San Francisco would be a better location than Mountain View. Kevin found us a space in SF, that he liked, and we jumped on it. I actually held the Hacker Dojo reservation until the Galvanize reservation was final.

I’m not entirely sure it made that the location much of a difference. While we had initially hoped to grab attention from I/O attendees, the GDG leaders summit was closer to our event, and several of our attendees were in town for that (as well as I/O). Maybe the next one will be the weekend before the GDE summit.

There were several reasons that it was so important to get this figured out first. First, obviously, we need to hold the event somewhere, and you need to be able to tell people where they’re going to go for the events. Second, we knew that people would be traveling to the area, and the sooner we could let them know about our event, the better. Finally, again, you can’t hold an event nowhere, well, you could, I guess, but it would be a different thing, and that’s not what we’re talking about here.

Once we had preliminarily held the space, I was able to make an initial announcement. This was timed to be right around the time when people were first finding out whether or not they had gotten I/O tickets, and would be making travel arrangements. It ended up really helping us gauge interest, and get people excited about the event early on.

Next up was finding sponsors. The first email that I sent to the organizers was asking them to reach out and connect with potential sponsors. They delivered, and we came up with a list of sponsors who were going to cover our food and prizes. From there, we were off to the races.

There were lots of details that we nailed down over the next few weeks. The planning continued over email, Hangouts, and Talkray group calls. I’ll share all of the details of what we decided in an upcoming post on ‘how to run a hackathon’.


After months of planning, the Pre-I/O Google Glass Hackathon is finally over, and I couldn’t have done it without the help of a bunch of people.

Sponsors

First, a huge thank you to our sponsors, who made this event both possible, and worthwhile for all of our participants.

Entangled Ventures was the first to step up, and basically underwrite the event. They secured a great venue, as well as contributing prize money. We wouldn’t have had much of an event without Entangled. Thank you, Entangled!

The Google Glass team paid for the food for the event. Having the food covered was a huge help, as it freed up ticket sales to go to other things like swag and prizes. It also gave me some assurance that no matter what the ticket sales ended up being, we would be able to feed people. Additionally, they provided some really cool Glass swag, that everybody loved! Thank you, Google!

Metaio also pitched in for food, taking care of dinner on Friday night and enough energy drinks to plow through the entire 24 hour event. They also offered an SDK as a prize, and gave out an SDK to a participant during the event. Thank you, Metaio!

HTC offered HTC One phones to each of the members of the winning team. In addition to prizes, Dario was on-site to help out during the event. Thank you, HTC!

Wearable Technologies Conference contributed prizes, in the form of two tickets to their conference, as well as a cash prize. Thank you, Wearable Technologies Conference!

GGDevCon offered a ticket to their conference as a prize. Thank you, GGDevCon!

NotionKit gave all of our participants access to their beta tools for prototyping and previewing Glassware. Thank you, NotionKit!

Judges

Next, I would like to thank all of our judges, for carving out the better part of their Saturday to come and watch presentations, deal with technical issues, and work out who the favorites were. Thank you, Kim Jacobson, Josh Salcman, Allen Firstenberg, and Kevin Adler!

Organizers and Helpers

Finally, there is one last group that was instrumental in making this event happen. Without these people, there would have been no hackathon.

Lawrence Wong and Joseph Wei, were the first people who I contacted about the event, and both contributed lots of insight, advice, and connections to sponsors.

Kevin Adler, who was instantly excited about it and started brainstorming ideas with me. He suggested that education technology would fit as a theme, along with Glass. Kevin thought that his company, Entangled Ventures might be a good fit as a sponsor. He also, through Entangled, secured the space, and helped on a lot of the major planning items.

Next, a few standout organizers, Libby Chang, 'Katy' Hsin-yi Berg, Trish Whetzel, and Dario Laverde all provided lots of helpful input, connections to sponsors, and were instrumental in figuring out all of the details that end up making or breaking an event. I also need to make special mention of Katy, since she was there for nearly the entire event, and anytime we needed someone to make a food run, or to help work the door, she volunteered. She did more work than I did for this event!

Then we had some people who were more active at the event itself, giving up large chunks of time to be available for helping with either technical questions, or making sure that there was coffee. Allen Firstenberg, GDE for Glass, made himself available to answer people’s questions (and helped as a judge), Shannon Fiume was both answering technical questions, and making sure that we had enough coffee for people, and (Ivan Yudhi)[https://plus.google.com/+IvanYudhi] was also helping out during the event making sure that people had what they needed to be productive for the long overnight stretch. This was in addition to the organizers who I’ve already mentioned, who were all doing lots of work, either staying overnight to help out, or doing food runs.

Both Bruna Maia and Kat Otto from Galvanize made my life easier, by being there for almost all of the event, and helping out with logistics issues like an occasional WiFi issue, keeping the place relatively clean, and making sure there was music or AV help when we needed it.

I also need to mention John Scott and Jeff Bond who were both attendees, but pitched in a lot during the event.

The rest of the participants were also all really great people. We asked them to help us out with a few things and they delivered. There was no drama, no complaints, no hassles, I almost felt a bit guilty that I had it so easy.

A huge thank you to everybody who was involved, and/or participated!


I wrote an example of a low frequency LiveCard using GDK for Google Glass. The master branch uses Gradle, the legacy branch is able to be imported into Eclipse.

This code is heavily based on the Live Card documentation on the GDK section of the Glass developer docs. The reason that I wanted to do this was that I wanted something that required as little code as possible to run.

Code

Here’s the entire source for the Service that creates and publishes the LiveCard. It’s very similar to what you see in the documentation.

Notes

A couple of notes, it uses a custom voice command, launch with:

'Ok Glass, start my awesome app'

This displays random data, it is not correct, and Glass does not have a built in HRM that I’m aware of. It will display a new value every 3 seconds, and will stop updating after 10 values have been generated.

Importing

Instructions for importing legacy version into Eclipse.

Instructions for importing into Android Studio.

Instructions for importing into IntelliJ. A note on this one, you’ll actually import this as a Gradle project, not ‘from existing sources’. Everything should be configured correctly to allow it to be imported as a Gradle project.

Source

Full source available on GitHub.


Source. I found this in an image search for ‘witness’. Had to use it. =)

I’ve been working on a project for Google Glass and Android that requires asynchronous messages to be passed around between threads. In the past, I’ve used Square’s Otto for this, but I wasn’t thrilled with the performance. Additionally, Otto makes some assumptions about which thread to run on, and how many threads to run with, that I wasn’t crazy about. Before continuing, I should point out that Otto is configurable, and some of these basic assumptions can be dealt with in the configs. Regardless, I felt like writing my own.

Code

Witness is a really simple event emitter for Java. The idea here is to build a really simple structure that can be used to implement observers easily. It’s sort of like JavaScript’s Event Emitter, and the code is short enough to read in its entirety.

I’ll start with Reporter because it’s so simple. Essentially, this is just an interface that you implement if you want your class to be able to receive events.

The Witness class maps class types to Reporter instances. This means that for a given data type, Witness will fan out the event to all registered Reporters. It uses an ExecutorService with a pool size of 10 threads to accomplish this as quickly as possible off of the main thread:

Usage

To receive events for a specific datatype, the receiving class needs to implement the Reporter interface, then register for whatever data types the following way:

Witness.register(EventTypeOne.class, this);
Witness.register(EventTypeTwo.class, this);

When you’re done listening, unregister with the following:

Witness.remove(EventTypeOne.class, this);
Witness.remove(EventTypeTwo.class, this);

To publish events to listeners:

Witness.notify(event);

Handling events in the Reporter:

@Override
public void notifyEvent(Object o) {
    if (o instanceof SomeObject) {
        objectHandlingMethod(((SomeObject) o));
    }
}

Android, it is a good idea to use a handler, to force the event handling to run on the thread you expect. E.g., if you need code run on the main thread, in an Activity or Service:

public class MyActivity extends Activity implements Reporter {
    private Handler handler = new Handler();

    // ...

    @Override
    public void notifyEvent(final Object o) {
        handler.post(new Runnable() {
            @Override
            public void run() {

                if (o instanceof SomeObject) {
                    objectHandlingMethod(((SomeObject) o));
                }

            }
        });
    }
}

Notes

Events are published on a background thread, using an ExecutorService, backed by a BlockingQueue. This has a few important implications:

  • Thread safety
    • You need to be careful about making sure that whatever you’re using this for is thread safe
  • UI/Main thread
    • All events will be posted to background threads
  • Out of order
    • Events are handled in parallel, so it is possible for them to come in out of order

Please find this project on GitHub. If I get enough questions about it, I might be willing to take the time to package it and submit it to maven central.

Update

+Dietrich Schulten had the following comment:

It has the effect that events can be delivered on arbitrary threads. The event handler must be threadsafe, must synchronize access to shared or stateful resources, and be careful not to create deadlocks. Otoh if you use a single event queue, you avoid this kind of complexity in the first place. I’d opt for the latter, threadsafe programming is something you want to avoid if you can.

I should note that my usage is all on Android, where I’m explicitly specifying the thread that the events will run on using Handlers. I haven’t used this in a non-Android environment, and I’m not entirely sure how to implement the equivalent behavior for regular Java.


Finally, I have enough of the major pieces in place to be able to make a real announcement about this!

Come hack with us!

The weekend before Google I/O 2014, we are holding a 24 hour hackathon to build Glassware for Education.

Smart Glass and Wearables will be enabling innovation across many industries in the coming years, one such field is Education. Entangled Ventures has a special interest in seeing leaps forward in Education using technologies like Google Glass. Let’s see how we can enable teachers and students with Glass!

Keep an eye on the Eventbrite page for updates.


A number of articles have appeared in the last week, asking if wearables have already peaked. I think that the answer is a solid no. I’m going to break this down into a few parts, tracking devices, health and smart wearables (Glass, smart watches, etc.).

Tracking

While, I do think that the fitness tracking space is limited, I think that has to do with the appeal of these devices. No matter how many features fitness trackers offer, they will only appeal to a certain segment of the market. However, I think that there are three important aspects that have been unexplored so far.

First, is the feature set, most of the tracking devices are simply motion tracking, they do step counting and possibly sleep tracking. There are some people that primarily care about these two things. However, it misses out on other potential exercising, like cycling, or weight lifting. There are some tracking devices designed to do better activity tracking, like Basis, but we aren’t quite there yet, and those devices don’t seem to have penetrated the market in the same way that FitBit and its competitors have. Adding more sensors, and providing a more complete activity tracking picture will entice more people.

Second is health. I’ll discuss this more below, but there is an overlap with tracking devices.

Third, tracking devices may be used in conjunction with smart devices. This allows them to be possibly more discreet and less expensive, connecting through Bluetooth Smart (BLE). Perhaps I’ll have a step counter on my hip, a heart rate monitor chest strap, and a temperature sensor on my arm, all talking to Glass. What this does is allows those other devices to cut down on their BOMs, for example, they would not need a display at all if connected to a smart watch or to Glass, because they would already have access to a glance-able display.

Health

This isn’t as much a consumer space, but I think that there is a ton of potential here. We are just now starting to see devices that can start addressing health issues showing up. What’s more, there is some overlap with the tracking devices, for people with lifestyle conditions that would be improved by exercise.

I have started seeing reports of wearable patches being developed that could run on body heat and measure blood pressure. Imagine if there was an easier way to do blood glucose readings with a non-invasive wearable? Or, a potential application for Glass which might assist patients in taking their pills, using computer vision to verify the correct pill, and motion tracking to verify that it was taken, then reporting to the physician. There are lots of potential applications in this space.

Smart Wearables

This is what is going to tie everything together. I’m not sure that people will be still walking around with phones in a few years or not. Either way, smart wearables will enable other categories of wearables, as well as providing their own value. We are starting to see some useful Glassware show up, things like LynxFit and DriveSafe, that really couldn’t be done without Glass or at least not as well.

Conclusion

Wearables are not doomed, and they have not peaked, but we aren’t there yet either. If we still aren’t there in a couple of years, I’ll have to re-think some things, but for now, I’m optimistic.