¿Habéis visto los nuevos correos HTML que enviamos desde Tractis? ¡Ah! es la nueva cereza de la aplicación. La acabamos de subir hace unos 4 días y la verdad, estoy contento. Si tu gestor de correos soporta HTML entonces podrás ver los correos de esta forma, de lo contrario, podrás leer el mismo en modo texto.

El diseño

En materia diseño, montar un modelo electrónico de HTML no es fácil, para nada. Si diagramar una web es compleja, por su cantidad de variantes y puntos, imaginen hacer esto para un programa de correo electrónico.

Al diseñar la idea de poner correos HTML, tuve en cuenta estos puntos:

1. Simplicidad
2. Menor cantidad de imágenes posibles
3. Personalización
4. Información

Bien, muchos de nosotros seguro habrá visto ya más de un e-mail en formato HTML. Personalmente, no me gustan. Primero porque el 99% de los correos en HTML nunca encajan bien en los lectores, además, porque la gente cada día empieza a leer correos desde múltiples dispositivos que ni siquiera respetan bien HTML, así que, es una tarea ardua de prueba y error (y no se imaginan) para que sea algo universal. El diseño intenté que tenga la simplicidad que necesitan para que no sea una publicidad print, o sea, el diseño que caracteriza Tractis: simplicidad, colores vivos, contrastes, buenas proporciones.

• Simplicidad: La idea es que los correos sean simples, tanto en diseño como en construcción. Esto permite flexibilidad para extenderlos o realizar otras operaciones.
• Menor cantidad de imágenes posibles: dado que los lectores de correo siempre bloquean imágenes, hay que permitir ver el correo sin imágenes.
• Personalización: a futuro, gracias al código se pueden imprimir el logotipo del cliente y los colores de su tema.
• Información: estructura hecha especialmente para transmitir niveles de información según los deseos. La primera parte permite hacer todo, la segunda sólo sirve para aquellos que quieren más o para leer información relacionada al hecho.

La estructura

El mail tiene unas zonas específicas y este modelo se puede extender dependiendo el uso. Por ejemplo, cuando se trata de poner facturas hay mini módulos de listados, etc. En esta imagen de pruebas nombro las zonas específicas de los correos html de Tractis:

Tenemos:

1. Un logotipo. Un poco inferior en tamaño que el original del sitio. Personalmente, el logo de tractis es demasiado grande para la ventana de lectura de un correo. Los grandes utilizan esta medida base.
2. Línea de identidad. Es un detalle de diseño, para que no quede “flotando” el diseño. Son marcas de diseño de identidad que le dan más fuerza al asunto. La nuestra tiene el color verde de Tractis.
3. Asunto. Frase que muestra el asunto del correo.
4. Resumen. Sirve para meter el mensaje principal del correo. La extensión es libre aunque las mejores pruebas fueron aquellas con poco texto. Menos de 4 líneas se hace. Escribirlo siempre entre 6 y 10 líneas.
5. Caja de acción principal. Acompañando al resumen, esta la caja de acciones principal. Sirve para que el usuario no tenga que buscar o leer entre los enlaces normales que aparezcan o bien para mostrar una información muy clave como por ejemplo, en el ejemplo de la foto, cuánto es la cantidad de crédito que dispones luego de la recarga.
6. Caja de información secundaria. Son párrafos para recordarle al usuario las otras opciones que dispone de la acción principal.
7. Modulo de detalles. Modulo que extiende y amplía en detalle la información. En algunas ocasiones no hará falta ponerlo. Permite el volcado de cualquier contenido en la zona, sean párrafos o listados de tablas.
8. Lista personalizada. Una tabla donde se puede personalizar la información en forma tabular. Sirve mayoritariamente para casos de pagos, precios, o bien para listar versiones o listados de ítems concretos.
9. Módulo de información adicional. Ampliación de información sobre el tema, como pueden ser vencimientos, penalidades o acciones relacionadas con el tema. También incluye la información de contacto.
10. Pie del correo. Pie de página con información de contacto.

Con esta estructura de datos, prácticamente cubrimos todas las necesidades actuales de Tractis. Digo prácticamente porque no sabemos las futuras. Igualmente, la flexibilidad que ha demostrado estuvo más que bien y ha dado pocos dolores de cabeza.

Lo que odiamos de este medio

