Ir al contenido principal

Etiqueta: PowerApps

Crear una pantalla de Carga en Power Apps

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Crear una pantalla de Carga en Power Apps

Muchas veces nos encontramos con aplicaciones que tienen cargas importantes de datos o colecciones en la pantalla inicial mediante OnStart, para evitar que el usuario este interactuando con la aplicación sin tener cargados todos los datos, podemos crear una pantalla de Loading inicialmente que una vez cargados los datos de acceso a la pantalla inicial de la aplicación. Para realizar esto, sigue los siguientes pasos:

Necesitarás al menos dos pantallas: una para la carga (por ejemplo, ScreenLoading) y la pantalla de inicio real (ScreenHome).

1. Pantalla de Carga (ScreenLoading)

  1. Inserta el GIF:
    • Ve a la pestaña Media (Medios) y Upload (Cargar) tu archivo GIF con el loading que te guste.
    • Inserta un control de Imagen en ScreenLoading y establece su propiedad Image al nombre de tu archivo GIF (ejemplo: MiGifDeCarga).
  2. Cubre la Pantalla con un color de background:
    • Inserta un control Rectangle (Rectángulo) y ajústalo para que cubra toda la pantalla. Dale un color de relleno (Fill) oscuro o el que desees.
    • Asegúrate de que el control Imagen del GIF esté delante de este rectángulo (usa la opción «Reorder» – Reordenar).
  3. Añade el Control Timer (Temporizador):
    • Inserta un control Timer (Temporizador) en ScreenLoading.

2. Lógica de la Aplicación (App.OnStart)

Aquí es donde se ejecutará tu lógica de carga inicial.

  • Variable de Control: Define una variable para rastrear si el proceso de carga ha finalizado.

Fragmento de código

// 1. Inicia la pantalla de carga

Navigate(ScreenLoading, ScreenTransition.None);

// 2. Establece la variable de control al inicio de la carga

Set(varCargaFinalizada, false);

// 3. Coloca AQUÍ toda tu lógica de carga (Collect, ClearCollect, LookUp, etc.)

// 4. Una vez que toda la lógica de carga haya terminado...

Set(varCargaFinalizada, true);

3. Configuración del Temporizador

Usa el Temporizador para esperar a que la variable varCargaFinalizada sea true y, opcionalmente, a que pase un tiempo mínimo para mostrar el GIF.

Propiedad del TemporizadorValor/FórmulaPropósito
Duration (Duración)1000 (milisegundos)Tiempo MÍNIMO para mostrar el GIF, si la carga es muy rápida.
AutoStartvarCargaFinalizadaEl temporizador comienza una vez que la lógica de OnStart ha terminado de ejecutarse y establece la variable en true.
RepeatfalseSolo debe ejecutarse una vez.
OnTimerEndNavigate(ScreenHome, ScreenTransition.Fade)Una vez que el temporizador finaliza, navega a la pantalla de inicio.

💡 Flujo de Ejecución

  1. El usuario abre la aplicación.
  2. Se ejecuta App.OnStart.
  3. Lo primero que hace es navegar a ScreenLoading y establece varCargaFinalizada en false.
  4. Se ejecuta toda tu lógica de OnStart (recolección de datos, etc.).
  5. Una vez finalizada la lógica, varCargaFinalizada se establece en true.
  6. Como Timer.AutoStart es varCargaFinalizada (que ahora es true), el temporizador comienza a contar.
  7. Después de la duración especificada (ejemplo: 1000 ms), se ejecuta Timer.OnTimerEnd, navegando a ScreenHome.

Power Apps Standards: Guia de Optimización

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards: Guia de Optimización

Trucos de Profesional para que tu App Vuele: Guía de Rendimiento 🏎️

Una aplicación lenta es una aplicación que nadie quiere usar. Estos consejos te ayudarán a optimizar tus Power Apps para que sean rápidas, eficientes y consuman menos batería.

1. Pide todos los cafés a la vez (Carga de datos concurrente)

Imagina que estás en una cafetería. Lo normal es que cada persona pida, pague y espere su café antes de que el siguiente pueda pedir. Es lento.

La función Concurrent es como tener varios camareros que toman nota a varios clientes a la vez. En lugar de esperar a que una tabla de datos se cargue para empezar a cargar la siguiente, Concurrent pide varias a la vez.

La regla: Usa Concurrent solo para pedir datos que están en la nube (SharePoint, Dataverse, etc.). No sirve de nada para datos que ya están en la «memoria» de la app (variables y colecciones).

Fragmento de código

// MODO LENTO (Secuencial)
// Primero pide el perfil del usuario... y espera.
Set(gblPerfilUsuario, ...);
// Cuando termina, pide los proyectos activos.
ClearCollect(colProyectosActivos, ...);


// MODO RÁPIDO (Concurrente)
// Pide el perfil del usuario Y los proyectos activos ¡a la vez!
Concurrent(
    Set(gblPerfilUsuario, ...),
    ClearCollect(colProyectosActivos, ...)
);

2. Deja que la nube trabaje por ti (Delegación) ☁️

Este es el concepto más importante para el rendimiento. «Delegar» significa pedirle al servidor (a la nube) que haga el trabajo pesado de filtrar, buscar u ordenar los datos por ti.

Imagina que necesitas un libro de una biblioteca gigante.

  • Sin delegar (lento): Le pides a la biblioteca que te envíe todos sus libros a tu casa y tú te pones a buscar el que quieres.
  • Delegando (rápido): Le dices al bibliotecario exactamente qué libro quieres, él lo busca por ti y te envía solo ese libro.

Beneficios: Es mucho más rápido y se transfieren muchos menos datos a tu dispositivo. Cómo hacerlo: Usa funciones que se puedan delegar (Power Apps te avisa con un triángulo azul si una función no se puede delegar). Para filtros complejos en Dataverse, usar Vistas de Dataverse es un truco genial, ya que las vistas no tienen problemas de delegación.

3. Ten los ingredientes a mano (Usa colecciones como caché) 📚

Si hay datos que vas a usar una y otra vez en tu app (como una lista de categorías o tipos de producto), no se los pidas a la nube cada vez.

La mejor práctica es cargarlos una sola vez cuando la app se inicia y guardarlos en una colección (en la «memoria» de la app).

Analogía: Es como en la cocina. En lugar de ir a la despensa (la nube) cada vez que necesitas una pizca de sal, pones el salero (la colección) en la encimera. Acceder a él es instantáneo.

