A mí me gusta la jerarquía clara que tiene el sitio al presentar los niveles en columnas distintas y la apariencia limpia del diseño visual que hicieron. A pesar de esto, me pregunto como recibirían los usuarios de Facebook este diseño. A mí me gusta pero no me quedo convencido que saldría igual con otros usuarios.

Este es una de estas interfaces para las que quisiera ver resultados de un estudio con usuarios.

• ¿Entienden ellos la jerarquía clara?
• ¿Se aprovechan de ella?
• ¿Logran sus metas de navegación mas rápidamente?

Y Facebook es un sitio (tal como Amazon) que tiene una cantidad de usuarios suficientemente grande que fácilmente se puede hacer una prueba A-B y encuestas remotas (si es que no se puede hacer estudios directos). Es posible que al hacer el A-B a una escala en que no salga en Mashable hasta repetir la prueba unas veces.

¿Que opinas del diseño Facebook que hizo iA?

¿Que opinarían sus amigos de Facebook?

No es nada del otro mundo ver que a una niña que ya conoce el iPhone le resulta muy fácil usar el iPad. Los dos dispositivos usan la misma interfaz. Buenas noticias para el iPad, pero nada mas allá de lo que se esperaba.

Lo mas interesante viene en los comentarios que hace la niña sin pensarlos y donde se trabó en las tareas que se puso a hacer. Al hacer estos comentarios ella se muestra tan capaz como un adulto en dar feedback de usabilidad.

¿Tiene videos?

Me llama la atención que tan pronto que empieza a jugar pregunta si el dispositivo corre videos. Supongo que esto viene de experiencia previa con el iPhone, que el papá le corrió unos videos en el iPhone y que al ver algo que parece igual al iPhone pero mas grande, piensa inmediatamente en correr videos en el nuevo dispositivo.

Me pregunto si hay otras razones por las cuales pensaría en correr videos en el iPad. Sería interesante saber que ella lo vio tan parecido a un televisor de pantalla plana que le parecía tele, pero Lapin tendría que aclarar primero el contexto que la chiquita lleva de sus experiencias con el iPhone.

Quiero el que tenga cámara

Una de las críticas que mas escucho del iPad es “¿por qué no tiene cámara?”

Me parece una pregunta justa. Parece que sería mas o menos fácil incluir una cámara en el iPad.

Pero al pensar en usar tal cámara me cuesta imaginar que quisiera sacar fotos con algo tan grande como el iPad si tengo la opción de hacer lo mismo con un dispositivo mas pequeño que saca fotos mejores. Lo que realmente quisiera es conectar una cámara profesional al iPad para editar y mostrar las fotos editadas en el momento.

Toques multitouch sin querer

Algo que le complicó a la niña es algo que me imagino dificulta a mucha gente. Al sostener el iPad por el borde ella toca el límite del área sensible. Al tocar el límite del área sensible cualquier toque que hace en la pantalla llega a ser una interacción multitouch que no quiso hacer. En el Home el resultado es que tocar los iconos de las apps no da resultado hasta que suelte el borde del dispositivo.

Si solo se ocupaba arreglar esto en el Home se podría hacer fácilmente. Nada mas ignore cualquier toque que se hace cerca del borde del dispositivo. La cosa es que este problema va a salir para todo género de aplicación. Es algo que se debe arreglar al nivel del sistema operativo o en el dispositivo mismo.

Lo difícil de arreglar esto de forma general es que la misma resolución tiene implicaciones distintas para todo género de aplicación. El tocar el borde de la pantalla sin querer en una app de editar imagenes no se implica lo mismo de lo que se implica en un juego o en un launcher como el Home. Una resolución a nivel de SO o hardware tendrá que balancear todas estas implicaciones.

Toque la carita del gato

