Esta semana toca hablar de las novedades en materia de edición de contrato. Hemos actualizado la barra de edición de contratos.

La idea de la nueva barra es mejorar la versatilidad de la aplicación de edición de contratos. Para ello hemos alivianado bastante la cantidad de opciones de acciones en la zona de acciones locales en el menú de la ventana de edición de contrato. Desaparecen los botones grandes grises de acciones principales y quedan solo disponibles las acciones: firmar, versiones y participantes.

La segunda gran iteración de la aplicación es la barra de edición. Ésta presenta todas las acciones principales de edición en la misma barra, permitiéndote hacer todo lo que podías hacer antes sin necesidad de realizar largos desplazamientos de pantalla.

Las nuevas posibilidades en la barra de edición son:

1. Salvar documentos.
2. Bloquear y desbloquear documentos.
3. Exportar documentos.
4. Adjuntar archivos.
5. Imprimir.
6. Firmar un documento.

Con esto damos un vuelco grande a la antigua forma de trabajar en documentos en la aplicación Tractis Contracts. Ahora notaréis que la edición es más cómoda, sin necesidad de desplazamientos, siempre trabajando en el foco deseado.

Como plus de edición, la barra cuenta ahora también con una opción de creación de tablas, la cual hablaremos en otra entrada del blog con más detalles.

Muchos de los que leen este blog ya se habrán enterado por Ernesto, que implementamos Tractis Identity en Mercadelia, un sitio de anuncios. Si bien este podría ser un post contando los ires y venires de la implementación técnica, esta entrada está más enfocada a todo lo que envuelve el mundo de los anuncios clasificados, la importancia de verificar la identidad real de sus usuarios e ideas para asegurar que la implementación funcional (diseño, usabilidad, interacción) de Tractis Identity en tu sitio de anuncios sea un éxito.

Los sitios de anuncios y la importancia de verificar la identidad real

Existen innumerables sitios de anuncios clasificados en el mundo. Uno a veces no se da cuenta y considera que solo hay 2 o 3. En efecto, sitios de anuncios de mucho peso, podemos contarlos con los dedos de las manos. Pero, si dejas aparte a los gigantes conocidos por todos, la realidad es que hay cientos de sitios de anuncios clasificados a lo largo y ancho de toda la red.

A diferencia de los foros o las tiendas online, los sitios de anuncios tienen dos grandes vigas que soportan todo el asunto: los anuncios y las personas.  Cuantos más anuncios tiene un sitio, más personas atrae y cuantas más personas visitan un sitio, más anuncios se publican. La demanda llama a la oferta y viceversa. Y digo “a diferencia de los foros o las tiendas online” porque, en el caso de los foros, por ejemplo, la identidad real de las personas que participan puede ser irrelevante. En el caso de las tiendas online, existen muchos compradores y un solo vendedor. Los que compran se identifican en gran medida con sus datos de facturación, de envío, etc. El que vende normalmente es solo una persona o empresa cuya identidad es posible verificar gracias a la pasarela de pago bancaria que utiliza, con lo que el problema de verificación de identidad en tiendas online se minimiza. Por el contrario, en los sitios de anuncios clasificados (como en cualquier marketplace online), existen múltiples compradores y múltiples vendedores, todos desconocidos entre sí. Aquí, la importancia de verificar la identidad real de la otra parte adquiere una nueva dimensión. Si no existe seguridad,  ya sea real o percibida, los compradores comprarán menos, los vendedores venderán menos, habrá menos incentivos a poner anuncios y a visitarlos.

Hasta ahora, “lo máximo en seguridad” son sitios de anuncios que tienen perfiles con estrellitas que te dicen que el sitio ha realizado distintas verificaciones y que puedes confiar en un vendedor. Sin embargo, este tipo de confianza también es limitada. Toda la información solicitada por el sitio web al vendedor se puede falsear o comprar (en eBay ocurre eso) y el sistema se quiebra a la mínima. Algunos piden el número del DNI en el registro, o fotocopias (sic) de DNI o pasaportes para realmente garantizar de una forma bastante cómica y fantasiosa que un anunciante es quien dice ser. Es imposible saber si esa persona es realmente Pepito González y vende relojes Rolex auténticos. Por si esto fuera poco, tener que gestionar la supuesta identidad de los usuarios con fotocopias de DNI y faxes es una pesadilla para la empresa y una molestia para el usuario tener que enviarlas. Y todo este esfuerzo de registro titánico para, al final, seguir con un sistema inseguro que no garantiza nada.

Como existen estas debilidades en el sistema, Mercadelia decidió no tener registro de usuarios ni sistemas de reputación imaginarios. Mucha gente se registra con un email (identidad), crea una reputación, defrauda, cierre la cuenta, vuelve a registrarse con otro email y el ciclo comienza de nuevo. Estos sistemas no sirven para nada, solo estorban y crean una falsa sensación de seguridad. Es por ello, que ofrecer sistemas de seguridad reales, fáciles de implementar y de gestionar como los que proporciona Tractis Identity conviene más que cualquier otra solución anticuada y espartana.