Lamentamos que el código no sea lo más limpio, resumido o estandarizado como lo es en nuestra aplicación web. El problema radica en que los lectores de correos hacen y deshacen a su antojo, impidiendo que los correos HTML vayan con un código estándar, utilizando hojas de estilos separadas. Entonces, el código tiene que ir en forma de sopa de letras: todo incluido en el cuerpo del documento. A mi forma de ver, hay demasiado código de más, incluso, ¡hasta me parece una ironía que lo haya programado yo! Pero hemos limitado el abuso al máximo, así no nos dañamos los ojos.

En un futuro, cuando los grandes fabricantes se den cuenta de este problema, haremos la traducción de los correos electrónicos utilizando técnicas estándares menos arcaicas.

Pocas veces habrán escuchado esta frase: principio de degradación. Es un término que se empezó a utilizar relativamente hace poco en discusiones de desarrolladores de aplicaciones web. En diseño web, este principio muestra cómo un sitio web se va «degradando» de la forma más ecológica posible frente a navegadores antiguos. La idea básica de este principio es que todo el material que se produzca para un sitio no afecte la lectura mínima cuando se utilice un navegador especial, que no cumpla con los estándares. A medida que bajamos de versión de un navegador observaremos la cantidad de soporte técnico.

Lo cierto es que un sitio bien degradado permite a cualquier usuario con un navegador antiguo seguir utilizando las cosas de un sitio de forma vertical, sin estilos de por medio, sin efectos, o con los disponibles para ese navegador en concreto. Un usuario con un dispositivo móvil que no soporta CSS podría aprovechar mejor la información si está bien degradada. Las imágenes –relacionadas con contenido– seguirán viéndose, mientras que las imágenes «decorativas» pasarán a un segundo o tercer plano.

El planteo

Desde un principio en Tractis tratamos que esto se vaya cumpliendo. Diseñando sólo para un grupo de estándares y no para una empresa en concreto. Aunque ponemos esfuerzo en dar soporte a navegadores obsoletos, nos damos cuenta que es un sobretrabajo gigante y la calidad no es la que queremos dar. Por ello, desarrollar algo para un navegador en concreto sólo hace que el sitio se observe horriblemente en otros. Es mejor sujetarse a este tipo de principios por la igualdad de beneficios que ofrece en todas las gamas de utilización.

Cómo se soluciona

El proceso a nivel código para llevar este principio no es simple del todo. Primero programamos en varias capas lógicas: XHTML para estructurar datos, CSS para la disposición y aspecto de cada estructura, JS para controlar eventos. La página debería verse incluso, sin soporte de CSS, esa es la meta. Un usuario debe al menos poder leer con lo que tiene a mano en ese momento. Si esta regla no se cumple, la degradación no es satisfactoria, lo que impide que un usuario quede limitado. A medida que el usuario vaya comprendiendo esto, utilizando versión más actualizadas de navegadores, éste irá recibiendo premios: el sitio comenzará a visualizarse a la idea más general, lleno de detalles los cuales llamamos regalos. Por ejemplo, al entrar al sitio con navegadores que soportan la propiedad estándar text-shadow podrán disfrutar de los detalles y sombreados que la aplicación permite.

El efecto obtenido

Si quieren ver el principio de degradación en acción, entren a Tractis utilizando Firefox, Safari y Internet Explorer 7. A simple vista, la barra principal del programa es casi igual en las 3 versiones, pero aquellos usuarios que utilicen navegadores con mayor soporte de estándares podrán disfrutar de los detalles. Los usuarios de Safari, verán la barra como fue en un principio, intencionalmente diseñada, mientras que en Firefox, al no tener todavía soporte de sombras ésta no mostrará la propiedad y dará otro aspecto, degradando correctamente. La barra seguirá siendo la misma sólo que, ésta responde a las propiedades mínimas que pueda soportar el navegador.

Algunas capturas de la barra principal en todos sus grados de degradación:

Otro excelente ejemplo de principio de degradación son los botones de acciones. Dependiendo la versión y la marca de navegador que utilicéis observaréis cambios notables. De nuevo: el tope lo ofrecen aquellos navegadores que soporten las propiedades estándares border-radius y text-shadow mientras que el resto lo mostrará como pueda, degradando hasta donde les sea posible. En Safari, los botones tienen esquinas redondeadas y sombreados en los textos, resaltando las formas de un botón, mientras que en IE7 y Firefox la cosa cambia debido a su nivel de programación: en IE7 los bordes redondeados no existen, dejando los botones de forma cuadrada y en Firefox hasta depende que versión, los bordes no son tan redondos como deberían ser por el mismo nivel que tiene la funcionalidad como está programada.

