How's the sound? Can everyone hear me? Hi, my name is Bridget Warner. I decided to

illustrate my talk because I wanted to appreciate where Ember had come from and how far it had come, and I think there are a lot of, there is a lot of value in legends and storytelling, especially in a community that's growing, to look back and see what it used to be like.

We also have this as a common practice in development already. We reflect on the story of our code and why things were written the way they were, and we also do retrospectives where we prepare ourselves

to look toward the future by seeing what we've done already. So I work for a small company in Baltimore, and me and my pens came all the way out here to Portland. I also brought a cold with me, so I apologize in advance, but stick with me.

This could be a fever dream more than anything, but hopefully it'll be fine. We also have a Baltimore contingent here, so that's very exciting. So I work for a small company called Alaview, based in Baltimore, and I'm a former teacher

that came into development from there, and we also have some other former teachers from Baltimore here, too. So once upon a time, as these stories always began, and in our case, though, it will be specifically in September of 2014,

so if anyone remembers where Ember was at during that time, so Alaview wanted to solve really big problems, specifically in an area of school finance and spending on students.

There's a huge lack of transparency and equity in funding right now for schools, and so we wanted to build something that would help bring more equity to the way that we fund schools, and in order to have that happen, we have to do something to make it more transparent, and so the heroine of the story is going to be Ember Ella, because why not?

And don't just think of this as an individual person. She is representative of an entire team of people that have been working on this product.

She lives in the kingdom of Emberdom, where we have City Hall setting state on our park, and we have our route, which is setting the model on City Hall, and we also have our route, our steel bridge, our route loading Mount Hood, and

I know this is now deprecated at the time of creating this app. We still had this concept of a view. Now, because it's Ember Ella, and she has an evil stepmother and evil stepdaughter, or stepsisters, she was not allowed to work in their very nice co-working space. She had to work from home

from her office hearth, which is full of cobwebs and very ashy,

but that's okay, because she loved what she did, and she was setting out to build something very ambitious. So what Balance needed to do was show thousands and thousands of lines of school financial data, and the best way to go about this was to show it in a table form

to keep it organized and semantic. So there were four things that it really had to do. It had to render quickly. It had to be sortable. It also had to be filterable, and it was really, really important that it was semantic as well.

Part of building a product for school districts means that it needs to be what is called Section 508 compliant, so it had to be a table form and not a huge collection of divs, so it's much easier to be screen readable. And so, because we're in Portland, we built this table out of reclaimed wood.

Well, the reality is it looks more like this kind of table, and so the desired table was going to have thousands of rows that you could easily see, and

this is built on top of a Rails API, and it's also using Ember data. So we have our seeds of our idea. We know exactly what we want to build, and we're choosing the tool

we're going to build it in. Because we're building something really ambitious, we chose to use Ember. And so once we planted those seeds and created the version one of our app, we were super excited to see what it would become. And version one in our case was this shiny, amazing

gourd instead of a pumpkin, because yet again, we're in Portland, and we have heritage gourds here. And it was so exciting and so shiny, and we knew that this was going to do exactly what we needed it to do. Okay. This is definitely going to get us to the Ember ball.

However, something strange happened. When we were rendering only around 200 rows, it was taking us six seconds, which is unacceptable. Something that should have been

quite easy to do was not working for us. And so what was going on? We had some deceptively simple HTML. Just a typical table with a table header and our rows full of financial data. And for school districts, it's not just number of rows. There's also a whole bunch of columns,

because you have to have different budget lines with not only the available amount and the spent amounts, but encumbered amounts, which means that the money that's committed to other things. So, this table had to show a lot, and

if you'll notice, something is lurking here. And if you guys were using Ember back in fall of 2014, you'll remember exactly what this was. And these were wicked, wicked fairies, and they were called metamorph script tags, and they were everywhere. And you couldn't get rid of them. They were just all over your table code.

To the point that was almost unreadable. And so now that we're looking under the hood of our of our app, it doesn't quite look exactly what we thought it would be. Because back in September of 2014,

we were using 1.6.0. So this meant that we were still using the metamorph.js library, and we were using blank script tags to carry metadata for our handlebars templates. So rendering all of these rows was very, very slow.