La implementación de Tractis Identity en Mercadelia

OK, asumamos que deseas implementar Tractis Identity para verificar la identidad real de tus usuarios en tu sitio de anuncios. ¿Cómo garantizar  que la implementación sea un éxito? En otras palabras, ¿cómo asegurar que la nueva funcionalidad sea valorada y utilizada por tus usuarios?. No basta con conocimientos de servidores y programación (la implementación técnica de Tractis Identity es muy fácil, podéis leer la documentación disponible en nuestra sección de ayuda), sino que hay que tomar una serie de decisiones en las áreas de diseño y usabilidad de la solución final.  Aquí , el tema es más complicado, ya que no existen fórmulas mágicas que puedan detallarse y sirvan para todos los casos. Cada sitio es un mundo y se pueden producir implementaciones de lo más variadas. Lo complicado no es implementar la tecnología sino pensar la mejor forma de que tus usuarios puedan aprovechar esta funcionalidad bien. De hecho, es el único desafío auténtico a superar.

Dado que en Mercadelia no se requiere registro, no podemos aplicar verificaciones de identidad a nivel de perfil, ya que no se guardan datos de usuarios como en eBay o Tractis, por ejemplo, por lo que lo de tener perfiles verificados fue desechado como idea. Entonces realizamos las verificaciones de identidad del anunciante a nivel de anuncio, y esto, más que nada, porque los anunciantes son más temporales de lo que os imagináis. El sistema de verificación de identidad opcional viene de perlas para verificar la identidad del que publica, siempre y cuando él/ella quiera.

Todo empieza cuando el usuario termina el proceso de publicación. Aquí podrá enterarse de las ventajas de verificar su identidad y comenzar el proceso:

Se pueden diseñar distintos incentivos para premiar a los anunciantes que verifiquen su identidad y así aumenten el nivel de seguridad de la plataforma. Mercadelia decidió destacar en sus listados los anuncios verificados con el color verde junto con el icono de Tractis.

Una vez dentro del anuncio, puede verse un distintivo que informa que el anunciante ha verificado su identidad para dar más confianza al potencial comprador.

Una vez vayan apareciendo anunciantes dispuestos a verificar su identidad, Mercadelia planea ir ofreciendo un mayor nivel de integración y más ventajas:

1. Posibilidad de filtrar en búsquedas por anuncios verificados.
2. Proceso de publicación automática de anuncios, sin necesidad de confirmaciones previas por email por parte del anunciante.

Otras posibles implementaciones

Existen más tipos de implementaciones que encajan mejor con sitios de anuncios que requieran registro o que ofrecen perfiles de usuarios. Por ejemplo:

1. Ofrecer login seguro a tu cuenta (mediante el uso de DNIe o cualquier certificado válido).
2. Ofrecer registros rápidos (sin comprobaciones previas).
3. Proceso de publicación de anuncios lineal y directo (sin moderación previa).
4. Perfiles con reputación inmodificable (para que una persona no pueda falsear su reputación creando varias identidades distintas).
5. Filtros de confianza (búsqueda solo de anuncios verificados).
6. Prioridad en resultados de búsqueda (los anuncios verificados aparecen al principio de la lista de resultados).
7. Mayor relevancia en listados (los anuncios verificados aparecen claramente destacados con recuadros, colores de fondo, tipos de letra, etc).

Estoy seguro que se me quedarán más ideas de implementación en la galera, pero ya saldrán a la luz y seguiremos ampliando el servicio para que los sitios de anuncios online, compraventa,  intercambio o actividad económica entre usuarios generen más responsabilidad de los anunciantes por lo publicado,  más seguridad jurídica en caso de que surjan disputas, mayor nivel de confianza en la plataforma y, por tanto, mayor número de compradores, vendedores y transacciones.

En enero anunciamos la posibilidad de utilizar Tractis para generar tus propias integraciones de contratación en tu sitio web. El sistema es simple:

1. Creas una plantilla privada con variables.
2. En la página del documento de plantilla, en la pestaña Botones activas la funcionalidad.
3. Copias el código del botón que quieres utilizar y lo pegas en el código fuente de tu sitio web.

Cuando un usuario haga clic en ese botón, automáticamente Tractis genera un contrato y todo lo que necesitas para que el usuario rellene los datos que le faltan al contrato y la posibilidad de firmar.

Ahora mismo, este proceso sigue en pie, pero hemos remodelado varias cosas para ampliar el abanico. Para empezar, tenemos botones nuevos, como podéis ver en los ejemplos:

Además de más botones, hay variedad de color. Suele ocurrir que los botones blancos no se apreciarían bien en páginas de fondo claro, así que hemos utilizado nuestra normativa identidad para generar botones oficiales para sitios de fondo claro. De esta forma tienes los mismos botones, tanto en inglés como en español, disponibles en blanco y negro.

Para más información, pueden ver este tipo de integración y otras que ofrecemos a nuestros clientes para que integren contratación electrónica en su sitio web.

