Physical Design
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 22 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/34739 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 20158 / 22
6
8
9
10
14
15
16
17
18
20
21
00:00
Software developerTrailBit rateFrequencyFault-tolerant systemNP-hardMultiplication signDesign of experimentsValidity (statistics)Core dumpCodeDebuggerComputer animation
02:03
Correlation and dependenceInfinityAbstractionNeuroinformatikMultiplication signRight angleDisk read-and-write head
02:42
PhysicsCorrelation and dependenceCategory of beingUser interfaceMomentumMassTouchscreenNeuroinformatikConstraint (mathematics)AbstractionGame controllerInterface (computing)Term (mathematics)CuboidDifferent (Kate Ryan album)Shape (magazine)Object (grammar)Medical imagingAcoustic shadowRight angleMultiplication signComputer animation
04:36
PhysicsRule of inferenceAttribute grammarFundamental theorem of algebraObject (grammar)Prime idealFinitary relationSpacetimeLiquidComputer architectureBuildingFocus (optics)Demo (music)MereologyData conversionLibrary (computing)Range (statistics)WordKey (cryptography)Template (C++)SurfaceMobile appCasting (performing arts)Category of beingState of matterProjective planeEvoluteLiquidAutomatic differentiationFlash memoryTerm (mathematics)Fundamental theorem of algebraSmoothingObject (grammar)Slide rulePhysicalismConstraint (mathematics)Rule of inferencePoint (geometry)Canonical ensembleNumberRight angleParameter (computer programming)InformationAcoustic shadowInverse elementMedical imagingEqualiser (mathematics)
08:59
SummierbarkeitGrand Unified TheorySmith chartEwe languagePerturbation theoryInstallation artTemplate (C++)Interactive televisionCartesian coordinate systemDemo (music)Right anglePhysicalismBitLiquidElectronic mailing listEndliche ModelltheorieGraph (mathematics)Incidence algebraDivisorConnectivity (graph theory)Template (C++)MathematicsCurve fittingEmailText editorSymbol tableSource codeLibrary (computing)WebsiteData miningCodeBit rateGroup actionFood energyWrapper (data mining)Function (mathematics)Point (geometry)Reading (process)Standard deviation1 (number)Rule of inferenceMobile appPlanningWeb 2.0Server (computing)Installation artCommitment schemeRoutingDrop (liquid)Level (video gaming)BootingComputer animation
12:20
Compilation albumBroadcast programmingSmith chartContext awarenessData managementPosition operatorState observerBitTransformation (genetics)Template (C++)Library (computing)Default (computer science)State of matterCartesian coordinate systemDataflowComputer animationContent (media)Medical imagingPattern languageVelocityRight angleQuicksortUniverse (mathematics)Digital photography
13:43
Function (mathematics)Default (computer science)Cartesian coordinate systemConfiguration spaceRouter (computing)Library (computing)Constraint (mathematics)Computer fileMathematicsRoutingGroup actionMobile appConnectivity (graph theory)Rule of inferenceImaginary numberFlow separationMoment (mathematics)Category of beingMultiplication signNetzplanDifferent (Kate Ryan album)Right angleSpacetimeLevel (video gaming)CASE <Informatik>AnalogyComputer animation
15:13
Function (mathematics)Default (computer science)Rule of inferenceElectronic mailing listDialectReverse engineeringDirection (geometry)RoutingRight angleRouter (computing)XMLComputer animation
15:46
Vapor pressureRevision controlMaß <Mathematik>UsabilityElement (mathematics)VelocityFunction (mathematics)Default (computer science)Transformation (genetics)Cartesian coordinate systemMobile appGroup actionVelocityLiquidSelf-organizationLibrary (computing)Point (geometry)DataflowContext awarenessSystem callComputer animationTemplate (C++)Element (mathematics)CASE <Informatik>Drop (liquid)Set (mathematics)Extension (kinesiology)Figurate numberBuildingNP-hardMedical imagingService (economics)Position operatorObservational studyMetropolitan area networkComplex (psychology)Web 2.0Computer animation
18:35
SummierbarkeitGroup actionExplosionSurfaceComputer animation
19:11
Group actionView (database)Flow separationMatching (graph theory)Web pageGreatest elementMedical imagingCondition numberComputer animation
19:36
Reverse engineeringDefault (computer science)VelocityFunction (mathematics)Right angleCommitment schemeFunctional (mathematics)Parameter (computer programming)Group actionElement (mathematics)Different (Kate Ryan album)Attribute grammarMatching (graph theory)State of matterComputer animation
20:32
Direction (geometry)Reverse engineeringGroup actionExplosionMatching (graph theory)Computer animation
21:03
Smith chartType theoryPosition operatorTemplate (C++)MeasurementPoint (geometry)Matching (graph theory)Element (mathematics)Web 2.0Condition numberComputer animationState of matterRight angle
21:54
Clique-widthElement (mathematics)Singuläres IntegralFunction (mathematics)Default (computer science)FunktorNetzplanVelocityWeb 2.0TouchscreenFitness functionCondition numberComputer animation
22:33
Reverse engineeringFunctional (mathematics)Web 2.0BitDirection (geometry)Right angleAzimuthXMLComputer animation
23:01
Ocean currentLiquidRight anglePerturbation theoryBlock (periodic table)Online helpWeb pageEndliche ModelltheorieMathematicsPoint (geometry)Revision controlPivot elementSemantics (computer science)Electronic mailing listNumberView (database)Source codeXML
24:32
Hydraulic jumpCommitment schemeMereologyRule of inferenceSlide ruleReverse engineeringSelection ruleScripting languageXML
25:11
Service (economics)Selection ruleLiquidElectronic mailing listNetzplanClique-widthDifferent (Kate Ryan album)Group actionRight angleVolumenvisualisierungCASE <Informatik>
25:43
Reverse engineeringComputer iconModemFunctional (mathematics)Different (Kate Ryan album)Rule of inferenceChemical equationElement (mathematics)Spring (hydrology)MappingSubject indexingConfiguration spaceMatching (graph theory)VelocityRoutingXML
26:13
Function (mathematics)Default (computer science)Reverse engineeringInteractive televisionUniform resource locatorLink (knot theory)LiquidEndliche ModelltheorieOnline helpGroup actionCASE <Informatik>Constraint (mathematics)Element (mathematics)Rule of inferenceBit rateTemplate (C++)State of matterMatching (graph theory)Reverse engineeringRoutingXMLComputer animation
27:41
Perturbation theoryMaxima and minimaDemo (music)Rule of inferencePoint (geometry)Projective planeBuildingBeta functionWebsiteGroup actionoutputConnectivity (graph theory)CuboidDifferent (Kate Ryan album)Software developerNumberComputer animation
30:07
Computer animation
Transcript: English(auto-generated)
00:17
We've heard a whole bunch of great talks already, awesome stuff.
00:21
We've heard a lot about user experience, and I don't think that's a coincidence. I think we're clearly a community that gets the value of user experience, and it flows directly out of some of the core Ember values, right? We work hard on shared solutions and infrastructure so that we spend progressively less and less time
00:42
on that minutia. And then the work that's left over, the work we never get rid of, is the hard stuff, right? It's deciding how to generate that great experience for our users. And when you think about user experience design, most people think right away about building experiences
01:01
for end users, right? If you're a front end dev, you do that a lot. Maybe you work with somebody whose title is actually user experience designer, and those people are awesome. They help an awful lot. But I want to argue that every developer, period, full stop, is always a user experience designer. Sometimes your user is an end user.
01:22
Sometimes your user is another developer who's going to have to interact with your code. Sometimes that user is your future self that you're either helping or punishing when you're going to come back to that code months later to look at it, right? So this talk today is going to talk about user experience, and there's two key audiences
01:44
whose experience I want to talk about today. The first is the end users that we're serving and building great experiences for them. But the second, of course, is the great experience for Ember developers, right? And those are two sides of the same coin. I don't think you can have one without the other.
02:03
So that's the kind of big picture of where I'm going with this talk. So computers, right? They're like, they're really abstract. And that's what's awesome about them. They're almost infinitely flexible, right? The kind of things that you can present to the user
02:21
are limited almost just by your imagination. And that's one of the things that makes them awesome, but it's also exactly why computers are so intimidating and frustrating for so many users and so many people. Because we have all this amazing machinery in our heads, in our eyes, for processing the physical world, right?
02:43
The physical world is what our brains evolved to process. We have all these cues and hints that we take advantage of and take completely for granted that almost every human being can do, and it makes its ways of thinking, ways of perceiving, ways of understanding where you are and what you're doing, what's going on around you.
03:02
And when you take human beings and you drop them into a screen world with very abstract shapes and things that don't behave physically, they get lost. And all of a sudden, you actually disable whole chunks of their own ability to think and perceive. There's a lot of different ways humans think and perceive, and we leave a lot of that behind
03:21
when we limit ourselves to a very abstract, visual kind of in the square box. And now that's actually a really big problem that's bigger than anything we can address right now here. We're gonna talk about attacking that problem and chipping away at it. The larger problem is one that we're all gonna work on
03:42
over the long term as we build better and better interface technologies. But we can talk about at least making the visual piece that we do have control over much closer to physical reality. And we do that by bringing in constraints. So your computer can't show anything, right?
04:02
You don't have to pretend that the objects on the screen have mass or momentum or that they cast shadows, right? They can go anywhere they want. When they're not on screen, they're not really anywhere. But that's deeply weird to human beings. And so when we constrain ourselves
04:22
and we put in the extra effort to pretend we're physical, that's the underlying reason that we see all these, that's why we feel so great about the user experiences of more physical UIs. So some of our earlier talks have already mentioned Google's Material Design spec. Material Design is a wonderful document.
04:41
You should check it out. And like Lauren Tan said to us yesterday, remember that design is not about how it looks, right? It's about how it works. And so even if you have no interest in making your app look like Google's apps that they write when they design with Material Design, the principles in there are extremely good stuff.
05:02
And they touched directly on my earlier point about physical constraints. So here's a quote from the introduction to Material Design, and I highlight it in big bold letters, without breaking the rules of physics. And the doc goes into a lot more detail about what they mean by that. But there's, you know, the kind of examples
05:20
are things like two objects should not really be able to pass through each other, or things that are on top of each other actually do cast shadows, or things don't accelerate instantly from zero to going fast, right? All these little things. Fundamentals of light surface and movement.
05:41
Here's that word movement again, right? Motion respects and reinforces the user as the prime mover. So this is why we care about motion, right? We had a great demo of all those polymer driven animations. That's exactly what I'm talking about. The reason that stuff is so appealing, the reason we immediately get it, is because it's appealing to that part of our mind
06:00
that makes these things seem more physical to us. So then of course the key question is, how does this fall into Ember's broader architecture? And this is where we switch the focus from the experience of the end users to the experience of the Ember developer, right? The challenge that we always have
06:21
as we develop Ember and we evolve it together as a community, is to find great APIs that we can all live with and work together with and build great conventions and tools and move on to build the next great thing. So what I'm gonna talk about today is where you fit all this stuff in to the Ember architecture and how you do it.
06:44
So animations and motion in general, right? When I saw, I guess I should first point out, right? I'm kind of using the terms interchangeably. Animation can mean a lot of things. Remember the principle I just had on the last slide about the user is the prime mover, right?
07:01
That's really the kind of animation we're talking about. The user does something and then we have smooth motion in reaction to the user. As opposed to the kind of animation that we have always had in terms of like flash ads where you have to whack the monkey or you know. That's not the kind of animation I'm talking about. So animations really live in the gaps
07:22
between what was and then what becomes, right? The animation is what's happening in between what the state was and what the state becomes. And so it's not really something that's a property of your, say for example, a template in Ember because the template is the static thing at the end, right? You have a template before, you have a template after
07:42
and that's the conventions that were great for us. So you need to find a place for the animation that is neither here nor there but in between. And so that was the kind of key insight that led me to publish the liquid fire animation library back in July which came out of some great conversations and talks that I did at EmberConf last year.
08:05
So I'm gonna do a, I'm gonna launch into a little demo of some liquid fire stuff and talk about how we find a place in the Ember architecture for all these kinds of rich behaviors. So the first step of course is installing it and yay for Ember add-ons, we just have one command
08:20
to install it. Right now we do have two branches because of all the evolution in Ember. This is a project that I care a lot about supporting across the whole wide range. So it actually is tested in CI against everything from Ember 1.8 all the way through to Canary. We're committed to supporting that. And I'm really excited to be announcing a 1.0
08:40
alongside Ember's 2.0 this summer. And yeah, that's really good, right? Yeah, thank you. And that's really kind of my point about this whole demo which is that we want this to be something that every Ember app can do and it shouldn't be that,
09:02
it shouldn't be a big extra deal, right? The goal is to make it so easy that it's almost, why would you not build rich interactive applications, right? So I'm gonna show a demo here. And I guess I'll turn up my font size. So, do I fit?
09:24
This is an Ember app. The EmberConf website is not actually an Ember app. I did not have the source code to it. I just decided it was kind of a nice example data to play with so I web scraped it. And I thought I did. I ran like wget before I got on the plane
09:40
to fly out here so I would have it all. And this is kind of fun trick you do with Ember actually. You could take somebody else's website, grab all the static output, not even knowing how it was assembled on the server or whatever, drop it into your application template, boot up Ember CLI, and you have an Ember app, right? And you can start to very incrementally refactor it into an actual Ember app.
10:01
You can take out the pieces, start to make them templates, start to take the repetitive data out and put it into models. And so that's what I did to put this together. So it's very simple, right? We have our list of speakers here and, oh, I already have the fancy stuff turned on. I wasn't intending to do it that way. Let's see.
10:28
We're gonna go back a bunch of commits. Okay. So this is a very stock Ember app. The point of this is to say there's nothing up my sleeve. This is a standard Ember app
10:40
that's doing very standard Ember things. You're gonna see the templates in a minute. But we have a speakers list. They do have this nice little physical bounciness right now. That's very simple, right? That's one CSS rule to say on hover, translate up a little bit, right? That's nicely self-contained, right? This is the kind of, there's a lot of little subtle details in building physical design that are self-contained enough
11:00
that you don't need to go use some big library to do it, right? A lot of these are the little details that you just have to get right as you design and as you build. And those ones are the easy ones because they're local, right? We're gonna talk about some of the less local things. I have a shuffle button here that just reorders the people, okay? And we can go and see the details of each of these people.
11:21
And I've also, just to give us something else to play with, I've put an inline editor in here where you can click and edit, right? And change something and save it and go back, okay? So that's our simple demo app, right? So we wanna give some nice richer interactions to this. And so we do the npm install liquid fire, right?
11:40
I have that already. Let's move up one more commit here. So by the first thing I'm gonna do, I'm gonna be switching back and forth to the code and the demo. I might as well just do it like this, let's see. So the first thing I'm gonna do is that this is my,
12:00
so at my top level route of this is called emberconf.hps. And I had an outlet before between a header and a footer component that I, this is just the stuff I copied off the website, right? I made an outlet. I'm switching it to a liquid outlet. That comes from the library. And that's not gonna change any of my behavior yet.
12:20
Well, it's gonna do one subtle thing. Let's take a look, see if you notice. So when I go to the next view, I have one little subtle bit of motion. My footer's going up and down. So that's the first observation about what we're doing here. One of the tricky things about putting animation into your existing applications is the management
12:40
of context and flow in your document, right? No matter what kind of animations you're trying to put in, whether you're implementing them on the web animations API, my default one I use in this library is velocity.js, where you're using CSS transforms. A lot of these things work best if you are absolutely positioning your content.
13:02
But that's a real pain in the butt when you're just laying out your normal flows. You wanna be able to take advantage of all the kind of layout that you do normally in your templates in CSS. So the first thing you'll notice is that the liquid outlet is a smart container for us. It is actually not interrupting our flow at all.
13:20
You'll notice I was able to drop it in. I didn't have to change any style sheets. But it also has this behavior. It notices that stuff's changing inside of it, and it'll measure the before and after states and smoothly change so that I'm already being a little less jumpy. But it's not doing anything cooler yet. So the next thing we're gonna do,
13:44
go into my next change. Geez, I need to find a better way to switch between these. Can you guys see them okay at this size if I don't go full screen? Okay, okay. So, I can zoom in anyway. There we go. So the next thing I'm gonna do is
14:00
I'm creating a new file called app slash transitions.js and this is a conventional thing from the library. It's, so your transitions file, you can think of it analogous to your router map. It's intended to be a global place to gather up rules about how your application behaves. And this is a kind of important thing. You'll notice that I didn't go into
14:21
the liquid outlet that I added and set a bunch of configuration about how it should animate. I think that's the wrong place. Because that outlet, right now it might only be running these two routes, but as our application grows, we still wanna have that great experience of being able to refactor and understand and grow. And you can have very sophisticated reasons
14:43
for animating different ways at different times. Much more than you can express just by setting a few properties on that component. So that's why I came up with this idea of having a separate transition map that can let you lay out logically in a kind of imaginary physical space where all your routes and components
15:01
and views, how they relate with each other. So in this case, I'm using two constraints, a from route constraint and a to route constraint. And I'm saying, and then I'm saying what animation to use and in a moment we'll show you where the animations come from. So already we're gonna do better now, right? We're gonna fade nicely from one to the next. You'll notice that the fade happens
15:20
when I go from the list of all to the detail. It doesn't happen on the return yet. That's because my rules here are directional, right? I said that the from route has to be the speakers. So because this is, but because this is directional and because directional is a very common thing, we have a shortcut for that, right? We can swap it so that we now have separate things
15:44
for both the forward and the reverse. So let's see, now we go back and forth, okay. So the important thing here is that we have a way to declare separate from our content, and notice I haven't touched my templates. This was a totally stock application.
16:00
I'm beginning to add this behavior without polluting those templates with complexity, okay? Now let's talk about where that fade animation comes from and how it's implemented because this is actually one of the things I don't think people have appreciated, even some people who use liquid fire. So let's see, make it bigger.
16:27
This is the wrong one. There we go. Now let's do the simple one. Transitions. So I wanted to show you a kind of minimalist example of how you implement animations
16:42
because I think a lot of people, even those of you who might have tried out this library, tend to be using the handful of built-in animations that I have, fade to left to right to up. And that's great. That's what they're there for. But one of my goals is to get us to arrive on a very comfortable API where we have composable, extensible ways to define animations
17:01
and literally just drop them into Ember add-ons and you could actually write a cool animation, put it in an Ember add-on and publish it and somebody else could just import it to their app and put it in their transition app and use it. So this is an example here of a very straightforward fade animation. In this case, I'm using velocity, which is a pretty nice animation library
17:21
to do the actual animation. But liquid fire is not an animation library, really. All it is is a way to organize Ember applications and give you a place to put your animation calls. And so in this case, I'm using velocity, but that's not at all required. You can use your CSS3 transform here.
17:40
You can use your web animation API, just like the Polymer stuff we saw in that other talk. All those kind of things can go right in here. So your call, all it has to do is it's receiving a context that has things like the old element and the new element. They're both already in the DOM. The new one is invisible
18:00
and they're already absolutely positioned for you, based on where they're gonna end up in their final flow. That's a lot of the hard work of building one of these kind of behaviors is getting that all set up and that's really the point of what liquid fire is doing. It's getting you set up to do an animation and then letting you drop in something that's gonna do it. In this case, we're gonna animate the old thing to opacity zero and then once the promise resolves,
18:23
we're gonna animate the new thing to opacity one and that visibility visible, that's a shorthand that the velocity gives us to bring it visible at the start of the animation, so we don't get any flicker. So let's do the next thing.
18:41
So up till now, this is stuff people have probably seen if they've checked out the library, but now I'm gonna show some newer things. So I mentioned really wanting to be able to compose rich behaviors out of smaller pieces and I think now as we approach a 1.0 API, I'm settling out a much simpler way to implement this stuff. Here's an example of a new transition called explode.
19:03
Now explode doesn't by itself actually move things around, but what it does is it gives you the ability to then add basically to animate separate pieces of your page separately. We're gonna explode the old and new views. Pick new here means for the new view,
19:21
find an image and then use the two up transition on it and then the two left at the bottom is for everything else that didn't match. So now when I go over, that image, the final image, you'll notice it's coming up from the bottom. Let's slow it down so we can see it better.
19:41
I think that's my next commit. Yeah, so and this will show you that all of these animations, they can take parameters too. We pass them through. When you implement animations, they can just receive arguments just the way functions should. So now they should go slower and you can see a little better what they're doing.
20:02
So now let's take a look at, because we have this explode capability, explode is really, remember that every transition has both an old and a new element that we're comparing and explode is no different. So it can match up elements on the old and elements on the new. So let's switch to this new match by.
20:24
So it looks like this. I'm gonna say match by data speaker ID. Now that's just an attribute that I put on my elements where I've bound the speaker ID into the DOM so it's nicely accessible. And did I get a reload yet? There we go, right? So there's that hero transition.
20:45
Let's make it work both directions. So let's add the reverse. The reverse is very similar. We're still gonna explode match by data speaker ID, fly to your partner, use to, but we're gonna switch the underlying one
21:01
for all the background stuff to the other direction. So now we'll have it two way. And they're gonna match right up. So you notice I didn't do anything into my templates again. This is still stock. And so when I'm designing those, that before state and that after state, I don't have to think about my animation. I can go and add them afterward and I could refactor this whole layout
21:21
and as long as I still have those elements, they're still gonna match. There's no more work to do. So this fly to animation actually, it's implemented the same as that fade when I showed you. The point of it is just that it's gonna measure the initial and final positions of those elements and do a nice smooth transition across.
21:41
So after the great Polymer talk we saw showing all these transitions, our speaker Brian pointed out that why don't more people use this web animations API? It's really cool. So I said, yeah, that's a good idea. So I re-implemented my, while I was sitting in the back just now,
22:01
I re-implemented the fly to that API instead. And this is it. It doesn't really kind of fit on one screen. The web, it's actually kind of more verbose API than Velocities. And the biggest reason for it is that velocity lets you break out all the separate pieces of the transform property and animate them separately and it does the merging for you.
22:21
And in this API you don't. Also, I have to do the promise wrapping myself. But let's go just drop over to our transitions map. And instead of saying fly to, we could say web fly to. And yes, please save anyway. All right. Yeah, the reverse, well, one of them is going one way
22:41
and the others go in the other. Right, they're using different APIs in both directions. But they look pretty close actually. There's a little bit of subtle weirdness in the web API one just because it's using a different easing function than my background is using right now. Right, that would be easy to fix. But this is pretty good for doing it in like 10 minutes in the back of the room. Right?
23:09
Yeah, so let's do some different things now. So, so far I showed you one liquid outlet. And that's an example of a template helper that is,
23:20
you always have some topmost thing that is stable. Right, that's kind of your pivot point that's gonna let you be able to animate it all. There's some topmost point that is the entry point for all the things below it that are gonna move around. Sometimes it might even be like the whole page. It might just be your topmost view. But there's always one. And so liquid outlet is one of those.
23:40
And here I'm inserting a liquid with which is another. Now all of these are named analogous to the built-in helpers in Ember. Outlet, with, if, we'll get to those. And they have the same basic semantics. The point of liquid with is, you can actually think of this, you'll see that it's right here, it's using the block param syntax
24:02
to yield up current model. Liquid with model as current model. Now this is using really nice new stuff that the block params unlocks for us. You could think of this actually internally as it runs in each. It's gonna yield more than once with different versions of that model as they've changed. That's how we get multiple things in the DOM together.
24:23
So by wrapping our list, so the model here, this is our list of speakers, right? The model is our list. By putting it in a liquid each, now I'm gonna have the ability to target that list for animation. So let's jump up to the next commit. And, oh actually this was me changing,
24:41
let's see, was this just the reverse slide too still? Let's see what we have. Oh there we go, yeah. I didn't show you the rule yet. I skipped that part, let's go. So we need a transition rule to, actually I think I've skipped ahead. That wasn't supposed to be so cool yet.
25:06
Yeah, okay, I don't know. I guess it's cooler than I thought it was. I thought I was gonna do an intermediate one that was more boring, but we'll go right to the cool one. So yeah, and these guys, so all I'm doing here,
25:20
when I click shuffle rate, all I'm doing is putting on a new list that's sorted differently. And the liquid width is, because it's bound to the list, it's gonna say, oh this list is changing. I'm gonna hold on to the old one, keep it in the DOM, render the new one invisible, then delegate to the transition mapping service and say, I've got all this stuff,
25:40
do you wanna animate it? And so in this case, the transition rule is this one. So here I'm using a different kind of mapping. This is not routes involved, right? I'm saying for a child of the speaker icons element, use explode, match by speaker ID,
26:01
and then fly to each other. So this is all the config it takes to do that thing. And we have this easing function here, that's why they bounce nicely. This is just the syntax Velocity uses to give spring values basically, so that when it gets to their final location, they bounce a little. Pretty nice.
26:20
Yeah, so let's show off one more thingy. So I mentioned that we have this interaction here, right? Where we can edit. Let's make that a little nicer too. So let's see. Now I don't know where I was in my commits.
26:41
I'm gonna have to just live code, huh? See, I was trying to avoid that. Okay, that looks good, well. Yeah, so here's the rule already that's gonna do it. I'm gonna write a transition for the liquid if helper.
27:01
So, and one thing I want to clarify, so all of these things where I'm saying when to do what, these are all constraints. In helper, to model, child of, route from, right? All of these are just constraints and a rule matches when all the constraints match. So in this case, if I'm in helper liquid if, and I'm going to the state true, right? The model in the case of an if
27:20
is the predicate you're passing into the if. If it's going to true, use up. If it's going from true, that's the reverse state, we'll use to down. And so then in the template, let's see, speaker details here. So before I had if editing, I'm just gonna do the liquid if editing, so that now this element will respect
27:40
the transition map, right? And it'll go find that rule. Did I reload already? There we go, yeah. So, mister, that's mister to you. So, that's the demo. So that's the point of the way we're trying to bake
28:01
this stuff in, so that it's not just a great experience for users, but a great experience for Ember developers. And so I'm very excited to be moving this toward a 1.0 API. I think I showed you these code already. Yeah, oh, and so that's the liquid if. And so here's my, oh, and I didn't mention,
28:21
there's one other project I did want to mention, which is called Ember Paper. That's a project started to try to give you out of the box components that have the Google material design features. It doesn't have a lot of the really rich, complicated motion stuff that I was showing, but we'd love to get those all together and make it actually work for people
28:41
who are interested in doing that kind of stuff. It's a cool project, you should check it out. They have some really neat, already have things like inputs and radio buttons and buttons that have those nice behaviors where you see the radiating action out when you touch them. Definitely check out the material design spec, like I said, it's worth reading in detail. And definitely check out LiquidFire.
29:02
I'm really excited to have people contributing. We've had really great contributions already, and it's wonderful to see people filing issues, fixing issues, it's great. So I would've actually said, a few days ago I would've said that I think I knew exactly what the 1.0 API was and that we were done and it was ready to go.
29:21
But Glimmer is really exciting. It's actually gonna unlock some newer things, I think, that might let us simplify even further and be able to possibly cut down the number of different kind of helpers you need to just one. So watch for great things before we do the beta in June, before we hit the 1.0.
29:41
And I hope you try it out and I hope you contribute. Thanks.
Recommendations
Series of 34 media
Series of 12 media
Series of 14 media
Series of 6 media