Cómo crear una aplicación web para votación de solicitudes de funciones

Define objetivos y el flujo central

Antes de diseñar pantallas o elegir una base de datos, decide qué debe lograr para el equipo de producto el “votación de solicitudes de funciones”. Un portal de votación puede ser:

• una herramienta de descubrimiento (sacar a la luz los mayores puntos de dolor),
• una entrada para priorización (comparar demanda entre temas), o
• un canal de comunicación (mostrar progreso y reducir emails repetitivos).

Si no eliges un propósito principal, acabarás con reglas poco claras y datos ruidosos.

¿Para quién es?

Sé explícito sobre la audiencia y si comparten el mismo espacio:

• Clientes: traen problemas reales y urgencia, pero pueden necesitar moderación.
• Equipos internos (Ventas, Soporte, Éxito): aportan contexto e impacto en ingresos, pero pueden sobrerrepresentar pocas cuentas.
• Usuarios beta: ofrecen feedback detallado y de alta señal, pero no reflejan todo el mercado.
• Todos: funciona mejor cuando los roles y las reglas de visibilidad están claras.

Flujo de usuario principal (qué deben poder hacer las personas)

Como mínimo, los usuarios deberían poder enviar una solicitud, votar, comentar, seguir actualizaciones y buscar ideas existentes.

La búsqueda importa más de lo que parece: evita duplicados y hace que el portal sea útil incluso cuando alguien no publica nada.

Flujo administrativo principal (qué debe poder hacer tu equipo)

Tu equipo de producto necesita un bucle de triage ligero:

• fusionar duplicados
• cambiar estado (por ejemplo, “Under Review”, “Planned”, “In Progress”, “Shipped”)
• etiquetar/categorizar
• exportar datos para planificación

Si alguno de estos pasos requiere trabajo manual fuera de la app, el sistema no se mantendrá actualizado.

Define el éxito desde el principio

Elige resultados medibles como:

• Adopción: votantes activos y visitantes recurrentes
• Calidad de las ideas: menos duplicados, descripciones más claras
• Tiempo ahorrado: menos tickets de soporte, triage más rápido

Estos objetivos guiarán decisiones posteriores, desde las reglas de votación hasta las herramientas de administración.

Roles de usuario, inicio de sesión y permisos

Tu app de votación solo parecerá “justa” si la gente entiende quién puede hacer qué —y si el abuso es difícil sin obligar a usuarios legítimos a dar demasiados pasos. Empieza con un conjunto pequeño de roles y los permisos asociados a cada uno.

Roles comunes (y qué pueden hacer)

• Visitante: puede explorar el tablero público y leer detalles de las solicitudes. Considera permitir que los visitantes filtren y busquen, pero restringe acciones como publicar y votar.
• Usuario registrado: puede crear solicitudes de función, hacer upvote, comentar (si soportas comentarios) y seguir actualizaciones.
• Moderador: puede fusionar duplicados, editar títulos/etiquetas para mayor claridad y ocultar contenido abusivo o de baja calidad.
• Admin: puede cambiar estados (Planned/In Progress/Shipped), gestionar categorías, configurar reglas y acceder a reportes.

Un modelo de permisos simple (por ejemplo can_vote, can_post, can_moderate, can_admin) es más fácil de mantener que codificar la lógica por todo el app.

Opciones de inicio de sesión: elige lo que encaje con tu audiencia

Para la mayoría de los portales de solicitudes, el enlace mágico por email es la opción de menor fricción y evita resets de contraseña. El login por contraseña es familiar pero añade sobrecarga de soporte. SSO (SAML/OIDC) suele ser opcional y mejor dejarlo como añadido para planes B2B.

Si ya tienes una app con cuentas, reutiliza ese sistema de identidad para que los usuarios no necesiten un login separado.

Votación anónima: útil, pero limítala

La votación anónima puede aumentar la participación, pero es más fácil de manipular. Si la permites, añade salvaguardas como:

• un voto por sesión del navegador más comprobaciones del lado del servidor
• límites de tasa más estrictos para usuarios anónimos
• exigir iniciar sesión para crear una nueva solicitud o para comentar

Datos mínimos de perfil a almacenar

Mantén los perfiles livianos:

• nombre (display name)
• email (para login + notificaciones)
• organización (opcional; útil para B2B)
• plan (si es relevante para ponderación, segmentación o priorización)