So, because Emberella is not to be daunted, she is going to find a way to make this work.

It's unacceptable to have six second rendering times for the table. So we're going to bridge from the six seconds to something like one to two seconds to render, using just some simple pagination of all these table rows. There were some concessions though. We could only show 50 rows at a time, and this meant that because we had

thousands and thousands of rows of financial data, that we had to show hundreds of page links. And because it took so much time to render all these page links, we had to use a couple hacks. So the two necessary hacks, and this will be the only time I show a little bit of code,

one of them was so that we could... Side note, because our team is from a Rails background, you will see CoffeeScript. So version one of the app was written in that.

So a whole bunch of code, just so that we can only show ten page links at a time. And so this cut down to just fractions of milliseconds, the amount of time it took us to actually show this. So we had to have offsets so that as you were to the extreme of the lower end of the pages, and then you got to the top of it,

it would actually always show the same number of page links, and it would also show you your last page and your first page links as well. The second hack that we needed to do was because if a user was, say, on page 400, they had gone all the way through, and then they added filters that could drastically cut the number of data

rows that they're actually looking at. So what we had to do was, in one of our routes, write this little transition to that would keep track of the max number of pages, and then if a user filtered for something and dropped down to just 10, it would actually transition them to page 10

instead of leaving them on page 50, or page 400, which had no data in it. So those two hacks were kind of acceptable, but we were still fighting for every single millisecond we could. We were using Ember Inspector and the Chrome

developer tools to their fullest so that we could get this to be as quick as possible, because when we're in our development spaces, we take it for granted that we have pretty good internet most of the time.

However, in these school districts, they don't always have great internet. It cuts in and out, and sometimes it's not fast enough to be able to load things that are JavaScript heavy quickly. So we were super happy when

Ember 1.8 was released. This was on October 26, 2014. So we jumped on it, and we celebrated. We were able to upgrade to this, and I'm sure many of you remember why this was such an exciting release, and for us

it was because we got this really cool new engine called the HTML bars. Rendering engine that would let us render all of our rows without all of those metamorph tags. So instead we would actually have DOM nodes instead of strings of HTML.

So now at this point, we're rendering four times as many rows per page, much, much more quickly. And so now our gourd is really cruising.

V1 is off to a great start. It is moving so quickly at this point, because now we are launching with our first school district, and then our second, and then our third, and we have users that are using this. And it's actually rendering fast enough for them. It's rendering quickly enough that

they are super excited to not have to use these legacy databases that they had used to look at financial data before, like Munis. And so everything's great. We make it to our Ember ball. We're having a great time. We are doing user testing. We are

using analytics to see how the app's being used, checking up on speed. Everything is going great. Our school-based and our district-based customers are super happy. They can look at so much financial data so quickly

that they have no qualms about being able to stay in greater communication with their faculty and also between principals and the districts, which means that because they have access to their data in real time, they can make smarter spending decisions.

And so we're already moving toward that equity because it's starting to reveal differences in how different schools are funded. However, as you all remember the story, we've hit a snag.

We've left our glass slipper on the steps. We've gone home. And what could this snag be? Well, all of a sudden, we're seeing this error pop up again and again and again. It's some weird,

unknown bug. It's always type error, undefined is not an object. And when we use the app the way we think the users are using it, there's no bugs that are showing up in the console. We can't see anything that seems broken. We cannot figure out what is going on. And

at this point, it's starting to become noise. But, Embarella has a hunch it might be something, and it's sort of a facepalm moment. Not, you're hoping that it might not actually be that, but oh yes it is. It is the users

using the back button to clear out filters. So whenever they add filters to their data, instead of using these large friendly X's that we have to remove them, they are using the back button. And because the way we'd set up the filters, was using a hash of filters, because they were all grouped in different categories,

it was removing it from the URL, and it was also removing the filter from the data so that it was rendering correctly. However, it was leaving these filters in the DOM, and so visually it looks like the filter was still applied.

Which is super frustrating to the user, and so they would end up in this dance of then trying to X out the filter and use the back button, and it wound up causing the app to get into this endless cycle and eventually just freeze. And that was the cause of the error, was the back button. And so

