Lo primero que me dijeron mis amigos cuando les dije dónde había estado ese día fue que si eso era una secta. Reconozco que escuchando mis propias palabras sacaba la misma conclusión, así que para no dar lugar a equívocos, me quedaré con la explicación oficial:

TED es un evento anual en el que los líderes mundiales del pensamiento y la acción comparten sus pasiones. TED es el acrónimo de Tecnología, Entretenimiento y Diseño, tres grandes áreas que, colectivamente, están definiendo nuestro futuro… aunque TED da cabida a una temática más amplia, mostrando “ideas que merecen la pena” según sus responsables.

TED ha creado el programa TEDx, eventos independentes organizados localmente para conectar a personas interesadas en compartir una experiencia al estilo de TED. En un TEDx, los conferenciantes invitados y los vídeos de charlas anteriores (TEDTalks) se combinan para favorecer el debate en profundidad y la interconexión entre un selecto grupo de asistentes.

El evento comenzó de una manera inmejorable con un videomapping (¿igual os suena la cabina de DJ de David Geuta?) realizado por los chicos de Arstic de manera sobresaliente.

• Allison Massari nos contó su trágica historia vital aderezada con algunas bromas y una buena interpretación. Sin duda admirable.
• Barbara Ehrenreich fue el contrapunto a otros ponentes que seguían la senda marcada por el optimismo como fuente de felicidad, salud y casi todo. Escritora, columnista y, sobre todo, “cazadora de mitos”. Su web no es esplendorosa, incluso se le ve demasiado el plumero, pero escucharla hablar fue una gozada.
• Matt Killingsworth es un investigador de la felicidad, así que venía al pelo en este TEDx. Además, no defraudó, veinte minutos se quedaron muy cortos para todo lo que tenía que contar.
• Ricard Arguís salió con un órgano y nos involucró en un experimento grupal donde demostró la capacidad que tenemos para desviar nuestra atención de lo que estamos haciendo. Está llevando la psicología positiva a las aulas para que niños, profesor y padres sean más felices.

Pero siempre que no estábamos atendiendo a una conferencia o un vídeo, los organizadores nos tuvieron algo especial reservado. Tartas de chocolate, almuerzo y comida experimental y artesana, y un poquito de cava para terminar. Vaya lujo.

Vuelvo a dar la enhorabuena a los organizadores por un trabajo ímprobo que dio un fruto perfecto. Espero que esta haya sido la primera edición de muchas. Ha sido un placer.

Os voy a dar algunos consejos basándome en lo que tuve que hacer yo para poner en marcha mi bici tras años sin usarla, pero recordad que no tengo ni idea, así que en caso de duda, llamad a vuestro amigo “frikiclista” (todos tenemos alguno, aunque no todos podemos pronunciar esta palabra).

Ajustes básicos para una bici antigua (o reciclada, que suena mejor)

Cuanto más vieja más vas a fardar, ahora está de moda lo retro (y con la crisis ni te cuento), así que no tienes excusa, nadie se va a reír de ti, o al menos, no de ti solo. Veamos los puntos básicos que tienes que revisar (esto es como la revisión del coche, pero que te la haces tú, es más barato aunque cansa más):

• Cambios (si tiene). Tienen que funcionar, si no no tiene gracia todo el rollo ese de las marchas para subir cuestas y tal. Puedes engrasar un poco la cadena y todos esos mecanismos de metal que la rodean.
• Frenos. Tendrás que revisar las zapatas no sea que las tengas demasiado desgastadas… estas cosas pasan, lo digo por experiencia. En todo caso, hay que ajustarlos para que vayan suaves, suaves. Esta operación puede ir desde lo trivial a lo exasperante, de forma inversamente proporcional a la antigüedad del modelo de tus frenos.
• Ruedas. Es de cajón pero tienes que hincharlas… y rezar para que no estén pinchadas. Si no ya te veo poniendo un parche o cambiando la llanta entera. Esto son palabras mayores, tendría que buscar en youtube.
• Tuercas. Verás que tu bici está llena de tuercas, para las que se usa una llave especial (o varias, vete a saber), así que pide prestada una a alguien que conozcas. Tendrás que revisar todas las que haya, pues tienen la maldita costumbre de aflojarse. Sobre todo, fíjate en las que mantienen unido el plato grande con el cuadro (i.e. la parte principal de la bici, lo que más pesa, etc.), necesitarás una llave especial e igual tienes que quitar alguna cubierta, pero merece la pena si no quieres que se te rompa un pedal mientras disfrutas del canto de los pajaritos.
• Polvo y suciedad. Límpiala un poco que el agua va barata. Que lo retro cuando está sucio sólo queda bien en un bar de esos con pinta irlandesa que tienen poca luz y mucho polvo. Y yo diría que no suelen poner bicicletas.

