So whenever I get approached about environmental design, the

first thing people go to is responsive design plus.

And it's not quite that.

Responsive design is gonna make things work on any screen size.

And obviously it's more than just break points.

There's a lot of stuff that's in responsive

design, could you, different interactions at different screen widths.

There's touch detection.

There's similar similar concepts in progressive enhancement.

Or you familiar with progressive enhancement?

Well, okay, good.

So, in response of design in the progressive enhance stock, it's gonna

fix somewhere in here, where is heavy presentation, a little bit of behavior.

So, the response of JavaScript is gonna be in the behavior, but

it's primarily lives in CSS is where, you know where it should land.

When we folded environmental design, it more looks more like this, where

it's heavy behavior, a lot of JavaScript, and a little bit of presentation.

So we might change, some things in about the way an application looks.

But primarily, we're gonna be dealing with how it acts.

And then it's often to the ethernet and things that I haven't thought of yet.

So to boil it down Environmental Design makes things work in any situation.

It's not just different screen sizes, but it's it's aware of, of what you're doing.

It's, if you're outside, if you're inside, if you're

at the beach or if you're in a hotel.

If you're moving, you're sitting around, all these are different

environments that your design and your experience can mold around.

You could say that it's, a bit of situational design.

Now a handful of years ago, decades maybe, I had my aha moment

with really user experience in general, but environmental design specifically.

I was living in LA at the time, and nobody in LA reads books.

It's true.

Anyone from L.A. here?

Good.

Okay.

Nobody there reads books.

And I was no exception to this.

I really didn't read that much, you know, I would stick to

the trade articles, smashing magazines [UNKNOWN] That stuff, you know, we read,

but to that point in my life, I had really never read

the book and then saw the movie for anything, in that order.

I'd seen the movie separately and read the book for things.

So this is around the time that True Grit came out, the Jeff Bridges version.

Anybody see it?

It was really good.

So I decided that True Grit was gonna be the very

first time that I read the book and then saw the movie.

Because I had never had that experience ruined for me.

Cuz the book is always so much better than the movie.

So I wanted to do this to myself.

And so I started reading the book.

It was this amazing story about this this young

girl, I think she was 14, avenging her father's death.

It was an incredible story.

But I read the book and the Jeff Bridges version hadn't come out yet.

So I decided I wanted to see the John Wayne version.

But I think it was 1960, late 60s.

It's a terrible movie.

But it was on Amazon's Instant Watch.

So I, I ordered it.

And in the beginning, they have this option, do you

want the standard version, or do you want the HD version?

Now this is the first time I had done book movie, so

I'm gonna splurge the extra dollar and I'm gonna get the HD version.

It's, you know, it's, I work hard for my money.

So, I get the HD version and I start watching and immediately it starts

buffering and skipping and pausing and getting

pixelated, and it was just really bad.

And then this message pops up, it says I notice

you're having trouble with your connection, would you like to

switch to the standard version and I'm like absolutely not

I spent a dollar on this, I want my HD version.

So, I say absolutely not, take my HD version and I continue watching.

Less than five minutes later, choppy again.

Pixelated buffering.

Really bad experience.

And I'm just waiting for this message to pop back up.

I'm like I hope I didn't waste $4.

And I, maybe 20 minutes later the message pops back up.

And it says, do you wanna switch to the standard version?

I say, absolutely.

Give me the standard version.

I can't deal with this crap anymore.

So I watched the rest of the movie.

It was terrible, not for any reason really, I mean the story's great but

John Wayne, let's face it, plays John

Wayne in every movie regardless of the character.

So, the movie wasn't great but the experience watching the standard

version of the movie was so much better than watching the HD

version and that's when I realized, that these really big graphics

you know, gorgeous photography do not always equate to a better experience.

Sometimes they can be a worse experience.

And, whoever thought to put the cinderblock of the web of

video, a giant video, slow moving, at the top of every page.

It's ridiculous.

It's the heaviest thing you can do, but we're putting him up there.

They don't really improve the experience, they improve the design, but this is

when I realized that the design and UX world are different things completely.

So in that, I, I came up with these general rules of environmental design.

The the real world exists and we can't control it.

And that's fine, cuz the web is a really chaotic place.

There's a lot of stuff going on.