Este fue mi momento favorito. El papá se da cuenta que le está resultando muy difícil a la niña encontrar como entrar el juego. En la pantalla inicial de la app aparece la carita de un gato con la palabra “juega” abajo. Este es lo que los diseñadores esperan que los usuarios toquen para iniciar el juego. En la parte inferior de la pantalla hay un botón.

La niña va inmediatamente para el botón. A pesar de ver que no le llevó donde quería ir la primera vez el botón, el saber que botones hacen cosas le lleva a apretar el botón otra vez al volver a encender la app. Al final su papá trata de corregirle y le guia a la carita del gato.

Feedback de usabilidad… no se requiere título

Lo que mas aprendo del video es que la excusa de que los usuarios de un sistema o un sitio no sean suficientes cultos para dar feedback valioso es excusa sin lógica. Si una niña de 2 años y medio puede dar feedback valioso no hay usuario que no pueda dar feedback valioso.

Para dar comentarios valiosos no se require conocimiento amplio del sistema ni tampoco de las metas empresariales del aplicación o sitio. Muchas veces tal conocimiento hace mas difícil dar feedback útil. En fin lo importante es esto: recibir comentarios y feedback de usuarios reales de su sistema o sitio.

Es algo tan sencillo que lo puede hacer una niña de 2 años y medio.

En su entrevista por Spoolcast (en) Dan Brown presenta una perspectiva interesante sobre la documentación del diseño de una aplicación basandose en su libro Communicating Design.

Cultivar documentos

Para iniciar Brown habla de empezar un documento con un núcleo de información necesaria y después añadir los detalles poco a poco. También habla sobre el valor de tener documentos que muestran tanto una vista detallada como una vista general.

Me parece que la manera de alcanzar esta meta de vista general y vista detallada se encuentra en hacer varios documentos. En trabajos anteriores por lo general trato de proveer estas dos vistas por medio de un diagrama de flujo de procesos o un mapa del sitio para la vista general y wireframes o prototipos de baja fidelidad para la vista detallada.

Diagramas de conceptos (Concept models)

Un diagrama de conceptos muestra como se relacionan elementos de un sitio o aplicación web y facilita la planificación del mismo. Nos sirve para entender cuales son los elementos claves de lo que vamos a construir y los procesos que vamos a representar en lo que construimos.

Lo mejor de estos diagramas es que no le encierran en un método fijo de mostrar la información. No exige que se muestre todo como páginas o actores. Le queda la libertad de representar una página o un actor pero el diagrama no se define por reglas rígidas. La idea es plasmar los conceptos básicos del sistema, al documentar mas este diagrama sirve como referencia de como se relacionan los componentes, actores, datos, y todo lo demás.

El diagrama de conceptos plasma las relaciones de todo lo que tiene que ver con el sistema, es una herramienta para aprender sobre el sistema que se va a desarrollar.

El preparar este diagrama requiere que aprenda como todos los conceptos en el sistema se relacionan y al final el diagrama sirve como punto de referencia para ud. y una herramienta de aprendizaje para comunicar a otras personas las relaciones entre los conceptos.

Me parece que empezar con un diagrama de conceptos consta una buena forma de comunicar al cliente nuestro entendimiento del sistema. Nos deja mostrar información general sobre el sistema sin distraerse por los detalles.

Flowcharts

Quizá los documentos que menos valoramos los diseñadores son los flowcharts [o diagramas de flujo]. En cambio, los clientes y los miembros del equipo de desarrollo y QA los valoran mucho. Como diseñadores a veces los menospreciamos porque muchas veces tenemos el flujo ahí guardado en la mente y no vemos el por que de un diagrama que plasma algo tan obvio. Es probable que los clientes y los miembros del equipo no tengan esa información guardada en la mente, por eso valoran mucho estos diagramas.

No son nada de sexy los diagramas de flujo, pero la gente los entiende casi por instinto y por eso son de utilidad.

Spool mencionó experiencias que tuvo al hacer flowcharts y preguntó