Encuentra tu camino, mide distancias, disfruta del éxito

La felicidad está en las cosas pequeñas como pasar todos los días por un pinar y sentir un poco la naturaleza en tus pulmones. Así que si puedes, aunque te tengas que desviar te recomiendo que elijas un camino que te guste, que no tenga complicaciones y en el que puedas encontrar algún momento de paz a tu alrededor. Si voy en bici no es para estar rodeado de coches y autobuses, eso es lo último que quiero.

Aquí en Zaragoza, puedes consultar el buscador de itinerarios ciclistas que te ofrece una ruta tranquila (carriles bici y calles máximo 30) entre dos lugares. De todas maneras, lo mejor es explorar tú mismo y cambiar, ver qué pasa si vas por aquí o por allá.

Finalmente, puedes cronometrar el tiempo y valorar qué te compensa más. Incluso puedes medir las distancias si dispones de un teléfono con gps (hay muchas apps, por ejemplo, runtastic para iphone).

Verás como eres un poquito más feliz pedaleando que conduciendo.

PD: Andar es igual de interesante, aunque no siempre resulta factible.

Cuando uno se lo plantea, el principal obstáculo es claro: la comodidad del coche. Pero realmente, ésta es muy relativa y lo que parece algo bueno, tiene su lado oscuro, del que nadie mejor que Leo Babauta para hacernos ver la otra cara de las supuestas limitaciones de no usar el coche:

1. Takes longer. [...] Driving in traffic is stressful. So we go places slower, which is less stressful, more fun. I like a slower life.
2. The weather. [...] We are so used to being in our metal-and-glass boxes that we forget how wonderful the rain is. And when the weather is good, cars isolate you from that. You don’t get to feel the sun on your shoulders, the wind in your face, the fresh smell of licorice when you pass a certain plant, see the squirrels dart past or the ducks mock you with their quack.
3. Convenience. Sure, buses can be inconvenient — sometimes they’re late and you wait and you’re late. But think about the inconveniences of cars we often forget: parking, getting stuck in traffic, [...], car repairs, oil changes, stopping for gas, car insurance, the dangers of car accidents, [...] the expense of a car and having to work more just to pay for it.

¿Quién puede resistirse al fresco olor del regaliz, a las ardillas moviéndose como estrellas fugaces o a los patos haciéndote la burla con sus graznidos? Yo no. En serio.

El curso tuvo dos partes: una técnica (la más extensa) y otra más informativa. Tanto Ángel como Óscar hicieron un gran trabajo, cada uno en su papel, pero siempre demostrando un vasto conocimiento de la materia. ¡Enhorabuena a los dos!

Desarrollo de aplicaciones con Qt Quick

En primer lugar, se hizo mucho hincapié en resaltar que el punto de entrada al desarrollo para móviles Nokia era developers.nokia.com, donde siempre había disponibles productos estables (las betas las ponen en otro sitio).

El seminario estuvo orientado a dispositivos móviles, aunque Qt Quick permite desarrollar aplicaciones para otras plataformas. Puesto que está basado en Qt, la formación consistió en un repaso de las principales características de éste, seguidas de una introducción práctica a Qt Quick.

