01
Disponibilidad de verdad
Cada día muestra cuántas horas quedan y cada hora cuántas plazas. Lo que está completo se ve completo, no se descubre al final.
Demo interactiva · Turismo
Reservar una actividad sin pasar por WhatsApp.
La cara móvil de Slotly. El viajero elige la actividad, ve qué huecos quedan de verdad, ajusta cuántos son y reserva. El precio se recalcula al vuelo y sale un código de confirmación que el guía comprueba en el punto de encuentro.
Prueba a reservar: cada día dice cuántas plazas quedan y las horas completas no se pueden elegir. Si se te queda pequeña, ábrela a pantalla completa.
TecnologíaHTML, CSS y JavaScript
ParaOperadores turísticos
DatosEsquema real de Slotly
ReservaCódigo de confirmación
Por qué una app
La web vende. La app hace que vuelvan.
Slotly ya resuelve la venta desde el navegador. La app tiene sentido para lo que viene después: el cliente que repite en la misma semana, el que quiere consultar su código sin buscar el email, y el operador que quiere estar en la pantalla de inicio del móvil durante las vacaciones de alguien.
Por eso esta demo no intenta ser la web otra vez. Va directa a lo que se hace con el móvil en la mano.
02
Precio que se mueve contigo
El total se recalcula al cambiar el número de personas, y el botón de reservar lleva siempre el precio y la hora elegida encima.
03
Código de confirmación
Ocho caracteres en monoespaciada, sin letras que se confundan al dictarlas. Es lo que el guía comprueba en la playa.
Sobre los datos
Sigue el esquema real, no uno inventado.
Slotly corre sobre Postgres con tablas de experiencias, disponibilidad y reservas. La demo usa esa misma estructura —capacidad máxima, mínimo de participantes, horas de cancelación, código de confirmación— para que conectar la API sea sustituir el origen de los datos, no rehacer las pantallas.
Las fotos son de Wikimedia Commons, con sus créditos dentro de la demo, y se presentan como ilustrativas: el operador no existe y no tendría sentido hacerlas pasar por suyas. En un producto real irían las del cliente.
“La demo puede ser de mentira. La estructura de datos, mejor que no.”
Accesibilidad
El selector de personas, ese gran suspenso.
En casi todas las apps de reserva, el «− 2 +» son dos iconos sin nombre y un número que cambia sin que nadie se entere. Con lector de pantalla es un callejón sin salida: no sabes qué botón es cuál ni qué ha pasado al pulsarlo.
Cada botón dice qué hace
«Añadir una persona» y «Quitar una persona», no «más» y «menos». Y al pulsarlos se anuncia el resultado con el precio ya recalculado.
Los topes explican por qué
Al llegar al máximo, el botón se desactiva y dice que no quedan más plazas. Un botón gris sin explicación es una pared.
Los días y las horas se anuncian enteros
«Martes 18 de agosto, dos horas disponibles», no «18». Y «16:00, completo», no un texto tachado que el lector no menciona.
Los ajustes automáticos se dicen en voz alta
Si cambias a una hora con menos plazas y hay que bajar el número de personas, se avisa en lugar de cambiarlo por detrás.
Lo que aprendimos
Tres atributos que React Native no lleva a la web.
La primera versión de estas demos se hizo con React Native, y construyéndola apareció el mismo problema una y otra vez: react-native-web pone bien los roles, pero no genera los atributos de estado. El resultado es una app que parece accesible en la revisión visual y no lo es con un lector de pantalla.
Se detecta midiendo el HTML que sale, no leyendo el código fuente.
| Lo que escribes | Lo que falta en web | Lo que hay que pasar |
|---|---|---|
accessibilityState={{checked}} | El lector nunca dice «seleccionado» | aria-checked |
accessibilityState={{disabled}} | El botón parece pulsable | aria-disabled |
accessibilityElementsHidden | Se leen los emojis decorativos | aria-hidden |
En los tres casos la solución es la misma y sirve para las tres plataformas, y es lo que aplico cuando la app se hace con React Native: pasar el atributo ARIA directamente, porque React Native lo traduce de vuelta a accessibilityState en iOS y Android.
Cómo está hecha
Un prototipo que se usa, no una captura.
Es un prototipo interactivo hecho con HTML, CSS y JavaScript, sin librerías: la app se descarga en menos de 20 KB más las fotos, y abre al instante desde un enlace. Las reservas que haces se guardan solo en tu navegador.
Sirve para validar el diseño y el flujo de reserva con el operador antes de programar. La app de tiendas la haría con React Native sobre el mismo esquema de datos de Slotly.
HTML
CSS
JavaScript sin dependencias
View Transitions
Modo oscuro
WCAG 2.2 AA
Qué es y qué no
Hasta dónde llega esta demo.
Es una maqueta funcional, no una pasarela de reservas
El operador es ficticio, no se cobra nada, no se envía ningún correo y las reservas se guardan solo en tu navegador. Para conectarla a Slotly de verdad haría falta:
- La API de Slotly como origen de experiencias y disponibilidad
- Pago con Stripe y reparto entre plataforma y operador
- Bloqueo de plaza mientras dura el proceso de pago
- Cuenta del viajero para ver y cancelar sus reservas
- Notificaciones push el día antes de la actividad
- Traducción, porque aquí el cliente llega en cuatro idiomas
¿Tienes un producto web y te falta la parte móvil?
Cuéntame qué hace hoy tu plataforma y qué querrías que la gente pudiera hacer desde el móvil. Te digo qué merece la pena llevar a una app, qué es mejor dejar en la web y con qué alcance empezar.