cibernéticamente, dirigentes

Hablando de los no límites de internet... (Ref.: Ciudad)
Un club de la Segunda División del fútbol danés va a ser manejado por una comunidad Web que tomará todo tipo de decisiones. Desde comprar a un jugador hasta elegir el nuevo técnico. ¿Y los dirigentes? A buscar trabajado en los clasificados...
¿Pensó que en el mundo del fútbol ya todo estaba inventado? Error. Porque a partir de anoche, una comunidad de Internet cerró un acuerdo con el Skjold BK, de la Segunda División danesa, para tomar decisiones sobre todo lo relacionado con el primer equipo. En este caso, chau entonces a las resoluciones monolíticas de uno o dos directivos. ¿Lo imaginan a José María Aguilar consultando a sus "pares-internaútas" sobre la compra del nuevo refuerzo de River? ¿O a Julio Comparada pidiendo permiso para que Independiente termine antes de tiempo la construcción del nuevo estadio? ¿O a Rafael Savino, discutiendo por chat sobre el técnico más conveniente para el futuro de San Lorenzo? Argentina año verde, parece.
La inestable situación del club aceleró este brusco cambio de timón, que se coronó anoche después de una asamblea extraordinaria de socios, quienes apoyaron mayoritariamente la propuesta del grupo Mitsuperligahold. Justamente, los "nuevos dueños" dirigirán los hilos a través de la compra de acciones.
"Es algo nuevo y emocionante, creamos una democracia distinta. Todos los miembros del Skjold, y con ellos los usuarios de esa Web, podrán influir en las decisiones, desde la elección de jugadores o su compra o venta", declaró el presidente del club, Jørgen Marthedal.
La idea, en realidad, está inspirada en la comunidad de aficionados ingleses "MyFootballClub", que en diciembre de 2007 compró el Ebbsfleet United, un equipo de la quinta categoría del fútbol inglés. Bjarne Vennike, promotor de la web danesa, destacó que su proyecto se diferencia del inglés en que ellos no han comprado el club, sino que se trata de un acuerdo de colaboración. La meta es que el proyecto empiece a funcionar en la temporada 2009-2010 y su objetivo a largo plazo es, como consta en el nombre de la Web, ascender a la Superliga, la máxima categoría del fútbol danés.
Fundado en 1915, el Skjold es un modesto club de Copenhague, pero de gran tradición, y con más de 1.500 jugadores en todas sus divisiones.

Si Laudrup estuviera muerto, haría chilenitas desde el cajón, pero lo tiene que ver en vivo!

probablemente, indefinido

Copio y pego un buen artículo del cual comparto muchas cosas. Hace poco, en una charla con colegas, había expuesto que no había persona en el mercado que pudiera abarcar todo lo que solicita el mismo, y los primeros que deben entenderlo son los diseñadores web (una profesión aún mucho más nueva que se del diseño gráfico) y los programadores, que deben hacer valer su trabajo, y luego los empleadores que solicitan personal altamente capacitado de una rama demasiado nueva; y por último, los clientes, que siempre andan volando por las nubes, y que siguen sin entender qué hacemos.
La multimedia se trabaja en equipo, no hay otra. Se requiere de diseñadores, comunicadores, programadores y líderes de proyectos; a lo sumo, alguno puede ocupar más de un rol, pero no todos a la vez, es imposble hacer todo, y todo bien.
Como diseñador, gráfico y de multimedios, y básico programador, entiendo muy bien lo que se explica en el artículo, hay que abrir el juego, tener mucha paciencia, no se puede correr todo el día atrás de la tecnología, menos si es especializada y con estándares no del todo claros (que se modifican muy a menudo)...
El desarrollo de un sitio web es una actividad muy nueva, que tiene todavía mucho espacio para madurar. Hasta que todos los roles y procesos se acomoden van a pasar largos años, especialmente mientras la tecnología y los estándares estén tan verdes.
Para los que tocan de oído en este tema, déjenme contarles que la producción de un sitio web comprende varias etapas, desde la concepción hasta la implementación. Parte (y sólo parte) del proceso es la creación de las páginas en sí, la parte visible del sitio, la parte que “sucede” entre el servidor y el navegador, y en el navegador mismo. Específicamente en la creación de las páginas, hay dos etapas muy claras: el diseño visual, realizado por un diseñador gráfico, y la incorporación de los datos dinámicos, por parte de uno o más programadores.