En cuanto a Qt, nos hablaron del objeto base de todos los demás (QObject), señales y slots, eventos, propiedades, metadatos, gestión de la memoria (borrado en cascada), layouts para la UI, bases de datos,… para finalmente descubrirnos Qt Quick, basado en el lenguaje QML (una mezcla de CSS y Javascript) y que permite un desarrollo rápido de aplicaciones. Todo esto para simplificar el desarrollo y estrechar lazos entre diseñadores y programadores (se cambia C++ por QML, un lenguaje de más alto nivel, similar a ActionScript). Además, Qt Quick permite testear tus aplicaciones móviles en los emuladores que tiene incorporados, de forma que no es necesario disponer de los teléfonos físicamente.

Para terminar nos dieron un terminal Nokia muy bonito, en el que espero programar alguna aplicación próximamente. Tras el curso me quedé con ganas de hacer alguna cosilla. Aquí os dejo un vídeo de un juego hecho en 300 líneas de código, no está nada mal, ¿no?.

El futuro de Nokia, Symbian y Qt

Está claro que tras el reciente acuerdo de Microsoft con Nokia para utilizar Windows Phone en sus terminales, el futuro de Qt resultaba bastante incierto.

Óscar trató de convencernos de que Nokia seguirá apostando por Qt/Symbian en lo que se conoce como “next billion”, es decir, el montón de dispositivos de baja capacidad que prevén vender en los próximos años en aquellos lugares donde la telefonía móvil todavía no está tan asentada. Pero claro, la realidad es que para la gama alta, la que podría competir con los iPhones y demás, la apuesta de Nokia es por Windows Phone.

El objetivo de Nokia quedó claro: crear un ecosistema de aplicaciones y desarrolladores que aumente el valor de sus terminales. Desde luego tienen una amplia base de dispositivos vendidos, aunque la diversidad de sistemas operativos puede ser un factor bastante negativo a la hora de captar adeptos.

Update noviembre 2011: Sobre Nokia y el tema del “next billion” (¿esas pantallas no llevan Qt, no?).

Primeros pasos

El curso comenzó tratando algunos conceptos relacionados con la motivación para ir acercándonos al tema poco a poco. Algunos ejemplos interesantes:

• Empleabilidad: Capacidad de una persona de tener un empleo. A mayor motivación, mayor empleabilidad.
• Actitud: Está en nuestra mano tener buenas actitudes, mientras que las aptitudes son más complejas, requieren de mayor trabajo y no siempre son alcanzables. Motivación y actitud van de la mano, una persona motivada tendrá mejores actitudes que una que no lo esté.
• Comunicación no verbal: No podemos no comunicar. Todos nosotros comunicamos algo aunque no queramos (e.g. con nuestra vestimenta o con nuestra postura corporal). Es importante saber comunicar para poder motivar a los demás.
• Inteligencia emocional: Capacidad de reconocer sentimientos propios y ajenos, y la habilidad para manejarlos (Wikipedia). En la parte intrapersonal podríamos hablar de autoconocimiento, autocontrol y automotivación. La motivación puede nacer en nosotros mismos.

¿Quién debe motivar a quién?

Esta es una pregunta sobre la que fuimos trabajando todo el curso, ya que tiene diversas facetas y no es sencilla de contestar. La respuesta simple es clara: cada uno debe motivarse a sí mismo, para que su bienestar (su felicidad) no dependa de nadie.

En el mundo de la empresa sabemos que, en general, los jefes exigen mayor motivación a los empleados y a su vez éstos reclaman a sus jefes que les motiven. Es la pescadilla que se muerde la cola. ¿La solución? Ni blanco ni negro, todos deben motivar y motivarse. En palabras de Alfonso Alcántara, de Yoriento:

“Los empleadores dicen que prefieren a los trabajadores que ya vienen motivados de casa y con la sonrisa puesta. Pero esas personas adquirieron esa motivación laboral que les sale de dentro de forma natural, gracias a experiencias profesionales y personales que tuvieron en el pasado en otras empresas o entorno laborales.”