¡Buenas noticias para todos! Desde hoy podéis utilizar la nueva interfaz de Tractis.com. A lo largo de estos meses, estuvimos trabajando duro para estudiar los problemas y las mejores soluciones. Así que, con las cosas claras, en un mes hicimos posible este nuevo lavado de cara y replanteamiento de algunas funciones. Como ya hemos hablado de lo que vendría en varias entradas del blog, nos limitaremos a comentar superficialmente los detalles más jugosos de la nueva interfaz:

Listados

Nuestro nuevo Tablero se ve así:

La sección de contratos, con su listado mejorado en el cual puedes ver los contratos firmados, bloqueados y borradores, ¡todo a un clic!. Las pestañas sirven para filtrar tipos de contratos según su estado y es uno de los nuevos elementos que agregamos a nuestro sistema de interfaz para organizar más información por documento y sección.

Las novedades de los listados:

1. Aumento notable de ítems por vista. De 10 a 25 ítems.
2. Información más relevante.
3. Sistema de tickets, para diferenciar estados.
4. Nuevo sistema de favoritos (ahora son una estrella al principio del listado).
5. Pestañas de filtrado rápido según el estado de cada ítem.

Vista de un documento

Cuando abras tu primer contrato o plantilla, notarás grandes cambios. Para empezar, implementamos pestañas, nuevos botones y menús de usuario. En esta captura podrás ver un documento de ejemplo:

Las novedades de los documentos:

1. Nuevo diseño de hoja de documento.
2. Hemos retirado los botones de la parte inferior y los hemos acomodado en la parte superior del menú de acciones.
3. Nuevo sistema para informar al usuario de sus posibilidades con el documento.
4. Organización con pestañas para editar, configurar alertas y otras opciones.
5. Nuevos menús de información, participantes, versiones.
6. Mejor redistribución y aprovechamiento de los espacios.
7. Menos código, páginas más rápidas.
8. Información de los firmantes en la página del contrato y no fuera como lo hacíamos antes.
9. Los equipos de participantes van en módulos separados para mejor identificación.

Formularios

Ya hablamos de los formularios en el blog y quería mostrarles el nuevo look de los mismos, por ejemplo, para crear un contrato:

O bien el formulario de preferencias de usuario:

Las nuevas mejoras de los formularios:

1. Mejor aprovechamiento de espacios.
2. Normalización de cientos de etiquetas.
3. Mejora en estilos de elementos: campos de texto, listas, botones.
4. Nuevos separadores.

El nuevo esquema aprovecha mejor el espacio dando más cabida a otro tipo de elementos de diseño que incorporamos como los separadores. Con los separadores podemos organizar varias mini-secciones de configuración e información en documentos y formularios. Como comentario final hemos normalizado todos los elementos de formulario para que tengan el mejor aspecto posible.

Ventanas modales

Como les venía comentando, las ventanas modales también han recibido un buen lavado de cara, ya habíamos comentado en un post esto, pero ahora dejan de ser unos bloques oscuros de información para tener una estructura más organizada y diferenciada, con botones de acciones normalizados a lo largo de todo el sitio. La información está actualizada y para los que venían usando la aplicación no tendrán problemas en reconocer dónde están las cosas. Una muestra de ello:

Las mejoras que podéis encontrar son:

1. Barra de títulos activas según el estado: de color verde y rojo cuando hay errores.
2. Nueva alerta dentro de la ventana modal para mejorar la legibilidad de posibles errores.
3. Normalización de botones y acciones.
4. Menos código y mejor semántica de estructuras.
5. Hace un mejor uso de los nuevos estilos de formularios.

Mejoras generales de la aplicación

Como hay cientos de mejoras en general, enumeraré las más importantes y visibles a lo largo de la aplicación:

1. Alertas:
   1. Nueva estructura y estilo.
   2. Mejora de los faldones informativos para los visitantes de Google y para las peticiones de información.
2. El spinner está rediseñado, para que ofrezca información sobre el proceso que se está realizando. ¡Adiós al spinner viejo de la versión beta!
3. Reducción notoria del código HTML y CSS:
   1. Las páginas ahora pesan menos y requieren de menos procesamiento en ordenadores, hace un mejor uso de los recursos.
   2. Todas las estructuras han sido revisadas y mejoradas para asegurar el uso correcto y evolutivo de la aplicación.
   3. Menos hojas de estilos y menos cantidades de clases y IDs.
4. Se han eliminado muchas imágenes en el sitio ganando así mucha velocidad de carga de páginas.
5. Textos:
   1. Corrección de muchos textos explicativos para mejorar la lectura general de la aplicación.
   2. Nuevos artículos en la sección de ayuda.
   3. Mejora general de denominaciones en las etiquetas de los formularios.

Y como siempre, esto no se queda aquí. Nuestra filosofía, como siempre, es la de seguir mejorando la aplicación como habéis comprobado a lo largo de 2 años no hemos dado respiro. Porque nos gusta y porque nuestra tarea es la de tener y mantener la que es la mejor plataforma web que permite negociar, gestionar y firmar contratos 100% online y con plena validez legal en el mundo offline.