¿Cómo selecciona ud. el nivel de complejidad en que quiere enfocar?

Si enfoca en los detalles demora mucho. Si es demasiado general el flujo no queda claro.

En mis trabajos muchas veces utilizo flowcharts distintos para circunstancias distintas. Por ejemplo un flowchart de nivel general como un site map o diagrama de flujo de proceso para toda la aplicación y según la necesidad hago diagramas mas detallados para explicar el proceso.

Lo que dice Brown sobre no utilizar este género de diagrama tiene mucho sentido. Cuando me siento muy presionado en un proyecto lo primero que dejo a un lado es hacer diagramas de flujo detallados. Puede que la manera clara en que comunican los flowcharts es la razón por la cual no los utilizamos. Vemos los flowcharts y nos decimos “obviamente es así” y nos preguntamos por qué gastamos tiempo en hacer un diagrama sobre algo tan claro. Es fácil olvidarnos de lo útiles que son estos diagramas para los demás miembros del equipo y para nuestros clientes.

Documentos como personas

No hay que sobrecargar a una persona con muchas responsabilidades. Asimismo no hay que asignar demasiadas responsabilidades a un documento. Como el ser humano los documentos tienen límites en lo que pueden lograr.

Establezca un propósito para cada documento. ¿Que quiero lograr con este documento? ¿Qué parte tiene este documento en el proceso del diseño?

Si ud. tiene un propósito para el documento puede asegurar que todo lo que aparezca en el documento cumple ese propósito. Puede hacer decisiones rápidas sobre lo que incluya o quite del documento.

Creo que lo mas importante de esto es poder hacer decisiones rápidas y seguras al saber el propósito del documento. ¿Cumple esta información el propósito del documento? Si no, quítelo. Si hace falta algo, agregue solo lo que concuerde con el propósito del documento.

El determinar el propósito exacto de cada documento puede hacerse mas difícil si hay muchas personas involucradas en la preparación de estos. Al discutir las diversas opiniones sobre el propósito del documento se pierde la oportunidad de enfocarlo en lo esencial.

Es posible que las responsabilidades de un documento cambien durante el ciclo de vida del mismo. Al llegar a diferentes fases del proyecto el propósito del documento puede variar.

He visto manifestarse diversos cambios durante el ciclo de vida de un documento. En unos casos, un cambio en el propósito del documento precipita un cambio en el formato del mismo, como añadir información técnica a un wireframe para el uso el equipo de Front End. En otros casos los documentos mismos no cambian pero se utilizan para propósitos distintos de los que tenían cuando fueron creados. Muchas veces los site maps y diagramas de flujo de alta nivel se utilizan para definir el sistema al reunirse con los clientes mientras los desarrolladores los utilizan para orientarse al trabajar en los diversos componentes que forman parte del sistema.

Probar sus documentos con los usuarios

Un punto muy interesante que levantó Spool en la entrevista era la idea de evaluar los documentos con las personas que los van a utilizar. Probamos el software que desarrollamos de aquellos documentos para asegurar que se cumplen las necesidades de los usuarios, ¿por qué no probamos los documentos mismos también?

Para lograr esto Brown sugiere mostrar documentos ejemplares de proyectos anteriores para asegurar que el contenido y formato de los documentos comunica bien los conceptos a las personas que los van a usar. Es parecido a hacer una evaluación competitiva. Mostrar los documentos, solicitar comentarios sobre ellos y adaptarlos según los comentarios.

Otra opción es hacer un proceso iterativo con los documentos. Mostrar los documentos para el proyecto actual al cliente, recibir comentarios sobre ellos y modificar el formato y contenido de ellos según el feedback.

(Donde trabajo hemos aprovechado de este proceso de evaluación iterativa en documentos internos. Esto para asegurar que los documentos que entregamos a los desarrolladores y los analistas de QA realmente se les da a entender.)

