Brian Wassom is coming FRIDAY at the beginning of class. After that class will be a work session-
Brian is very well known in the AR community and would be an amazing contact for ur Linkedin. He has really helped out past ar grad class alumni so it's worth connecting with him ^^.
After he talks, students can meet with him 1 on 1. If you have legal questions about AR and your project he would be the person to talk to.
WHEN RYAN STAAKE and Patrick Piemonte first worked together, they helped you get around: Both were interface designers at Apple, with Piemonte working specifically on the iPhone's map technology. Now, nearly a decade later, the two are working together again—but this time, instead of helping you get around, they want to use the power of augmented reality to appreciate the hidden things around you.
That's the idea behind Mirage, an iOS app the duo and a small team just released. It's not the first AR app available in the App Store, and it certainly won't be the last, but it may well be the only one to marry augmented reality's hidden-world appeal with social media's shareable, re-mixable content. And in doing so, it's making AR not simply a technology of curiosity, but one of connection.
In case you've been at a three-month silent retreat, you've likely heard something about how certain tech titans are charging toward AR—and using your phone's camera to get there. Both Facebook and Applehave introduced developer platforms that allow people to integrate AR effects into apps. However, while early experiments have been encouraging, especially those using Apple's ARKit, they're essentially built around simulations that bridge some sort of experience gap: What does that bulgogi bowl look like in real life? Could my yard handle a SpaceX Falcon 9 landing? How many cats fit in my office? Whether they're useful or fantastic, they feel very much like sealed products. You fire it up, see the thing you need to see, and ... well, that's it.
Mirage, for its part, is even less useful than a floating tic-tac-toe game. But that's the idea. It's not a service or a simulation or a product—it's a palette. The whole point, as Staake says, is for people "to communicate through the real world."
How that communication works is a little bit group text, a little bit social-media app, and a little bit treasure hunt. When you fire up Mirage, you're presented with a camera view, along with a small Google Maps thumbanail in the upper corner. To add a "mirage," you point your camera at something and take a photo; the app then allows you to adorn the object with text, drawings, 3D emoji, even photos or animated GIFs. The mirage then shows up on the map as a glowing circle—as do all the other mirages people have made in your vicinity.
If you want to find those other mirages, enlarge the map and walk toward the glowing circles (this will feel familiar if you spent any time playing last year's AR breakout, Pokemon Go). When you get close to a mirage, a tiny thumbnail of the exact area will guide you toward the right spot to trigger the mirage. You can photograph or film other mirages, and then share those on other platforms—or you can just enjoy the small thrill of seeing something others can't.
The mirages themselves, though, aren't just static objects; if someone has created a mirage of a hashtag, for instance, then tapping on that hashtag will launch Twitter. Not only are mirages virtual objects that exist in the real world, then, but they act as a portal between the two. "Where we interact with each other on the internet, whether it's on a page or in chat, is kind of this representation of a non-space," Staake says. "We're very interested in the idea the Internet oozing into reality a bit more." (Staake has blurred those lines before; he directed the viral meta-video for Young Thug's "Wyclef Jean", and has created numerous VR projects.)
Despite its iOS exclusivity, Mirage wasn't built with Apple's ARKit; Staake and Piemonte came up with the original prototype eight months ago, and scaled it up themselves. "ARKit is amazing," Piemonte says. "but it's a special use case." Whereas ARKit apps react to the user's surroundings to perform a generalized function, Mirage is far more context-specific: Oh, hey, someone created a mirage outside this specific restaurant you're walking past, it says. Check it out.
And if you're worried about a cityscape clogged with the AR equivalent of pop-up ads and ghost sites, don't be. Each mirage is designed to disappear after 24 hours—unless other users upvote it. (People can also report mirages for objectionable content, in which case they'll be deleted early.) That, Staake and Piemonte hope, will reward humor and creativity, making the places you walk by every day just a little more enjoyable.
Someday—a someday that, in all likelihood, is much closer than we might have once imagined—this other layer of experience will simply be part of everyday life. Whether by AR-enabled glasses or some other means, physical and virtual objects will co-exist; that interplay will provide instruction, distraction, and everything in between. For now, though, there's exploration; for now, there are apps like Mirage, trying to deliver on the promise of AR. One hand-placed poop emoji at a time.
Google has launched a digital library of user-created 3D objects that can be used to populate virtual- and augmented-reality worlds.
Called Poly, the open-source database functions like a clip-art library, allowing anyone to find and download 3D shapes – from simple trees and animals, to complex buildings and environments.
Currently everything on the platform is free and licensed under Creative Commons, meaning the objects can be freely used to populate VR and AR games, and can also be used in architecture and design.
As the platform is open-source, users are invited to upload their own 3D objects to the library. But to kickstart the project, Google commissioned various artists to stock the virtual shelves, with objects ranging from pizza to poodles, dolphins to demons, and much more besides.
These artists made their objects using Google's integrated VR painting and sculpting apps, Tilt Brush and Blocks.
These models favour a low-polygon style, which is understood to have been a stylistic choice from Google. However, the simple rendering also means the objects should load quickly on Google's Daydream VR platform.
The objects and complete scenes can be viewed and downloaded on mobile or desktop browsers, and used with developer apps such as Google's own ARCore or Apple's version, ARKit.
Users can modify and re-upload objects to a new listing – but Google will always credit and link back to the original source.
The database is expected to become a useful tool for VR and AR hobbyists and developers who are just starting out, as most professional game designers are more likely to use objects they have created themselves.
In terms of architecture, the library already includes 3D renderings of skyscrapers, cabins, lighthouses and even the Colosseum.
A search for the word "chair" brings up moveable models of kitchen chairs, desk chairs and deck chairs, as well an item called That Expensive Chair, which looks remarkably like a pixel version of the Eames Lounge Chair.
[Editor’s note: This is the fourth in a series of seven posts on running your own Google Ventures design sprint. Read the first part here, the second here, and the third here.]
At the Google Ventures Design Studio, we have a five-day process for taking a product or feature from design through prototyping and testing. We call it a product design sprint. In the first two days of the sprint, we’ve learned about the problem, shared a lot of knowledge, and chosen the challenge we want to tackle in this sprint. It’s time to start cranking out solutions. Expect this step to take between two hours and all day.
I call this step “diverge” because when everyone (from the CEO to the marketing manager) is cranking out quick sketches, we tend to get a lot of ideas–and different kinds of ideas. Remember in the Legend of Zelda how the map would light up rooms you had visited as you explored the dungeon? That’s what you’re doing on Day 2: illuminating all of the possible paths.
Although you’re going to be generating ideas, don’t think of this as brainstorming–at least not the everybody-is-shouting kind of brainstorming. Instead, everyone in the sprint will be working quietly and individually, often around the same table. The exercises outlined below force you to get ideas out of your head and onto paper, without getting stuck feeling like they have to be finished or perfect.
ADVERTISING
DUST OFF THOSE OLD IDEAS
In my experience, some of the best ideas that come out of sprints were usually around before the sprint started. It’s not that they were bad ideas; they just hadn’t gotten enough love yet. The sprint gives you a chance to put all solutions on a level playing field. If you don’t bring out your pre-existing ideas, you do yourself a disservice.
Because new ideas are so shiny and fresh, the facilitator needs to remind everyone to think old first. There’s no need to be embarrassed of that solution you thought of five months ago while eating a burrito or taking a shower.
PAPER FIRST
One problem with business-as-usual-design is that companies get in the habit of going straight to high-fidelity mockups. In a design sprint, we start designing on paper for a number of reasons:
• It’s faster. • Everyone can contribute (not just designers). • Nobody gets too attached to the ideas that are generated because they’re so quick and rough. We purposefully use thick markers to make sure nothing gets too precious. • Did I mention it’s faster?
Run the series of exercises below to guide everyone from note-taking through sketching and sharing. See my earlier post for an exact list of the materials you need. I use my trusty Time Timer so everyone can see how much time is left in each exercise.
When I’m facilitating a sprint, I like to remind everybody that we’re not going to share any of the materials until we make storyboards–that’s step five of the cycle–and they’ll have plenty of time to polish those up. I want to make sure everybody feels loose and knows they’re actually going to have plenty of time to work, even though we’re keeping time as we go.
1. CHOOSE PART OF THE PROBLEM
In Day 1, you drew a user story diagram. Look at it together as a team. If the user story is more than two steps long (and it probably is), you’re going to need to divide it up before you start sketching. This is as simple as finding natural chunks in the story and drawing a box around them, like this:
Now decide which part to focus on first. It usually makes sense to have everybody in the sprint focus on the same part of the problem at once. If you take that approach, you’ll do one cycle for each part of the problem, with everybody collaborating on each part as you go.
You can also divide and conquer–everybody picks a piece of the story they’re interested in and works on that. This way is usually faster, although it introduces the risk that people don’t think about the user story holistically. If you have more than two or three chunks in your story, you might have to divide and conquer, or perhaps decide you’re going to focus on a smaller part of the problem for this sprint.
Either way, the facilitator ensures that everybody knows which piece of the user story they’re focusing on before you continue.
2. TAKE NOTES (5 MINUTES)
At this point in the sprint, the whiteboards and walls are probably covered in diagrams, notes, and “how might we” sticky notes. This is your chance to reload that stuff into your brain. Everyone takes a piece of paper and jots down anything they think is useful.
Now you’re going to add all the other ideas that are in your head, mix them with the notes you just took, and loosely organize them on paper. The mind map is going to be your “cheat sheet” you can use when you’re sketching UI ideas.
If you’re not familiar with mind mapping already, I often describe it as writing down everything in your head with no specific formatting; or quiet individual brainstorming. You can write words and connect them or not, you can draw pictures or not–you basically can’t do it wrong. The important thing is that everyone is getting every solution, old and new, out of their head and onto paper at very low fidelity.
Here’s an example:
4. CRAZY EIGHTS (5 MINUTES)
Everybody folds a blank sheet of paper in half four times, then unfolds it, so they get eight panels. Then you have five minutes total to draw eight sketches, one in each panel. Yes, you did the math correctly, that’s about 40 seconds per sketch, which is crazy…but it’s a great way to crank out variations of ideas quickly. And since these aren’t shared with the group, there’s no need to worry about making them pretty.
Since you have only 40 seconds for each drawing, you’ll need to turn off the self-editing and just get your ideas on paper. Crazy Eights will also help loosen up your creative muscles and make you more productive in subsequent sketching exercises. If you get stuck, try repeating an earlier sketch with a small variation– this type of exploration is useful and it keeps you moving.
For best results, do two rounds of Crazy Eights. On the second round, everyone will have the hang of it. You’re scraping the bottom of the barrel, which makes it more painful to come up with new ideas, but often this is where the most interesting solutions come from.
Now you may be thinking, I’m a bit of a hypocrite: Earlier in this post, I said old ideas are best, and now I’m asking you to come up with new ideas. Don’t get me wrong, it’s OK to fill out your Crazy Eights sheets with old ideas. But new ones are good too–just because old ideas tend to be stronger doesn’t mean they always win.
Pro tip: Get the Bit Timer app for your iPhone and set it to 30-second work periods and 10-second rest periods for eight reps, so you don’t have to time it yourself. The rest period alarm acts as your 10-second warning to wind down your current sketch. (Crazy Eights are based on the 685 exercise introduced to us by Brynn Evans.)
5. STORYBOARD (10–20 MINUTES)
Now we’re going to make that user story diagram more concrete, and we’re going to make something that will be shared anonymously and critiqued by the group. The goal is to take the ideas we’ve generated so far and sketch an actual UI showing how a user would move through this part of the story– where they click, what info they enter, what they think, etc.
Start with a blank sheet of paper, and put three sticky notes on it. Each sticky note is one frame in the storyboard. It’s kind of like a comic book that you’re going to fill in. Look back at your mind map and your Crazy Eights and find the best ideas. Chances are, you’re itching to illustrate at least one of them in more detail. Now you’re ready to rock. I ask everybody to draw UI in the three frames of their storyboard showing a progression: first this, then that, then that.
There are three important storyboard rules: • Make it stand alone: Just like a real product, your drawing has to make sense by itself, without you there to pitch it. In the next steps, people will be looking at these, but you won’t have a chance to talk about your idea until the end. • Keep it anonymous: Don’t write your name on your drawing. You’ll want all ideas to start on a level playing field and it can be distracting to know which one was drawn by the CEO. • Give it a name: Come up with a catchy title for your idea. That makes it easier to discuss and compare later. When you finish the storyboards, hang them on the wall with some sticky stuff. Pro tip: Hang them side by side (like an art museum) so people won’t have to crowd in too tight to see them.
6. SILENT CRITIQUE (5–10 MINUTES)
Give everybody a bunch of dot stickers. Then, without speaking, everybody looks at the different storyboards and puts a sticker on every idea or part of an idea they like. There are no limits to how many stickers you can use, and I don’t even prevent people who want to brazenly vote for their own ideas. By the end, you’ve got a kind of heat map, and some ideas are already standing out.
7. 3-MINUTE CRITIQUES (3 MINUTES PER IDEA)
Next, everybody gathers around the storyboards one at a time. First, people talk about what they liked, then we ask the person who drew it if we missed anything important. Usually the best, most popular ideas are the ones people can understand without an explanation, so the author of the storyboard often doesn’t have anything else to add. This process works far better than letting people explain their ideas first–which almost always uses up a lot of time.
Sometimes I like to do this step on a projector, especially if there are a lot of ideas to get through. I’ll take photos of each storyboard on my phone, upload them to Dropbox, put them in a Keynote file, then make notes about parts we like with outlines and text labels as we go through on the projector. This is easier for everyone to see, and you have a digital artifact of the ideas for later. The downside is the setup: Count on 15 extra minutes to capture and upload photos.
8. SUPER VOTE (5 MINUTES)
Once we’ve looked at all the ideas, everybody gets one or two “special” stickers (which can be the same dot stickers from before with a pen mark on them). These are “super votes” for the ideas you think are the very best. Between the original heat map and these super votes, it’s very easy to see which are the strongest concepts.
The super votes offer a unique way to tweak the process to reflect the decision-making structure of your team or company. Does your CEO make all final decisions about the product? If that’s the case, be honest about it and give her three super votes and everybody else one. Or maybe it’s a UX director or maybe a tandem of product and design who call the shots. The simple rule is to give the deciders extra votes.
By default, this process will be a meritocracy, but that’s not always the way companies work, and frankly, consensus can lead to poor design decisions. The last thing you want are decisions that the deciders don’t truly support. On some teams, these may be unwritten rules, so don’t be surprised if it feels a bit awkward to bring it up–in the long run, you’ll be glad you did.
REPEAT
Now it’s back to the first step to start the whole cycle over again. (Don’t worry, it gets easier with every repetition.) If you split up the user story last time, it may be time to move on to another chunk. Often when I’m running a sprint I’ll realize at this point that our scope was too large, and we should just double down and keep working on the same section. Either way, the end of a cycle is a good time to take a few minutes and carefully decide where to focus next.
Expect a team to be able to do this cycle two or three times in a day before getting burned out. Throw in plenty of breaks and snacks to keep the troops moving.
Stay tuned for the next episode, where we’ll talk about how to decide which pieces of these storyboards go into your prototype.
