RubyConf 2015

Mejora tu creatividad como programador Ruby

Louisa Barrett  · 


Extracto de la transcripción automática del vídeo realizada por YouTube.

- So, hi, I'm Louisa. I'm on Twitter, @weesie_b, and I'm from Colorado so I have to use mountain pictures everywhere I can. So, I'm a developer and a designer at Haught Codeworks and we're a small consultancy based out of Longmont, Colorado. And I'm a chapter leader for Girl Develop It - Boulder.

Woo! And then, before we get started, I just wanna really quickly run through how I've set up my slides. So, as you may know, we are in Texas right now and Texas has some famous cows. And cows need cowboys, and cowboys ride horses. And horses are a lot like ponies.

And I drew a lot of ponies for my slide deck. So, now that that's taken care of, we can go ahead and get started and talk about design. So, unlike the popular perception of what design means, it's actually much bigger than the elements to come together to form what we typically associate with visual design.

So, typography, color palettes and layout. I think designers often get a bad rap for being overly sentimental about these things. And even though they may have a slightly unhealthy fixation on letter forms, these elements really are just details of what a designer's job is and don't encompass the full breadth of what design is actually all about.

So, at its core, design requires the ability to take a set of restrictions framing a problem and find the best solution within those limitations to maximize impact, usability and engagement with users. So, design is all about people and it's about how the things those people need actually work.

So, has anyone here every built something that was super cool but then turned out to be pretty challenging for the people that you shared it with to use? I know I have. I have, it's happened. And maybe your app was so challenging to use that those people just didn't use it and they just didn't understand something that, from your perspective, made perfect sense.

And that's a pretty frustrating experience, right? It's not fun to have something you've put a lot of effort into not really be appreciated or understood. But there's a silver lining to going through that because it is actually a great thing to have experienced.

So, going through the process of seeing first-hand what happens when someone doesn't understand or relate to your thought process and then, by association, doesn't understand your product means that you've taken the first step. And welcome to design. So, it's a glorious place where you get to build cool stuff by figuring out how to make things that are relevant and useful to other humans.

So, clearly, the code that you write is important when you're building software, but design is just as critical a component. And this is because products that offer unique and effective solutions to human problems that are also intuitive for users to understand and relate to really set themselves apart from the crowd of competitors.

So, how many times have you heard something along the lines of, "It's like Twitter for cats," or, "it's Uber for dog-walking"? And this is because coming up with original ideas is really hard. And it's easier not to and, instead, just use established, successful products like Twitter and Uber as a starting point and then just tweak them enough to make them yours.

And this isn't always a bad approach, but what it means is that, if you can came up with something that's unexpected and better than those established models of solving users' problems, that it's going to really get people's attention. And creative design solutions are a major deciding factor in the choices that lead to those novel approaches.

So, since design and creative thinking is something that can be a big part of what sets you and your work apart from the crowd, how many of you consider yourself to be creative? Okay, awesome. Now, how many of you think of yourselves as designers? A few, okay.

That's good, a few. So, I really wanna help everyone in this room feel like they have the ability to be creative and then also to participate in the design process and to feel like they can make positive design contributions to their teams and their projects.

And so, on that note, I think it's a good time for a story. So, I went through one of Jeff Casimir's early developer training programs before he started Turing School of Software & Design and I have this very distinct memory of him telling our class that we were not allowed to use Bootstrap to build out the front ends of our projects that we'd be presenting at our demo nights because Bootstrap would, in his words, "Make it too easy to win.

" And he told us this a day or something right before the demo and it was followed by this sort of giant collective groan throughout the class because we really hadn't been learning about front end and Bootstrap would be a time- and sort of sanity-saving resource that we could use to make things look okay (laughs) while we were just focusing on getting our projects to actually work and then getting them successfully deployed on time.

And then, just like that, he just was taking it away from us because it made it too easy to win. So, chew on that for a second. We had spent months writing and studying Ruby and now we were building these Greenfield Rails apps in very short timelines and showing them to people who could very well turn into our employers.

And what, of all things, is Jeff worried about teams using to their unfair advantage? A tool that gives you just a little bit of help with very basic visual design. So, we were building complex back end systems and that was what we really wanted to show off, right? Why would getting some outside help polishing the user-facing part of the app be such an issue? He was justifiably worried that teams would use a clean-looking user-facing product to compensate for crummy back end code.

And he was worried that teams that only got the minimum project requirements completed would sway the crowd with a slick-looking front end while teams who went above and beyond with the back end, but had a less usable front end wouldn't get the attention from the community that they really deserved.

[ ... ]

Nota: se han omitido las otras 3.024 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.