You can try and control it I don't know how many times

I've had conversations with people where they tried to overwrite browser defaults.

To implement a different experience.

And you're just fighting stuff tooth and nail.

It increases QA time.

The length of the project, everything it's just not worth it.

So you have to let some of this stuff go,

and embrace all these variable factors when you're building something.

Am sure a lot of people have seen this, this is do

websites need to look exactly the same in every browser dot com?

And I would say that do web sites need to act the same in every situation?

No, they don't.

If I'm, if somebody is on top of a mountain.

And for some reason the need to read a medium article.

And they have one bar of service, I don't know why

they have one bar of service on top of a mountain.

Maybe there's one like T-Mobile tower and they're roaming.

but, maybe you don't serve them those really heavy fonts and

that big image across the top, because that's gonna degrade their experience.

Maybe you just serve them the content, so they can, they can deal with it like that.

And it would be a better experience for them specifically.

It's really about making your content accessible to everyone in any situation.

You know, that the environments of being on a mountaintop, reading medium,

is completely different than being in a dark alley in Manhattan reading medium.

I don't know why, either one of those situations would happen but.

You never know.

They're totally different.

And we're kinda treating them the same right now.

What's really frustrating for me is that, you know, connecting

the world to my phone and the phone to my browser.

They're kinda disconnected right now.

I can communicate to my phone.

My phone really can't communicate to my browser much.

A little bit, and we'll get in to it later.

But the environment really can't communicate through the phone either.

So, there's all these things that are really close

to each other but, they're not quite connected yet.

I think it's a little ridiculous that for my

phone to realize that it's raining outside, it has to

go off and hit a Yahoo weather API and come

back instead of you know, water droplets on the phone.

And so you're like, hey, I think it's raining right now.

And the key to doing this stuff is building smarter applications

using, using APIs that are available to us to do this stuff.

We're already seeing a lot of this.

In 2002, 2004, when I was in college.

I, I went to college for more than 2 years, but that span of time I was working

in a dining hall, really brutal, like, full on fast food hair net stuff.

It was, yeah, I know, right?

[LAUGH] There was this thermometer in the dining hall.

That when it got cold outside, it would, it would start blowing heat.

It was terrible because you would be like sweating all

the time cuz it had no sense of actual temperature.

But it would react to the outside, so it was a little bit of envi, designing up

for the environment around Yeah, we're seeing this in other places.

There's the auto-brightness setting on your phone, that I, I know

I disabled it, because I hate it but it is in there.

And there's a little light sensor next to your camera

that measures lumens that will soften and brighten the display.

To react to wherever you are.

So if you're in a dark alley in New York.

And your trying to read medium, it's not gonna

be super bright, it's gonna dim it a little bit.

So it's a little better experience for your

eyes so that it doesn't burn your retinas.

When I go to the gym, once every six months

and I watch Netflix, it degrades the quality of the video.

So it's a little pixelated, but it's better for me because I can be on

the treadmill and ignore, I don't know, how boring it is to be on a treadmill.

It's like the worst.

We're seeing proximity sensors on cars.

You seen the, the commercials where a ball bounces

in front of a car and the car stops itself?

Because it's surrounded with proximity sensors.

So it's being it's being aware of the situation that it's in.

And on a related note, there are proximity sensors in your phone, too.

And we can access them through an API.

Right now, they're really just used for when you take

a call, you know, the screen, Siri just turned on.

[SOUND] [LAUGH] It's like the fourth time that's happened giving this talk.

It's really strange, I haven't learned yet.

But it turns the phone off, like the

screen off to, to prevent against incidental touches.

That's what it does right now.

But we can do a lot of other stuff with it,

we can be able to transfer data, though not pretty soon.

Right now, we're looking at the web through

this, this little, the world through this little pinhole.

And whether that pinhole is the phone or the

browser, it doesn't really matter but it's really small.

This is the pinhole.

It's a lot bigger on the screen.

That's actually pretty big But, you know, we're looking

at the world through this, right now, and what we're

trying to do with environmental design is open that, that

hole, a bit, a little bit, stick our head through.

And look around and say, you know, we're not

like, we might be like this when we're using something,

but there's a lot of stuff going on around us

that we can take into account and modify the experience.

Environmental Design is not a new concept.