“También todos nosotros podemos cambiar nuestra motivación e introducir en la botellita, de forma gradual, el barquito que más nos interesa. ¿Cómo? La idea es fácil aunque conlleva tiempo, planificación y esfuerzo. Como todo lo bueno. Si quieres estar motivado para llegar a hacer las cosas o conseguir los objetivos que te has propuesto, organiza tu vida y tus hábitos para aumentar la probabilidad de que eso ocurra, especialmente en el contexto laboral.”

¿Cómo motivar y motivarse?

Para motivar me parecieron especialmente interesantes las 5 R’s de la motivación:

• Retribución
• Retos
• Respeto
• Reconocimiento
• Recreación

Para motivarse viene bien echar un vistazo a algunos factores que aumentan la autoestima:

• Cumplimiento de los objetivos personales
• Inventario de éxitos
• Visualización
• Diálogo interno positivo
• Gratitud

Observamos que las técnicas del palo o de la zanahoria pierden fuerza en las empresas actuales y sólo nos permiten evitar una conducta o favorecer un comportamiento repetitivo, respectivamente. Pero para explicar todo esto, creo que lo mejor es ver el genial vídeo realizado por Dan Pink, titulado “Drive: The surprising truth about what motivates us”:

Para concluir, citaré otra vez un post muy interesante de Alfonso Alcántara que dice así:

No existe una motivación de las personas, sino una motivación para cada persona en un momento y contexto determinados. La genuina finalidad de un profesional de los recursos humanos es conocer la inclinación motivacional de cada uno de sus clientes internos en el ámbito de la organización de que se trate.

Los “departamentos de personal” sólo tienen sentido si tratan la motivación de cada persona como un caso único.

¿Y tú, te preocupas por tu motivación o dejas esa responsabilidad en manos de otros?

Sin duda, esta industria merece un estudio detallado, pues resulta chocante que en el 2010 tuviera el honor de crecer un 6% a pesar de la “crisis mundial” de la que viven los medios y que utilizan los políticos para tomarnos el pelo, aunque ése es otro tema

Etapas del proceso productivo

En primer lugar, veamos las etapas del proceso de producción de un videojuego:

1. Idea / Concepto: estudios preliminares del diseño y el mercado, se define el framework de trabajo (consola, tipo de jugador,…) y se presenta un “sumario ejecutivo” y algunas consideraciones de marketing. Finalmente tenemos un “Project Binder” con una versión inicial de los documentos importantes.
2. Preproducción: Es la etapa clave, con una duración aprox. de 5 meses y un gasto acumulado de 1/3 del presupuesto al finalizarla. La idea fundamental es prototipar. El objetivo es determinar si se sigue adelante con el juego. En ella se demuestra el potencial real del juego, ya que dará como resultado una versión 100% jugable y publicable llamada “fpp”. Esta versión deberá responder a las 3 C’s:
• “Character”: ¿Qué controlamos?
• “Control”: ¿Cómo lo controlamos?
• “Camera”: ¿Cómo lo ve el jugador?
3. Producción: En esta etapa se desarrolla el juego completo, partiendo de la “fpp”. Tiene una duración de unos 3 meses, durante los que se trabaja en una versión “alpha”, la cual tiene un 75% de los mapas jugables, la interfaz casi terminada y todo lo necesario para poder comenzar los tests mientras se termina el 25% restante del juego.
4. Test: Cuando comienzan los tests, el objetivo es llegar a una versión “beta” que tenga el juego completo y muchos bugs ya corregidos. A partir de la “beta” se comenzará a optimizar y estabilizar la versión, pulir los últimos detalles del juego, etc. hasta obtener la versión “Master Candidate”, es decir, la versión candidata a ser máster (i.e. la definitiva, la que se distribuirá).
5. Validación (opcional, sólo aplica al caso de consolas): Una vez se obtiene la “Master Candidate”, ésta se envía al fabricante oportuno (Nintendo, Sony, Microsoft, etc,) y tras unos 2 meses apróx. te devuelven lo que se conoce como versión “Gold Master”, la cual está ya lista para ser lanzada.