Vuestros comentarios, tanto mediante la opción de Feedback de la aplicación como por el blog son más que bienvenidos.

Esta semana vi una presentación fabulosa sobre nuevas técnicas de desarrollo CSS: CSS orientado a objetos (OOCSS). Nicole Sullivan, nos cuenta una forma interesante –que no es nueva pero tampoco se consolidó de forma oficial– de desarrollar CSS para sitios de grandísima escala como lo es Yahoo!, pero que también sirve como buena filosofía de desarrollo para sitios pequeños y medianos.

La idea básica se resume en crear componentes de estructuras que sirvan a lo largo de todo el sitio, y luego, mediante hojas de estilo particulares (o personalizadas) puedas extender lo que necesites a medida que vayas creando nuevas estructuras. De esta forma defines por ejemplo: módulos de contenido, de menús, de listas, de pestañas, de cabecerazas, etc. Hasta aquí, no hay misterios, todos hacemos esto en parte.

En Tractis empezamos un primer framework hace 2 años, crecimos de 0 a 100 en menos de un año lo cual nos ha causado algunos inconvenientes para poder crecer de forma orgánica y rápida con nuestro primer intento modelo. Esto lo anotamos en cuentas pendientes y con nuestra nueva interfaz agregamos más capas de “abstracción” que normalmente necesitaríamos. Nuestra estructura actual es esta:

1. authentication-pasarela.css
2. authentication.css
3. homepage.css
4. iehack-customs.css
5. lightbox.css
6. main.css
7. print.css

Mirando los nombres de los archivos podrán deducir algunas partes de Tractis y otras no. Nuestra hoja principal, es la hoja main.css la que nos permite tener todas las estructuras de Tractis definidas, digamos que es la que tiene todos los frameworks actuales: formularios, layouts, colores, tipografías, contratos, etc. Bien, el problema de trabajar así es que con el tiempo el tema se hace inmanejable y pierdes conciencia de todas las estructuras del sitio y terminas creando nuevas hojas de estilos para casos particulares que tienen sus propias estructuras, colores, etc.

Nuestro nuevo framework que venimos trabajando ordena este caos y nos permite hacer unas cositas extra que os vendría de maravilla si podéis aplicar. Para empezar, tenemos un conjunto nuevo de hojas de estilo numeradas:

1. 01-layouts.css
2. 02-fonts.css
3. 03-header.css
4. 04-nav.css
5. 05-subheader.css
6. 06-alerts.css
7. 07-content.css
8. 08-menus.css
9. 09-buttons.css
10. 10-footer.css
11. 11-list.css
12. …

Al principio os parecerá un caos, ¡más de 11 hojas de estilo por página!, pero no es así. En realidad, usamos más de 11 hojas de estilo pero en el momento de subida, un proceso automático las une en una, que denominaremos main.css. Bien, ese es nuestro humilde acercamiento a lo que vendría a ser un framework de CSS. Ya hablamos de lo bueno que era usar este tipo de modalidad de desarrollo, pero lo bueno de hacerlo en particiones es que es más organizado de actualizar y hacer crecer. No es lo mismo entrar un día a un archivo de CSS con 1500 líneas de código y ponerse a ver todas las dependencias y herencias que tenga a hacerlo en sólo un trozo de archivo en concreto.

Siguiendo el tema, esta organización nos permite definir dónde se alojarán nuestros componentes. Cada componente tendrá una cantidad de clases características que reutilizaremos a lo largo de nuestro sitio. Cada componente se basa en una serie de estructuras que ya hemos definido y creado, estas las definimos en el código con una serie de clases que reutilizaremos a nuestro gusto, para que esta regla se cumpla, como explica Nicole se deben dar estas condiciones:

1. Debe estar formado por clases y no debe estar formada por IDs.
2. Debe tener colores neutros, estos se deben formular luego aparte.
3. Debe tener cada parte definida y parametrizada.
4. Esta estructura debe poder ubicarse en cualquier parte del sitio y reaccionar ante las reglas.

La primera regla nos permite tener libertad. Los IDs en general nos traen conflictos para reproducir estructuras. Mucha gente usa un ID para definir por ejemplo un listado pero si un bendito día decidimos poner dos listados en un mismo documento ya se armó la gorda. Por eso, definir un tipo de menú conviene más utilizar una clase que un ID. Los IDs son excelentes para definir estructuras padre, las cuales nos ayudan a definir herencias simples con más comodidad pero nunca, nunca, las características de un módulo en particular.

La segunda regla, es la de parametrizar y definir cada parte de un módulo. Por ejemplo, en nuestro framework, tenemos definido los menús de esta forma:

<div class="menus">
  <div class="mtitle">
    <h3>Aquí va el título</h3>
  </div>
  <div class="mcontent">
    Aquí ponemos un contenido que definiremos en una hoja custom.css
  </div>
  <div class="mfooter">
    Aquí ponemos un pie de menú y <a href="/compare">Un enlace</a>
  </div>