He aprovechado más de la segunda opción que de la primera y principalmente al evaluar documentos internos. Cuesta menos esfuerzo evaluar documentos con el equipo interno y hay menos riesgo que el equipo mal entienda que se están evaluando los documentos para asegurar que se comuniquen bien, no porque no se sepa lo que se está haciendo. Con los clientes hay mas riesgo de que el evaluar los documentos del proyecto actual les inspire el sentimiento erróneo que estamos inventando el proceso en el momento. Creo que lo que sugiere Brown de mostrar documentos de proyectos anteriores sirve para evitar este problema y mas bien dar confianza al cliente que siempre buscamos la manera de servirle bien.

Publicar libros y la experiencia pos-publicación

Al terminar la entrevista Brown habla de como se ha cambiado de opinión en cuanto a unos de los documentos que se describen en su libro al ver el crecimiento de RIA y las tecnologías relacionadas. Unos elementos que él antes consideraba opcionales (tales como anotaciones en los wireframes) ahora los considera necesarios. Otros elementos ya no los incluiría en los documentos.

Hay unos documentos sobre los cuales las buenas practicas aceptadas han cambiado. (Por ejemplo ya por unos años no se recomienda usar wireframe sin anotaciones.) Con estos cambios lo que se encuentra en el libro ahora sirve mas para dar comienzo a formalizar los documentos que como machote. Al igual que siempre, el diseñador tiene que recibir y analizar las opciones y decidir como adaptarlas para cumplir las necesidades del usuario.

Esta vez salió igual. Todo el vuelo pasamos por turbulencia, y esto no permitió a los asistentes del vuelo servir bebidas a los viajantes.

Debido a que la turbulencia causa muchas lesiones entre los asistentes del vuelo, los aerolíneas prohiben a los asistentes servir bebidas o comidas al viajar por aire turbulente, sino que por política tienen que quedarse sentados.

No todos saben esto, y al ver que no nos servían nada, unos se pusieron inquietos y empezaron a quejarse.

Al ver que la gente se fastidiaba, los asistentes explicaron la situación. Porque no podían servir nada, que era política del aerolinea, que el capitán estimaba que sería tanto tiempo mas hasta que saliéramos de la turbulencia y podrían servirnos.

Después de esto me quedé asombrado. El capitán nos comunicó por la radio, pidio disculpas por la demora en el servir bebidas y comida y nos comunicó cuanto tiempo estimaron los controladores de tráfico aereo que experimentaríamos mas la turbulencia.

Es decir que primeramente los asistentes del vuelo nos hablaron para explicar porque no podían servirnos y nos dieron un estimado del tiempo que faltaba para poder servirnos. Y por si acaso esto no era suficiente, el capitán nos comunicó, acudiendo a la autoridad mayor que hay en los vuelos. Esto no cambió la situación, todavía teníamos que esperar. Pero el ser tan claros (y transparentes) en comunicarnos esta información nos ayudó a enfrentar la situación con mayor paciencia y compenetración.

Un esfuerzo simple para comunicar la situación nos ayudó a sentirnos como el capitán, los pilotos, y los asistentes del vuelo se preocupaban por nuestros deseos y necesidades.

A veces al servir a los clientes es fácil olvidarse del poder de la transparencia. Si somos claros y directos sobre una situación imperfecta lo antes posible, muchos clientes entienden. Lo que les fastidia a muchos es no saber que pasa hasta la última hora, y encontrar en ese momento que algo salió mal.

Para lograr trabajar en el aeropuerto se exige buen manejo del inglés. Esto requiere bastante esfuerzo y consta un logro significante.

Me he esforzado mucho para aprender el español y a mi parecer representa un logro en mi vida. Cuando la gente me dice que hablo bien el español, me siento bien y me siento un poco menos extranjero.

Cuando nos encontramos los ayudantes del aeropuerto y yo, tengo que tomar una decisión. ¿Muestro lo grande que soy o les doy la oportunidad de mostrar sus habilidades a los oficiales y los asistentes de vuelo?