4. Viaja con equipaje de mano (Limita el tamaño de las colecciones) 🧳

Las colecciones se guardan en la memoria del dispositivo. Si cargas colecciones enormes, especialmente en un móvil, la app puede quedarse sin memoria y cerrarse de golpe.

La regla: Carga solo las filas y columnas que necesites. Cómo hacerlo: Usa la función ShowColumns para elegir solo las columnas que te interesan. Es como hacer la maleta para un viaje: no te llevas todo el armario, solo la ropa que te vas a poner.

Fragmento de código

// En lugar de traer TODA la tabla de Cuentas...
// ...traemos solo las columnas de nombre, ciudad, provincia y código postal.
ClearCollect(
    colCuentas,
    ShowColumns(
        Cuentas,
        "nombre",
        "ciudad",
        "provincia",
        "codigo_postal"
    )
);

5. Envía todos los paquetes de una vez («Batch Patch») 📦

Si necesitas actualizar varios registros a la vez en tu origen de datos, no lo hagas uno por uno.

  • Lento (ForAll + Patch): Es como ir a correos y enviar 20 cartas, haciendo la cola 20 veces.
  • Rápido (Patch con una tabla): Es meter las 20 cartas en una caja grande y enviarla toda de una vez.

Esta técnica, a menudo llamada «batch patch», es increíblemente más rápida.

6. No lo hagas todo al entrar por la puerta (Reduce el código en OnStart) ⏰

La propiedad OnStart de la app es lo primero que se ejecuta. Cuantas más cosas pongas ahí, más tardará en abrirse la pantalla inicial.

La solución: Mueve el código que no sea absolutamente esencial para el arranque a la propiedad OnVisible de la primera pantalla. O mejor aún, carga los datos justo en la pantalla donde se vayan a necesitar.

7. Menos es más (Minimiza los controles por pantalla) 🖼️

Cada botón, etiqueta, icono o campo de texto que pones en una pantalla consume memoria y hace que tarde más en cargar.

  • Simplifica tus diseños.
  • Si una pantalla tiene demasiadas cosas, divídela en varias pantallas más pequeñas.
  • Para listas de elementos repetitivos, usa siempre una Galería. Una galería es súper eficiente: da igual que muestre 10 o 1.000 filas, para la app sigue contando como un solo control.

8. No interrumpas al que habla (Usa DelayOutput) 🗣️

En los campos de búsqueda, por defecto, la app busca con cada letra que el usuario escribe. Esto genera muchísimas consultas innecesarias.

Activa la propiedad DelayOutput a true en el campo de texto. Con esto, la app esperará a que el usuario haga una pequeña pausa al escribir antes de lanzar la búsqueda. Es mucho más eficiente.

9. No grites de una habitación a otra (No referencies controles de otras pantallas) 🔗

Nunca escribas una fórmula en la Pantalla A que dependa directamente de un control que está en la Pantalla B (ej: InputDeLaPantallaB.Text). Esto obliga a la app a mantener las dos pantallas cargadas en memoria a la vez, gastando recursos.

La solución: Guarda el valor del control de la Pantalla B en una variable global. Luego, desde la Pantalla A, lee el valor de esa variable. Es mucho más limpio y eficiente.

10. Prepara la ensalada en la cocina, no en el huerto (Evita el problema N+1) 🥗

El problema «N+1» es un asesino silencioso del rendimiento. Ocurre cuando haces 1 consulta para traer una lista, y luego N consultas más (una por cada elemento de la lista) para obtener un detalle. Por ejemplo, 1 consulta para traer 100 contactos, y luego 100 consultas más para traer el nombre de la empresa de cada contacto.

  • Solución en Dataverse: ¡Es fácil! Dataverse es inteligente y puede traer los datos relacionados en la primera consulta. Simplemente usa la notación de punto: ThisItem.Empresa.'Nombre de la Empresa'.
  • Solución en SharePoint: SharePoint no es tan listo. El truco es:
    1. Cargar todos los contactos en una colección.
    2. Cargar todas las empresas en otra colección.
    3. Usar la función AddColumns para «unir» las dos colecciones en tu app. Es como ir al huerto, traer una cesta con todos los tomates y otra con todas las lechugas, y luego preparar la ensalada en la cocina. Es mucho más rápido que ir al huerto por cada hoja de lechuga.

Power Apps Standards: Manejo de Errores

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards: Manejo de Errores

Aquí tienes una guía sobre cómo manejar errores en tus aplicaciones, explicada de forma sencilla para que tus apps sean robustas y no dejen tirados a los usuarios.

Manejo de Errores: El Plan B para una App a Prueba de Fallos 🛡️

Una aplicación profesional no se bloquea ni se queda callada cuando algo sale mal. Al contrario, tiene un «Plan B» para cada situación. Anticiparse a los errores es lo que diferencia una app mediocre de una excelente. Aquí te explicamos cómo hacerlo.

1. Primer Paso: Activa el «Modo Plan B»

Antes de nada, tienes que activar una opción en la configuración avanzada de Power Apps llamada «Manejo de errores a nivel de fórmula».

Al encender este interruptor, «desbloqueas» las funciones (IfError, IsError) y propiedades (OnError) que te permitirán crear estos planes B.

2. Al Guardar Datos (Patch): Confirma Siempre la Entrega 📦

Cuando usas las funciones Patch o Collect para guardar datos, nunca des por hecho que ha funcionado. La conexión a internet podría fallar, o el usuario podría no tener permisos.

Piensa en ello como si enviaras un paquete importante: no te quedas tranquilo hasta que recibes la confirmación de entrega. La función IsError es esa confirmación.

Fragmento de código

// Intentamos crear una nueva factura
If(
    // PREGUNTAMOS: "¿Ha dado error el envío del paquete (Patch)?"
    IsError(
        Patch(
            'Facturas',
            Defaults('Facturas'),
            {
                // ... datos de la factura ...
            }
        )
    ),
    // SI HAY ERROR (Plan B):
    // Mostramos un mensaje de error claro.
    Notify(
        "Error: no se pudo crear la factura.",
        NotificationType.Error
    ),
    // SI TODO VA BIEN (Plan A):
    // Llevamos al usuario a la pantalla de éxito.
    Navigate('PantallaExito')
)

3. Con Formularios Estándar: Usa los Buzones de «Éxito» y «Fallo» ✅❌