Solo recoge lo que realmente vas a usar; reduce el riesgo de privacidad y acelera la incorporación.

Límites de tasa que frenan el spam sin bloquear usuarios reales

Añade throttles básicos como “X votos por minuto” y “Y solicitudes nuevas por día”. Aplica límites más estrictos a cuentas nuevas y usuarios anónimos, y relájalos para usuarios de confianza (cuentas antiguas, email verificado, organizaciones conocidas).

Cuando un usuario alcanza un límite, muestra un mensaje claro y el tiempo para reintentar en vez de un error genérico.

Diseñar el modelo de datos: solicitudes, votos, estados

Un portal de solicitudes de funciones vive o muere por su modelo de datos. Si tus registros son consistentes, podrás ordenar, filtrar, deduplicar e informar sin limpieza manual interminable.

Solicitud de función: campos principales

Empieza con el conjunto mínimo que capture la intención:

• Título: corto, específico, buscable.
• Descripción: el “por qué” más contexto (quién lo necesita, qué problema resuelve).
• Categoría: un único bucket primario (por ejemplo, Billing, Mobile, Integrations) para mantener filtros simples.
• Adjuntos (opcionales): capturas o documentos; guarda metadatos (nombre de archivo, tamaño, uploader) y una referencia de archivo segura.

Añade campos amigables para el backend que rindan luego: created_by, created_at, updated_at, y un canonical_request_id (útil para fusionar duplicados).

Votos: elige un modelo que puedas explicar

Tu tabla de votos suele enlazar user_id → request_id, pero las reglas varían:

• Un voto por usuario: el más simple y claro.
• Créditos de voto: cada usuario tiene un presupuesto limitado (por ejemplo, 10 créditos) que puede distribuir; almacena credits_spent por voto.
• Votos ponderados: útil para B2B (ponderar por plan); almacena weight y conserva un rastro de auditoría.

Cualquiera que elijas, aplica unicidad (por ejemplo, un voto activo por usuario por solicitud) para que los totales sean fiables.

Estados: modela progreso, no promesas

Un modelo práctico de estados es: New → Under Review → Planned → In Progress → Shipped, más Won’t Do.

Almacena status, status_updated_at y opcionalmente status_reason (especialmente para Won’t Do). Considera un status_history ligero para transparencia e informes.

Etiquetas, categorías y reglas de discusión

Usa categorías para filtros de alto nivel y tags para etiquetas flexibles (por ejemplo, “enterprise”, “UI”, “API”). Las tags deben ser many-to-many.

Para comentarios y reacciones, define lo permitido: comentarios enlazados a una solicitud, edición en una ventana de tiempo, y reacciones limitadas a un conjunto pequeño (p. ej., 👍/👎) o desactivarlas para evitar ruido.

Incluye campos de moderación como is_hidden y hidden_reason para gestionar calidad sin borrar datos.

Planear la experiencia de usuario y pantallas clave

Un portal de solicitudes triunfa o fracasa por la claridad: la gente debe entender rápido qué necesita el equipo de producto, qué ya se ha pedido y cómo participar. Diseña un conjunto pequeño de pantallas que guíen a los usuarios desde “tengo una idea” hasta “veo qué pasó con ella”.

Inicio / feed: orienta al usuario rápido

La pantalla de inicio es una página de decisión. Debe responder:

• “¿Qué están pidiendo los demás?”
• “¿Por dónde empiezo?”

Incluye modos de feed simples como Trending y Newest. Si ofreces una vista “For you”, mantenla opcional y explica por qué aparecen los items (p. ej., según tags que sigue el usuario).

Muestra contexto ligero en cada tarjeta: título, resumen corto, estado, conteo de votos y una pista de actividad (comentario reciente o actualización).

Página de detalle de la solicitud: deja claro el caso

La página de detalle debe leerse como un mini expediente. Comienza con una declaración del problema clara (qué intenta conseguir el usuario), luego los detalles de apoyo.

Incluye:

• votos y un resumen claro de “por qué importa”
• comentarios para discusión y aclaraciones
• estado y un historial/cronología visible de actualizaciones

Mantén las acciones clave fáciles de encontrar: Vote, Follow, y Copiar/compartir enlace.

Flujo de envío: reducir solicitudes vagas y duplicadas