Ventajas para Tractis y para nuestros usuarios

Este principio nos deja beneficios tanto a nosotros, como desarrolladores como a nuestros usuarios. Nosotros no trabajamos para Microsoft o la Fundación Mozilla, sino, que trabajamos para un set de estándares, y consideramos más importante tener un nivel de soporte alto de estándares que un nivel alto de soporte de navegadores obsoletos. Nuestro código es resumido, justo y rápido. La escalabilidad es gigante, en comparación con otros proyectos y podemos tomar cartas en el asunto en cualquier situación. Para nuestros usuarios, todos los beneficios de un código que sigue los estándares: velocidad de carga, soporte, degradación, aprovechamiento de recursos de forma correcta y más.

Cuando entréis a una aplicación y no la podáis usar porque no está bien degradada os acordaréis de los estándares y de este post en donde hablamos del principio de degradación.

Esta nueva versión de Tractis trae novedades en cuanto listados de información en la aplicación se refiera. Las nuevas listas universales que hemos realizado traen un montón de mejoras de código y diseño de información. En este post resumiré todas las mejoras que hemos introducido:

Tipos de datos utilizados en Tractis

En Tractis tratamos ya con varios tipos de información y que necesitan ser listados: comentarios, contratos, plantillas, personas, documentos firmados, borradores, gastos, etc. Los listados universales en Tractis permiten la identificación de cada item con un icono, el cual permite a un usuario distinguir diferentes tipos de items en una misma lista. Todos los iconos utilizados en la aplicación Tractis son cortesía del proyecto Tango. Como podrán apreciar en esta imagen donde veremos documentos firmados y documentos que están siendo editados:

Los items están definidos con un tamaño de letra prominente, en comparación con otros datos. Esto permite al usuario discernir la importancia de la información dentro de una fila. En muchos ejemplos encontraréis sitios que definen tamaños de tipografía muy iguales para casi toda la información. En Tractis evitamos esto reduciendo el tamaño de la información según el nivel de necesidad. Primero, en tamaño grande, el nombre del item y segundo, utilizando el mismo tamaño, el estado. Todos los estados en los nuevos listados tienen el mismo tamaño para una rápida lectura. Como segundo tamaño, está la información adicional, la cual se considera secundaria y opcional en muchos casos.

Uno de los problemas que nos encontramos fue el ancho de los listados condicionaba mucho la información a mostrar, haciendo que las listas crecieran en espacio vertical. Lo cual limitaba la lectura rápida de varios items y la uniformidad de las formas. Gracias a las propiedades de CSS y una concienzuda investigación pudimos lograr la funcionalidad de esconder los contenidos que se fueran fuera de foco en una celda, como lo tienen muchos programas. Esto ayuda enormemente a la lectura de datos, tanto de forma vertical como horizontal.

Iluminación de celdas

Gracias a las bondades de CSS, los listados tienen tres estados: reading, hovering y activation. El modo reading (lectura) es el que normalmente observarás. No tiene ningún tipo de efecto, ni color más que los elementos utilizados. En este estado no hay elementos seleccionados, ni estás actuando con el modo hovering.

El modo hover ayuda al usuario a situar su cursor en una gran lista de datos. CSS aquí actúa de una forma amena coloreando el fondo de la fila con un color azul claro, permitiendo al usuario mover el cursor sobre la misma zona, que en caso de que no fuera así, podría ocurrir que el cursor se desplace hacia otra fila y el usuario termine perdiendo el foco que necesitaba.

Una vez el usuario realice una opción de acción o activación, entra el modo activation. La fila tomará un color amarillo de advertencia, que le indicará al usuario que puede realizar otra acción con ese dato en concreto o con varios de la lista. Por ejemplo, en esta imagen 3 items de una lista están activos para aceptar la única acción disponible: borrar, que permite este módulo. En un futuro, aplicaremos más acciones basadas en la activación de items en listas, por ejemplo, que un usuario pueda seleccionar 4 contratos de una lista y editarles las etiquetas en modo batch o meter los contratos en carpetas que el usuario se cree para ir almacenando contratos según sus criterios de organización.

Semántica de las listas