Si usas un control de Formulario estándar, Power Apps te lo pone aún más fácil. El formulario tiene dos «buzones» especiales:

  • OnSuccess: Aquí pones el código que se ejecutará solo si el formulario se guarda correctamente.
  • OnFailure: Aquí pones el código para tu Plan B, lo que se ejecutará si falla el guardado.

Fragmento de código

// En la propiedad OnSelect del botón de ENVIAR
// Simplemente le decimos al formulario que se envíe. Nada más.
SubmitForm(frm_Factura);

// En la propiedad OnSuccess del PROPIO FORMULARIO
// Si todo va bien, navegamos a la pantalla de éxito.
Navigate('PantallaExito');

// En la propiedad OnFailure del PROPIO FORMULARIO
// Si algo falla, mostramos un mensaje de error.
Notify(
    "Error: no se pudo crear la factura.",
    NotificationType.Error
);

¡REGLA DE ORO! ¡MUY IMPORTANTE! Nunca pongas código justo después de la función SubmitForm() en el botón.

Fragmento de código

// ¡¡¡NO HAGAS ESTO!!!
SubmitForm(frm_Factura);
Navigate('PantallaExito'); // ¡Esto está MAL!

¿Por qué? Porque si SubmitForm falla, Power Apps seguirá ejecutando la siguiente línea de código. El resultado es que el usuario será llevado a la pantalla de «Éxito» aunque sus datos no se hayan guardado. ¡Un desastre!

4. Con Power Automate: La Misma Regla de «Confirmar Entrega» 🤖

Cuando tu app llama a un flujo de Power Automate, aplica la misma lógica que con Patch. Un flujo puede fallar por muchas razones. Usa IsError para comprobar la respuesta antes de continuar.

Fragmento de código

// Preguntamos si la ejecución del flujo ha dado error
If(
    IsError(
        MiFlujoParaTraerFacturas.Run("C0001023")
    ),
    // Si falla, notificamos
    Notify("Error: no se pudieron recuperar las facturas.", NotificationType.Error),
    // Si va bien, continuamos
    Navigate('PantallaExito')
)

5. La Red de Seguridad para tus Cálculos (Función IfError) 🤸

A veces, una operación matemática puede dar un error (el más típico es dividir por cero). La función IfError es una red de seguridad que te permite indicar un valor alternativo en caso de que el cálculo falle.

Fragmento de código

// Queremos calcular el porcentaje de tareas completadas
// Si gblTareasTotales es 0, esto daría un error de "división por cero".
// Con IfError, si eso ocurre, simplemente devolverá 0. ¡Sin dramas!
IfError(
    gblTareasCompletadas / gblTareasTotales,
    0 
)

6. La Alarma General para Errores Inesperados (OnError) 🚨

La propiedad OnError de la aplicación es la «alarma de incendios» general. Atrapa cualquier error que tú no hayas controlado previamente con IsError o IfError.

  • Durante el desarrollo: Puedes usarla para mostrarte a ti, como desarrollador, un mensaje muy detallado sobre qué ha fallado, dónde y por qué. Te ayuda a encontrar y arreglar fallos rápidamente.
  • En producción (la app final): Nunca muestres ese mensaje técnico al usuario final, ¡le asustarás! Para las apps en producción, lo que se hace es usar OnError para registrar el error de forma silenciosa en un sistema de análisis (como Trace y Azure Application Insights), de modo que los desarrolladores puedan verlo y arreglarlo sin que el usuario se entere del detalle técnico.

Power Apps Standards: Diseño de formularios y guía UX

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards: Diseño de formularios y guía UX

Un buen formulario es como un asistente amable que guía al usuario, le ayuda a no cometer errores y le avisa si algo va mal. Aquí te explico los trucos para conseguirlo.

1. Ponle «Guardarraíles» a tus Campos de Texto

Cuando un campo solo debe contener números (como un año o una cantidad), no dejes que el usuario pueda escribir letras.

  • Ponlo en modo numérico: En las propiedades del campo de texto, cambia la propiedad Format a Number. Esto hará que en el móvil solo aparezca el teclado numérico y en el ordenador no se puedan escribir letras. Es la forma más fácil de evitar errores.
  • Limita la longitud: Ajusta la propiedad MaxLength para que coincida con el límite de caracteres del campo. Puedes poner un número fijo o, mejor aún, preguntarle a tu origen de datos cuál es el límite para ese campo.

Fragmento de código

// En la propiedad MaxLength de un campo de texto para el nombre del proyecto
// Le preguntas a tu origen de datos "Projects" cuál es el largo máximo para el campo "Project Name"
DataSourceInfo(Projects, DataSourceInfo.MaxLength, "Project Name")

2. Revisa los Datos Antes de Enviar ✅

Antes de que el usuario pulse «Enviar», asegúrate de que el formulario está bien rellenado. Esto se llama validación de datos. Comprueba cosas como:

  • Que los campos obligatorios no estén vacíos.
  • Que los datos tengan el formato correcto (emails con «@», teléfonos con el número de dígitos adecuado, etc.).
  • Que los números estén dentro de un rango permitido (ej: una nota del 1 al 10).
  • Que los campos de confirmación coincidan (ej: al escribir una nueva contraseña).

Cuando algo está mal, tienes que avisar al usuario. Puedes hacerlo de dos maneras:

  1. Después de enviar: El usuario pulsa «Enviar» y solo entonces la app revisa todo y le dice lo que está mal.
  2. Antes de enviar (en tiempo real): A medida que el usuario escribe, la app va validando cada campo. Si un campo está correcto, le pones un ✔️ al lado. Es la opción más moderna y amigable.

Para mostrar los errores, usa una o varias de estas estrategias:

  • Muestra una lista en la parte superior del formulario con todos los errores.
  • Resalta en rojo el borde de los campos que están mal.
  • Muestra un mensaje de error justo al lado del campo incorrecto.

¡Error común a evitar! No desactives el botón de «Enviar» sin más. Si lo haces, el usuario no sabrá por qué no puede continuar. Es mejor dejarlo activo y, si lo pulsa, mostrarle los errores que debe corregir.

3. Ten un Plan B para los Errores 🆘

Nunca asumas que un formulario se ha enviado correctamente solo porque el usuario le dio a «Enviar». Pueden pasar cosas: se cae la conexión a internet, la base de datos da un error, etc. A esto se le llama manejo de errores.

  • Si usas un control de Formulario: Aprovecha las propiedades OnSuccess (qué hacer si todo va bien) y OnFailure (qué hacer si algo falla).
  • Si usas la función Patch: Envuelve tu función Patch dentro de una función IfError. Así, si Patch da un error, puedes capturarlo y actuar en consecuencia.