It's been around since the ancient Greeks used to use it.

And when they would do construction projects.

In the 40s it got formalized as

environmental design, it's the same thing it's

just taking things to account, taking things

into account that are in your environment.

Including regulations, we have a regulatory body on

the web, W3C, anyone from the W3C here?

W3C is awful.

[LAUGH] They're not awful.

[LAUGH] But how do we get there on the web?

We have to use what I'm calling local APIs.

Because APIs are gonna connect us to the world.

There are a lot of APIs out there already, a lot of them are external.

There's you know, JSON services, there's XML APIs.

Talked about the Yahoo weather, which is a really popular one.

I think the iPhone uses it.

But the the native JavaScript APIs that are being

exposed to us since HTML5 started being put together.

You know, we've already seen them.

The very first one, that I saw was geolocation, years ago.

This was like right when HTML5 came out.

Everyone's like, oh wow we have this geolocation.

But it kinda got lost in the mix.

Because of the, you know, the new elements and all the other cool HTML5 stuff.

The video element and the you know,

section headers and all the new document objects.

But it kinda got lost but that's okay

because we're starting to see em come back around.

[SOUND] And of course there's more than

this, anyone familiar with this monster drama?

This source set, has anybody experienced this yet?

>> [INAUDIBLE].

>> Yeah, responsive images.

So picture fill is a poly fill that

lets us do responsive images based on screen size.

It's pretty good.

It took off in the community quite a bit,

and because we all wanted the picture element so bad.

It was so good, that the W3C came up with this instead.

That nobody wanted, and everybody like freaked out about it.

But it eventually, it essentially lets you create a list of

images to use in different contexts,

different screen sizes and different resolutions.

This is what it looks like, and now you can see a couple properties in here.

Big.jpg at 1x, and big-hd at 2x.

And what I wanted to talk about here that,

relates to environmental design is that 1x and 2x.

What's happening there, and it's really buried in the specification, but the, the

1x and 2x tells the browser, that this is my normal image, this is my 2 to 1 pixel

ratio image but the browser will look at that and there's a user setting that's

buried in the browser that says don't feed me HD images if I'm on a 3G connection.

And it's in the browser.

So, if i'm on my WiFi right now, if I wasn't on

my WiFi, the browser would say okay you have a retina device.

I know you can handle this really big image physically,

but you don't have the bandwidth to really take it.

So I am not gonna give you that, that really high res image.

I'm gonna give you the 1x, cuz I know that you can't handle it.

And this is the, one of the first

actual implementations of bandwidth testing on the web.

It's really buried in the specification but I'm, it's, it's really cool.

And I'm really excited.

It's implemented in Chrome.

I don't know if the user settings' there but source set is supported in Chrome.

And it's currently being worked on in Firefox.

No word from Internet Explorer.

Also no surprise.

So this is any, this is something for the browser to do.

But what about us?

For us, we have the combination of a Mozilla project called Boot to Gecko.

And the W3C.

Has anyone had any experience with Boot to Gecko?

At all, good.

So what it is, it's a, it's a

web based operating system that Mozilla came up with.

All the applications are built with HTML CSS and JavaScript.

Firefox came out with a phone.

It has Boot to Gecko on it, it's called Firefox OS officially, I think.

And what was cool about this was, unlike when Google

did it with Chrome OS, and they kept all their APIs internal, Mozilla

decided to work the W3C on these APIs to make them a standard.

Which is really cool, cuz we actually get to use them.

They have a huge list of API's that help you access the device,

device directly, and a lot of them are, are getting standardized pretty well.

I really think performance is, is the experience gateway.

Working at a user experience design agency,

we do a lot of user flows, experience

mapping prototypes just anything you can think

of that has to do with user experience.

But in the end, if the application

doesn't load or doesn't load quickly, they're worthless.

So if we can't get pass this.

Then there's nothing.

So let's see how we can use some of these APIs

that Boot To Gecko is exposing to us, to help the experience.

Let's go back to that guy on the mountain for a little bit.

And in the, in the spirit of developing a persona, let's pick a random name.

I don't know, we'll call him, Carl.

Carl, random guy [LAUGH] is on a mountain top.

What does he care about in his experience?

He's probably been hiking up there all day.