Características de la industria del videojuego

• Se trabaja con las últimas tecnologías, ya que los consumidores demandan novedades periódicamente (hasta la fecha, cada 5 años se produce un cambio de generación en las consolas, con lo que ya va tocando…)
• En los 3 primeros meses tras la salida al mercado de un videojuego se producen el 60% de sus ventas. Esto se debe a que suelen ser muy esperados, por lo que se aprovecha la venta compulsiva.
• Los videojuegos están disponibles en plataformas cada vez más variadas: consolas (de sobremesa y portátiles), PCs, teléfonos móviles,… y los canales de distribución también están en proceso de cambio: steam, app store, facebook,…
• Es muy importante la Propiedad Intelectual (IP en inglés), por lo que las productoras impulsan creaciones propias, aunque también adquieren licencias externas.
• El actor más importante en la cadena de valor (si hablamos solo de consolas) son los fabricantes de consolas (actualmente los grandes son Nintendo, Microsoft y Sony), ya que definen el hardware sobre el que los publishers tendrán que trabajar. Los primeros llevan ventaja en todos los sentidos: conocen mejor la plataforma (i.e. potencialmente pueden hacer mejores videojuegos) y, además, cuando no son ellos los que crean el videjuego, los publishers han de pagarles royalties.

Otros temas tratados en el curso

No sólo de la industria trató el curso, también se dedicó una buena parte del tiempo a aprender sobre temas relacionados y a hacer ejercicios prácticos.

Por ejemplo, el primer día jugamos a un juego en equipos en el que se trataba de construir la torre más alta en 30 minutos y con el siguiente material:

• 1 metro de cuerda.
• 1 metro de celo.
• 1 nube de algodón (marshmallow).
• 20 espaguetis.

El ejercicio es muy interesante, te enseña a planificar, prototipar y rediseñar, trabajar en equipo,… diría que todo el curso mereció la pena por este ejercicio. Puedes ver una presentación sobre el reto del malvavisco (marshmallow) en la web de TED.

Por otro lado, también se dedicó un tiempo a explicar la gestión de proyectos con Scrum, donde se comentaron los siguientes conceptos:

• Product backlog: Es una lista de alto nivel que se mantiene durante todo el proyecto. Contiene items que describen potenciales características de forma poco concreta, las cuales se priorizan en función de su valor de negocio.
• Sprint backlog: La lista de trabajo que deberá realizar el equipo en el siguiente sprint.
• Daily Scrum meetings: Qué has hecho, qué vas a hacer y tienes algún problema. No más de 15 minutos.
• Tiempo de los sprints. Duración fija, de forma que sea más fácil predecir lo que va a darnos tiempo a realizar.
• Framework de scrum: reglas, ceremonias y artefactos,
• Tareas pequeñas, no más de 3 días, para que sea más fácil estimarlas correctamente.

También hicimos una planificación grosso modo del desarrollo completo de un videojuego, sin tener en cuenta una metodología completa, simplemente para ver qué roles hacen falta en el equipo:

• Programmer (motores de físicas, luces, gráficos, colisiones, sonido. Efectos especiales, menús, hud, modos de juego, inteligencia artificial, cámaras, debug,…)
• Level Designer
• Game Designer
• Sound Designer
• Data Manager
• 3D & 2D Artists (modelados de personajes, texturas y mapeados de texturas, objetos 3D,…)
• Animator

Esto es todo, si tenéis más curiosidad sobre el funcionamient de la industria, os recomiendo esta web “The Video Game Industry | Resume Play” (en inglés), donde se describe con más detalle todo el ecosistema.

La primera charla fue impartida por Teresa Oliver, no sé a qué se dedica, pero supongo que será algo así como “llevar el agilismo hasta el último rincón del planeta”. Puedes ver el vídeo completo aquí. La idea era presentar en qué consiste el desarrollo ágil y vendérselo a la gente de nogocio (de la que por cierto había más bien poca). De lo que dijo me quedo con lo siguiente:

• El agilismo es una filosofía, una forma de pensar, no le gusta que se entienda como una metodología. Además, no está limitado al desarrollo de software (aunque en el 95% de los casos sigue siendo así).
• Las “metodologías ágiles” no son para todo el mundo, hay equipos que trabajan mejor de otras formas, aunque ella cree que, en general, todo equipo se beneficiaría de seguir un proceso más abierto al cambio.
• El 64% de las funcionalidades desarrolladas en el mundo nunca se utilizan.
• Se centra en SCRUM:
  • Apuestan por reconocer que los cambios ocurren y facilitar su tratamiento.
  • Se utilizan sprints compuestos de historias que vamos a implementar.
  • Los sprints tienen que durar de 2 a 3 semanas. La planificación se hace pensando qué cabe en este tiempo (time-boxing).
  • Al principio de cada sprint se priorizan las historias según la importancia que tienen para el cliente.
  • Las historias elegidas para el sprint han de estar terminadas al 100% cuando éste termina.
  • Tras cada sprint se entrega al cliente un producto funcional (cada vez más avanzada, pero real).

La segunda charla fue impartida por Jose M. Cristobal, CTO de SevenClick, empresa aragonesa dedicada al desarrollo de aplicaciones móviles. El vídeo está disponible para visualización online. Su charla estuvo orientada a comentar lo que habían aprendido al aplicar algunas técnicas de desarrollo ágil. Muchas cosas interesantes:

• Las reuniones diarias han de ser diarias, intentaron hacerlas martes y jueves pero no dio resultado. Está claro que las standup han de ser muy cortas y no tiene sentido que participen 15 personas, pues se pierde el ritmo.
• No estimar en horas
  • Comenta la Ley de Parkinson: “El trabajo se alarga hasta completar el tiempo planificado para su finalización”.
  • Las estimaciones en horas/días son personales y cada uno tendrá la suya, con lo que no hay forma de establecer un valor absoluto. Además, las horas pendientes son irreales, ya que puedan faltar tareas o ser erróneas.
  • Ellos utilizan estimación relativa, concretamente con Planificación de Póker.
  • Al cliente no le importan las tareas que hayas tenido que hacer para completar una funcionalidad, lo que le importa es que funcione y haga lo que él espera.
• Termina lo que empieces
  • Tendencia a terminar prematuramente las tareas, sólo por acabar cuanto antes.
  • Lo que hacen es dejarse un buffer de colchón para pruebas y otras labores necesarias, pero que se tiene tendencia a no hacer por falta de tiempo.
• Pregunta al Product Manager (Cliente)
  • NO interpretar, imaginar o suponer lo que quiere el cliente. Preguntarle.
• Consejos
  • Scrum no sirve para todos. Si no encaja en tu equipo de desarrollo, es mejor usar otra metodología.
  • La agilidad no es una bala de plata. Hacen falta prácticas de ingeniería, no basta con sólo usar una metodología ágil.
  • La agilidad necesita compromiso por parte de todos los stakeholders.

Del diseño de producto al diseño de la experiencia

De la presentación de Jordi Morillo (Del diseño de producto al diseño de la experiencia) podemos destacar su descripción de la metodología de diseño que utilizan, llamada “Design Thinking”, la cual está basada en empatizar con el usuario/cliente, haciendo de él el centro del proceso de diseño. Creatividad, racionalidad y empatía, podrían ser sus palabras clave.

Es muy importante que toda la empresa tenga una misma visión de cómo debe ser la experiencia y de cómo son las personas que van a vivirla. Hay que tratar de interactuar con los clientes en el mayor número de etapas posibles, no sólo al final. Es interesante investigar qué factores pueden influir en tu negocio y, además, hacerlo cuanto antes. Es más barato. Hay que iterar soluciones, conceptos, prototipos, todo. Es importante evolucionar junto al cliente y hacer que este evolucione gracias a ti.

La experiencia abarca todo el proceso

La experiencia no es sólo una cuestión de estilo, no basta con hacerlo atractivo.

Tampoco es sólo una cuestión de forma y función, no basta con que sea manejable y cumpla su función.