</div>

De esta forma, sabemos qué partes tiene un módulo de menú, y nunca nos saldremos de esta línea de estructura. Teniendo la documentación de estructuras podemos hacer miles de menús de forma automática sin tener que dudar qué utilizar y qué no, pero lo mejor, como tenemos parametrizado todo, podemos, por ejemplo, quitar el pie de página de este módulo en particular y el menú seguirá teniendo un orden y una prolijidad¹ máxima.

Definiendo cada parte del sitio de esta forma, nos permite luego acelerar nuestros tiempos de desarrollo, incluso, nos viene bien para bocetar cosas ¡sin tener que tocar CSS! De esta forma, si la semana que viene queremos hacer una sección nueva en Tractis, sólo tenemos que escribir las estructuras básicas en una vista de plantilla sin tocar CSS:

1. Definimos si tendrá título o no.
2. Definimos un área de contenido (con una columna o dos).
3. Definimos los menús y su contenidos.
4. Definimos el tipo de contenido principal de esa sección: listas, tablas informativas, etc.

Así, lo que nos llevaría unas dos semanas de planear, armar y probar podemos reducirla a unos 2 o 3 días.

Me gustaría saber de vuestra mano qué tipo de organización utilizáis, y como desarrolláis vuestras estructuras de CSS y HTML en los proyectos, así seguimos este debate interesante.

¹ Prolijo: 2. adj. Cuidadoso o esmerado.

Como veníamos comentando en las entradas de este mes y el pasado, seguimos con la línea de modificaciones para mejorar el uso de Tractis. Esta semana, les contaré algunas de las ideas que pensamos para mejorar las ventanas modales.

Qué tenemos que mejorar

Existen varios aspectos que tenemos que mejorar en las ventanas modales y en base al feedback recibido y la dedicación que le entregamos al tema nos queda esta lista:

1. Modularización de la ventana modal.
2. Integración con el sistema de apariencia.
3. Feedback visual y estructural según las acciones de nuestros usuarios.
4. Mejora del sistema de botones.
5. Neutralización del módulo.

Estructura de la nueva ventana modal

Ahora mismo la ventana modal es un bloque entero de elementos HTML que no nos permite iterar demasiado. Nos dimos cuenta cuando quisimos hacer algo extra para la sección de configuración del sistema, donde tuvimos que adaptar varias cosas dentro de la ventana modal. Tuvimos que realizar cambios a los títulos y otras zonas que no estaban preparadas gráficamente ni estructuralmente para soportar cosas como: tablas, módulos de selección de certificados, etc. Por lo que nos causó bastantes problemas para las tareas que debíamos realizar. Luego tuvimos problemas con los botones, existe una anarquía total a la hora de parametrizar el orden, con qué etiquetado y la cantidad por ventana. Al poco tiempo agregamos una “x” para ofrecer la posibilidad de cerrar la ventana entera, lo que posibilita cancelar el proceso pero todas estas cosas en la ventana modal actual no nos satisfacía del todo.

En el gráfico anterior, hicimos un esquema básico de la ventana modal actual y la que necesitamos. Como podrán ver, tienen las mismas estructuras sólo que, las divisiones son más delimitadas: cabecera, cuerpo variable y zona de decisión. La cabecera tendrá su forma y acción, algo que comentaré más abajo de esta entrada, mientras que el cuerpo variable será la nueva parte que dará vida al sitio. Por último, la zona de decisión, donde los botones aparecen y actúan según las acciones que los usuarios realicen dentro de la misma.

Feedback

Pensamos una forma de informar al usuario sobre operaciones y acciones de una forma intuitiva y clara dentro de una ventana modal: Esto es genial, nuestros clientes pueden estar más informados sin necesidad de crear nuevas alertas y mensajes, y ofrecerles siempre una opción o más viables cuando realice alguna acción de importancia.

Para empezar, la ventana modal nueva será más orgánica. Tendrá varios estados diferenciados: estándar, aviso y espera.

Las ventanas estándares tendrán el color de la barra del título que elijas en la sección de Apariencia, mientras que el resto se mantendrá de forma normativa. Esta barra de título igualmente tendrá dos estados más: espera, utilizado cuando hacemos algún proceso, como por ejemplo, comprobar certificados y otro de aviso, que lo utilizaremos cuando algo no vaya bien o bien para alertar al usuario de algo en concreto.

En la zona de decisión queremos que tenga más vida propia. Que actúe según las consecuencias de cada acción: si el usuario rellena los campos que el botón de enviar se active, si el usuario hizo una opción que hace que la ventana entre en un estado de espera, entonces que elimine los botones y deje otro correspondiente a las acciones que posibiliten dicha espera, así evitamos que los usuarios hagan dos veces “clic” para enviar datos o no se den cuenta de que tipo de cosas pasan.