So his battery is probably drained.

He probably has really poor bandwidth.

So when he's up there reading that Medium article, we're not

going to give him that giant image, all that JavaScript to do.

Parallaxing, that just doesn't add a whole lot

to the experience, but that's a whole other issue.

And we probably, maybe we'll pull back some of

the fonts, or load them more responsible, at least.

So he's gonna have a different experience.

And this is more of a small pipe experience.

It's really not much, but he needs to accomplish his

goal of getting the content so we'll let him do that.

What we have available.

There's a bit of a history besi, behind bandwidth testing.

The very first type of bandwidth testing that we saw

is a JavaScript object in Firefox and Chrome, it's called Online.

It's navagator.online.

And it returns true or false if you're online or offline.

Which is great, if they worked the same in both browsers.

They do not.

And in Chrome, it acts as, what you'd expect when I

go up and shut my WiFi off, it triggers an event.

Okay.

You're offline.

In Firefox.

It stays true, so it looks like you're

online until you actually explicit go, explicitly go

and select Browse and Offline mode, which no

one does, I don't even know where it is.

So they act totally differently so, we can't really use it reliably.

Next, there was the Network Information API, which came out of

Boot to Gecko, which was the coolest API I have ever seen.

It gave you everything you needed to, to do bandwidth test.

It gave you what type of connection you are on.

If you are on 3G, WiFi, if 2G is a thing, I don't know.

But anything you needed.

And they'll give you signal strength also.

It was really cool.

But if you Google, network information API W3C, you'll find that

says, we stopped working on this because it was too hard.

That's where we are with this.

So, what we landed on is MobileConnection.

So MobileConnection API that's in Boot to Gecko right now, only Boot

to Gecko right now, and you need to be a certified Mozilla application to use it.

It does give us all the information that we need.

Hopefully, this will its way through the W3C and then eventually

into our normal browsers, so we can do proper bandwidth testing.

But you'll get things like, is the person roaming?

Yes or no?

There is a data cap on the plan?

Yes or no?

What's the signal strength you get in decimal milliwatts, whatever

that is, but you get a 0 to 100 numbers.

So you can pick, and pick and choose, if you don't have much bandwidth

maybe you'll throttle back some of the

assets and create a better experience overall.

But this is really cool.

I hope it goes through.

Unfortunately this is like the 4th iteration

of bandwidth testing that we've tried to do.

Hopefully this one will stick.

One of the other things that Carl on

the mountaintop is concerned with, is his battery.

We have a battery API now.

It's currently in draft form, with the W3C which is actually pretty far

along from now, even though they've been working on it since like 2009.

But it's, it's getting pretty close finally.

And you can get everything you would ever need out

of a battery for information in this API, it's incredible.

You get the level, battery level, what, how much

battery I have right now, which is like 10%.

You can get is it charging, is the device charging?

Is it discharging?

The, you can calculate the rate that its discharging at.

So you can see if your application is burning too much battery.

Then dial it back.

You can get the actual event when the, when the battery changes.

So if it's plugged in and it goes up a level, it will fire an event off.

If it goes down a level, if it will another event off.

And you can constantly get that value.

It's very cool.

And you can see this in Firefox now if you go in

the console and just navigate adopt battery the whole object will show up.

And this is a very cool one.

It's a contrast Carl on top of a mountain, we have another persona.

This person is.

Say we're in Manhattan.

And for the sake of creating a persona, let's make up another person.

Let's call him, Luke.

Random guy, another random guy.

So what are Luke's expectations?

And what is his, what's he concerned with?

Being in the city, he's probably not

concerned with bandwidth cuz he's in the city.

There might be some issues, but certainly not as much as Carl.

Is he concerned with battery life?

Maybe, he might be draining a little low.

But he's probably has pretty good access to electricity at some point.

So he may not be concerned with that.

He could be concerned with the amount of light, maybe it's night time,

or if it's day time, and he can't read his phone very well.

Or whatever device he's on.

He could be carrying an iMac around with him, I don't know how Luke acts.

But he could also be in a high distraction environment.

So, we could be concerned with that.

From, that's a sort of both ends, his concern and our concern as the developers.

And this is a, a large pipe experience that would be completely different

from the small pipe experience that Carl might be experiencing on the mountain.

