• Un tablero más ajustado.
• Documento de bienvenida con resumen de las mejores funcionalidades
• Atajo para crear documentos nuevos usando una plantilla de tu librería privada.
• Estadísticas generales de uso de la aplicación

Un tablero más ajustado

Durante 3 años el tablero de Tractis Contracts siempre fue el listado de contratos en borrador, bloqueados (en edición y sin firmar) y los documentos firmados. Fuera de esto, el tablero no había sufrido cambio alguno que pueda documentar. Si bien la practicidad cumplía su objetivo, quedaban cosas pendientes por montar para hacer el tablero una página la cual no tener que escapar ni bien se terminaba de cargar.

Para ello hemos reducido notablemente la cantidad de contratos en la lista. Esta decisión está hecha en base a algunas sugerencias de usuarios más asiduos de la aplicación, que ven su tablero minado de documentos y que hace la página un poco más larga de navegar. Para ello, hemos reducido la lista de documentos en la lista a 10. Si pasas de ese número, saldrá el paginador. De esta forma mantenemos el tablero más compacto y menos lleno de información.

Documento de bienvenida

Ahora, al crear una nueva cuenta de usuario en Tractis Contracts, desaparecen los listados fantasías que hicimos referencia en un pasado y nos han servidor para investigar el impacto que éstos generaban. Contrario a nuestra creencia, los listados fantasía en cuentas nuevas generaban más dudas que pistas sobre la forma real de la aplicación. Por ello, hemos decidido remodelar la funcionalidad para que, al crear una cuenta nueva, el sistema automáticamente crea un documento con un resumen completo de las funcionalidades más importantes de Tractis Contracts.

Esperamos que este cambio aliente a los usuarios a interactuar mejor con nuestra aplicación en su primer uso. Que puedan leer sobre las funcionalidades clave, cómo usarlas y, por qué no, ¡realizar su primera firma de pruebas!

Atajos para crear contratos desde plantillas

Los usuarios avanzados y más avezados de Tractis Contracts podrán ahora, a un sólo click, crear contratos nuevos basados en sus plantillas. Esto evita tener que hacer más de 4 clicks para crear un contrato basado en una plantilla. La forma antigua requería estar en una plantilla, darle a un botón y comenzar a rellenar detalles. La nueva forma está presente en una caja en vuestro tablero. Veréis vuestras plantillas que se guardan en vuestra librería privada, escoged una y al darle al botón Empezar podréis ya estar en el contrato hecho.

Los usuarios Business además tienen diferenciados en su listado las plantillas de su Librería Business y su Librería Privada para mejor orden.

Estadísticas

Muchos usuarios sobrepasan los 40 contratos, en muchos casos, los nuevos desplazan en el listado a los antiguos, por consiguiente uno puede perder la noción de la actividad. En Tractis nos preocupa que no puedas llevar o tener el control de determinados aspectos de tus contratos, por ello hemos decidido crearte un módulo de estadísticas, básico pero eficaz para que sepas:

• Cuántos contratos for firmar tienes.
• Cuántos contratos firmados tienes.
• Plantillas en tu librería.
• Número de invitaciones a contratos pendientes por aceptar.

Esperamos que estas mejoras alegren vuestro día a día en nuestra aplicación. Para cualquier duda, estamos a vuestra disposición para responder cualquier pregunta, sea en el blog o en cualquiera de nuestras aplicaciones usando la herramienta de feedback.

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.

La nueva barra te da acceso a:

1. Todos los productos disponibles de Tractis.
2. Tu cuenta de usuario.
3. Tu cuenta business.
4. El crédito actual en esa aplicación activa.
5. La ayuda.
6. Botón de cerrar cesión.

Pero los cambios no se ciernen únicamente en la navegación principal de productos, sino también en la cabecera:

1. Notaréis que hemos cambiado los logotipos y esto se debe a una nueva política de productos, los cuales tienen un logotipo indicativo del tipo de cuenta que tengáis.
2. Nueva barra de país e idioma activo.
3. Inclusión del idioma catalán.

Con esto completamos una parte del desarrollo y ahora nos queda una segunda revisión, que tratará sobre la normalización de crédito a lo largo de todas nuestras aplicaciones.

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.

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.

En resumen, las interfaces que están dirigidas a mejorar la habilidad del usuario para permanecer en el flujo no deberían infravalorar la importancia de la velocidad para apoyar la creatividad, calidad y diversión. Cada vez que hay una interrupción, literal o conceptual, que se interpone en el camino de los usuarios concentrándose en sus tareas, se pierde el flujo. Las interfaces lentas, las cuales defino como aquellas que que se interponen en el camino de usuarios que realizan acciones tan rápido como las piensan, son problemáticas.

- “Interfaces for Staying in the Flow” de Benjamin B. Bederson.

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.

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.

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.

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.