¿Y cuál es el problema?
Simplificar trae sus problemas, así que cuando miramos el proceso un poco más de cerca, descubrimos un paso intermedio, casi una formalidad, que muchos consideran una zona gris entre el diseño y la programación: el maquetado. El maquetado consiste en crear un esqueleto estático de la página en formato HTML+CSS según lo determinado por el diseñador. Esta maqueta sirve al programador de plantilla, quien le agrega luego la parte dinámica provista por el programa.

La pregunta es: ¿quién debe hacer el maquetado? Hay varios argumentos a considerar:

El diseñador no debe hacerlo porque:
* Los diseñadores encuentran difícil entender todas las sutilezas y variaciones de los lenguajes de marcado. Se trata de una organización altamente estructurada y técnica, que se pelea fuertemente con la “soltura” creativa en la que deben sumergirse para realizar el diseño apropiadamente.
* Los diseñadores consideran que la tarea está muy alejada de su profesión: ellos estudiaron morfología, semiología, comunicación, órdenes epistemológicos, etc., y su formación es -hasta cierto punto- independiente del medio en el que se expresen (web, revistas, libros, packaging, etc.).

A su vez, el programador no debe hacerlo porque:
* Los programadores, por su parte, están generalmente especializados en un lenguaje imperativo (Java, PHP, Python, C#, Ruby, etc.), y -cuando no lo conocen en profundidad- encuentran el HTML “soso” o incluso “simplón”.
* Además, “volcar” el diseño a HTML+CSS implica entender el diseño propuesto hasta cierto punto, y los programadores encuentran difícil (y aburrido) interpretar las -a veces inexistentes- indicaciones del diseñador respecto de la relación y jerarquía entre los distintos componentes visuales.
* Por último, el armado conlleva la utilización de programas como Photoshop para crear las imágenes necesarias, programas con los que suelen estar más familiarizados los diseñadores que los programadores.
Se da entonces una discusión bastante graciosa a mi entender, en la que programador y diseñador se miran con recelo y se señalan mutuamente diciendo “el maquetado lo tenés que hacer vos”. Por alguna razón que no entiendo, ambos esperan que sea el otro quien realice la tarea. Voy ahora a explicar por qué pienso que ninguna de las dos posiciones es correcta; que se trata de una falsa dicotomía y que en realidad existe una tercera posición: el maquetador es otra persona.

El proceso de creación de la página es más complejo
Para mí, el staff ideal para desarrollar una página web requiere de cuatro personas o roles: un líder o responsable de proyecto, un diseñador gráfico, un maquetador y un programador. Y las etapas no son dos, ni tres; hay cuatro etapas en la producción de la página, a saber:
1. Diseño de interfaz - Realizado hasta cierto punto por todos en conjunto.
2. Diseño gráfico - Realizado por el diseñador gráfico.
3. Maquetado web - Realizado por el maquetador web.
4. Programación - Realizada por el programador.

El diseño de interfaz
El diseño de interfaz es la parte donde se decide qué elementos habrá en la página y cómo se comportarán. Es un momento muy importante de la producción, ya que en él se plantea cómo va a realizar el usuario las distintas acciones, con qué herramientas contará, qué funcionalidades específicas de web se le adicionarán a la aplicación, etc. Bien hecho, es un trabajo conjunto entre el líder de proyecto, el programador, el maquetador y el diseñador. Se decide si se van a utilizar botones, input boxes, radio buttons, AJAX, RSS, pingbacks, trackbacks, preferencias en cookies, etc., y cómo se van a utilizar. Se discutirán conceptos de usabilidad y accesibilidad.
Aunque el diseño de interfaz es un trabajo de los cuatro, algunos tendrán más responsabilidad que otros, siendo el diseñador el responsable final de esta etapa. Éste debe tener alguna especialización en el área de diseño de interfaces de web, ya que debe conocer no sólo lo que es posible, sino también cómo aprovechar los elementos para producir la comunicación que se desea obtener. El líder de proyecto tendrá en claro los objetivos aplicativos a cumplir. El programador y el maquetador darán sus visiones sobre la factibilidad técnica, incluyendo por ejemplo sus análisis del impacto sobre la performance. Finalmente, el maquetador aportará su conocimiento sobre el lenguaje Web.
Aclaro que cuando digo lenguaje Web no estoy hablando de los lenguajes descriptivos de la página (HTML+CSS), sino que hablo de las características funcionales que tienen las páginas para insertarse en el mundo Web moderno (2.0, por el momento): interoperabilidad (RSS, pingbacks, microformatos), accesibilidad, etc.

El diseño gráfico
Luego de aprobarse el diseño de interfaz, se procede al diseño gráfico. Éste es realizado exclusivamente por el diseñador, quien lo realiza generalmente en una herramienta que ofrezca la máxima flexibilidad gráfica; es decir, el diseñador debe poder mover, alterar y acomodar los elementos sin limitaciones hasta quedar conforme. Eso implica que no se puede utilizar una herramienta que obligue a pensar en HTML (ej: Dreamweaver), sino que se utilizará una herramienta de estilo libre, como Photoshop o mejor aún Fireworks. Una vez obtenido y preaprobado el diseño preliminar, el diseñador deberá reunirse con el maquetador para ponerse de acuerdo sobre lo siguiente:
* Conveniencia técnica y relevancia de cada elemento gráfico: aquí se sopesan la dificultad técnica y recarga de performance (peso y capacidad de procesamiento) asociada a cada rasgo del diseño, y se evalúa si es necesario mantenerlo o replantear su utilización.
* Comportamiento de los elementos en diferentes situaciones: se plantean diferentes escenarios, evaluando qué debe pasar si una palabra o frase queda demasiado larga, cómo deben interactuar los márgenes cuando los elementos cambian de orden, cómo deben modificarse los elementos ante diferentes tamaños de pantalla, etc.

El maquetado
Cuando ya hay consenso sobre el diseño, debe producirse el maquetado. Ésta es una etapa increíblemente subestimada y a la vez muy importante. En ella se vuelcan los elementos gráficos a un formato compatible con Web, teniendo en cuenta el lenguaje Web. Esto es, no sólo el maquetado debe producir código HTML y CSS válidos (utilizando también JavaScript cuando sea necesario), sino que además debe elaborar un producto que contenga todos los elementos necesarios para que sea una página web profesional:
* Accesibilidad: uso de ALT, TITLE, accesos directos, marcado específico.
* Interoperabilidad: microformatos, RDF, marcación en header.
* Escalabilidad: estructura adecuada, estrategias de organización de clases.
* Compatibilidad: soporte de navegadores.
* Semántica: utilización apropiada de tags.
* Performance: minimización de código y cantidad de requerimientos al servidor (round trips).
* Otros: hoja de estilos para impresora, SEO.

La programación
Finalmente, el programador realiza la parte más fácilmente comprendida del proceso, aunque por supuesto no por eso la más sencilla, que consiste en utilizar la maqueta HTML como plantilla para los programas que generan el contenido dinámico.

Conclusión
Lo que acabo de exponer es una enorme simplificación del proceso, aunque creo que da una idea más clara de cuál es el rol que veo en el maquetador. Su trabajo es muy complejo, muy técnico y requiere una alta especialización, estar al día con los cambios y tendencias (nuevamente menciono los microformatos, nuevos navegadores, nuevos estándares), conocer deficiencias de los navegadores actuales y cómo subsanarlas o cómo éstas afectarán a la aplicación, tendencias en el tamaño de la pantalla, SEO, en fin… miles de pequeños detalles que hacen del maquetador un profesional por propio derecho, sin el cual los resultados obtenidos serán sin duda pobres o incompletos.

El no tener un maquetador profesional en el equipo de desarrollo suele traer uno o varios de los siguientes problemas con la página a desarrollar:
* No valida correctamente, por lo que se ve en menos navegadores, tiene menos Page Rank en Google, etc.
* Es pesada, ya sea en tamaño, round trips al servidor o simplemente en uso de CPU al ser desplegada en el navegador. Todo esto empobrece la experiencia del usuario.
* No es accesible, y como mínimo es incómoda en algún aspecto.
* Hace mal uso o desaprovecha el marcado en el header, por lo que obtiene menos Page Rank en Google del esperado.
* No respeta estándares y rompe la semántica: una vez más, tiene menos Page Rank en Google, pero ése es sólo el principio de los problemas que esto trae.
* Se ve o se siente como un “bicho raro” en la web, porque no respeta códigos a los que el usuario está acostumbrado. El usuario no se encuentra cómodo y no puede utilizar herramientas que considera útiles (autocompletadores, ruedita de scroll del mouse, modos de visualización de su navegador, accesos directos de teclado, gestures, etc.).
* Es difícil de mantener, aún siendo dinámica. Por ejemplo, el archivo CSS es incomprensible; cualquier pequeña modificación o agregado conlleva mucho más esfuerzo del necesario.
* La compatibilidad en navegadores es pobre, dejando a muchos usuarios afuera (siempre más de los necesarios).
* Carga en un orden inapropiado. Por ejemplo, el usuario puede ver las barras y menús utilitarios mucho antes que el contenido principal de la página.
* No se ve bien al imprimirla, o imprime información innecesaria, dejando afuera información que sería realmente útil en la versión impresa.
* No aprovecha todas las posibilidades de interoperabilidad que ofrece la web.

Va a costar mucho poder hacer todo eso y bien... mientras, hay que seguir haciendo.

políticamente, explicado


Una muy buena manera de explicar algo muy complicado.

De un muy interesante blog.

erróneamente, eximidos

Para alguien que siempre destaca los errores para poder avanzar, mejorar, y aunque para muchos sea sólo un crítico y nada más, me he sorprendido con una buena iniciativa de un diario uruguayo que en todas sus notas ha decidido ubicar una aplicación (típica del 2.0) que ayuda a través a sus lectores a sanar errores comunes de una redacción; así, el usuario colabora como un corrector más en la edición. Acompaña al formulario, el siguiente texto:

"¿Encontraste un error? Ayudanos a corregirlo"
Que Cervantes escribiera "fizieron" en lugar de hicieron, no nos exime de culpa. Tampoco que la ortografía sea un proceso dinámico como lo demuestra el propio ejemplo. Los errores no se deben cometer, pero los cometemos. A veces por apresuramiento, error de tipeo, "lapsus cálami", porque teníamos momentáneamente saturadas las áreas corticales, subcorticales y/o basales; o de bestias nomás. ¿Qué podemos hacer al respecto? En primer lugar avergonzarnos, ofrecer disculpas y procurar no repetirlos. En segundo lugar, podemos pedir ayuda y es lo que estamos haciendo.
Por favor, ayúdenos a combatir nuestros errores. Indique aquí los que encontró.
Interesante...

macanudamente, Liniers

El título debería haber sido incansablemente, dedicadamente, todas hubieran sido apropiadas. El artista Liniers saca a la venta, desde su propia editorial, Macanudo 6.
Lo destacable y original de este trabajo es que la primera edición es que tendrá todas las tapas dibujadas a mano (¡5000!!!), excelente idea donde cada uno de los que la compre tendrá una distinta. A través de su newsletter anuncia una pre-venta donde se venderán el mismo día los libros con la tapa en blanco. Genial!

editorialmente, doble


Decían que River iba a tener que armar dos equipos para jugar Torneo y Copa, pero parece que el que jugó dos partidos, y al mismo tiempo fue Argentinos Juniors! Al menos eso decía el diario el 01/11/08 a las 21.00 horas. Dicen que todo lo que tiene que ver con el Diego se está duplicando por estos días con tal de que sea noticia, mmm!