Me costó darme cuenta que al final, no le importa a nadie si yo hablo español. Los que trabajan en el aeropuerto se han preparado para hablar inglés y tienen ansia de hacerlo.

Al enfocar en mostrar mis habilidades, les quito a ellos la oportunidad de mostrar las suyas y no les doy nada de valor a cambio.

¿Cuantas veces hacemos esto mismo en nuestros tratos profesionales? ¿En los equipos y proyectos en los cuales trabajamos, damos suficiente oportunidad a los demás mostrar lo grande que son ellos, o nos enfocamos en la grandeza propia?

Al enfocar en lo grande que son los compañeros mostramos la confianza que tenemos en ellos y a la vez una oportunidad de ver ellos mismos lo grandes que son. Y tal como nos hace sentir bien a nosotros mostrar nuestras habilidades, ellos sentirán bien al mostrar las suyas y se animarán.

Para fomentar una forma de pensar que supera las barreras entre las disciplinas Burke presentó una herramienta que hizo como parte de su proyecto Knowledge Web. La herramienta presenta redes de asociaciones entre personas, ideas, tecnologías, e invenciones. Por medio de herramientas de este género Burke espera fomentar la innovación.

Su red ejemplar KWeb presenta una red de personas de renombre en la historia del arte y la ciencia, mostrando quienes eran amigos, colegas, enemigos, etc. La idea es navegar la red para ver que relaciones dieron comienzo a ideas o tecnologías nuevas y ver como estas innovaciones afectaron a la red de personas e ideas.

KWeb utiliza un sistema de esferas cocentricas para desplegar esta red. Las esferas interiores representan períodos históricos, las exteriores gente e ideas actuales. Para ayudar a los usuarios navegar la red, al escoger un nodo en la esfera, se hace highlight a las conexiones directas de este nodo a otros nodos en la red con una highlight secundaria a las conexiones secundarias.

Por medio de esta representación de la ciencia, Burke quiere llamar la atención de la gente al mostrar relaciones interesantes e instarles a navegar la red siguiendo el mismo impulso que esperimentás al leer un cuento de suspenso. Quiere aprovechar de la curiosidad sobre como se relacionan las ideas para motivar el aprendizaje.

Burke dio un ejemplo de unas relaciones y conexiones de las cuales salieron innovaciones importantes utilizando el sistema KWeb

Empezó con Richard Arkwright, un hombre que fabricó máquinas para coser. Conocía a toda la gente normal que uno conoce dentro de la industria textil. Pero también habla con un hombre que no tiene nada que ver con textiles, pero que mantiene máquinas para la Universidad de Glasgow, James Watt. Cuando se conocieron, Watt estaba pensando en como mejorar la máquina de vapor, lo cual inspiró a Arkwright a desarrollar la primera factoría de algodón movida por agua.

Burke sugiere que si prestemos atención a situaciones parecidas en la actualidad, podemos predecir dónde, cuando, y que genero de innovaciones sucederán.

Ecología social

Burke propone la idea de una ecología social. Lo expica como la capacidad de la sociedad para desarrollar conocimiento sobre los efectos periféricos de una tecnología antes de adoptarla y evaluar como una sociedad si queremos fomentar la adopción de aquella tecnología o no. (Ver bien los efectos periféricos del asbesto –que causa el cáncer– antes de utilizarlo y decidir si vamos a utilizarlo en la construcción o mas bien buscar otras soluciones al problema de los incendios.)

Al mencionar esto Burke explica que no propone controles gubernamentales sobre la innovación ni tampoco que dejemos todo a las fuerzas económicas. Espera una solución que aprovecha de la educación para capacitar a la gente para contribuir de forma significante a las decisiones sobre la innovación. “Que al balancear el dinamismo empresarial con el bien del público, podemos ‘have our cake and eat it.’”