Regla de oro: Si ocurre un error, muéstrale un mensaje claro al usuario («No se pudo guardar el registro por un problema de conexión. Por favor, inténtalo de nuevo.») y no le saques de la pantalla hasta que el problema se solucione.

4. ¡Evita que se Pierda el Trabajo! 💾

A todos nos ha pasado: estás rellenando un formulario largo, le das sin querer al botón de «Atrás» y pierdes todo tu trabajo. ¡Es frustrante!

Para evitarlo, si el usuario ha modificado algo en el formulario e intenta salir, muéstrale un menú emergente de confirmación. Pregúntale algo como: «Tienes cambios sin guardar. ¿Seguro que quieres salir?», con los botones «Aceptar» y «Cancelar».

5. Usa un Formulario «Camaleón» para Todo 🦎

En lugar de crear una pantalla para «Crear Registro», otra para «Editar Registro» y una tercera para «Ver Registro», usa un único formulario para las tres cosas.

Esto te ahorra muchísimo tiempo de desarrollo y mantenimiento, y te aseguras de que el diseño sea siempre consistente. El formulario es como un actor versátil que puede interpretar tres papeles distintos.

  • Si usas un control de Formulario: Es muy fácil. Simplemente usa las funciones NewForm, EditForm y ViewForm para cambiar el «modo» del formulario.
  • Si usas la función Patch: Es un poco más manual. Tienes que crear código para cambiar la propiedad DisplayMode de cada control individualmente (de editable a solo vista).

Power Apps Standards: Plantillas de Estilo

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards: Plantillas de Estilo

Creando un Estilo para tu App: Tu Propio «Kit de Diseño»

Para que tu aplicación tenga un aspecto coherente y profesional, no puedes ir decidiendo los colores y las fuentes sobre la marcha. Lo que se hace es crear un «Kit de Diseño» o un «Manual de Estilo» desde el principio.

Piensa en ello como si fueras un diseñador de interiores: antes de empezar a decorar una casa, eliges la paleta de colores, el tipo de muebles y el estilo general. En Power Apps hacemos lo mismo.

Este «Kit de Diseño» se define en una propiedad de la aplicación llamada OnStart. Piensa en OnStart como lo primero que la app lee al «despertarse». Ahí es donde cargaremos todas nuestras reglas de estilo para que estén disponibles en toda la aplicación.

Los 4 Pilares de tu «Kit de Diseño»

Definiremos 4 grandes variables «globales» (recuerda, las que están disponibles en toda la casa) para guardar nuestro estilo:

Nombre de la VariablePropósito (¿Qué guardamos aquí?)
gblAppColorsLa Paleta de Colores oficial de la app.
gblAppFontsLas Tipografías y Tamaños que usaremos (para títulos, texto normal, etc.).
gblAppIconsNuestro Set de Iconos personalizados.
gblAppDefaultsLas Reglas de Estilo por Defecto para todos los controles (botones, textos, etc.).

El Truco del Copia y Pega: Un consejo de profesional es tener una pantalla oculta en tu app llamada «Plantillas» o «Controles Maestros». En esa pantalla, dejas una copia de cada control (un botón, una etiqueta, etc.) ya con el estilo aplicado. Así, cuando necesites un botón nuevo, en lugar de crearlo de cero y aplicarle 10 propiedades de estilo, simplemente vas a tu pantalla oculta, copias el botón maestro y lo pegas donde lo necesites. ¡Te ahorrará horas de trabajo!

El Código Mágico para tu «Kit de Diseño»

Aquí tienes un ejemplo de código que puedes copiar y pegar directamente en la propiedad OnStart de tu aplicación para definir tu kit. Es un punto de partida genial.

Fragmento de código

// --- 1. La Paleta de Colores de la App ---
Set(
    gblAppColors,
    {
        // Colores principales de tu marca
        Primario1: ColorValue("#30475E"), // Un azul oscuro
        Primario2: ColorValue("#F05454"), // Un rojo coral
        Primario3: ColorValue("#222831"), // Casi negro
        Primario4: ColorValue("#DDDDDD"), // Un gris muy claro

        
        // Colores de acento para mensajes, alertas, etc.
        Negro: ColorValue("#000000"),
        Verde: ColorValue("#28A745"), // Para éxitos
        Rojo: ColorValue("#DC3545"), // Para errores
        Blanco: ColorValue("#FFFFFF"),
        Amarillo: ColorValue("#FFC107"), // Para avisos
        
        // Colores neutros (grises) para fondos, bordes, etc.
        GrisOscuro: ColorValue("#484644"),
        GrisMedio: ColorValue("#B3b0AD"),
        GrisClaro: ColorValue("#F3F2F1")
    }
);

// --- 2. Las Tipografías y Tamaños de la App ---
Set(
    gblAppFonts,
    {
        // Fuentes para los textos
        Titulos: "Roboto, Open Sans", // Si no encuentra Roboto, usará Open Sans
        Cuerpo: "Lato",
        
        // Tamaños estándar para no ir a ojo
        Tamaño: {
            Mini: 10,
            Normal: 13,
            Subtitulo: 16,
            Titulo: 20,
            Enorme: 28
        }
    }
);

// --- 3. Los Iconos Personalizados de la App ---
Set(
   gblAppIcons,
    {
       // El código de los iconos se guarda en una tabla de Excel llamada AppIcons
       Checklist: LookUp(AppIcons, Nombre="Checklist", CodigoSVG),
       Checkmark: LookUp(AppIcons, Nombre="Checkmark", CodigoSVG)
   }
);

// --- 4. Las Reglas de Estilo por Defecto para los Controles ---
// Esta es la parte más larga. Define cómo se verá un botón, una etiqueta, etc.
// por defecto, para no tener que configurarlo cada vez.
Set(
    gblAppDefaults,
    {
        // ... aquí iría toda la lista de propiedades por defecto ...
        // Por ejemplo:
        Altura: 40,
        ColorTexto: gblAppColors.Negro,
        RellenoBoton: gblAppColors.Primario1,
        ColorBotonHover: ColorFade(gblAppColors.Primario1, -10%), // Un poco más oscuro al pasar el ratón
        BordeRadio: 0 // Esquinas cuadradas por defecto
        
        // El código completo del ejemplo original iría aquí.
    }
);

El Truco de los Iconos (SVG)