La mayoría de solicitudes de baja calidad vienen de prompts poco claros. Usa una plantilla corta que empuje al usuario a escribir entradas útiles:

• ¿Qué problema estás resolviendo?
• ¿Quién se ve afectado?
• ¿Cómo sería un resultado “mejor”?

Mientras escriben, sugiere solicitudes similares para que el usuario vote en lugar de crear duplicados.

Búsqueda y filtros: el hábito de “buscar antes de publicar”

Haz la búsqueda prominente en cada página. Añade filtros que coincidan con cómo piensa la gente: categoría, estado, tags y periodo (p. ej., últimos 30 días).

Mantén la UI de filtros compacta y permite compartir vistas filtradas vía URL para colaboración rápida.

Manejar duplicados y calidad de contenido

Los duplicados son inevitables: usuarios distintos describen la misma necesidad con palabras diferentes, o piden algo que ya existe. Manejar duplicados bien mantiene el tablero legible y hace que los votos tengan sentido.

Definir reglas de duplicado y fusión

Empieza con una definición clara: un “duplicado” es una solicitud que pide el mismo resultado para el mismo grupo de usuarios, aunque la implementación difiera.

Si dos publicaciones son “relacionadas pero distintas” (p. ej., misma área del producto pero casos de uso distintos), mantenlas separadas y añade una etiqueta de relación en lugar de fusionar.

Cuando fusiones, elige una solicitud canónica (normalmente el título más claro, la mejor descripción o la publicación más antigua con más actividad) y convierte las otras en registros “Merged into #123”.

Haz las fusiones visibles y comprensibles

Muestra la relación de fusión a los usuarios en ambos lados:

• En el duplicado: un banner con enlace a la solicitud canónica
• En la canónica: una sección pequeña “Merged from X requests” con enlaces

Esto evita confusión y reduce tickets de soporte tipo “¿dónde quedó mi publicación?”

Decide qué pasa con los votos

Traslada los votos automáticamente a la solicitud canónica y preserva la atribución (“Tu voto fue movido a…”) para que los usuarios no se sientan borrados.

Conserva un rastro de auditoría (quién fusionó, cuándo y por qué) para moderadores.

Prevenir duplicados en el momento de envío

Mientras el usuario escribe un título, sugiere solicitudes similares usando búsqueda básica (título + tags) y muestra las coincidencias principales con conteos de votos. Un aviso suave como “¿Alguna de estas es la misma?” puede reducir duplicados drásticamente.

Usa una lista de verificación de moderación consistente

Da a los moderadores una lista corta:

• título claro
• un problema por solicitud
• contexto útil
• sin datos privados
• categoría correcta
• decisión: fusionar/relacionar/aprobar

La consistencia genera confianza y mantiene la cola de gestión manejable.

Establecer reglas de votación y medidas anti-abuso

La votación es el motor del portal, así que define reglas fáciles de entender y difíciles de manipular. Mecánicas predecibles reducen tickets de soporte (“¿por qué mi idea bajó?”) y hacen que el tablero se sienta justo.

Elige un modelo de votación

Empieza por decidir qué significa un “voto”:

• Solo upvote: el más simple y común.
• Up/down votes: ayuda a separar “agradable” de “por favor no”, pero puede crear negatividad.
• Puntos de prioridad: cada usuario tiene un pequeño presupuesto (por ejemplo, 10 puntos) para distribuir. Fomenta trade-offs y aporta entradas de mayor calidad para el roadmap.

Establece restricciones que desincentiven el abuso

Como mínimo, aplica un voto por solicitud por usuario. Si permites downvotes o puntos, aplica límites equivalentes (un downvote, o un presupuesto fijo de puntos).

Añade fricción ligera donde importe:

• Cooldowns para votación rápida o acciones de cuenta (evita “tormentas de votos”).
• Revisiones anti-bot en patrones sospechosos (CAPTCHA solo cuando se dispare).
• Límites por IP/dispositivo para tráfico anónimo.

Decide si los votos son reversibles

Permite a los usuarios cambiar o eliminar votos en la mayoría de los casos: las necesidades cambian y la reversibilidad reduce frustración.

Si usas puntos de prioridad, la reversibilidad es esencial para que puedan redistribuir puntos.

Haz el orden transparente

