Upgrade to Pro — share decks privately, control downloads, hide ads and more …

La relación entre diseñadores y programadores

Avatar for Fede Isas Fede Isas
November 22, 2013

La relación entre diseñadores y programadores

Avatar for Fede Isas

Fede Isas

November 22, 2013

Other Decks in Programming

Transcript

  1. ¿QUIÉN SOY? • Desarrollo sitios desde 2008 • Frontend y

    backend (full stack) • Lic. en Adm. de Empresas • Antes: Cinemaki, The UX Department, Kalidoscopio, TercerClick, Freelance • Ahora: The Industry
  2. AL PRINCIPIO… • No había diseñadores • Interés académico •

    Los programadores “diseñaban” interfaces para su software • Todavía lo hacen…
  3. PROCESO USUAL 1. El cliente expone sus requerimientos 2. Los

    diseñadores hacen propuestas, hasta que el cliente aprueba alguna. 3. El programador se lleva el PSD para implementarlo en HTML/CSS.
  4. POSIBLES SOLUCIONES • Comunicación • Equipos en diferentes países, con

    diferentes horarios y diferentes idiomas • Todos preguntan todo: nadie toma un paso sin consultarle a cada uno de la cadena
  5. LA BRECHA ES EDUCATIVA • Los programadores DEBERÍAN tener nociones

    básicas de diseño • Los diseñadores DEBERÍAN tener nociones básicas de HTML, CSS, browsers, etc.
  6. MAQUETAR ES PROGRAMAR? • Hay una discusión técnica al respecto.

    • Son lenguajes de representación de datos HTML Markup
  7. HOY ES MAS FÁCIL MAQUETAR Los browsers cada vez están

    más adheridos a los estándares de la W3C
  8. TIPOGRAFÍAS 1. Websafe fonts: Times New Roman, Arial, Helvetica, Impact,

    Lucida Sans, Lucida Grande, Tahoma, Verdana, Courier New 2. Flash: Cufon y sIFR 3. CSS3 @font-face: EOT, WOFF, TTF, SVG
  9. TIPOGRAFÍAS • Google Fonts: gratis, rápido, fácil, 629 familias •

    Adobe Typekit: muy barato, rápido, fácil, 936 familias
  10. TIPOGRAFÍAS • Tus propio TTF: probablemente ilegal, difícil de implementar,

    no anda en todos los browsers, más lento porque tu server hostea la fuente
  11. IMAGENES • JPG (baseline optimized o progressive) • PNG cuando

    necesitamos transparencia • Remover metadata
  12. IMAGENES • Un buen CMS debería proveer imágenes en el

    formato y tamaño que las necesitemos. • Si vamos a usar muchas imágenes chicas, podemos ponerlas en un sprite (por ejemplo, iconos)
  13. IMAGENES • Multiples dispositivos, multiples resoluciones, retina display. Problema aún

    no resuelto. • En algún momento (un par de años) tendremos un estándar de la W3C: <img src="fallback.jpg" srcset="small.jpg 640w 1x, small- hd.jpg 640w 2x, large.jpg 1x, large-hd.jpg 2x">! ! • Por ahora: Javascript para <img> y CSS media queries para backgrounds
  14. LOREM IPSUM DOLOR • El contenido de relleno no siempre

    guarda relación con el contenido real • Los diseños muy ajustados se rompen fácilmente
  15. FUNCIONES PRINCIPALES • @extend: heredar clases • @mixins: funciones en

    CSS • @variables: $este-color puede cambiar • @imports: separación modular de archivos
  16. FRAMEWORKS / UI KITS • Armados por líderes de la

    industria • Permiten arrancar rápido con prototipos • Sirven para aprender best practices y seguir programando en la misma línea • Modulares
  17. KITCHEN SINK / STYLE GUIDE • Ver TODOS los elementos

    de UI al mismo tiempo y como funcionan entre ellos • Hacer pruebas rápidas • Separar el código del backend que generalmente ensucia
  18. KITCHEN SINK / STYLE GUIDE <a href="#" class="button success radius”>!

    ! Enviar! </a>! ! <a href="{{{ route("contact.store", ["id" => $player- >id]) }}}" class="button success radius" data-submit data-status="{{{ $player->isActive() }}}" ng- class="{ success: player.active }"> ! ! Enviar! </a>! • HTML antes de la implementación con el backend • HTML después de la implementación con el backend