Paco Viñoly, Designing in a Developer World, WarmGun 2013
Upcoming SlideShare
Loading in...5
×
 

Paco Viñoly, Designing in a Developer World, WarmGun 2013

on

  • 1,063 views

Designing in a Developer World: The Secrets Behind Working with Engineers

Designing in a Developer World: The Secrets Behind Working with Engineers

Statistics

Views

Total Views
1,063
Views on SlideShare
1,063
Embed Views
0

Actions

Likes
2
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Paco Viñoly, Designing in a Developer World, WarmGun 2013 Paco Viñoly, Designing in a Developer World, WarmGun 2013 Presentation Transcript

  • Hi. A bit about me. Presentation has two parts. 1. Case Study of a project I can’t show you but I believe captures the spirit of how we work at Square. This part will be fast. 2. Guidelines that illustrate how important the marriage of Design and Engineering is at Square. We’re still a startup. This may be a different kind of presentation but I hope it works for you all. Let’s start with a short video.
  • HOW TO DRAW A STRAIGHT LINE This is what I’d like to talk about first. It serves to illustrate how the most basic design task can’t happen without an engineer and how both sides work together and push each other to ensure the most perfect results.
  • Inevitable you will hear a presentation that talks about design being how you get from point A to point B. Instead of talking in broad generalizations I decided to focus on that specific straight line.
  • This is how I draw a straight line. Not very good, right?
  • If we go back in history, Cave-person drawings were not much better. Straight as an arrow had a different meaning back in 5,000 B.C. If we look at what they were doing it’s not bad given that they didn’t have rulers.
  • Egyptians got a little better. The designers of the great pyramids got a little help from the engineers.
  • who invented the plumb line and made one of the seven wonders possible.
  • y = mx + b then we get a mathematical formula for it with Euclid and all the theory behind that.
  • at this point you might be thinking, i got a plumb line. i can figure out some kind of saw. let’s make a ruler and get on with it. and this is where the case study begins. we obsess about the details and we want to make sure that we create experiences that are as simple and as transparent as possible for our customers. a ruler is just not good enough.
  • PRECISE a ruler is precise
  • ACCURATE a ruler is not accurate. we need to be accurate. there’s a whole other side to design at Square which deals with the Wabi-Sabi aesthetic or imperfectness, but that’s a different case study.
  • So, in the 1800s a french engineer named Peaucellier invented the Peaucellier–Lipkin linkage. The first machine to draw a perfectly straight line.
  • this is how the system works. finally we had an accurate line.
  • Then we got computers and this is how they draw lines There are a few ways to they do it. Bresenham's line algorithm — optimized to use only additions (i.e. no divisions or multiplications); it also avoids floating-point computations. this is where we get to present day at Square. we are developing a new interface that calls for a straight line. and we begin by questioning how can we make the best possible straight line. the engineers and designer sit side by side to make this happen. btw, i’m not the engineer so excuse me if i don’t do justice to their contribution.
  • 1   #html   2   .example   3      hr 4   5   6   7   8   9   10   11   12   13   14 html. this is option 1. we would do this 15 years ago.
  • 1   #css-­‐border   2   .example   3      .css-­‐border   4   ! 5   ! 6   .css-­‐border   7      border-­‐bottom:  1px  solid  black 8   9   10   11   12   13   14 css. then we did this. both begin to break down in certain scenarios, particularly when dealing with iOS retina devices.
  • 1   #css-­‐shadow   2   .example   3      .css-­‐shadow   4   ! 5   ! 6   .css-­‐shadow   7      box-­‐shadow:  0  1px  1px  -­‐1px  black 8   9   10   11   12   13   14 css box shadow. So to correct for this engineers came up with the css box shadow. is everyone following this? this is basically a 1 pixel line with a cropped shadow that comes close to recreating accurately in Retina, but not quite.
  • 1   #svg   2   .example   3      svg  xmlns="http://www.w3.org/2000/svg"  version="1.1"   4          line  x1="0"  y1="0"  x2="100%"  y2="0"   5   ! 6   svg   7      width:  100%   8      height:  1px   9      line   10          stroke-­‐width:  1   11          stroke:  black 12   13   14 svg. then this happens. this is a true 1 pixel Retina line. it is perfect and looks amazing.
  • #html #css-­‐border #css-­‐shadow #svg this is what we knew we wanted but we had to keep at it until we achieved the best possible result.
  • this is our case study and it’s going to be great, when i launches. :-)
  • designgineer s engaged engaged Let me be specific about how we get that done: The key takeaway from this deck is that design and engineering cannot exists without the other. Nothing happens without an engineer. They make it all happen. It’s about how to make the designs not only pixel perfect, but come to life like you couldn’t even imagine.
  • s s engaged - understanding kickoff the project with everyone in the room the days of waterfall methodology seem ancient to me. sit next to each other. design in code.
  • s kickoff the kickoff the project project with with everyone in everyone in the the room sit next to each other - methodologies are outdated design in code understanding kickoff the project with everyone in the room the days of waterfall methodology seem ancient to me. sit next to each other. design in code.
  • s s understanding - ! understanding define the audience, the goals and the metrics. performance is as much a part of the experience as is the photography. understand form factors and breakpoints design every state explain the core of what you’re trying to accomplish, not just your proposed solution.
  • s define the understand form audience, goals, factors and and metrics breakpoints design design every state - defend defend your design understanding define the audience, the goals and the metrics. performance is as much a part of the experience as is the photography. understand form factors and breakpoints design every state explain the core of what you’re trying to accomplish, not just your proposed solution.
  • s s communicatio n understanding Common Language - typography, styles, the grid. the framework for what you’re building. the system. - annotate as much as they need but no more. - know what ‘jank’ means, etc. - understand bugzilla, jira, etc., know how to QA and submit feedback
  • s framework the of what you’re building know what what ‘jank’ means annotate more than they need know how to submit feedback understanding Common Language - typography, styles, the grid. the framework for what you’re building. the system. - annotate as much as they need but no more. - know what ‘jank’ means, etc. - understand bugzilla, jira, etc., know how to QA and submit feedback
  • s s don’ts define the scope and stick to it. don’t compromise. don’t compress their timeline. don’t say it’s final if it’s not. understanding
  • s define the scope and stick to it don’t compress their timeline define the scope and stick to it. don’t compromise. don’t compress their timeline. don’t say it’s final if it’s not. don’t don’t compromise don’t say it’s final final if it’s not understanding
  • thank you