El orden dirige comportamiento, así que explícalo. Si “Top” se basa en votos, dilo. Si “Trending” usa actividad reciente, explícalo también.

Considera ofrecer varias vistas: “Top”, “Newest” y “Recently Updated”, con etiquetas claras.

Fomenta votación reflexiva

Considera límites como X votos por semana (o un refresco mensual de puntos). En combinación con un buen flujo de triage, esto empuja a los usuarios a apoyar lo que más importa en vez de clicar todo.

Construir herramientas administrativas para triage y moderación

Las herramientas admin son las que mantienen un portal usable cuando empiezan a llegar envíos. Sin ellas, el backlog se vuelve una mezcla de duplicados, ideas vagas y hilos tensos que consumen tiempo del equipo.

Empieza con una cola de moderación clara

Da a los admins un lugar único para revisar:

• nuevas presentaciones antes de hacerlas públicas (opcional)
• items marcados por usuarios (spam, abuso, fuera de tema)
• solicitudes que parecen duplicadas (coincidencia por título/palabras clave)

Cada item debe mostrar el resumen de la solicitud, autor, conteo de votos, solicitudes similares y comentarios recientes para que un moderador decida rápido.

Habilita acciones masivas para triage rápido

La mayor parte del trabajo admin es repetitivo. Añade acciones en lote para que los moderadores puedan seleccionar varias solicitudes y aplicar cambios de una vez:

• etiquetar (por ejemplo “Integrations”, “Billing”, “Mobile”)
• cambiar estado (Planned, Under Review, Not Planned, Shipped)
• fusionar duplicados en una solicitud canónica
• cerrar con motivo y link opcional a una solicitud relacionada

Esto es especialmente útil tras lanzamientos cuando el feedback escala.

Mantén notas internas separadas de la discusión pública

Los comentarios públicos son para usuarios. Los admins necesitan un espacio privado para contexto: enlaces a tickets de soporte, impacto en ingresos, limitaciones técnicas y la razón de la decisión.

Haz que las notas internas sean visibles solo para el personal y sepáralas claramente del hilo público para evitar publicaciones accidentales.

Añade un log de auditoría para responsabilidad

Registra acciones clave como cambios de estado, fusiones y eliminaciones con timestamp y actor. Cuando un cliente pregunte “¿por qué desapareció esto?” tendrás un historial fiable.

Facilita reporting con exportaciones simples

Una exportación CSV básica (filtrada por estado, tag, rango de fechas o votos) ayuda en reuniones de roadmap y actualizaciones a stakeholders, sin forzar a todos al UI de admin.

Notificaciones y suscripciones

Las notificaciones son cómo tu portal sigue siendo útil después de la primera visita. Bien hechas, reducen preguntas repetidas (“¿hay novedades?”) y mantienen a los usuarios comprometidos sin inundar sus bandejas.

Sobre qué notificar a los usuarios

Empieza con un conjunto pequeño de eventos que encajen con expectativas reales:

• Cambios de estado (p. ej., “Planned”, “In Progress”, “Released”)
• Nuevos comentarios en una solicitud que siguen
• Menciones (opcional) cuando alguien etiqueta a otro en un comentario

Mantén el texto específico: incluye título de la solicitud, el nuevo estado y un enlace directo al hilo.

Suscripciones: hacer seguir por defecto

Permite que la gente siga/subscribe a una solicitud con un clic. Considera auto-suscribir a un usuario cuando:

• envía una nueva solicitud
• vota una solicitud
• deja un comentario

Esta regla simple reduce tickets de soporte porque los usuarios pueden auto-servirse actualizaciones.

In-app vs. email

Usa notificaciones in-app para bucles de retroalimentación rápidos (contador, bandeja de notificaciones). Usa email para cambios importantes y menos frecuentes, sobre todo cambios de estado.

Para evitar spam, ofrece resúmenes (digest) diarios o semanales que agrupen varias actualizaciones. Un digest también es un buen valor por defecto para usuarios que siguen muchas solicitudes.

Preferencias y control de baja

Cada email debe incluir un enlace para darse de baja, y la app debe tener preferencias claras de notificación (por ejemplo, “Solo cambios de estado”, “Toda la actividad”, “Solo digest”). Enlaza a ellas desde una página de ajustes como /settings/notifications.