Como siempre, os dejo unos cuántos PDFs de los wireframes que realizamos para trabajar asuntos de diseño de interfaz.

Dentro del proceso de reajuste gráfico y otras mejoras de usabilidad, la semana pasada revisamos una de las partes clave del sitio: la cabecera. La cabecera en materia de importancia de estructura es como el alma del sitio. Nuestra cabecera actual creció de un buscador, un logotipo y una barra de navegación a tener más cosas. Digamos que, con el tiempo fue creciendo de una forma poco desordenada, ya que no estaba concebida para tener dichas opciones. Pero esto cambió.

Como consigna principal, la armonía es un factor importante en la nueva cabecera. La disposición de las estructuras estaban muy desajustadas y desproporcionadas. En la nueva trabajé para buscar ese equilibrio, esta armonía que tanto cuesta y que podemos ver en este gráfico donde verán el antes y el después.

La segunda consigna es re-alinear varias funcionalidades, agruparlas de otra forma y sacarlas de la barra principal de navegación. Para ver los resultados, os dejo el primer y el segundo esquema de la nueva cabecera y sus aplicaciones. En los esquemas podrán observar que, la cabecera cambia notablemente en comparación con el Tractis actual:

1. En la primera franja de la cabecera, la ocupamos para las utilidades de usuario y opciones de configuración.
2. Por primera vez empezamos a indicar jurisdicciones, idiomas como corresponde.
3. La barra de navegación ya no contiene opciones de usuario, ni créditos. Sólo las áreas principales de la aplicación.
4. Las opciones de la barra despliegan más subopciones, permitiendo una escalabilidad suficiente.
5. Las opciones de usuario están sujetas a varios usos, por ejemplo, al destacar contratos, plantillas y marcarlos como favoritos haría que aparezca el indicativo en la parte de usuario.
6. Reducción notable de efectos, colores y gráfico en la cabecera para ayudar a neutralizar la aplicación y permitir así que destaque el logotipo de Tractis o de uno de sus partners.

Nuestro otro problema fue que nos quedamos paralizados a la hora de aplicar la cabecera actual con otras aplicaciones, por ejemplo, para imprimir, para contratos copia exportados, para revisión de versiones, etc. La nueva cabecera está enfocada a otras aplicaciones en el sitio. Por ejemplo, en el PDF número dos podéis apreciar otros estados de la cabecera para cuando un cliente envía contratos y otro ejemplo cuando quiere imprimir un documento. En ambos casos la cabecera respeta las formas y la armonía de la principal, pero las opciones cambian y se le da relevancia a otro tipo de información en comparación con lo que tenemos ahora y que no hemos tenido tiempo de mejorar.

Lo que vayáis a mirar en los PDF no es el resultado gráfico final de la aplicación, son esquemas representativos de lo que la aplicación tendrá o bien posibles aplicaciones, así que toda la información incluida es de ejemplo y una oportunidad de compartir nuestro trabajo con vosotros.

La próxima semana os contaremos las revisiones que le estamos haciendo a las ventanas modales.

Como la semana pasada, esta semana les hablaré de algunos detalles de diseño que vendrán en los futuros formularios de Tractis. Llevábamos un tiempo ya pensando en cómo mejorar los formularios y las vueltas que le estuve dando.

Cuando creamos la primera versión de Tractis, utilizamos en una extensiva mayoría, un modelo de formulario para todo. Cada parte del sitio tenía una misma estructura de HTML, lo cual nos permitía hacer muchas cosas sin tener que re-pensarlo todo. Un ejemplo de la estructura base era:

<div class="form">
  <div class="moduloA">
    <p>Texto explicativo</p>
  </div>

  <div class="moduloB">
    <label>Etiqueta <input type="text" /></label>
  </div>
</div>

A diferencia de otros formularios, este lo creamos diseñando pequeños módulos para definir las estructuras. Así, de esta forma, podemos tener varios tipos de formularios usando el mismo código pero sólo actuando de forma diferente, según el tipo de “módulo” que yo le ordene nuestra hoja de estilo va montando los elementos del formulario. De esta forma, cuando observas un formulario en Tractis podrás ver que las etiquetas y los campos de texto siempre están ubicados de una misma forma:

El problema de utilizar esta forma es el aprovechamiento que hacemos del espacio en la aplicación y las limitaciones de llevarlo a otros ámbitos como ventanas modales, módulos de menús, etc. Algunos formularios no necesitan tanta verticalidad, debido a que los presentamos en una ventana modal (la de firma por ejemplo) mientras que en otros la verticalidad es necesaria. Necesito tener más ventajas de espacio, que con CSS y una concienzuda forma de armar los formularios podría tener elementos dispuestos de esta forma:

¿Cómo mejorar esto? Una solución simple fue crear más variantes y una estructura enfocada más a todas las formas de presentación que tiene Tractis. Con esto en mente puse manos a un pequeño framework en CSS para formularios que dentro de poco lo tendremos en línea. La idea es simple: crear más niveles de presentación mediante el uso de tres clases: fnormal, fhorizontal, fvertical y modularizando los elementos así puedo, recrearlos de diferentes formas. En las pruebas que hice, los resultados fueron excelentes y me sentí muy conforme.