Una barrera a lograr esta ecología social se encuentra en el resistir cambio. Saldrán tecnologías que no le gusta a la gente o a las instituciones de la sociedad porque requieren el pensar de las cosas de una forma nueva.

El genio de Mozart se escondió por años por los celos de un patrón. La iglesia católica censuró y ordenaron la muerte por fuego a los que dijeron que la tierra no era el centro del universo. Hay gente que todavía no quiere aceptar la teoría de la evolución. Nos resulta mas fácil pensar de las formas conocidas y cómodas que cambiar nuestra forma de pensar.

Para terminar su presentación habló de la necesidad de extender la oportunidad de la educación a todos para poder lograr un futuro en que todo ciudadano del mundo puede tomar decisiones sobre que innovaciones deben recibir de nuestros recursos para lograr tanto el crecimiento económico como el bien de la sociedad.

Nuestras instituciones

Burke mencionó que a veces nuestras instituciones nos impiden innovar porque se basan en los problemas, las soluciones, y la ciencia del pasado. Tales instituciones miran hacia atrás esperando innovar basándose en los descubrimientos del pasado. Tiene sentido, pero es probable que el futuro para el cual querés prepararte no extenderá en una línea recta del pasado o el presente. Al enfocar en los logros históricos y actuales de una institución frena el encuentro de ideas que nos lleva a la innovación.

Otra síntoma del problema de instituciones se ve en la manera en que enfoquemos los estudios posgraduados. Llegamos a “aprender mas y mas sobre menos.” Por ejemplo, un colega cuyo estudios culminaron en investigar como utilizó el coma John Milton en sus escritos. Burke ve como causa de esto las ideas de Rene Descartes que se encuentran en el Discurso de Método. Para estudiar problemas complejos de forma adecuada, hay que “dividir las dificultades que tengamos en tantas partes como sea preciso, para solucionarlas mejor.”

Como resultado, dividimos la ciencia en una tabla de disciplinas donde todos enfocan exclusivamente en su propia disciplina. Se dice que apenas empezamos a derrumbar las murallas que separaban las disciplinas, pero puede que seguimos igual, nada mas pensando que vamos superando las barreras.

Donde vive la innovación

Burke dice que los lugares donde vamos a encontrar ideas nuevas se encuentran en los huecos entre disciplinas, mercados, y necesidades sociales. Como dice Norbert Wiener, “el cambio viene mas que nada de la tierra abandonada que se encuentra entre las fronteras de las disciplinas.”

O en palabras de Burke…

Cuando datos distintos se asocian y se unan en maneras nuevas, 1 + 1 = 3. Las reglas de la matemática cambian. El total es mas grande del sumo de las partes.

Cuando se combinan ideas de formas nuevas, salen innovaciones que pueden cambiar la historia por us efectos primordiales y periféricos. Este es el enfoque del trabajo de Burke en la serie Connections, sus convocatorias, y su proyecto la Knowledge Web que se describirá en la siguiente entrada.

James Burke presentó recientemente en BYU, donde saqué el bachillerato. Su presentación me impresionó tanto que me siento compelido compartir unas de las ideas en una serie de entradas.

Para los que no conozcan el trabajo de Burke, fue el que promovió la serie Connections, la cual presentó invenciones y como se relacionaron invenciones e ideas que parecían completamente distintas y separadas. Conectó las ideas e invenciones que inspiraron entre si a los inventores que hicieron posible la vida moderna.

La convocatoria trató temas de sus discursos Staying Ahead y The Knowledge Web. El enfocó mucho en buscar la manera de predecir la innovación y sus efectos periféricos. Mencionó a la Knowledge web (red de conocimiento) como herramienta para pronosticar innovación y efectos periféricos y fomentar el pensar en una manera interdisciplinaria e innovativa.

Predecir los efectos periféricos