Una buena higiene de notificaciones genera confianza —y la confianza aumenta la participación.

Conectar la votación con el roadmap y las actualizaciones de lanzamientos

La votación solo tiene sentido si la gente ve qué pasó después. La forma más simple de cerrar el ciclo es conectar tu portal a un roadmap público ligero y a un changelog —ambos basados en los mismos estados de solicitud.

Vincular solicitudes a un roadmap público (opcional)

Si publicas un roadmap en /roadmap, bájalo a estados que sean fáciles de entender: “Under Review”, “Planned”, “In Progress” y “Shipped.” Mantén el mapeo consistente para que los usuarios aprendan qué significa cada estado.

No todo tiene que ser público. Un compromiso común: mostrar temas de alto nivel públicamente y mantener fechas exactas y proyectos internos privados. Evita así prometer de más mientras das entrada al votante.

Vincular el trabajo entregado a los votos originales

Cuando algo se lanza, permite que los admins marquen la solicitud como “Shipped” y adjunten una referencia de release.

Idealmente, la página del feature lanzado muestra:

• el título y resumen original de la solicitud
• total de votos (y quizás comentarios destacados)
• una nota breve “Qué cambió” del equipo

Esto transforma el sistema de upvoting en un flujo visible de triage de feedback en vez de un buzón muerto.

Publicar un changelog que haga referencia a solicitudes