Tampoco basta con resolver un problema de negocio que me están planteando una serie de clientes.

La experiencia debe abarcar todo lo anterior y, además, participar en la estrategia de la empresa. ¿Hacia dónde vamos? Mire, Sr. Gerente, hemos hecho estos estudios y resulta que hemos detectado estas necesidades, oportunidades, tendencias, etc.

Cuesta mucho que la UX tenga peso en las empresas

Lo anterior es el ideal, la realidad es que han tenido muchas dificultades para integrar la UX en una empresa grande como HP. Llevan diez años en ello y todavía estiman unos diez más hasta que estén donde quieren estar, es decir, participando en los planes de negocio. Eso son veinte años, tela.

Se puede pensar que HP es grande y que cuesta mucho que las ideas progresen y se implementen, pero precisamente por su tamaño, tienen la capacidad de ser líderes en UX. Además, por el tipo de productos y clientes que tienen, deberían amar al usuario sobre todas las cosas, ”deberían pensar en él y con él”.

Desgraciadamente, esta frustración es normal. Hasta hace poco, las empresas ”no necesitaban pensar en las personas”, ya vendían de todas formas. Ahora no, ahora hay más opciones donde elegir, los clientes están mejor informados y te van a abandonar si no los cuidas. Es lo que le está pasando a muchas empresas, que no se preocupan de la experiencia, pero ”la experiencia lo es todo”.

Tutoriales

• Getting Started with Matlab (PDF, 2MB). Éste es sin duda el documento que hay que leer en primer lugar, es muy fácil de leer y te presenta las características más importantes del lenguaje. Además, sirve como pincelada de la potencia que tiene Matlab. Es gratuito y se puede descargar de Mathworks. Incluye las siguientes secciones:
  1. Introducción.
  2. Matrices y arrays.
  3. Gráficos.
  4. Programación.
  5. Análisis de Datos.
  6. Creación de Interfaces Gráficos de Usuario (sí, con Matlab puedes crear tu propia aplicación gráfica).
  7. Herramientas del Escritorio y el Entorno de Desarrollo.
  8. Interfaces externas.

• An Introduction to Matlab por David F. Griffiths (PDF, 1,6MB). Este documento es mitad referencia, mitad tutorial. Está bastante bien formateado y es fácil de leer. Si lo sigues paso a paso puede que te quedes con los conceptos fundamentales de Matlab, aunque quizás sea más útil como resumen rápido del lenguaje.

• Introduction to Matlab por Ela Pekalska (PDF, 500KB). Este documento se asemeja mucho al anterior, por lo que lo dejo aquí como otra opción posible, que cada cuál se quede con el que más le guste.

Referencias

• La ayuda en línea de Matlab (i.e. la que aparece al pulsar F1 y que también está disponible via web) es sin duda la mejor referencia, ya que, junto con la descripción y definición de cada función, característica o toolbox, acompaña ejemplos muy ilustrativos de uso que ayudan a poner en contexto fácilmente cada punto.

Programas de ejemplo

Sin duda, una vez que uno ha tomado contacto con un lenguaje o entorno de programación, la mejora forma de afianzar y ampliar conocimientos es estudiando código hecho por programadores con más experiencia. Existe gran cantidad de código de ejemplo en internet, aunque si tuviera que elegir un lugar, escogería MATLAB Central, la comunidad que Mathworks ha creado en torno a su propio producto. Además de programas de ejemplo, contiene foros, blogs, preguntas/respuestas y enlaces interesantes.

Otros enlaces

• Preguntas más votadas sobre Matlab en stackoverflow. Preguntas sobre Matlab de recomendada lectura.
• Enlaces más populares sobre Matlab en delicious. Como muy bien sabe Valeri Jakobs, esta herramienta puede ser muy potente a la hora de encontrar información de calidad (a pesar de haber sido comprada por Yahoo).

Uno de los ejemplos más conocidos es Winamp, que incluso tiene una comunidad en torno a sus skins.