Cuando un desarrollador de HTML tiene que crear un listado, lo primero que se le viene a la mente es listas desordenadas u ordenadas. Éstas listas son ideales para muchos casos, pero cuando se requiere el uso de múltiples datos lo mejor es utilizar una tabla de HTML para representar datos de forma tabular y con relaciones entre sí.

Aquí es donde entran factores como la utilización de columnas y filas, cabeceras y títulos de sumario, etc. Los listados de Tractis son independientes ahora como módulo. Basta extraer un listado y se presentarán los datos y el título del listado. Para ello aprovechamos otra bondad de las tablas en HTML, y me estoy refiriendo al elemento CAPTION. Todos los listados traen el elemento CAPTION, que ayuda a titularizar todas las listas y dejarlas independientes de otros contenidos y elementos.

Antes utilizábamos títulos H3 y H4 para estas listas, pero no nos permitían independizar los datos de las tablas en otras secciones, así que hemos puesto CAPTION para poder reutilizar las tablas sin necesidad de ir borrando o agregando nuevos títulos.

Listados fantasía

Una de las novedades que se encontrarán los usuarios noveles de Tractis son los listados fantasía. Muchas aplicaciones, cuando el usuario empieza a utilizarlas, no les muestran una serie de datos de ejemplo, lo cual complica la forma en que los usuarios aprenden o conocen una aplicación.

En nuestras primeras versiones, el usuario se encontraba un texto corto explicativo que le explicaba que es lo que tenía que hacer, pero nunca, un usuario sabría que pasaría si él/ella realizar una creación de contrato u creaba una plantilla. ¿Qué saldría allí? ¿Qué datos vería? Todas esas incógnitas las solucionamos mostrando datos de ejemplo. Esto permite saber cómo son los datos que crea un usuario, qué datos adicionales les puede poner, cómo están ordenados, que estados muestra.

Para hacerlo, habíamos visto algunos ejemplos, pero eran limitados. Muchos ponen una imagen con una marca de agua que dice “example data” lo cual tiene unas pegas. Por ejemplo, sólo sirve y funciona para sitios con anchos de páginas fijos. Como tenemos un sitio multidioma, hay que crear capturas de los datos en varios idiomas, lo cual es improductivo. Tal es el caso, que si en un futuro, una lista cambia o tiene un agregado nos veríamos forzados a realizar otra tanda de imágenes de ejemplo, así que esta opción la descartamos. Además, si la conexión falla y la imagen no se descarga, el usuario no verá mucho. El nivel de interactividad es mínima.

Lo que hicimos fue crear una lista con datos fantasía, y todos estos datos al ser pinchados lanzan una alerta al usuario para invitarles a crear u operar ya con la aplicación. Esta lista tiene datos en gris, controles desactivados y está traducida en todos los idiomas disponibles de Tractis y es flexible a los cambios de ancho de página, celdas y otras acciones que realice el usuario con el navegador.

Listas funcionales, universales y expandibles según el contexto. Queremos extender el uso de las listas, pero estamos reticentes a la hora de agregarles más complejidad, creemos que lo mejor no es precisamente la cantidad de caracteristicas y funcionalidades sino el conjunto exacto de acciones que podamos hacer para llevar a cabo nuestras tareas.

Hace unos años escribía sobre una interesante teoría del diseño que poco se aplicaba a los cánones de la época. Se trata sobre la separación del contenido de la presentación y su función en un proyecto web. En Tractis desde un principio pactamos esta vía, que nos permite hacer capas de desarrollo a unas escalas bastante altas, por ejemplo, separamos el trabajo de los programadores del de los diseñadores y los que gestionan el contenido. Esto nos permite un nivel de personalización y modificación de la aplicación más de lo que solemos ver en estos casos.

Pero para los meros mortales que no entendemos sobre patrones de diseño o metodologías, nos queda admirar y disfrutar el resultado final de este trabajo: Apariencias (requiere una cuenta). Cambia los colores de la aplicación, cambia nuestro logotipo por el tuyo con dos clics.