To deal with this, we have some, we have something called the IdleObserver.

This is in Firefox right now.

And what it can do tell if you an user is idle or not.

Basically, if they're paying attention.

You can set a timer on it.

You can say if Luke hasn't done anything in five

seconds I know he's not paying attention there any more.

So I'm gonna stop firing Ajax requests.

At him.

808 saves, it saves our servers because we don't have to keep firing requests.

It saves his battery because he's not constantly receiving requests, and when he

comes back there an event fires that says oh, he's not idle any more.

Let's start the, the pipe up again.

So that's the way we could help.

We help a high-distraction environment.

There's also the device light API.

This is actually a really cool one, I mean I think there

all a really cool or else it wouldn't be in the presentation.

But this will measure the amount of light in the room.

So let's say, Luke is reading a medium mark, will maybe the same one as Carl.

And he is huddled in a dark alley way for some reason.

So he's sitting behind a box, hiding from a mugger and the screen's really bright.

And he doesn't want that because he's hiding from a mugger

and he wants to read this medium article so bad [LAUGH]

So we can see that there's, there's not

much light in his environment so we can dim

the interface a little bit to save his

life from the mugger potentially so we're saving lives.

Is what it comes down to.

And this is the only one that does it.

What it will do is return a the lux

value of how much available light is in the room.

And then you can do whatever you want with that number.

And I do have a demo that we put together.

This is what I used to look like.

Let's see if I can play it.

>> Right, we're here at [UNKNOWN].

>> All right, well.

I'll describe what's going on.

This is Dmitri.

We built a demo on Android device running Firefox,

and it's testing the, the lux value, see it's changing.

With the amount of available light in the room and Dimitry is gonna

go into this secret room that we have at, at, in the office.

I am telling when it's secret.

But he is gonna go into the room and when the [UNKNOWN] value hits a certain point.

You can't hear it but it plays a Barry White song.

We'll be measuring the [CROSSTALK].

>> When it gets dark.

>> [CROSSTALK] Telling you what it is.

So right now it's 1000 [CROSSTALK].

>> And the market for this incredible.

You wouldn't, you wouldn't believe it.

Picture yourself as a teenager in the basement with your boyfriend

or girlfriend and, you know, things are getting a little heavy.

You're playing some Barry White on your Android device, and then, and then

Dad busts in the door and the light shines and the song shuts off.

Automatically.

That's the market for this, and I think it's pretty good.

But so this is the demo.

I could send it out later, but so you

can hear it, but basically he's going back and forth.

He's really impressed with himself.

>> You come out to the light and then, there it is.

>> Yeah, so, it's more likely that instead of those

clean experiences, you're gonna get something that's a little different.

Like the city on the mountain top.

But the the point is that through the partnership in, you

know, Mozilla and the W3C, and a lot of other things.

You know, so geolocation is still really, really nice for, for environmental design.

But they're, they're exposing these APIs to us so

we can help develop a better experience for the users.

And that's what it comes down to, you know,

we're developing an experience and in the UX process.

As we start doing these things that don't fit into Photoshop,

developers are becoming more and more important to the design process.

I think it's really great.

Now I dare somebody to try and, try and put into Photoshop

something that plays a Barry White song when the, the lights go down.

It's really difficult.

You know, we need to start doing more prototyping in this thing.

And, and Steve is giving a talk tomorrow on prototyping.

Which is, is gonna be really good if you're interested in that.

So, I don't think it would be responsible to, talk about

the future without talking about a way to actually get there.

You know, we can say, here are all these cool APIs and, cool concepts, but part of

bringing Environmental Design to the web, is bringing it into your process as well.

To do that, we actually need to change the way we work together as teams.

I've been development director at Fresh Tilled Soil for a while now.

And we made a lot of changes, just in the way we work together.

[SOUND] Starting with, you know, really simple stuff, like the way we sit.

Does anybody experience something like this, where developers sit in

a certain area, and designers sit in a certain area.

Then you have culture in the middle.

Ping Pong tables or whatever.

Has anyone experienced that?

This needs to stop.

This absolutely needs to stop.

There's some benefits to it.

Certainly from the way it's been explained to

me, at least is that there's professional development

opportunities when you sit with other designers, or

you sit with other developers, you're gonna talk shop.

