TUX2013 - La relación entre Diseñadores y Programadores

Nombre/es de Expositor/es: Federico Isas

Observaciones:

- Diapositiva 1:
Buenas tardes, mi nombre es Federico Isas. Hace 6 años que desarrollo sitios web. He trabajado tanto como desarrollador de front-end como de back-end. Soy Lic. en Adm. de Empresas, pero me divierte más programar que Excel. He tenido la oportunidad de trabajar con muchas empresas tucumanas, mendocinas, porteñas, formando parte de sus equipos o freelance. Hace 8 meses trabajo en un startup llamado The Industry.
- Diapositiva 2:
Si tuviéramos que escribir la historia de internet, una de las posibles frases para empezar sería: “Al principio, no había programadores”. Eran un montón de muchachos como el de la foto, preocupados por mandar mails de una punta a la otra de su campus universitario. Estos programadores “diseñaban” sus interfaces como podían.
- Diapositiva 3:
Background imposible, links invisibles, casi inusable.
- Diapositiva 4:
Cada módulo de la plataforma de AFIP tiene su propio diseño.
- Diapositiva 5:
El sr. Brin no sabe ni diseño ni html (Ni le interesa)
- Diapositiva 6:
En una consultora o sitio grande. El cliente puede ser también el product owner (CEO, investors, PMs, etc)
- Diapositiva 7:
Diferentes capacidades y conocimientos. Diferentes intereses.
- Diapositiva 9:
El diseño final muchas veces es imposible (o muy difícil) de implementar en HTML/CSS
- Diapositiva 11:
Esto es una diagrama de Gantt para organizar tareas y tiempos de ejecución, relaciona las actividades. Nuestro trabajo es un proceso creativo, por lo tanto, caótico.
- Diapositiva 12:
Escena clásica de Los Simpsons. El equipo comienza a buscar culpables entre ellos.
- Diapositiva 13:
Algunos opinan que el problema radica en que los programadores y los diseñadores están cableados diferente.
- Diapositiva 14:
Basecamp se llena de mensajes, 100 mails por día, miedo de tomar decisiones sin consultar.
- Diapositiva 15:
PROTIP: Para los diseñadores, aprender a maquetar es una excelente manera de incrementar su valor de hora.
- Diapositiva 16:
Muchos diseñadores tienen miedo de dar el salto, o directamente no les interesa programar.
- Diapositiva 18:
Aprender a identificar elementos semánticos en el diseño es clave.
- Diapositiva 19:
La console de inspección (Developer Tools) es muy útil para aprender cómo están hechos otros sitios.
- Diapositiva 27:
Podés cambiar de color y tamaño, sin tener que rehacer los sprites.
- Diapositiva 29:
SASS: http://sass-lang.com/
COMPASS: http://compass-style.org/
LESS: http://lesscss.org/
- Diapositiva 31:
BOOTSTRAP: http://getbootstrap.com/
ZURB FOUNDATION: http://foundation.zurb.com/
GUMBY: http://gumbyframework.com/
- Diapositiva 33:
El “kitchen sink” proporciona un playground donde diseñadores y programadores pueden hacer pruebas de diseño antes de la implementación.

Transcript

1. LA RELACION ENTRE DISEÑADORES Y PROGRAMADORES Federico Isas - @fedeisas - 22/Nov/2013 Tucumán, Argentina
2. ¿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
3. AL PRINCIPIO… • No había diseñadores • Interés académico • Los programadores “diseñaban” interfaces para su software • Todavía lo hacen…
4. SISTEMA UNT Volver a 1999. (background de antología)
5. AFIP Cada módulo tiene su propio diseño.
6. –Sergey Brin, fundador de Google “We didn’t have a designer and I don’t do HTML.”
7. 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.
8. Cliente (dueño de producto) P.M. Venta Diseño Program. EQUIPO & COMUNICACIÓN Distintos idiomas!
9. IMPLEMENTACIÓN Cuando por fin llega al programador….
10. El programador se encuentra con algo así… :-(
11. EXPECTATIVA VS REALIDAD El cliente se frustra PSD HTML/CSS
12. EL PROCESO ESTÁ ROTO Parece que es simple… …pero en realidad es así.
13. CLIENTE ENOJADO = EQUIPO EN CRISIS
15. 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
16. 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.
17. MAQUETAR ES PROGRAMAR? • Hay una discusión técnica al respecto. • Son lenguajes de representación de datos HTML Markup
18. HOY ES MAS FÁCIL MAQUETAR Los browsers cada vez están más adheridos a los estándares de la W3C
19. IDENTIFICAR ELEMENTOS EN EL DISEÑO Esa es la parte semántica de HTML h2 > a h3 h4 p img
21. DISEÑAR PENSANDO EN LA IMPLEMENTACIÓN Tips para empezar a usar hoy mismo
22. 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
23. TIPOGRAFÍAS • Google Fonts: gratis, rápido, fácil, 629 familias • Adobe Typekit: muy barato, rápido, fácil, 936 familias
24. 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
25. IMAGENES • JPG (baseline optimized o progressive) • PNG cuando necesitamos transparencia • Remover metadata
26. 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)
27. 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
28. ICONOS COMO FUENTE :-)
29. 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
30. PREPROCESADORES DE CSS
31. FUNCIONES PRINCIPALES • @extend: heredar clases • @mixins: funciones en CSS • @variables: $este-color puede cambiar • @imports: separación modular de archivos
32. 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
33. 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
34. 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
35. KITCHEN SINK / STYLE GUIDE
36. MUCHAS GRACIAS federicoisas@gmail.com - @fedeisas ! Preguntas?