Así es, en Tractis hemos aplicado la posibilidad de que modifiques la apariencia de tu aplicación desde un formulario. Es bastante fácil hacerlo y bien funcional, pero todavía con limitaciones. La idea básica es que, cualquier persona, con un programita que capture colores (por ejemplo Colorschemer [ver una versión online]) pueda capturar los colores de su marca o su correspondiente sitio y volcarlos sobre la delicada interfaz de Tractis. Pero no sólo eso, también puede subir su logotipo (respetando unas medidas) para terminar de poner la cereza sobre la tarta. Podéis mezclar bastantes colores en la pantalla, la idea y mi recomendación es que utilicéis pocos colores y en base de ellos construyan un acabado final. La aplicación también permite cambiar un determinado valor, por ejemplo, no hace falta llenar todos los campos del formulario para ver cambios, podéis cambiar de golpe todos los verdes tocando las partes necesarias y, en caso de haber modificado mucho y no recordar los valores finales siempre os quedará el botón de revertir cambios.

La verdad, queremos que en un futuro cercano puedas subir tu propia CSS, tus reglas, tus colores (10 o 50), tus imágenes y con esto puedas, incluso, cambiar de pi a pa el aspecto de la aplicación. Pero para ello, estamos trabajando duro para estudiar y fundar los cimientos de la aplicación, que como verán no es nada pequeña ya.

Esto promete y, la verdad, me encanta. Existen limitaciones pero en mi pruebas hice bastantes plantillas que saldrán ni bien queden terminadas para producción. Les invito a realizar capturas de pantalla con vuestras combinaciones de colores y probar la nueva funcionalidad.

Una de las tareas más divertidas en el desarrollo de Tractis fue ésta, me ha encantado y de momento, me tomaré un respiro para realizar otro major change en la aplicación y hacer de ésta cada día una aplicación que dé placer utilizarla para trabajar y realizar negocios.

Tratando de mantener la continuidad de posts sobre diseño esta semana les dejo algo que les puede gustar bastante: mi Kit GUI de desarrollo IA para construir wireframes. Llevo usándolo un tiempo ya, y no me puedo quejar de lo bien que me vino.

El kit contiene más que nada, elementos de formulario y otras cosas de prototipaje rápido. Tenía pensado agregarle más cosas pero, serían en todo caso, caprichos de cada uno. Si pongo estructuras fuera de los formularios probablemente no se terminen de adaptar nunca a las cosas que vayan a hacer.

El archivo está en PDF. Utilizo normalmente Illustrator para estirar, adaptar, agrandar o modificarlas. Me lleva cerca de 5 segundos darle la forma adecuada para el wireframe y lo realizo todo con tres herramientas: Selection tool, Direct Selection Tool y Text Tool.

Con todas estas, modifico las estructuras.

El kit tiene licencia CC Atribution y podéis hacer lo que queráis con él, siempre y cuando citéis la fuente.

Una de las funcionalidades chulas de negonation que he visto en estos días en los builds son el cambio de nombre de grupo. Ahora, en vez de ser “la parte uno” puedes llamarte como quieras “grupo de la muerte” por ejemplo. Como me gusta jugar con la app, pues tengo un grupo de negociación que se llama “Los villanos locos”.

Y cuando los efectos de tanto trabajo ya tocan, se los villanos escriben comentarios como éste:

Estos pequeños detalles que hacen la tarea de negociar más divertida.

Llevaba tiempo sin escribir, lo siento. Con los deadlines a mantener y el blog me cuesta el doble, más si uno quiere escribir cosas interesantes. Pues hoy les voy a mostrar bastantes cosas de la aplicación. Probablemente este sea el único post que veréis de mi persona este mes y el otro, así que, aprovecharé para plasmar temas interesantes.

Primero quiero contarles en qué plan está diseñada. Normalmente, vengo practicando el diseño centrado al usuario hace unos 7 u 8 años. Este método, si bien no está mal visto y es uno de los más practicados y dominados por gente de mi área, pero no está causando el mismo efecto en esta época.

Normalmente, cuando observo interfaces diseñadas con éste método, noto que centrarse en el usuario está malinterpretado del todo. En mis comienzos, creí que diseñar bajo este método era como: tomar una libreta, un boli y sentarme a escuchar a cada usuario; anotando sin parar cada “exigencia”, cada “capricho” y con esos datos plasmarlos en una interfaz. Es aquí donde se producen los destrozos más grandes de la humanidad en lo que diseño de interfaces se conozca, recuerdo que algunas cosas de las que había diseñado me habían salido como el coche que diseñó Homer Simpson en la empresa de su hermano.

Como les decía, también me ocurre esto cuando aplico sólo diseño centrado al usuario. Tiendo a poner todas las exigencias posibles de los usuarios, tratando de normalizar todo. Pues bien, para cambiar un poco el aire, he decido tomar otro camino que resulta igual de guiado y me deja en la ciudad sin tener que hacer mucho kilometraje: el diseño centrado a la acción.