Los skins son sustitutos de la apariencia de los controles estándar de un sistema operativo con una interfaz de usuario basada en ventanas (e.g. Windows 7, Ubuntu Linux, Mac OS X). Los skins pueden ser o no personalizables por el usuario (si lo son, se dice que la aplicación es skinnable). La definición anterior puede ampliarse a interfaces gráficas no basadas en ventanas, como por ejemplo la de un cajero automático o la de un teléfono móvil.

A la hora de decidir si queremos utilizar skins (o hacer skinnable nuestra GUI) hay que valorar los pros y los contras de esta elección. Como siempre en el mundo de la UX, no hay una solución general, pues cada caso es distinto (no one-size-fits-all solution).

Motivos para SÍ utilizar skins

• Mayor impacto visual, que puede resultar en un producto estéticamente más agradable o en una mayor conexión emocional entre usuario y producto.
• Diferenciarse de la competencia (o equipararse a ella). Tenemos una interfaz gráfica distinta, por tanto somos distintos (¿mejores? muy dudoso).
• Branding de aplicaciones OEM. Puede ser obligatorio en determinados productos (¿suficiente con el splash inicial o el about?).
• Misma interfaz en varios sistemas. En aplicaciones multiplataforma puede ser interesante para mejorar la consistencia (e.g. Google Chrome tiene casi la misma apariencia en Linux, Windows y Mac). Las bondades de este punto son muy dudosas ya que habría que estar muy seguro de que tus usuarios cambian de sistema tan frecuentemente.
• Mejorar la consistencia entre aplicaciones de una misma marca o suite, de forma que estar familiarizado con una de ellas, facilite la utilización de otra (e.g. Adobe utiliza una GUI personalizada de forma similar en todos sus productos).
• Reducir la complejidad del sistema operativo. Es el caso de la mayoría de los cajeros automáticos que corren sobre entornos Windows. También se utiliza en aplicaciones infantiles.
• Mejorar la interfaz estándar, cambiando los controles estándar o haciendo nuevos. Aplicable en productos muy concretos, e.g. editores de sonido. No es fácil de conseguir y hay que tener muy claro que se va a mejorar lo existente.

Motivos para NO utilizar skins

• Pérdida de consistencia desde el punto de vista de la usabilidad, ya que el usuario reconoce fácilmente los controles estándar que utiliza el sistema operativo (y la mayoría de las aplicaciones) y sabe cómo interaccionar con ellos, mientras que una interfaz con distinta apariencia tiene una barrera inicial, ya que el usuario va a tener que redescubrir a qué equivale cada elemento y cómo funciona.
• Desaprovechamiento de las mejoras en el sistema. Si se utilizan los controles estándar y se siguen sus guías de UX, cuando éste lance una nueva versión, la aplicación se beneficiará de todas las mejoras que incluya esa nueva versión. Si utilizamos skins, las mejoras en el sistema serán omitidas.
• Mayor tiempo de desarrollo. Añadir skins no deja de ser una funcionalidad que conlleva un desarrollo. Se puede paliar utilizando librerías especializadas (e.g. Prof-UIs), aunque en mi opinión éstas suelen tener demasiadas cosas (más dinero, más features, más complejidad, más bugs, más problemas)
• Es difícil hacerlo bien. La mayoría de aplicaciones con skins que han tenido éxito, tienen una gran compañía por detrás. Hay mucho trabajo de diseño gráfico y de interfaces.

Conclusión

Si decides que tu aplicación tenga un skin propio o sea skinnable, hazlo por una muy buena razón y siendo consciente de que vas a necesitar un esfuerzo extra para no empeorar la experiencia de tus usuarios. Si tienes dudas, es probable que no te convenga utilizar skins.

Por otra parte, hay aplicaciones de mucho éxito que utilizan skins, e.g. World of Warcraft, Spotify, Adobe Photoshop,… así que no hay duda de que en algunos casos existe un beneficio derivado de su utilización.

Referencias

• When would you prefer a custom/skinned user interface in a desktop application?
• What are good examples of custom/skinned user interfaces?