Desarrollo E-commerce: car-mechanic-huntington.co.uk

#car-mechanic-huntington.co.uk - sitio profesional para un taller mecánico

El proyecto car-mechanic-huntington.co.uk presenta los servicios de un taller mecánico y permite reservar cita. El público son propietarios de coches de la zona, personas que persiguen una avería concreta y pequeñas empresas que mantienen varios vehículos en circulación. El sitio salió a producción en 2012 y el trabajo llevó unas seis semanas.

#El mapa es lo más caro de la página de contacto

Empiezo por aquí porque es el elemento que el cliente encarga en media frase y que cuesta más que todo el resto de la página de contacto junto.

Un mapa incrustado es script ajeno, hojas de estilo ajenas y una tanda de peticiones de mosaicos de imagen, todo desde una infraestructura sobre la que no tenemos ningún control. En un sitio pequeño ese único componente pesa habitualmente más que todo el contenido de la página. Y se ejecuta para cada visitante, incluido el que entró a por un número de teléfono y se habrá ido en diez segundos.

La solución consiste en no cargarlo con la página. Por defecto se muestra una imagen estática con la ubicación marcada y la dirección en texto al lado; el mapa interactivo arranca solo cuando alguien lo toca. Quien necesitaba la dirección la tiene de inmediato, y quien quiere una ruta hace un toque más y recibe la herramienta completa. El orden es el inverso del intuitivo, y por eso la versión pesada acaba tan a menudo siendo la predeterminada.

Conviene señalar que esta decisión no es una optimización aislada, sino el mismo criterio que recorre todo el proyecto: lo que sirve a una minoría de visitantes no debe pagarlo la mayoría, y lo que la mayoría necesita debe estar disponible sin esperar a nada.

#Una cita no es un campo de formulario

El módulo de reservas parece un formulario de contacto con un campo de fecha. No se comporta como tal, porque reparte algo de lo que existe una cantidad finita.

Un taller no tiene una agenda en el sentido en que la tiene un consultor. Tiene elevadores y tiene mecánicos, y una cita es la combinación de ambos durante un tiempo que depende del trabajo. Un cambio de aceite y una avería eléctrica intermitente ocupan partes del día completamente distintas. Un modelo de datos que guarda la reserva como fecha y hora se rompe la primera mañana en que dos personas quieren las ocho y hay un elevador.

De ahí sale la decisión que constituye el fondo del módulo. La disponibilidad que se ve en el navegador es la fotografía de un instante que ya pasó. Entre que se pinta la lista y se pulsa el botón pasan con frecuencia diez o quince minutos, porque la persona va a comprobar si puede pedir la mañana libre. La comprobación tiene que repetirse en el servidor en el momento de escribir, y tiene que hacerse de forma que dos peticiones no puedan atravesar la misma hora libre. Una interfaz que se limita a atenuar las horas ocupadas parece correcta y produce la primera reserva doble en cuanto coinciden dos personas en la página.

La segunda consecuencia afecta a la caché. Casi todo en un sitio de taller es estable: descripción de servicios, cómo llegar, horario. Ese contenido puede vivir mucho tiempo en caché. La vista de disponibilidad es justo lo contrario, porque su único valor es estar al día. Una configuración que cachea todo sin excepción sirve sin pestañear una foto de la agenda de hace una semana, y nadie se entera hasta que un cliente está delante de una persiana bajada. Por eso la vista de reservas queda excluida de la caché de forma explícita, no por casualidad.

Queda explicar por qué se escribieron puntos de entrada propios en lugar de instalar una extensión de reservas. Las extensiones de este tipo modelan una peluquería o una consulta: un profesional, una silla, una duración fija. Doblar ese modelo para que acepte un segundo eje y una duración variable cuesta más que escribir el camino de escritura uno mismo, y deja supuestos ajenos exactamente donde un supuesto equivocado acaba en un cliente al que se le dio las nueve y no entra.

#Funcionalidades clave y tecnologías utilizadas