Ahora no utilizo más módulos, sino una estructura de grilla dispuesta de esta forma:

<div class="formularios fnormal">
  <div class="grilla1">
    <label>Nombre:</label>
    <input type="text" name="some_name" value="" id="some_name" />
  </div>
</div>

De esta forma, defino varias cosas:

1. Usando la clase formulario, doy los estilos gráficos básicos de la aplicación.
2. Usando la clase fnormal, fvertical o fhorizontal defino cómo se dispondrán las etiquetas y los campos de texto.
3. Usando la clase grilla[número] puedo definir varias estructuras dentro de un modelo fnormal, fvertical o fhorizontal. De esta forma, si quiero representar las opciones en radios o checkboxes no tengo que tener todo coloreado, sino que puedo utilizar texto normal, sin tener que agregar docenas de clases y variantes tanto en mi código HTML como CSS.

Con estas nuevas armas, puedo pensar en varias cosas, seguir desarrollando y hacer pequeñas modificaciones sin tener miedos ni extender la parte de formularios en CSS demasiado a tal punto que no lo entienda ni Cristo. También de esta forma doy formas fáciles a mis compañeros de hacer las cosas, simplemente tienen que aprender dos cosas y definir los elementos del formulario según estas pequeñas normas y poder usar, por ejemplo el formulario de identificación en varios ámbitos.

Hola a todos. En Tractis queremos darle una vuelta de tuerca a toda la interfaz de la aplicación. Si os cuento todo lo que hemos hecho en el lapso de 12 meses, no se lo terminarían de creer. Si no me creen, se pueden pasar por el archivo del blog.

Es por ello que decidimos darle una vuelta de tuerca para mejorar la experiencia de uso. Valga la redundancia, y a diferencia de otras empresas con productos propios, en Tractis todos usamos Tractis de una forma medio friki. No sólo para crear contratos, la utilizamos para varias cosas: plantillas, documentación, discusión, etc. Es una herramienta de la mar completa. Como somos usuarios inquietos, con el tiempo nos quemamos con algunas cosas. Empezamos por notar molestias de uso, sobre todo porque lo usamos extensivamente.

De todas estas cosas, creamos una lista resumida y concreta de las partes que cambiaremos en un futuro cercano: cabecera, navegación principal, rotulado de secciones y sub-secciones, estructura contenido de la aplicación, menú local y menú de acciones, pie de página, formularios, ventanas modales, tablero de la aplicación, apariencia. Y la semana pasada hicimos dos: formularios y menú de acciones.

De los formularios no voy a comentar nada ahora, pero las ideas del menú de acciones (o menú local, como algunos le llaman), sí, y esto es lo que les puedo mostrar:

Las cosas como son: los botones sólo deben generan acciones; las cajas de información y opciones son otras cosas. Por ello, reducimos tamaño en los botones de acciones, para que se parezcan más a un botón que a un mini-banner. Las cajas de información serán negativas: espacios blancos, bordes y divisiones de cosas con fondos de colores muy suaves.

No sólo retocamos gráficamente las cajas y los botones, también cambiaremos algunas funcionalidades para que editar detalles, borrar participantes o realizar cualquier otra operación sea más fácil. Quitaremos muchos efectos y eventos de AJAX que realmente aportan menos valor y reforzaremos aquellos que sí.

De esta forma, las cajas de información las puedo preparar para varios casos: opciones de filtrados, mini-formularios, caja de información adicional, cajas de tips de ayuda, etc. Los botones dejarán de abrirse y plegarse como si fueran multifunción, sino más de ir a una acción en concreto: crear documento, ir a otra sección, salvar, borrar, etc.

Para un mayor deleite, os dejo (uno por aquí y el otro por allá) dos documentos PDF con algunos de los sketches que hicimos.

Para la próxima os contaré como estamos trabajando con los formularios.

Y tenemos página de inicio nueva. Luego de dos semanas intensivas, al fin estrenamos la nueva forma de entrar y conocer Tractis. Todas las semanas estamos mejorando cada aspecto de la aplicación y, me muerdo la lengua por no decir las cosas que vienen.

Cómo empezó todo

Cuando salimos al aire con Tractis teníamos una página de inicio similar a la que tenemos ahora. Cuando digo similar, me refiero a que, tenía una organización de datos igual a la que podéis observar ahora: iniciar sesión, tour, etc.

En aquella época, Tractis era un proyecto cerrado, que sólo favorecía a un grupo de betatesters, e invitaba a cualquiera a serlo. Era una página de inicio a modo de trailer de lo que vendría después en agosto del 2007. Nuestra aplicación, que estaba creciendo tenía look and feel más oscuro que el actual, y era lo mejor que podíamos hacer para invitar a la gente a descubrir Tractis en aquel entonces, dado que el parque de DNI electrónicos era bajo en España.

