Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
I'm gonna talk today about style guide driven development on a project that I've been working on at pivotal labs how many people here have done test-driven development Oh awesome so a whole bunch of you do you mind if you haven't done test-driven
development raising your hand I see a few ok so basically and this is gonna be my summary of test-driven development because from what I've seen so far everybody that I've ever asked about it comes up with a different answer for exactly what it means
but the rough idea is how do you work incrementally and write tests that are going to figure out whether you're on the path to getting your code to do what you want it to do or not and then how do you then later use those tests to to make sure that your
code still works when you make other changes and that sounds fantastic but sometimes it kind of works with CSS and other times it doesn't really and so in my project we came up with something called style guide style guide driven development which I think
the pivotal labs New York office actually sort of started using that term first and I'm not even really sure where they got it but it's been working out pretty well so I want to tell you a little bit about it I'm sewing to talk about a few things
first the goals the challenges our plan how we execute it on it and the results that we got and it gets super important to focus on results because it's something that's really the right approach then it has good results so our goal was to reskin the
site to match some new branding we had this site which was you know very heavy and was loading super slow and generally weren't happy with it there were a bunch of things that that just weren't right and the designers really wanted to change it too
these were the sort of intermediate designs we came up with we had a two-phase project the first one we called we called B flat because we knew that we weren't going to get to do a huge change in the way any of the UX worked we just needed to flatten things
out and get some of the excess UI stuff out of there and then very shortly after we did another redesign which this is what we ended up with basically we didn't know for sure that this would be such a different design when we were going through it but
even still the component system that we built and the style guide really helped us get through two major redesigns in something like three or four months so the challenges there were a lot of them actually first there was so much CSS 91% of it unused but on
a standard page it was like 314 KB uncompressed it was not so much slowing the page down I mean that was part of it but it was just really unwieldy to work with we had custom CSS per view it's a rails app and rails really wants to encourage you to write
CSS a separate CSS file for every single view that you have in your app and you kind of have to fight it to get it not to not to have you do that source CSS tended to be either deeply nested and specific and so not reusable at all or it was extremely global
almost impossible to know the scope and where it was used and what in fact you'd break if you changed any of it we also had a problem with layout proliferation layouts and rails are your sort of top-level templates that your starting points for your app
it seemed like for basically every single page we had created a new a new starting point layout even though they weren't actually substantially different what tended to be different in them was actually the content area and when we would make changes we've
quite frequently forget that we had another layout for you know some random page and end up with end up with one of our layouts being broken because it wasn't up to date we also kind of had partials inception someone on the team before we all started must
have really loved creating partials we had partials for things that weren't shared anywhere we had we had like nested layers like each partial would have like a line or two in it and then it would point to another partial a line or two and it would point
to another partial you get like 12 deep before you could finally see anything about what was going on in your partial we also had a sort of more buttons more better philosophy we had like 20 or 30 different kinds of buttons different sizes you couldn't
and always see that they were different they look like the same orange button but actually they were you know pixel difference or they looked exactly the same but they were actually coded twice and so you'd end up with extra images because of course everything
was done with images it didn't have any css3 so it's really hard to change designers would ask for what should be a simple thing like I'd like to update the button styles for the small green buttons and we would give them estimates like well that'll
probably take a week which is just not the amount of time it should take to change a button style over we also had jQuery soup and a lot of it everything was these custom widgets and one-offs setup on the page rather than reusable we had like six different
ways of toggling something which just seemed a little bit crazy we've also put our frameworks in our assets file which in rails that's where your own code is supposed to go which meant that people felt like it was ok to change them because the Heron
assets and so we end up with like all these different frameworks all in assets and slightly modified from their originals so basically impossible to upgrade we also had a sort of epic stories that were sort of difficult to estimate they give us a story that
was along the lines of redesigned the marketplace page and we're like yeah that could be you know that could be a few days or that could be a few weeks it's super hard to tell how long that's going to take we also had a crazy deadline constraint
we had about six weeks and the design wasn't complete when we got started basically our PM was supportive but at the same time he knew that we had to get the first version of the site out and he basically said I need to see some progress by January first
and if I don't then I'm gonna have to call the project off and we're gonna just have to you know reskin it whatever we have to do whatever crazy terrible CSS we have to write and I was like no no please give me time we're gonna do it definitely
didn't want to write more crazy on top of the crazy that we already had it was a little overwhelming the constraints were pretty tough so we started thinking about how to get there we know what we wanted to look like what we have was too fragile and brittle
to really get it there incrementally so what did we want to do we basically decided that we needed to build components and start using style guide driven development to sort of rescue our project from the the chaos that had gone into I should mention as well
our velocity was really low we were having trouble releasing features which is something that happens to teams when they get into a place where their front-end code is really messy it gets really hard to get something new out because you're having to work
around all this legacy to get anything released and some components helped us structure the site and now I'll give you a little demo and this style guide is actually live on the web so you can check it out I will tweet out the link later but it's at
console run pivotal do and it's slash style guide and we decided to build on top of bootstrap mainly because the product wasn't defined yet we didn't know exactly what it was going to be or what it was for the designers were still doing a lot of
user testing and still figuring out like why would somebody use this it's a tool for the product that I work on is a tool for being able to scale cloud applications adding instances and and things like that being able to check the health of your system
and make sure that your your apps are running well and that they you know being able to change different setup of them live and on the cloud and so it's a funny product to be working on because a lot of people who are going to want to change these things
[ ... ]
Nota: se han omitido las otras 4.121 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.