El diseño responsive pone primero, en pantalla estrecha, lo que de verdad se busca desde un teléfono: el número, la dirección y cómo llegar. El texto de la oferta viene después, porque la pregunta por un taller se hace normalmente desde un aparcamiento o desde el arcén, no desde un escritorio.

Conviene situar esto en el tiempo. En 2012 el diseño responsive era una partida del presupuesto y no algo dado por hecho. Flexbox no estaba en uso general y la retícula CSS no existía, así que las columnas se montaban con bloques flotados y los puntos de ruptura se elegían contra los anchos reales de los teléfonos que la gente llevaba encima. De ahí viene la retícula de Bootstrap: no por moda, sino porque la alternativa era escribir lo mismo desde cero y mantenerlo en solitario durante años.

La integración con redes sociales trae publicaciones y reseñas a la página. Aquí un sitio se vuelve dependiente de un servidor que nadie aquí controla, así que el comportamiento ante un fallo había que resolverlo durante la construcción. Las respuestas se cachean, y cuando la fuente no contesta la sección muestra el último contenido conocido o no se pinta. Un recuadro vacío con un mensaje de error en la portada de un taller se lee como una caída completa del sitio, no como una interfaz ajena con una tarde mala.

El trabajo de buscadores se apoyó en HTML5 semántico, metadatos ordenados y datos estructurados que describen un negocio local. En un servicio de proximidad tres cosas pesan por encima del resto en forma legible por máquina: nombre, dirección y teléfono en una única escritura invariable, el horario y la zona atendida. Una discrepancia entre la dirección del sitio y la de los directorios externos es un defecto clásico de vida larga, precisamente porque ambas versiones le parecen bien a un lector humano.

WordPress como superficie de edición tiene aquí un motivo concreto. Un taller no tiene redacción. Los cambios los hace el propietario o quien esté en la oficina, entre dos trabajos, de modo que cambiar el horario debe ser posible sin conocimientos técnicos y sin riesgo alguno de desmontar la maquetación.

#Migrar un sitio viejo es sobre todo migrar direcciones

Esto no era una hoja en blanco. Existía una versión anterior del sitio, y parte del contenido sobrevivía solo como copias archivadas, que recuperamos a través de Web Archive.

La mitad fácil de una migración así es el texto. La mitad que se salta es la de las direcciones. Un sitio que lleva años publicado tiene enlaces en directorios locales, en listados del sector y en correos ya enviados a clientes, y nadie va a actualizar ninguno de ellos. Cada URL antigua necesita por tanto una nueva concreta y una redirección permanente, en lugar de un barrido general hacia la portada. El barrido general se ve bien en el navegador, porque no aparece ningún error, y tira a la basura todo lo que la dirección antigua había acumulado.

#Desafíos y soluciones de programación

El peso de página se atacó en tres sitios: compresión de imágenes, caché del contenido que cambia poco y reducción del número de archivos de estilos y scripts. Lo último tenía en 2012 una importancia que hoy no tiene, porque los navegadores abrían una conexión por archivo contra un límite bajo de descargas en paralelo. Unir diez hojas de estilo en una no era cosmética entonces, quitaba nueve idas y vueltas al servidor.

Los módulos que adaptan el contenido al visitante fueron el otro frente, y chocan de lleno con la caché, porque la caché renta justo por entregar el mismo documento a mucha gente. La salida está en separar: el esqueleto de la página y los textos de servicios son comunes y se cachean, mientras que los fragmentos que dependen del visitante se piden aparte después de la carga. Sin esa separación, cualquier personalización invalida la caché del sitio entero y hay que elegir una de las dos cosas.

#Herramientas y tecnologías

Una nota sobre extensiones antes del inventario, porque de ella cuelga una decisión. Las extensiones funcionales se usan donde compensan, pero la seguridad no descansa sobre una de ellas, porque una extensión de seguridad es código que corre dentro de la aplicación que pretende proteger y empieza a trabajar cuando la petición ya ha llegado allí. Filtrar el tráfico por delante de la aplicación, mantener el núcleo al día, restringir el acceso a la administración y tener una copia probada rinden más que un panel que cuenta intentos de acceso bloqueados.