Los iconos que no son estándar (como el logo de tu empresa) se suelen usar en formato SVG, que es básicamente código que dibuja una imagen. Para no ensuciar el código de la app, el truco es:

  1. Crear un Excel con dos columnas: Nombre y CodigoSVG.
  2. En cada fila, pones el nombre del icono (ej: «LogoEmpresa») y pegas todo el código SVG en la otra celda.
  3. Usas la opción «Importar desde Excel» en Power Apps para añadir esa tabla a tu aplicación. ¡Y listo! Ya puedes llamar a tus iconos.

¿Te Parece Mucho Lío? ¡Usa una Plantilla!

Si todo lo anterior te parece demasiado trabajo, hay una solución más fácil. La comunidad ha creado plantillas que hacen todo esto por ti.

La más recomendada es la Plantilla de Branding de Sancho Harker. Es la mejor por varias razones:

  • Súper rápido de configurar: Solo tienes que elegir 3 colores principales y la plantilla crea toda la paleta de colores y las reglas de estilo automáticamente.
  • Totalmente personalizable: Si no te gusta cómo se ve un tipo de botón por defecto, puedes cambiarlo fácilmente.
  • Funciona para los controles nuevos: Cualquier control nuevo que añadas a la app ya adoptará el estilo automáticamente. ¡Magia!
  • ¡No necesitas licencia Premium! Funciona con cualquier licencia de Power Apps, ya que guarda toda la información de estilo dentro de la propia aplicación.

Power Apps Standards: Revisando Aplicaciones Canvas

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards: Revisando Aplicaciones Canvas

Poniendo a Prueba tu App: El Control de Calidad

Antes de que una aplicación vea la luz, tiene que pasar por varias fases de revisión. Es como cuando un chef prueba un plato varias veces antes de que salga de la cocina. ¡Vamos a ver cuáles son!

El Corrector Automático (Comprobador de Aplicaciones) 🔍

Piensa en el Comprobador de Aplicaciones como el corrector ortográfico de Word, pero para tu aplicación. Es una herramienta que viene dentro de Power Apps y que está constantemente revisando lo que haces.

  • Si ve un error grave (una fórmula mal escrita o algo que romperá la app), te avisará con un punto rojo. Es como la línea roja que subraya una palabra mal escrita. ¡Es obligatorio arreglarlo!
  • También te dará avisos sobre otras cosas que no son errores «rojos», como problemas de accesibilidad (cosas que dificultan el uso a personas con alguna discapacidad) o de rendimiento (cosas que hacen que la app vaya lenta). Aunque no aparezca el punto rojo, también tienes que arreglarlos.

Regla de oro: Antes de publicar tu app, el App Checker debería estar limpio, sin ningún aviso. Si por alguna extraña razón no puedes arreglar algo, tienes que tener una justificación muy, muy buena.

La «ITV» del Código (Power Apps Code Review Tool) ✅

Esta es una herramienta externa de Microsoft que hace una revisión automática de tu app, como si le pasara la ITV.

La herramienta analiza tu aplicación comparándola con una lista de buenas prácticas y te da una nota. Te dirá qué partes «han pasado la inspección» y cuáles no, explicándote qué tienes que arreglar.

Regla de oro: No te obsesiones con sacar un 100%, a veces hay buenas razones para no seguir una regla al pie de la letra. Intenta conseguir una nota del 90% o más.

Desplegar los Planos (Revisión del Código Fuente) 📜

Imagina que tu app es una casa. Normalmente, para ver el código de un botón, tienes que entrar en esa «habitación» y hacer clic en el botón. Con esta herramienta, es como si desplegaras los planos completos de la casa en una mesa gigante.

La herramienta «desempaqueta» el archivo de tu app y te muestra todo el código de una pantalla en un solo archivo de texto. Esto es súper útil para que un desarrollador pueda leer todo el código de arriba a abajo de un tirón, sin tener que ir haciendo clic en cada elemento.

Recomendación: Para leer estos «planos», se suele usar un programa llamado Visual Studio Code, que tiene herramientas para que el código se vea más claro y ordenado.

Que la Pruebe un Amigo (Pruebas Funcionales) 🧑‍🤝‍🧑

Esta fase es muy simple: consiste en que otra persona pruebe la aplicación, no el mismo desarrollador que la ha creado.

¿Por qué? Porque el creador ya se sabe todos los trucos y caminos. Otra persona (un compañero desarrollador o un tester profesional) usará la app de formas inesperadas y es mucho más probable que encuentre fallos o comportamientos raros. Es como pedirle a un amigo que lea un email importante que has escrito; seguro que encuentra algún error que tú ya no veías.

El Ensayo General con Público (Pruebas de Aceptación del Usuario – UAT) 🎯

Esta es la prueba de fuego y la más importante de todas. Antes de lanzar la app a toda la empresa, se selecciona a un pequeño grupo de personas que serán los usuarios finales para que la prueben.

No se trata de que busquen errores de código, sino de que confirmen si la aplicación es útil, fácil de entender y si realmente les soluciona el problema para el que fue creada. Se les da un guion con tareas típicas (ej: «Crea un nuevo cliente», «Registra un gasto») y ellos dan su opinión.

Su feedback es crucial para hacer los últimos retoques y asegurar que la app no solo funciona, sino que la gente querrá usarla.

Power Apps Standards: Configuración de Aplicaciones

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards: Configuración de Aplicaciones

Pestaña General: El Logo y el «Modo Detective» 🕵️‍♂️

  • Icono de la aplicación: Es la imagen que representará tu app. Puedes elegir uno de los que vienen por defecto o subir tu propio logo. Si subes el tuyo, asegúrate de que sea una imagen cuadrada de 245×245 píxeles en formato .jpg o .png y que coincida con la imagen de tu empresa. 🎨
  • Depurar la aplicación publicada: Piensa en esto como un «modo detective» para tu app.
    • Actívalo mientras estás creando la aplicación. Te dará más pistas si algo falla.
    • Desactívalo antes de que la gente empiece a usar la app de forma oficial. Este modo hace que la app vaya un poco más lenta, y quieres que el rendimiento sea el mejor posible para el usuario final.

Pestaña Mostrar: Cómo se ve tu App 🖥️📱

