Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
so it's kind of awesome to speak for John because he really gave me a chance when I hadn't spoken anywhere and he had no idea if I would turn out to you know stand up on the stage and go or if I would actually be able to speak and took a bigger chance
at letting me talk about something which was kind of off the original agenda so very grateful about that and and um kind of life-changing moment there but I was not a Java programmer when I met him I was a carpenter so small adjustment um so today yes I'm
going to change up my topic a little bit again because as often happens I'm generally speaking super-excited about something that's going on right now and you have to propose talk topics much in advance and it doesn't always correlate so this is
going to end up being kind of a mishmash of some sass stuff and some style guide stuff and some process stuff at some point I didn't actually think that process was very important I thought that if my code was awesome everything was awesome and that and
that was about all there was to it and then after sort of refactoring lots and lots of you eyes we seem to my company now we seem to end up with really gnarly CSS and and cleaning it up and so we've done that at a bunch of different places Facebook Salesforce
Adobe PayPal we worked with a lot of big companies to do some really cool UI reef actors and over time I guess I realized that an important part of it was actually the process that we were going through and the human issues that we were solving at the same
time and how that related to the code issues that we were seeing I'm going to talk a bit about that today and I'm going to also talk about how some of the ways that we use sass and handlebars and some other tools to make the process a little bit smoother
about six months ago I hired a couple of just so amazing developers I'm really really happy to work with them and we just started fixing things so whatever was the biggest pain point that at that moment we'd fix it and then whatever was the biggest
pain point once that pain point was gone we'd fixed that to we spend sort of iterating on our process and we're far from having it perfected I think there's oh maybe we'll always be working on it but we've come up with some ways of using
sass and some other tools that do seem to actually be working for us so this is a old-school kind of style guide from 2007 I believe so this is the the sort of version of a style guide that I want us to move away from this is the like PDF tome that gets sort
of delivered and worked on over and over and says do do this and don't do that it'll have things like exactly the positioning and the sizes of the logo and the space between the letters of the logo and the and the actual little triangle thingy which
sounds like a good idea but in the web this is usually a foregone conclusion this is usually already something that's decided there's an asset for the logo and you don't mess with it for the most part so it's not overly useful also not so useful
for the web is how to put the logo on a hat right this is beautiful right it's their color palette so it's got the warm colors on the left and the cool colors on the right it seems really pretty and I like to look at it but it doesn't help me know
if I'm allowed to use that bright yellow for type or if it's only meant for backgrounds or if it's only meant to be used in gradients so it's a little bit too too vague for being something for developers to actually use the same for typography
um this is more of like a work of art you know it's great to me that the thesis typefaces warm and intuitive but as a developer I don't care I just need to know what type do I need to use what are my choices and how do I stay within the boundaries
and respect the design that's already been put forth so why don't these style guides work for me they don't work because they take months and months to produce that's that's huge the web is constantly moving our projects are constantly
moving in six months the styles are going to have changed from what they were now so if it takes six months to produce a guide like this it'll be out of date before anybody ever gets it the other thing is that they tend to be designed Trek and kind of
exclude engineering from the equation they're not a great way to have to have a partnership between engineering and design so I think that we need to kill that type of style guide and that sort of vision of what a style guide can be so that we can have
a leaner and sort of more effective version emerge we believe in living style guides and that's sort of a term we made up so I'll tell you a little bit more about it a living style guide is a guide to the existing site Styles it's not some esoteric
don't we really wish our Styles were kind of like this it's a guy into what the Styles really are on the actual site the other thing is that it lives in code it has to live in code you need to use the same code to generate the style guide that you
use to generate those same components on your site because if you do that the style guide never gets out of date unless you have components that are getting out of date and that tells you something about what's going on with the site and then again collaboration
tool for engineering and design teams to work together it really matters that we have a space where we can talk about design decisions that isn't in the feature because in one feature it might feel like the right thing to do to choose another shade of
grey for your dividing line but if you make decisions like that over and over and over again you end up with a bunch of incoherent designs and you end up with CSS or SAS that doesn't make any sense at all and that's really hard to work with so good
style guide will lead to a better UI code more informed design choices and then as well a better performing site this is what we've seen over and over again is as we refactor UI and give a sets of styles for developers to use to build new pages the site
starts to get cleaner little by little right so often we have this sense that we're on this path where with time the technical debt is piling up and piling up but if we have a style guide in place and we have pieces LEGOs of functionality that we can use
without having to reinvent more sass or more CSS then we can end up with being able to build features without having to add code so this project that I'm going to talk to you about was a collaboration with Trulia they called us I think it was last year
sometime and asked us if we could help them do a retake on their UI they were starting to notice that they weren't able to release features as fast they had some inconsistencies and they wanted some help figuring out how to do it their team is so good
I have to say most of the places that I end up working with there's somebody that has been trying to do a style guide for a while has even made a start on it and even maybe has some of the components that they need but they've never gotten the support
or the time to actually make it a reality it's hard to do internally their features their pressures priorities change this is something where you really have to dig in and like build a substantial portion of the components required to build out a UI because
if you don't then it's going to be really easy for people to say oh what I need is never available in this style guide I'll just go back to doing it the old way um so yeah people often try internally to to make this work and it truly a few developers
had been real and designers as well had been really interested in creating a style guide and there had been a few internal attempts so they were super excited they were motivated as well to switch to SAS which made it a really fun project and they had enough
legacy and technical debt that it made the whole thing worthwhile from a performance perspective as well as from a team efficiency perspective so this is a this is a image that one of their engineering managers sent to me his name is Luis and it says I've
got the blues and the reason he sent this is because each one of those blue links is actually a subtly different color of blue color pick errors you know people didn't know or they were making decisions in various contexts and they're basically ending
up with the blues if you will and so this is part of what motivated them to really want to be a part of the project our typical flow works like this we've done it over and over again and it seems to work pretty consistently I'm not going to say every
project we've done is a success but the vast majority have been so we break it down like this first we do a visual inventory which is all about finding out where are we at now what do we need to know what do we need to analyze what data do we need in order
to make decisions once we have that information we kind of rationalize the styles so even though the site has 50 different shades of blue we're not going to build all 50 we're going to help the designers to make some decisions about which they want
in which they don't want though I think it helps that were not particularly opinionated about their choices as long as they choose you know less numbers they can choose whatever blue they like and then finally we build out an actual component library based
on all of those choices and so they get a substantial portion of code which actually fits with their new code standards which actually doesn't have the kind of duplication and it kind of switches the momentum I guess of the project and of the the code
that they're working on over to something that's going to be more efficient the final step is deployment and that's something that the team actually participates in pretty heavily and we'll talk about that as well which is you know once you
have a component library do you just like release it to your entire site at once or how do you manage rolling that out so like I said the visual inventory is about finding the right data to make the decisions that you need to make in order to refactor the
UI well um a funny thing happened actually I was talking about about learning how to use sass and and my sort of misadventures into using sass at Airbnb last year and a guy came up to me after the the talk and he said when are you going to do a talk about
switching back to CSS from sass when your sass gets messy and I was like what I mean I kind of didn't understand where he was coming from with that and so I said to him well when you were switching to sassed you cleaned up your CSS right like you you actually
refactor it and he said well we didn't exactly have time to refactor it so we just converted it and started writing sass and time and you're shocked that that didn't turn out well um you know not having architecture it actually doesn't matter
[ ... ]
Nota: se han omitido las otras 5.576 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.