Al principio la gente se siente descolocada al escuchar esto, pero este término se baraja hace tiempo y he leído unos cuántos papers que los desmenuzan, en donde se explica más que nada diseños basados pura y exclusivamente en patrones de acciones.

No está nada mal. Es lo más concreto que me he topado hasta el momento y, junto a pequeñas dosis de diseño centrado al usuario podemos alcanzar lo que muchos conocemos por: una completa arquitectura de software. Diseñar pensando en las acciones y no en las posibilidades que puede tener un usuario. Esto en general deforma la aplicación a niveles inexistentes. Prueben de hacer una pequeña cosa, verán como la aplicación exige una interfaz “capaz de hacerlo todo” en vez de hacer determinadas acciones y bien.

Nuestro proceso de diseño quizás varíe bastante a lo que se practica en otras empresas. Para empezar, he exigido desde un principio seguir una línea de desarrollo que nos permitan una flexibilidad grande, atenernos a márgenes de errores y que no dé tanto a equivocaciones irreversibles. Para ello, nuestro patrón de diseño (el cual comentaré más adelante) sigue unos pasos muy simples: apertura proceso > reunión de mapeo > prototipo borrador > presentación del prototipo > producción final > subida de material.

No es común, al menos para mí, ver esto en todas las empresas, incluso en consultoras grandes. Todas van a por el objetivo porque no hay tiempo, ni presupuesto para realizar dichos pasos, pero son tan esenciales, que desde que los he comenzado a aplicar a la fuerza me puedo levantar a la mañana con pocos dolores de cabeza. Yendo al grano, les presento algunos esbozos en PDF de la aplicación, para que podáis observar el tema desde cerca, cómo creamos los prototipos, que son, la base y la documentación para cada desarrollador y colaborador del proyecto. No tardamos meses en hacer esto, de hecho, toda esta planificación y producción normalmente toma una semana o dos.

• Esbozo de la sección settings.
• Workflow de Invoicing
• Workflow de negociación
• Wireframe de Contrato (esbozo)
• Borrador final del módulo de usuarios.

Espero que les haya gustado, cualquier cosa nos preguntan sin dramas en los comentarios. Intentaremos responder, aunque nos encontremos ahorcados por las fechas de lanzamiento.

Normalmente, siempre se pone una palabrita al final de cada post con el nombre del autor. Aquí escribimos, en general, 3 personas: David, Manolo y este servidor. Para notificarle al mundo quienes invierten tiempo en el blog de su trabajo, cuando podrían estar jugando a las cartas en el bar de la esquina, he puesto las imágenes debajo del “quienes somos”.

Yo sé que esto no cambiará el mundo, ni Google nos va a comprar por ello… pero es que quedaba tan lindo…

Cuando doy conferencias sobre cómo hacer dinero mediante un blog siempre acabo poniendo el ejemplo que en España y latinoamérica apenas se da: una persona, experta en algo escribe sobre su especialidad y es contratada por ello.

Normalmente, esta persona, tiene trabajo, vive de ello muy bien y no necesita «pagarse el hosting» una de las excusas más burdas en este ámbito. Tampoco me refiero a los blogs comerciales, dedicados al mundo de la noticia jurídica, donde te puedes aburrir de leer una nota. Simplemente, gente que se dedique a esto, que cuente que es lo que hace. Lamentablemente, este fenómeno sólo se da en excelentes dosis en America, donde el «pago por servicio» está al día.

Siguiendo con el tema, encontrar blogs especializados de profesionales, que se dediquen a escribir sobre su tema y no a divagar en otras historias es casi nulo. Parece que existiera un miedo a perder clientes o a avivar a la competencia. El primer caso, podríamos ejemplificarlo como, si escribo sobre lo mío, cualquiera podría llegar a desarrollarlo (ejemplo un redactor de contratos) lo cual le quitaría trabajo. El segundo caso, la competencia, terror a develar el talento para beneficio del otro. Pero creo yo que, en estos casos, no hay nadie como un maestro en algo, es difícil sentarse y redactar un documento bien como lo puede llegar a hacer, por ejemplo, Wayne Schiess o construir adecuadamente un contrato como Ken Adams. Sin embargo, ambos exponen sus formas, sin restricciones para que el resto aprenda, conozca. Yo creo que, ambos se están llenando de dinero por el simple hecho de contar cosas.