Aquí decides cómo se adaptará tu aplicación a las diferentes pantallas.

  • Para ordenadores y portátiles: La gente espera que las apps se ajusten al tamaño de la ventana. A menos que sea un prototipo rápido o tengas poco presupuesto, haz que tu diseño sea adaptable («responsive»).
  • Para móviles: Como la gente suele sujetar el móvil en vertical, elige la orientación vertical. Es crucial que bloquees la orientación para que la app no se gire y se descuadre si el usuario mueve el teléfono.
  • Para tablets: La orientación depende del uso:
    • Si el usuario va a estar de pie o caminando (p. ej., un operario en un almacén), elige vertical.
    • Si el usuario va a estar sentado (p. ej., un comercial mostrando un catálogo), elige horizontal.
    • Si no lo tienes claro, haz que la app sea adaptable.

Chuleta de configuración recomendada

Empieza con estos ajustes y cámbialos solo si tienes una buena razón.

  • App para Ordenador (Horizontal):
    • Ajustar al tamaño: No
    • Bloquear relación de aspecto: No
    • Bloquear orientación: No (Le das total libertad para que se adapte sola).
  • App para Móvil (Vertical):
    • Ajustar al tamaño: Sí
    • Bloquear relación de aspecto: Sí
    • Bloquear orientación: Sí (Así te aseguras de que se vea exactamente como la diseñaste).
  • App para Tablet (Vertical u Horizontal):
    • Igual que en el móvil, activa las tres opciones (Sí, Sí, Sí) para una experiencia controlada.

Pestaña Actualizaciones: Novedades y Experimentos 🧪

Aquí decides si quieres usar las funcionalidades más nuevas que Microsoft está preparando.

  • Características en versión preliminar (Preview): Son novedades que están a punto de salir oficialmente. Recomendación: actívalas todas, ya que pronto serán estándar y así te vas acostumbrando.
  • Características experimentales (Experimental): ¡Cuidado! Son pruebas que pueden cambiar, romperse o desaparecer. No las uses en aplicaciones en producción a menos que las hayas probado a fondo.
  • Características retiradas (Retired): 👴 Son funciones antiguas y obsoletas. Nunca las uses.

Excepciones importantes:

  • Activa la característica experimental «Propiedades de componente mejoradas».
  • No actives la característica en preliminar «Mantener en memoria las pantallas visitadas recientemente».

Pestaña Soporte Técnico: La Versión de tu «Taller» 🏗️

  • Versión de creación de Power Apps: Esto es como la versión de las herramientas con las que construyes tu app. No la cambies a mitad de un proyecto. Si lo haces, podrías introducir errores inesperados. Si tienes que actualizarla, deberás volver a probar toda la aplicación para asegurarte de que todo sigue funcionando correctamente.

Power Apps Standards – Comentar Código

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards – Comentar Código

¿Para Qué Escribir Comentarios en el Código? Las «Notas al Margen» para tu Yo del Futuro

Imagina que escribes una fórmula súper ingeniosa en tu Power App. En ese momento, te parece la cosa más lógica del mundo. Pero vuelves a verla dentro de seis meses… y no tienes ni la más remota idea de qué hace o, más importante, por qué lo hiciste así.

Los comentarios son precisamente eso: notas al margen que te dejas a ti mismo y a otros desarrolladores para explicar la intención de tu código. Son para los humanos, no para el ordenador.

Saber lo que querías que hiciera el código es súper útil, sobre todo cuando algo falla. Si tu comentario dice «aquí calculo el descuento del 15%» y el resultado que ves es un 20%, ¡bingo!, ya sabes dónde está el error.

El Debate de los Informáticos: ¿Comentarios Sí o No?

Entre los programadores hay un eterno debate sobre si se debe comentar el código o no. Algunos dicen que un buen código se explica por sí mismo.

La respuesta corta para nosotros es: en Power Apps, sí, úsalos. Ahorran muchísimo tiempo.

¡Ojo! Esto no es una excusa para escribir código enrevesado. Un comentario no arregla un código que no hay por dónde cogerlo. Sería como cocinar un plato horrible y ponerle un cartelito que diga «Sabe bien». ¡Mejor cocina bien desde el principio!

El Estilo: Cómo Dejar Comentarios «Elegantes»

Para que todo quede limpio y ordenado, sigue estas simples reglas de estilo:

  1. Pon el comentario en su propia línea, justo encima del código que quieres explicar.
  2. Nunca pongas un comentario al lado de una línea de código. Queda desordenado.
  3. Empieza el comentario con mayúscula.
  4. Termina la frase con un punto.

Los Dos Tipos de «Post-it» que Puedes Usar

En Power Apps tienes dos maneras de dejar notas:

La Nota Rápida (Comentario de Línea)

Se usa para una sola frase. Simplemente pones dos barras // al principio.

Sintaxis: // [Aquí va tu comentario]

Ejemplo:

Fragmento de código

// Validar la orden de trabajo para asegurar que no será rechazada al enviarla.
If(IsBlank(txt_FirmaCliente.Text), DisplayMode.Disabled, DisplayMode.Edit)

El Parrafito Explicativo (Comentario de Bloque)

Perfecto para cuando necesitas explicar algo con más detalle. Empieza con /* y termina con */.

Sintaxis: /* [Aquí va tu súper comentario de varias líneas] */

Ejemplo:

Fragmento de código

/*
 Pantalla de Detalles de la Orden:
 – Se usa un único formulario para crear, editar y ver un registro.
   Así minimizamos el número de controles en la app.
 – Envía un PDF firmado por email al jefe del empleado
   después de enviar el formulario para guardarlo como copia.
*/
Visible = locModoFormulario = "Editar"

Consejos de Oro para Escribir Buenos Comentarios

Aquí viene lo más importante. No se trata de escribir por escribir.

👍 HAZ ESTO: Explica el «PORQUÉ» (la intención). Un buen comentario es como el «cómo se hizo» de una película. No describe lo que ves en pantalla, sino por qué el director tomó esa decisión.

  • Ejemplo: // Calcular el total final incluyendo el impuesto de tarifa especial para Canarias.

👎 NO HAGAS ESTO: No expliques el «QUÉ» (lo que es obvio). El código ya dice lo que hace. No hace falta que lo traduzcas. Eso es ruido.

  • Mal ejemplo: // Poner el valor de la variable 'NombreUsuario' a "Juan" Set(gblNombreUsuario, "Juan") (¡Ya se ve que hace eso!)

👍 HAZ ESTO: Si cambias el código, ¡actualiza el comentario! Un comentario anticuado es peor que no tener ningún comentario, porque miente y confunde. Si cambias la receta, ¡tacha la nota antigua!