En /changelog, crea entradas de releases y enlaza cada entrada a solicitudes relacionadas (y viceversa). Por ejemplo: “Added SSO for teams (related: #123, #98).”

Los usuarios que apoyaron una idea pueden confirmar rápidamente que se implementó y los nuevos visitantes pueden ver resultados antes de enviar duplicados.

Decidir qué es público y qué privado

Ten una política explícita: qué estados son visibles, si los conteos de votos son públicos y si las notas internas permanecen solo para admins. Límites claros hacen el proceso predecible.

Analítica e informes que ayuden a decidir

La analítica en una app de votación no es para métricas de vanidad, sino para hacer las compensaciones visibles. Los dashboards correctos te ayudan a responder tres preguntas rápido:

• ¿Qué piden los usuarios?
• ¿Quién lo pide?
• ¿Qué tan urgente es para el equipo de producto responder?

Métricas centrales a seguir

Empieza con un conjunto pequeño y fiable:

• Nuevas solicitudes: por día/semana y cómo cambian tras lanzamientos
• Votos: totales, por solicitud y crecimiento de votos en el tiempo
• Usuarios activos: personas que vieron, votaron o comentaron (no solo registradas)
• Tiempo hasta triage: cuánto tarda una solicitud en pasar de “New” a un estado gestionado

El tiempo hasta triage refleja salud interna: si sube, los usuarios se sienten ignorados incluso con un roadmap fuerte.

Temas, categorías y segmentación

Añade reportes que saquen patrones:

• Categorías principales (por nuevas solicitudes y por votos)
• Temas recurrentes usando tags o etiquetas ligeras

Si tienes metadata de clientes (plan, industria, tamaño de cuenta), segmenta por ello. Una solicitud con pocos votos puede seguir siendo crítica si la apoya un segmento estratégico.

Detectar abuso sin convertirlo en un proyecto de seguridad

Algunas vistas de anomalías ayudan mucho:

• ráfagas de votos en una sola solicitud
• muchos votos desde el mismo identificador de red (si lo almacenas)
• cuentas nuevas votando inmediatamente y solo una vez

Convertir dashboards en un hábito semanal

Define una revisión semanal: top movers, solicitudes “New” envejecidas y temas principales. Documenta decisiones (“merged”, “planned”, “not now”) para que el reporting refleje decisiones, no solo actividad.

Seguridad, privacidad y cumplimiento básico

La seguridad es más fácil de añadir si la planificas desde el principio. Un portal de solicitudes maneja cuentas, contenido generado por usuarios y señales como votos —así que necesita protecciones básicas antes de invitar usuarios reales.

Seguridad de cuentas y sesiones

Si soportas contraseñas, almacénalas usando un algoritmo moderno de hashing (p. ej., bcrypt/argon2) y nunca en texto plano.

Prefiere sesiones de corta duración con cookies seguras (HTTP-only, Secure y un ajuste SameSite sensato). Para formularios que cambian datos (enviar ideas, votar, comentar), añade protección CSRF para que otros sitios no puedan disparar acciones en nombre de tus usuarios.

Validar entradas y prevenir XSS

Trata cada solicitud, comentario y título como input no confiable:

• valida en servidor: límites de longitud, caracteres permitidos, campos requeridos
• renderiza contenido de forma segura: escapa HTML por defecto y solo permite formato (como Markdown) si lo sanitizas
• ten cuidado con enlaces: evita javascript: y trucos similares

Esto protege contra scripts inyectados (XSS) y mantiene la UI estable.

Controles y monitoreo de abuso

Los sistemas de votación atraen spam y “tormentas de votos”. Añade límites de tasa para:

• nuevas solicitudes (por cuenta y opcionalmente por IP)
• comentarios/respuestas
• votos/unvotes

Combínalo con monitorización básica (picos, fallos repetidos, envíos duplicados repetidos). Incluso límites simples mantienen la moderación manejable.

Privacidad: recoge menos, explica claro

Decide qué datos personales guardas y por qué (email para login, display name para atribución, IP para prevención de abuso, etc.). Manténlo mínimo, documenta la retención (cuánto tiempo guardas logs) y hazlo accesible en la política de privacidad.

Si sirves a usuarios en regiones reguladas, planifica GDPR/CCPA básicos: solicitudes de acceso, borrado y un propósito claro para cada campo.

Política de eliminación solo para admins

Crea reglas consistentes que sigan los admins:

• cuándo eliminar contenido (spam, acoso, datos personales)
• si haces “soft delete” (ocultar pero retener para auditoría) o “hard delete”
• cómo comunicas la eliminación al autor

La consistencia reduce acusaciones de sesgo cuando las ideas se eliminan.

Elegir stack tecnológico y planear el lanzamiento del MVP

Un portal de solicitudes tiene más probabilidad de éxito por reglas claras e iteración rápida que por una arquitectura sofisticada. Elige un stack que tu equipo pueda lanzar y soportar con confianza.

Elige un stack acorde a tu equipo

Elige un camino “sencillo” de extremo a extremo:

• Frontend: React/Next.js, Vue/Nuxt o un enfoque server-rendered (Rails, Django templates) si el equipo lo prefiere.
• Backend: Node (Nest/Express), Rails, Django o Laravel.
• Base de datos: Postgres es una opción sólida por defecto para solicitudes, votos y logs de auditoría.
• Hosting: plataformas gestionadas reducen el trabajo de ops para un MVP.

Optimiza por familiaridad del desarrollador, no por rendimiento teórico.

Si tu objetivo es validar el flujo rápidamente (envío → búsqueda → votación → actualizaciones de estado → moderación) sin construir todo desde cero, una plataforma de generación de apps vía chat como Koder.ai puede ayudarte a generar la app inicial por conversación, iterar la UX y exportar código cuando estés listo. Koder.ai está pensada para aplicaciones completas (React en web, Go + PostgreSQL en backend y Flutter para móvil) y soporta trabajo práctico como despliegue/hosting, dominios personalizados y snapshots con rollback.

Despliegue: entornos, migraciones, backups

Configura dev → staging → production pronto para poder probar reglas de votación sin arriesgar datos reales.

Plan para:

• migraciones de esquema (y estrategia de rollback)
• backups automáticos de la base de datos
• monitorización básica (errores + uptime)

Tests automáticos para las partes delicadas

Aunque sea una app pequeña, requiere tests para la lógica que afecta confianza:

• límites de votación (por usuario, por periodos)
• comportamiento de fusión de duplicados (transferencia de votos, redirecciones)
• comprobaciones de permisos (admin vs usuario regular)

Definir alcance del MVP (y qué posponer)

Un buen MVP suele incluir: crear solicitud, búsqueda, upvote, actualizaciones de estado y moderación admin.

Elementos comunes para más adelante: SSO, ponderación de votos, integraciones profundas (Jira/Linear), analítica avanzada y roles personalizados.

Plan de lanzamiento: empezar pequeño, aprender rápido

Invita a un grupo piloto (usuarios power + compañeros internos), publica directrices claras y observa cómo la gente realmente envía y vota.

Haz ciclos cortos de feedback, arregla fricciones y expande acceso. Una página liviana como /pricing o /blog puede ayudar a poner expectativas y compartir progreso.