Pero luego vino el lanzamiento del sitio, en su versión 1.0. Tractis ya dejó de ser un sitio beta, cerrado al público, y comenzamos a ofrecer la posibilidad de que la gente se registrara. Hicimos una refactoría total de toda la aplicación; nuevas secciones; nuevas convenciones; nuevo estilo gráfico, etc. Abrimos la aplicación de pi a pa para que todo el mundo pudiera descubrir, sin miramientos, la aplicación. Aprovechamos todo nuestro conocimiento, nuestra forma de programar estándar para que Google nos trajera una inmensa cantidad de visitantes, que se registraron y comenzaron a utilizar la aplicación, mayoritariamente, para compartir plantillas.

Si bien la cantidad de visitas subió notablemente, esto produjo un daño colateral que identificamos: la gente comenzó a pensar que Tractis era un sitio sólo para compartir plantillas. Lo cual es algo realmente falso: estamos especializados en firma electrónica, y además de integración de servicio de firma electrónica y comprobación de identidad en sitios de terceros y que la gente se enterara de esto de sorpresa no beneficiaba mucho.

Ahora que el DNIe está en auge, queríamos potenciar las herramientas de negocio que teníamos para que Tractis no se quedara sólo en una herramienta exclusiva de creación de plantillas. Diseñamos una página con funciones de contenido para dos casos de uso muy concretos. De esta forma podemos transmitir a nuestros usuarios nuevos más información sobre la funcionalidad principal de Tractis, sino que también otras cosas maravillosas: lector gratis, API, editor nuevo, firma digitales, etc.

Producción

El sketching de la aplicación, como todo, parte de la concepción del papel y boli. Hacemos muchos ejemplos con papel y boli para hacer el bosquejo inicial. Luego, todo el bosquejo (obra digna de movimiento abstracto) se pasa a PDF, con elementos de nuestro kit GUI que tanto aprovechamos para tener un panorama claro, con copy fantasía de la aplicación.

El código fue una parte dura, pero entretenida de cómo montar la nueva página. Utilizamos un slider bastante popular llamado Coda Slider. Nos vino al pelo y nos ahorró unas cuántas horas de desarrollo, y tuvimos, claro, que meter nuestras manos a fondo para que muchas de las cosas que no contemplaba el slider funcionara con el esquema de uso que planificamos para Tractis: casos de uso, diferentes cantidades de pestañas por casos, colores, contenidos, etc. El trabajo de código y puesta en marcha fue de aproximadamente 1 semana.

Otra parte importante, y que, en muchos casos, cuando hablamos de diseño y programación es el copy. Mucha gente, me incluyo, nos olvidamos de comentar esta esencial parte del desarrollo que hace del proyecto algo más sólido y con forma, de hecho, es algo tan vital para nosotros que cada nuevo desarrollo intentamos mejorar la forma de aprovechar un buen copy con el diseño y la programación para que nadie se sienta perdido en la aplicación. La nueva página de inicio además, necesita esto: una explicación clara de qué es Tractis, para qué sirve y las ventajas que uno gana al utilizarlo.

El resultado

Lo que hoy podréis apreciar al entrar a nuestra dirección es una página de inicio que tiene información producida exclusivamente para dos tipos de usuarios: los usuarios que no conocen Tractis y nuestros usuarios habituales. Cada caso cuenta con un set de información y herramientas exclusivas para cada necesidad.

Los usuarios no registrados podrán enterarse nuestra principal especialidad: una herramienta para hacer y firmar contratos online que puedes hacer validar en el mundo offline, además de la interesante promoción del lector de tarjetas inteligentes, registrarte con un clic, aprender más sobre la API de Tractis y más. Nuestro principal objetivo en este caso es que la gente sepa que es Tractis y se registre.

Los usuarios que ya son habituales en Tractis no necesitan ver todo esto, por ello, habilitamos una caja de inicio de sesión rápida y en el visor exponemos todas las cosas geniales que venimos desarrollando para que nuestros usuarios se conviertan en powerusers. Queremos que nuestros usuarios le saquen el jugo a toda la aplicación. Conociendo detalles de la API, utilizando el lector, conociendo nuestras tarifas, colaborando con Tractis y con futuras nuevas funcionalidades de la aplicación. Nuestro principal objetivo en este caso es que el usuario tenga a mano las cosas para iniciar sesión y aprenda de una forma cómoda las nuevas cosas que trae la plataforma.

Vuestra opinión

Seguimos abiertos a vuestras sugerencias, es más, suplicamos que nos envíen más, porque sin dudas nos vienen al pelo. Sabemos que no podemos contentar al 100% de la gente en todo, pero no desestimamos nunca una sugerencia vuestra. Es vital para una empresa que sus usuarios les realicen sugerencias, incluso las más alocadas. Para nosotros vuestra sugerencia, vuestros comentarios ya sean por el blog o bien, utilizando el enlace de “Feedback” de la aplicación nos da tremenda emoción.

¡Hasta el próximo anuncio!