👎 NO HAGAS ESTO: No te pases comentando cada línea. Comentar en exceso es contraproducente. Cada comentario es algo más que tienes que mantener, y si hay demasiados, la gente dejará de leerlos. Es como acumular «deuda»: al final te da más trabajo del que te ahorra.

👍 HAZ ESTO: Escribe frases completas y con un lenguaje normal. Escribe como si se lo estuvieras explicando a un compañero de trabajo.

👎 NO HAGAS ESTO: Evita abreviaturas, siglas raras o jerga. No escribas «Calc. imp xq el usr es de Fuerteven.». Escribe la frase completa para que cualquiera, incluso alguien nuevo en el proyecto, lo pueda entender.

Power Apps Standards – Variables

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards – Variables

El Alcance de las Variables: ¿Dónde «Viven» tus Datos?

El «alcance» de una variable simplemente decide en qué partes de tu aplicación (tu «casa») puedes leer o usar esa nota. Si necesitas un dato en muchas habitaciones, usarás una nota «global». Si solo la necesitas en una habitación, usarás una nota «local».

Elegir el tipo correcto es clave para tener una app ordenada y que funcione bien.

Tipo de Variable (y su analogía)Cómo se Crea (la Función)Dónde Funciona (su Alcance)
Global (El Post-it en la nevera)SetLa nota está disponible en todas las habitaciones de la casa (en toda la app).
Local (La pizarra de la cocina)UpdateContextLa nota solo existe y se puede leer en una sola habitación (la pantalla actual).
De un solo uso (El cálculo en una servilleta)WithLa nota solo existe para hacer un cálculo rápido y se tira a la basura al terminar.

Ejemplos para que lo veas claro

1. Variable Global (El Post-it en la Nevera) – Función Set

Úsala para guardar datos que necesitas en TODA la app, como el nombre del usuario que ha iniciado sesión.

Con Set, le dices a Power Apps: «Oye, crea este Post-it y pégalo en la nevera para que todos lo vean».

Fragmento de código

// Le decimos a la app: "Crea una nota global llamada 'gblImpuestoVenta'"
// "y apunta el resultado de coger el subtotal y multiplicarlo por 0.13"
Set(
    gblImpuestoVenta,
    Value(txt_Pedidos_Subtotal.Text) * 0.13
);

2. Variable Local (La Pizarra de la Cocina) – Función UpdateContext

Úsala para cosas que solo importan en la pantalla donde estás, como mostrar u ocultar un menú emergente.

Con UpdateContext, le dices: «Apunta o actualiza estas notas en la pizarra de ESTA habitación». Puedes crear o modificar varias a la vez.

Fragmento de código

// Le decimos a la app: "En la pizarra de esta habitación..."
UpdateContext(
    {
        // "...apunta que el número de productos es 0"
        locContadorProductos: 0,
        // "...apunta que el menú de confirmación está oculto (false)"
        locMostrarMenuConfirmacion: false,
        // "...y borra lo que sea que hubiera en el formulario de pedido"
        locModoFormularioPedido: Blank()
    }
);

(Truco: Fíjate que los nombres empiezan por gbl para las globales y loc para las locales. ¡Es una buena práctica para no liarte!)

3. Variable de un Solo Uso (El Cálculo en la Servilleta) – Función With

Esta es genial para no ensuciar tu app con variables que solo necesitas un instante. Es como hacer un cálculo rápido en una servilleta y luego tirarla.

Con With, le dices: «Primero, calcula esto y guárdalo en esta nota temporal. Justo después, usa esa nota para hacer esto otro. Luego, olvídate de todo».

Fragmento de código

// Le decimos a la app:
// "PRIMERO: busca el contacto de este pedido y guárdalo en una 'servilleta' 
// llamada 'contactoDelNegocio'"
With(
    {contactoDelNegocio: LookUp('Pedidos de Venta', ID = ThisItem.ID)},
    
    // "SEGUNDO: ahora usa esa servilleta para juntar el nombre, un espacio 
    // y el apellido. Cuando termines, tira la servilleta a la basura."
    Concatenate(
        contactoDelNegocio.Nombre,
        " ",
        contactoDelNegocio.Apellido
    )
);

¿Por Qué Complicarse con Variables Globales y Locales?

Podrías pensar: «Si las variables globales se pueden usar en todas partes, ¿por qué no usar solo esas y me quito de líos?». ¡Buena pregunta! La respuesta corta es: para evitar el caos y crear apps que no se rompan solas.

El Peligro de Usar Solo Variables Globales (El Caos de los Post-its en la Nevera)

Imagina una mansión enorme (una app muy grande con muchas pantallas) donde la única forma de comunicarse es dejando Post-its en la nevera de la cocina.

Al principio parece fácil. Dejas una nota que dice: cantidadLeche = 1.

Pero de repente, alguien en el salón (Pantalla A) está pensando en hacer un bizcocho y cambia la nota de la nevera a cantidadLeche = 3. Un poco después, otra persona en el jardín (Pantalla B), que solo quería un café, ve la nota, coge el único cartón de leche y, como ya lo ha usado, cambia la nota a cantidadLeche = 0.

Por la noche, la persona del salón va a hacer su bizcocho, mira la nota que él mismo había cambiado y ve que pone «0». ¡Alguien ha usado la leche! Su plan se ha arruinado.

Ese es el problema: cuando una variable puede ser modificada desde cualquier sitio, es muy difícil seguirle la pista. Un cambio que haces en una pantalla puede romper algo en otra punta de la aplicación sin que te des cuenta. Arreglar estos fallos («bugs») es una auténtica pesadilla.

La Ventaja de las Variables Locales (Cada Cosa en su Sitio)

Ahora imagina que cada habitación tiene su propia pizarra. La persona del salón puede apuntar en su pizarra: lecheParaBizcocho = 3.

Puede cambiar ese número, borrarlo o hacer lo que quiera, con la total tranquilidad de que no está afectando a ninguna otra pizarra de la casa. La persona del jardín seguirá viendo la nota principal de la nevera (cantidadLeche = 1) y sabrá que esa es la leche para todos.

Para el que crea la app, esto es un alivio. Es mucho más fácil y rápido comprobar que todo funciona bien en una sola pantalla, sabiendo que tus cambios están «encapsulados» y no van a provocar un desastre en otro lugar. Escribes código de mejor calidad y mucho más rápido.

La Eficiencia de las de un Solo Uso (Mantén tu Casa Ordenada)

Y por último, las variables de la servilleta (With). ¿Por qué existen? Para no acumular basura.