Esto me gustaría verlo más a seguido en España. Sobre todo en el ámbito legal, donde la gente común y corriente tiene apenas idea. Una o varias personas con talento en estos aspectos, tanto legales, composición, redacción y negociación puedan tener sus respectivos weblogs, crear su centro de negocios basados en sus servicios se podrían beneficiar terriblemente de este mundo al cual comparo con los remedios: todo el mundo se enferma, nunca será una pérdida una farmacia.

Wayne tiene un weblog de lo más entrenido. Se focaliza, más que nada, en la escritura legal, que no es lo mismo a cómo que escribir un blog o que yo me ponga a redactar algo, carezco de conocimientos incluso si tengo manuales punto por punto sobre el tema. Pero es interesante saber que, existen muchas pegas en la forma en la que uno escribe un contrato, sobre todo si es para algo grande donde muchas veces una incomprensión del texto o una letra mal escrita puede cambiar la situación.

Valdría la pena leer blogs de gente dedicada a esto, tanto a la redacción en español de contratos como a la composición de los mismos.

Cuando se trata de argumentar, hay que dejar de lado la sangre caliente que uno tiene. Pero que le voy a hacer, soy un ser humano: insulto, pataleo, duermo, como, erupto y me pongo enojado con ciertos temas. El tema Internet Explorer 7 me tiene tan de los pelos, que no pararé hasta que me den lo que pido. Blake Ross, un chaval de veintipico de años, es uno de los fundadores de Firefox, argumenta el uso de Firefox de una forma más amable que la mía, me gusta:

People ask me, “Well, gee, if IE7 is starting to catch up to Firefox, and if they’ve got their hand back in development right now, and eventually they might actually catch up to Firefox in terms of features, what’s the benefit of using Firefox? Why are you guys still around if you say that your only goal is just to make the Web a better place?”

My answer to that is, how much can you really trust a company that five years ago completely left you abandoned? If they do, in fact, succeed in taking back some of the market share that Firefox has gotten back from them, who’s to say that they’re not going to disappear again? My issue is not so much at a product level; it’s at a company level. How do you trust a company that left everyone out in the cold for five years?

Eso amigos, eso es un punto muy importante. Algo tan importante como como preocupante. Es por eso que utilizamos lo mejor para hacer Tractis: software libre. No dependemos de ASP, ni de .NET ni de nada corporativo que nos ate, tanto económicamente como funcionalmente. Imaginaros que, usamos bases de datos de Microsoft. Para sentirnos como peces en el agua, seguimos usando material de Microsoft. Que tal si, usamos .NET y MSHTML y porqué no otras cosas. De aquí a 2 años, Microsoft decide dar de baja .NET, o mejor, deciden no actualizar .NET o cualquier plataforma de desarrollo por el simple que ahora han sacado algo nuevo. ¿Microsoft regalará todo ese software para que lo continue gente ajena a Microsoft? la respuesta es NO. Nosotros, en este caso, nos vemos en un apuro:

1. Vamos a tener que gastar más dinero en nuevas versiones de software de desarrollo.
2. Vamos a tener que actualizar servidores para poder correr decentemente el nuevo software.
3. Vamos a tener que mudar y reescribir muchas cosas, vuelta bugs.
4. Vamos a tener que corregir bugs del nuevo desarrollo.
5. Vamos a tener que ahorrar dinero para la próxima movida que haga Microsoft.

No. No creo que a nadie le interese usar un software que está desactualizado por culpa de una empresa. No creo que sea bueno para una empresa tener que esperar sentado a ver cuando le solucionan un bug, cuando le ingresan una nueva funcionalidad. De esta misma forma, no quiero un navegador que, cuando salga así se quedará, parado y varado durante otros cinco años más.

Y Firefox no es como una distribución GNU/Linux, no es un producto verde o que le falten cosas. Es un producto muy acabado y muy superior en prestaciones y soporte comparado con Internet Explorer. Lo mismo para otros navegadores: Safari, Opera, etc. No tienen nada que envidiarle a Microsoft, no tienen qué temer porque no compiten en nada.

Es una pena, porque la versión de nuestro software premia a toda la gente que utilice navegadores que soporten estándares. Los que sigan con IE, tendrán que esperar a que Microsoft se ponga al día con este tema. Nosotros no podemos modificar código fuente del Internet Explorer para mejorar vuestra experiencia de uso.