El inventario en sí es corto. WordPress para la edición, PHP y MySQL en el servidor, HTML5, CSS3 y JavaScript en la capa de presentación, retícula y componentes de Bootstrap para el diseño responsive, copias de seguridad automáticas, control de versiones del código y seguimiento de la visibilidad en buscadores.

La palabra copia merece una aclaración. Una copia que nadie ha restaurado nunca es un archivo, no una salvaguarda. La restauración tiene que haberse hecho al menos una vez en un entorno aparte, porque los huecos de una copia solo aparecen durante la restauración y para entonces suele haber prisa. En un taller con agenda eso incluye comprobar que vuelven también las reservas y no únicamente las páginas.

#Soporte y mantenimiento en WordPress

El mantenimiento cubre la corrección de averías, la instalación de actualizaciones de núcleo, tema y extensiones, la revisión de registros, las copias de seguridad según la política acordada y los cambios menores de contenido y presentación. Esa lista tiene un borde y conviene enseñarlo. No incluye la garantía de que una actualización no vaya a romper nunca nada, porque esa garantía no la puede dar ningún sitio ensamblado con piezas que mantienen equipos independientes.

Lo que sí incluye es el orden de los pasos. Los cambios se aplican primero fuera de producción y el camino de vuelta está preparado antes de hacer falta, en lugar de improvisado mientras suena el teléfono. Un sitio con módulo de reservas añade además una obligación que no tiene un sitio informativo. Cualquier actualización que toque el tratamiento de formularios o el manejo de fechas se prueba contra una copia de producción con reservas reales. La razón es prosaica: en una instalación vacía la agenda siempre está libre, así que ninguna prueba llega al camino donde el módulo puede romperse de verdad.

Ese camino son las colisiones entre dos peticiones para la misma hora y los casos límite en los bordes de una jornada laboral. Por el mismo motivo las ventanas de mantenimiento caen fuera del horario del taller. Un formulario de reserva que no responde justo cuando alguien quiere una cita cuesta un trabajo, no una visita. Ese cálculo decide también qué cambios esperan a la siguiente ventana planificada y cuáles merecen hacerse el mismo día.

#Resumen y análisis preliminar de los requisitos del cliente

La planificación arrancó con un conjunto de preguntas que había que responder antes de construir nada. Para qué sirve el sitio y a quién atiende. Qué había ya en la lista de requisitos del cliente, que aquí incluía reservas, enlaces con perfiles sociales y contenido adaptado al visitante. Cómo debía conectarse con la base de datos existente y qué permitía el calendario. Qué ejemplos quería señalar el cliente, en los que apuntaba a interfaces legibles y a una presentación clara de la oferta. Cuánto del sitio anterior se conservaba y cuánto se escribía de nuevo. Y hasta dónde llegaba el presupuesto, que es la pregunta que decide si un alcance se entrega de una vez o por etapas.

Las respuestas fijaron el orden del trabajo: primero aquello por lo que la gente entra en la web de un taller, es decir servicios, cómo llegar y contacto; después las reservas, el elemento más complejo y el único que cambia de verdad la forma de trabajar de la oficina; y al final las integraciones externas, las menos críticas y las más fáciles de añadir tras el lanzamiento. Lo que se traslada de este trabajo es el método. Comprobar la disponibilidad de un recurso finito en el servidor en el momento de escribir, mantener fuera de la caché las vistas que dependen del tiempo, aplazar los componentes externos pesados hasta que alguien los pida y mapear las direcciones antiguas una a una durante una migración. Lo que no se traslada es el modelo de contenido de este proyecto ni sus integraciones, escritos para un taller y un briefing de la categoría Sitios web. Por eso un segundo proyecto arranca con un análisis de alcance, y el presupuesto va después.