this isn't so surprising when you are talking about people that are using an app that are

principals or at the district official level. It's a different generation than a lot of people that are in tech right now. And so you have to remember that these are the same people whose biggest feature that we shipped was being able to print the tables.

You have no idea how much they asked for and how excited they were to be able to print. Because even though they could look at this data at any time, they loved being able to print it. So knowing that, you can understand why they loved using the back button. And that's totally fine. We had to meet them where they were at. So

we decide instead of making incremental changes, we are going to completely redo this app. We're going to rewrite it from scratch, because why not? We are going to do a version 2, and version 2 has to do a couple things now.

It needs a way to keep track of state, so that the DOM is always going to reflect changes triggered by the back button. Also, the redesign is going to have to make filtering a lot easier. So that even if they still use the back button, it's more appealing to actually edit and delete the filters on the data.

And then, just to throw another wrench in there, we decided that we were going to have infinite scrolling instead of pagination. And on top of that, the infinite scrolling would also have to be matched up with a bar chart of

columns, and so they always needed to be in sync. That is a story for another day, because it's still in progress. And so, even though this would have been an opportunity to use a different framework or

library, like Embarella's glass slipper, Ember continues to be a great fit for us. The release schedule, release schedule, the continuous improvements by the core team, by the community, meant that we decided to stick with Ember. And because you don't want to change too many things at once,

we stayed with 1.13 while we were doing the redesign. So we are very much looking forward to Glimmer 2, because this will be huge for us to be able to render the tables even faster.

And so, as our app continues to evolve and we can look back at how far we've come, the same I'd like to think about for Ember, as well, and our use of it.

So now that we are at the close, the state of where we're at now is that we have an app that's being used by school districts across the country, all the way from this coast back to the East Coast and in between. So it's being load tested by hundreds of users,

school districts everywhere, and Ember has performed beautifully. We're rendering billions of dollars in school financial data, and I believe, as of this talk, we have the largest collection of school financial data in the entire world right now, and Ember is handling that.

So it's a good thing that we chose something ambitious, because it's only become more ambitious, and I wanted to take the end of my talk to thank everyone that's been working on it, because it's been part of why we've been successful, a huge part, and I wanted to recognize

how all of these improvements have a very real concrete effect on the people in the community and people's ability to build really cool things that are designed to make this world better. That's the conclusion of my talk. Thank you for listening. You can follow me on Twitter at Bridget Warner, and

if you have any questions, I'm happy to answer them. My name is Lisa. You mentioned that you did a lot of user testing as well, like to find out the thing with the back button and stuff.

So I would be interested how you like combine Ember and user testing, because like we have some same issues like finding out how people use our application, and if there is something you use especially for that. For the user testing? Yeah. Yeah, just a simple

small script, just a few actions, open-ended actions we want the user to be able to do, and then we just turn a computer camera and film it, and then the whole team will watch the video later, and it has really surprising insights, things we never expected.

Never in a million years could have predicted that the user would have used it that way. I also think that what's been really useful for us is using Mixpanel. So if you're familiar with Mixpanel, it lets us do analytics on specific user actions, and so we look at that really, really closely.

One of the surprising difficulties in the app was users being able to log in, remembering passwords, and so we saw, once we started tracking failed versus successful logins, we were able to make some changes that made it much easier for them to log in,

and you can actually see with that data the improvement, so that's also a good way of tracking. The way we caught the back button error was using bug snag, and then seeing that come through a lot, and sometimes the last thing is I try to do stupid things to the app, things that make no sense,

clicks that aren't really doing anything that I can think of, but if it's possible to do, sometimes it can lead us into really interesting, weird things that, and trigger bugs that we can then identify. I keep thinking of examples.

I apologize, last one. Some of our users were, we didn't know what this bug was coming from. It was another weird one. They were saving the app to the desktop, and then double-clicking on the app, the HTML on the desktop, and loading it, and it loads it so it looks like it exists,

but it's just, yeah, so you know what I mean. Anyway. Thank you. All right, if no one else has any questions, thank you again.