But you're gonna talk shop regardless.

So, you know, at what, what, what is the cost of that

professional development is a worse product in the end, I think, personally.

I think we need more conversations earlier on in the process.

Where designers and developers or whatever you're gonna call yourself as a title.

I've heard that titles are bad, earlier today.

Whatever that process is it's, it's gotta be more fluid.

And everyone needs to be involved and the

only thing this produces, is a really crappy process.

So we have time.

Project management over the entire course of the project.

Fairly typical.

UX and design is lumped in the beginning and then development at the end.

Has anyone experience at this?

This is a safe place.

This, this needs to step too.

This is horrible.

And this small overlap here is what, is the, that can't be done conversation.

Between developers and designers.

So what happens is, the design in UX teams go off and they design this,

this fantastic experience without ever having a conversation

with the people who have to build it.

So they don't know you know, if there might be

some technological constraint that we just can't do a certain thing.

So, this little overlap happens.

The developer gets this stereotype of being

somebody who always says no, because of this.

Designers have to go back again and redo everything and if

you've ever had a conversation with a client where they've signed

off on design and then something's been handed to a developer

and the developer says no we can't actually do this stuff.

You have to go back to the client, and say like, oh we screwed up.

We have to design this over again.

And it makes everybody look bad because of this.

And the only reason I could think of that something

like this was every conceived, [SOUND] you know, not having your

entire team on a project the entire time, is I'm

assuming someone's trying to jam development of a previous project here.

And design for the next project over there.

And what they're just doing is wasting everybody's time and money,

because we have to go back over the same stuff again.

So this has to stop, and it needs to look more like this.

We're all part of the same team.

We're all having conversations.

Up front we're prototyping more to communicate these experiences.

[BLANK_AUDIO]

And it really comes down to your skinny jeans needing my neck beard.

These are, the designer developer relationships that we have.

These new API's aren't gonna do anything by themselves.

If people don't know about them.

So, if you're in the beginning of the process and you say hey,

there's this, API I think that could help this experience a great deal.

Unless that's communicated, that's never gonna get

in there and then you have to jam

it into your workflow in that little

time that you've allocated to develop the project.

And that's not how we're gonna advance any of this stuff to make better experiences.

Scope and resources need to shift in that direction as well so

whoever, whomever's scoping the project needs to be aware of this stuff.

So it's all about communicating to the whole team.

And I really think that often times, the

best designer on the project is the developer.

We're developing these experiences, I don't think I've ever

been on a project that didn't need to be built.

I don't know whether that, that happens.

But ultimately, and I came up with this

artist's rendering of what I think this new age.

Let's call him a unicorn, or her, a unicorn.

Looks like as you can see our, our unicorn has a very

prominent neck beard, let me see if I can do this thing.

Here's our neckbeard here.

And then some impossibly tight jeans.

I didn't mean to circle his crotch.

[LAUGH] Am trying to circle his jeans.

It's not an exact science.

Just very, very thick glasses, and huge earphones, and apparently giant nipples.

>> [LAUGH] >> I don't know why he has giant nipples.

[LAUGH] But this, you know, this is the, no, this is the developer

being a designer on your project, I guess this is the represent, the representative.

And the greatest project I have really ever

worked on, has been those projects where development

and design is right there in the same

room sketching on a white board, spitting out ideas.

We're all talking to each other.

By the time something's presented to a client or a product

owner, everyone's on the same page, everyone knows it could be executed.

And we all, we all are really happy with the experience.

[SOUND] Jeffery Zeldman, semi-famously tweeted

a while ago, that content precedes design.

Design in the absence of content is not design, it's decoration.

I completely agree with this.

I would also add that context precedes design and

design in the absence of context is just decoration.

So this is very important.

I think in experienced design, context is really king.

Design doesn't look like this any more.

This is really pretty, but it really is decoration.

This is something you can, you can create in Photoshop, but web design is changing,

pretty rapidly, and we're moving out of Photoshop or sketch.

For you hipsters.

[LAUGH] Sorry.

Design looks more like this now, but it feels like something completely different.

It's it's very aware of your surroundings, your location and your needs.

It's not just design anymore.

It's an experience.

[BLANK_AUDIO]

And that's all I have.

>> [SOUND]