Imagina que cada vez que haces un cálculo rápido (sumar dos números, buscar un dato…), lo apuntas en un Post-it y lo pegas en la nevera. En poco tiempo, la nevera estaría tan llena de notas que sería imposible encontrar la importante.

La memoria de tu app funciona parecido. Si la llenas de variables que solo usas una vez, la estás sobrecargando inútilmente, y eso puede hacer que vaya más lenta.

La función With es como usar una servilleta: haces el cálculo, lo usas en ese mismo instante y la tiras a la basura. La variable desaparece de la memoria, manteniendo tu app limpia, ordenada y ágil.

Power Apps Standards – Nomenclaturas

Escrito por Enrique G. en . Publicado en Power Apps. No hay comentarios en Power Apps Standards – Nomenclaturas

1. Nombres de las Pantallas: ¡Ponles un Apellido!

Cada pantalla de tu aplicación es como una habitación de una casa. Necesitas saber para qué sirve de un solo vistazo.

  • La regla de oro: El nombre debe decir para qué es la pantalla (en 2 o 3 palabras) y siempre terminar con la palabra Screen. Pon la primera letra de cada palabra en mayúscula.
  • ¿Por qué es importante? Porque ayuda a los programas de lectura para personas con discapacidad visual a anunciar «has entrado en la pantalla de Pedidos», haciendo tu app más accesible para todos.
👍 Buenos Ejemplos👎 Malos Ejemplos🤔 ¿Por qué está mal?
PantallaPedidosPedidosLe falta el «apellido» Pantalla.
PantallaFirmaClientePantallaFirmaDelClienteDemasiado largo y lioso para leer.
PantallaPrincipalpantallaprincipalLas mayúsculas importan, así se lee mejor.

2. Nombres de los Controles: ¡Las Etiquetas Chivatas!

Los controles son los «juguetes» que pones en cada pantalla: botones, cajas para escribir texto, listas desplegables, etc. Sus nombres deben ser como etiquetas chivatas que te digan 3 cosas de un vistazo: qué es, dónde está y para qué sirve.

La fórmula mágica es: prefijo_Pantalla_Proposito

  • Prefijo: Unas siglas cortas para saber qué tipo de control es (ej: btn para botón, txt para texto). Abajo te dejo una chuleta.
  • Pantalla: El nombre de la pantalla donde está (sin la palabra Screen).
  • Propósito: Para qué sirve ese control.
👍 Buenos Ejemplos👎 Malos Ejemplos🤔 ¿Por qué está mal?
btn_Pedidos_Enviarbtn_Enviar_PedidosEl orden está al revés.
txt_Principal_EmailUsuarioTextoEmailNo dice dónde está ni qué es exactamente.
gal_Clientes_ListagaleriaClientesNo sigue el formato, es más difícil de leer.

Chuleta de Prefijos Más Comunes

¿Qué es?Prefijo
Un Botón (Button)btn
Una Entrada de Texto (Text Input)txt
Una Etiqueta (Label)lbl
Una Galería (para mostrar listas)gal
Un Desplegable (Drop Down)drp
Un Icono (Icon)ico
Una Imagen (Image)img
Un Selector de Fecha (Date Picker)dte
Una Casilla de Marcar (Check Box)chk

3. Nombres de las Variables: ¡Cajas para Guardar Datos!

Imagina que una variable es una caja donde guardas un dato temporalmente (el email del usuario, un resultado de un cálculo, etc.). El nombre de la caja debe decirte qué tipo de caja es y qué hay dentro.

  • La regla: Usa gbl al principio si el dato se puede usar en toda la aplicación (Global), o loc si solo se usa en la pantalla actual (Local). Luego, di para qué es, juntando las palabras y poniendo la primera letra de cada una en mayúscula (esto se llama camelCase, ¡como las jorobas de un camello!).
👍 Buenos Ejemplos👎 Malos Ejemplos🤔 ¿Por qué está mal?
gblUsuarioConectadoUsuarioConectadoNo sabemos si es global o local.
locCantidadCajasloc_Cantidad_Cajas¡Sin guiones bajos! Todo junto.
locCargandoDatoslocBooleanoCargandoNo incluyas el tipo de dato (eso ya lo sabe la app).

4. Nombres de las Colecciones: ¡Tus Libretas de Apuntes!

Una colección es como una libreta donde te apuntas una lista de cosas para trabajar con ellas dentro de la app (por ejemplo, una lista de clientes que has filtrado).

  • La regla: Empieza siempre con col. Si los datos vienen de algún sitio, pon una abreviatura de su origen (ej: Sp para SharePoint, Dv para Dataverse). Luego, describe qué datos contiene. Todo junto en formato camelCase.
👍 Buenos Ejemplos👎 Malos Ejemplos🤔 ¿Por qué está mal?
colSpEmpleadoscolEmpleadosNo dice de dónde vienen los datos.
colDvLeadsVentascoldv_leads_ventas¡Vaya lío de mayúsculas y guiones!
colMenuNavegacionMenuNavegacionLe falta el prefijo col.

5. Nombres de las Tablas de Datos: ¡Los Almacenes!

Estas son las tablas donde guardas la información «de verdad» (tu lista de productos, tu base de datos de empleados…).

  • La regla: Sé claro y conciso (1 a 3 palabras). Usa singular (ej: Pedido en vez de Pedidos) y pon la primera letra de cada palabra en mayúscula.
👍 Buenos Ejemplos👎 Malos Ejemplos🤔 ¿Por qué está mal?
EmpleadoEmpNo uses abreviaturas, ¡sé claro!
ProyectoConstruccionProyectosDemasiado general, ¿proyectos de qué?
OrdenReparacionOrdenesReparacionesMejor en singular y con las mayúsculas bien puestas.

Desarrollado por
►
Las cookies necesarias habilitan funciones esenciales del sitio como inicios de sesión seguros y ajustes de preferencias de consentimiento. No almacenan datos personales.
Ninguno
►
Las cookies funcionales soportan funciones como compartir contenido en redes sociales, recopilar comentarios y habilitar herramientas de terceros.
Ninguno
►
Las cookies analíticas rastrean las interacciones de los visitantes, proporcionando información sobre métricas como el número de visitantes, la tasa de rebote y las fuentes de tráfico.
Ninguno
►
Las cookies de publicidad ofrecen anuncios personalizados basados en tus visitas anteriores y analizan la efectividad de las campañas publicitarias.
Ninguno
Desarrollado por
Powered by  GDPR Cookie Compliance
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.