Burke presentó la cuestión de predecir los efectos periféricos a través de hablar sobre tecnologías que tienen efectos periféricos dañinos a pesar de que valoramos los efectos básicos de aquellos. Por ejemplo, la energía nuclear, el asbesto, el thalidomide fueron inventados y usados para mejorar la vida. No fue hasta después de usar estas tecnologías que nos dimos cuenta que el asbesto causa cancer y malestar respiratorio, thalidomide causa defectos de parto, y la energía nuclear produce desechos peligrosos.

Los efectos periféricos pueden tener efectos que cruzan de una disciplina académica a otra. Por ejemplo, el inventar el estribo en Afganistan nos dio el idioma inglés moderno.

Al adaptar el estribo afgani medieval, los franceses ayudaron a sus caballeros pelear de una manera mas eficaz y vencer a los anglosajones en la batalla de Hastings en 1066. El reinado frances sobre las islas británicas cambió el inglés al grado que anglosajones buscaron hablar de una manera mas fina e hicieron esto al hablar mas como los franceses. Por medio de esto se cambió el inglés del inglés antiguo de los anglosajones al inglés medio, lo cual se convirtió en el inglés que se usa hoy en día en Inglaterra, los Estados Unidos de América, Australia, y Nueva Zelanda.

Barreras a la innovación

Cajas intelectuales

Claramente quisiéramos evitar los problemas que enfrentamos con tecnologías como el asbesto y la energía nuclear, o encontrar la manera de predecir los problemas antes de enfrentarlos. Es que estos efectos periféricos no se ven hasta que empezamos a utilizar una tecnología. Muchas veces no vemos estos efectos periféricos porque vemos el mundo desde la caja de nuestro entendimiento actual. Se requiere un gran esfuerzo para ver al mundo fuera de aquella cajita.

Burke expresa esto con el siguiente ejemplo de Ludwig Wittgenstein

Alguien se acercó a Wittgenstein y comentó que ignorantes tuvieron que ser los europeos antes de Copérnico, porque al ver hacia el cielo no se dieron cuenta que (como todos sabemos) la tierra gira alrededor del sol, sino pensaban que el sol giraba alrededor de la tierra.

Supuestamente Wittgenstein respondió… “Me pregunto como se vería el cielo si de verdad el sol girara alrededor de la tierra.” A lo que iba es que se vería exactamente igual.

Al tomar la decisión de que hacer con una idea o tecnología, solamente tenés tu punto de vista. Si sos astrónomo y la paradigma contemporanea es que el universo es hecho de huevo, construís tus herramientas para buscar la cáscara.

Todos nos encontramos dentro de una caja.

De hecho, las cajas de cada cual pueden ser muy distintas. Puede que desde la caja mía es muy difícil entender como ves las cosas desde la tuya y viceversa.

Al final, tenemos que superar nuestras cajas de entendimiento o la habilidad natural que tenemos para innovar y asociar ideas se limita y se estanca.

Como las cosas pueden cambiar en un sólo año. Ahora trabajo mas con ingenieros, informáticos, y diseñadores que hablan español que los que hablan inglés. Ahora debe reflejarse en el blog.

Como se divide

Para los interesados, el blog ahora se divide en la parte en inglés, que se encuentra en en.delcaos.com y la parte en español que se encuentra en es.delcaos.com. Las entradas mas importantes y mas visitadas van a aparecer en los dos blogs, pero el contenido de los dos es completamente separado. Hay entradas que solamente aparecerán en un idioma o el otro.

Hay varios motivos por los que unas entradas solamente aparecerán en español y otras en inglés. Lo primordial es que unos temas interesan mas a la comunidad de ai y experiencia de usuario entre hispanohablantes que los que hablan inglés y vice versa. Voy a aprovechar de las estadísticas de visitas para ver si hay que traducir lo que aparece en un idioma en el otro. Pido de antemano su perdón por no escribir todo en los dos idiomas.