> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/microsoft-design-style-vision-y-proceso.md). # Microsoft Design Style: Visión y Proceso Es curioso saber cómo Microsoft se inspiró en este lenguaje de diseño. Impresión y embalaje de estilo suizo, rótulos o gráficos utilizados en los centros de transporte para orientar caminos, e incluso nuestro propio software. La página “”, también es indicativo de ello. En la siguiente figura podemos ver un claro ejemplo de estos estilos. *Si los tenemos en nuestro día a día y ya los conocemos, ¿por qué no llevarlos al mundo móvil y aprovechar este conocimiento? ¡a buen entendedor pocas palabras bastan! Microsoft ha apostado por ello.* ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-09f16579ef5221741b3f5a69cd5dc3ca5429061a%2Fimage8.png?alt=media) **Figura 08- Inspiración de Microsoft Design Style** Recordemos, según vimos en el capítulo anterior, que este proceso surgió como una iniciativa denominada **Metro** y que ha derivado en lo que hoy conocemos como *Microsoft Design Style* (o ***Microsoft Design Language***) y en la que Microsoft no permanecerá quieto. Según dice, “se trata de un viaje multi-anual” y, por tanto, seguirá evolucionando. Para conocer más sobre esta historia, visitar la página: . {% hint style="info" %} **Nota**: Si los requisitos, no se entienden bien desde el principio, la aplicación nunca llegará a tener éxito. El prototipo es un camino acertado y el boceto, un buen punto de partida. {% endhint %} Como sabemos, los **cinco principios** básicos del nuevo diseño *Microsoft Design Language* se basan en un **proceso** que consta de cinco etapas que debemos cubrir desde el comienzo. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-200f4b5655cf778e844bbdc262c1dbd88e4b56da%2Fimage9.png?alt=media) **Figura 09.- Etapas del proceso de diseño “Microsoft Design Style”** ## Concepto El concepto o modelo conceptual es la etapa en la que nos plantearemos tres preguntas, que responderemos de acuerdo a lo que el usuario será capaz de hacer con la aplicación: * ¿Qué va a hacer la aplicación? o ¿Qué queremos que haga? * ¿Para quién es? o ¿A quién va dirigida? * ¿En qué va a destacar? ## Estructura Partiremos de la premisa, “todo es más fácil con una buena organización y una sencilla navegación”. Diseñaremos por tanto la estructura o Arquitectura de Información (AI), de nuestra aplicación. Concretaremos cada una de las pantallas que la formarán y estableceremos la relación jerárquica entre ellas. Antes de crear la navegación de nuestra aplicación, echaremos un vistazo a las recomendaciones de Microsoft para aplicaciones UWP que contempla tres tipos de navegación tal y como recoge la siguiente tabla. **Tabla 1.- Conceptos básicos de navegación entre páginas** | Representación | Tipo | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-a07c2b410c7bdee7685a316e8e51a7d6ea4952aa%2Fimage10.png?alt=media) | **Jerárquica**. Las páginas se organizan en una estructura de árbol. Cada página secundaria tiene un elemento primario, y un elemento primario puede tener una o más páginas secundarias. Para llegar a una página secundaria, hay que pasar siempre por un elemento primario. Ej.: Control, *Hub*, patrón “maestro y detalles” (como la aplicación de correo de Windows). | | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-31620701be1ce76f76c00b374f19a7474f327367%2Fimage11.png?alt=media) | **Mismo nivel**. Existen páginas en paralelo. Navegación entre páginas en cualquier orden. Ej.: Controles de pestañas (o Pivot), panel de navegación (Menú *Hamburger*). | | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-64172f9bf2f0d2512dd59e5ad2075d44c753eb80%2Fimage12.png?alt=media) | **Ambas**. Mezcla de las anteriores. | | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-9f7c5c096c6034fd42add46abd8b64921653ef9a%2Fimage13.png?alt=media) | **Botón o navegación hacia atrás.** Permite recorrer el historial de navegación hacia atrás e incluso cambiar entre aplicaciones. | Los **hipervínculos y botones** forman parte del contenido de una página y posibilitan la navegación entre páginas. Es importante asegurar que, haciendo uso de estos, no obviamos los tipos de navegación. Una vez entendido los tipos de navegación, veamos cuál será la estructura base para nuestra aplicación según los requisitos de que disponemos hasta este momento. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-06435692afd326457d419504a2a3eb3f19268e7f%2Fimage14.png?alt=media) **Figura 10.- Estructura de la aplicación Task\[in]** Hemos añadido dos nuevas ventanas dado que suponemos que existirá una ventana ***Config*** para cierta configuración o personalización de usuario y una ventana **Acerca de (o *****About)*** donde mostrar información del usuario y la aplicación. En consecuencia, añadiremos dos nuevos requisitos a nuestro *Product Backlog* (PB). ## Interacción La interacción tiene como objetivo contar la historia de la aplicación a través de bocetos, *wireframes*, maquetas o prototipos. Representaremos justo lo que queremos evitando flujos y acciones innecesarias. “La sencillez y agilidad entre el usuario y la aplicación han de ser lo más natural posible”. Podríamos pensar que con la estructura sería suficiente para comenzar a diseñar la aplicación, y más aún si somos exageradamente técnicos. “Querremos comenzar a desarrollar y estaremos con ganas de enfrentarnos a Visual Studio”. Aunque pueda parecer lo contrario, incluso si la aplicación es para nosotros mismos, **nunca** nos sentiremos conformes con el diseño de la misma. Entraremos en un continuo cambio a medida que vayamos completando funcionalidad y usando la aplicación en el dispositivo físico. Iremos detectando nuevas funcionalidades que querremos añadir. Bien porque lo hemos visto en la aplicación X que acabamos de instalar, bien porque es una novedad que podría encajar en la aplicación o, simplemente porque se trata de una nueva funcionalidad que puede suponernos un reto técnico que nos gustaría incorporar. Evitaremos caer en esta situación si simbolizamos el modelo conceptual y la estructura (o AI) a través de la interacción, siguiendo las siguientes representaciones, donde cada una de ellas evoluciona la anterior. * Boceto. Se trata de un simple dibujo en papel de una idea general resumida de manera sencilla y sin muchos detalles. * Wireframe. Es una representación estática de baja calidad, comúnmente en blanco y negro. * Mockup. Representación estática y de calidad media que muestra las funcionalidades básicas y en color. * Prototipo. Representación del producto final en HTML, PPT, animación o cualquier otro formato navegable, con el que el usuario puede interactuar. Como recomendación, deberíamos completar al menos un boceto, *wireframe* o *mockup* y un prototipo, respondiendo con ello a la pregunta **¿Qué deben poder hacer los usuarios?** Iremos profundizando a continuación en cada uno de ellos utilizando diferentes técnicas y/o herramientas. {% hint style="info" %} **Nota**: Tenemos que centrarnos en una primera versión y en los requisitos que implementará la misma. La incorporación de mejoras, nuevas funcionalidades, etc., las iremos añadiendo en versiones sucesivas. Así, conseguiremos centrarnos en la primera versión y tenerla disponible lo antes posible. Recordemos que perseguimos la eficiencia y por consiguiente evitar costes innecesarios. {% endhint %} ### Boceto (o Sketch). Por supuesto, la primera herramienta que conocemos y que estamos utilizando sin apenas darnos cuenta, consiste en esa hoja de papel en blanco que tenemos delante en la que solemos plasmar nuestra idea con la ayuda de un lápiz o bolígrafo con el que “garabatear” o representar nuestra primera impresión de aplicación. Podríamos simplificarlo como: “*Papel, lápiz y garabato*” Es una de las herramientas más fáciles de utilizar y con un poco de imaginación podemos conseguir que sea bastante poderosa y dinámica. No necesita de aprendizaje e incluso puede aportar mucha interactividad si la estamos presentando a un compañero, a un cliente o a nosotros mismos. Para crear un boceto con estas particularidades, sigamos los siguientes pasos: 1. Dividimos varios **papeles** o folios en blanco en cuatro partes iguales cada uno. 2. Cada una de estas partes representará una **pantalla** o **una parte de ésta** si pretendemos que contenga **secciones**. Estaremos representando en tal caso un control *Hub*, *Pivot*, *Menú*, sección desplegable o cualquier otro control que nos aporte división de contenido. 3. A partir de aquí, utilizar un **lápiz** o bolígrafo para comenzar a dibujar (“garabatear”) en cada una de las partes de papel. 4. Escribir un número o **índice**, en la esquina superior izquierda de cada pantalla e introducirlo en un círculo en un color diferente, por ejemplo, en rojo. Indicar también un sub-índice para cada sección de una pantalla. 5. En una pizarra o un *flipboard*/*flipchart* colocar las pantallas organizadamente y unirlas con flechas de manera que representen un flujo de navegación entre ellas. Podemos utilizar trozos de papel en color para simular el fondo de las pantallas, *Post-Its* como pantallas, una mesa o una pared para plasmar su navegación, pero lo que verdaderamente da la potencia a esta herramienta, es la agilidad para cambiar la navegación e interactuar con terceras personas de una manera amena y creativa. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-90adb5fb961281d10b953220ad9b0f2007848f21%2Fimage15.png?alt=media) **Figura 11.- Boceto en papel sobre una mesa** Una vez que hemos completado nuestra primera versión del boceto. Anotamos las tareas o secuencias de pasos que puede realizar el usuario. Utilizar un folio en blanco o escribir al pie del boceto, la secuencia de estos pasos indicándolos con los índices creados en el punto número 4. Cada una de estas secuencias de pasos es lo que ya conocemos como historias de usuario y definiremos las siguientes: 1-3,1-2, 1-2-4, 1-2-4, 1-2-5, 1-2-6, 1-2-7, 2-2, 2-4, 2-5, 2-6 y 2-7. Igualmente, las flechas e incluso el posicionamiento de las hojas de papel pueden determinar también estas secuencias. ### Wireframe Un *wireframe* no es únicamente una representación gráfica, sino más bien, una idea visual o representación esbozada de cómo será la estructura de cada una de las páginas, que persigue: * La abstracción de colores, estilos, imágenes, etc., e incluso comportamiento, evitando así cualquier tipo de distracción. * Definir la usabilidad de la aplicación. Trata de focalizar los esfuerzos en la estructura, es decir, en el diseño de la interacción, y, generalmente dirigido a nosotros como desarrolladores. Para la generación de Wireframes, existen numerosas herramientas, algunas de las cuales son: *Justinmind, Ilustrator, Fireworks, Mockflow\.com, Balsamiq Mockups* o, *PowerPoint*. Es esta última en la que nos basaremos para construir nuestro *wireframe*. Con nuestro boceto listo comenzaremos a realizar el *wireframe* comenzando por descargar las plantillas de diseño **PowerPoint** (.pptx) proporcionadas por Microsoft y localizadas en este enlace: . Una vez descargadas, dispondremos de un documento *PowerPoint* para cada dispositivo (Tablet, PC y Móvil) donde encontraremos una diapositiva (o *slide*) representando a cada pantalla de estos dispositivos. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-d81ef36e87335c428b9483d18736a502f3da657a%2Fimage16.png?alt=media) ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-e62cfb8db0235eec352b56488597f40c59729724%2Fimage17.png?alt=media) **Figura 12.- Plantillas de diseño PowerPoint** Además de la representación de estas pantallas, contaremos con un conjunto de controles que podemos localizar en el menú “Storyboarding – Storyboard shapes” de PowerPoint. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-8e16feb90cb2f10cd7315dd434949a9da0f7043a%2Fimage18.png?alt=media) **Figura 13.- Paleta de controles de IU de PowerPoint** Con estas plantillas estaremos listos para trasladar nuestro boceto a un siguiente nivel, el *wireframe*. Las dos siguientes figuras, muestran los diferentes *wireframes* para PC/Tabletas y para Teléfonos. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-f4412eaf388905e87d96a3ca2d2c4466311de130%2Fimage19.png?alt=media) **Figura 14.- Wireframe en PowerPoint para PC / Tabletas** ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-37e036bf087fc26e56b5bbec55dbcc3de6f0514f%2Fimage20.png?alt=media) **Figura 15.- Wireframe en PowerPoint para Teléfonos** En ambas figuras la navegación viene representada como sigue: * Al pie de cada diapositiva (o *slide)* se indica el número de la pantalla. Aprovecharemos este número ya en PowerPoint los muestra por defecto. * La navegación se simboliza con círculos rojos, los cuales muestran la pantalla de destino a la que se redirigirá al usuario al ejercer una determinada acción. * En último lugar se ha incluido la pantalla *Splash Screen*. Aunque por orden cronológico deberíamos haberla situado la primera, hemos decidido dejarla para el final, puesto que, en la mayoría de los casos, será la menos significativa o, al menos, la que menos implicación e interacción tendrá con los requisitos. Durante el proceso de generación de *wireframe*, se nos habrán planteado dudas que habremos ido resolviendo a la vez que las hemos ido reflejando en el detalle/descripción de los requisitos. Incluso probablemente habremos realizado varios ajustes en el *wireframe*. ¡Es normal, de eso se trata! En este instante estamos listos para mostrar al usuario el resultado final. **Lo que él inicialmente quería, y lo más importante, lo que él realmente necesita**. ¡Veremos si ambos hemos entendido lo mismo! ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-735c77f73292ae11da37b9dcfdc1cf6a3c5658d1%2Fimage21.png?alt=media) **Figura 16.- Proceso de refinado del wireframe** Continuaremos con este proceso hasta haber consensuado el mismo por ambas partes. Será entonces cuando demos el siguiente paso. ### Maqueta o Mockup A diferencia de un *wireframe*, una maqueta o *mockup*, es una representación estática y más realista de lo que será el resultado final de la aplicación, contiene colores, imágenes, iconos, textos de ejemplos y estilos. Dirigido principalmente a los usuarios finales de la aplicación. Para la generación de maquetas (o *mockups*), contamos también con herramientas de diseño y edición de imágenes tales como Photoshop o Gimp y con otras herramientas web de diseño en tiempo real: InnvisionApp.com, Moqups.com, Prottapp.com, Justinmind.com, etc. Muchas de ellas destinadas a dispositivos concretos, pero no por ello van a dejar de aportarnos una representación de lo que queremos conseguir y enseñar. PowerPoint también es otra herramienta y, será ésta la que usemos. Continuaremos así con la evolución de nuestro diseño, es decir, partiremos en este caso de nuestro anterior *wireframe* e iremos añadiéndole color, imágenes, iconos, estilos y textos más descriptivos a modo de ejemplo. En la siguiente figura podemos ver la pantalla número dos del *wireframe*, una vez evolucionada al nivel de *mockup*. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-21275aac1cb3bdead35a1f8916ea01286f5b2fce%2Fimage22.png?alt=media) **Figura 17.- Mockup en PowerPoint de la pantalla número dos del wireframe para Windows y Tabletas** De igual modo, iremos diseñando el resto de pantallas y, una vez completadas todas, volveremos a realizar el proceso de refinamiento junto con el usuario final. Para esta etapa de iteración podemos crear uno o varios requisitos técnicos o de diseño. En tal caso, les vincularemos las presentaciones PowerPoint con los bocetos, los *wireframes* y las maquetas. Los tendremos localizados y conseguiremos planificar mejor el trabajo del equipo. La siguiente figura ejemplifica esto para el caso de un único requisito en el que se incluyen todas las presentaciones (.PPTX) de esta etapa de interacción. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-263d22e1b0a5e2bf80f2874cd50f6803f2c78c42%2Fimage23.png?alt=media) **Figura 18.- Product Backlog Item en VSTS con los wireframes y mockups adjuntos** Se recomienda ir asociando cada historia de usuario a cada requisito según vayamos construyendo el boceto, *wireframe* y/o maqueta. Lo conseguiremos fácilmente creando un nuevo fichero PowerPoint con la historia en cuestión y vinculando al *Product Backlog Item*. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-b33f42a2b01e2063271bdf8aa99d7a7c20d3265a%2Fimage24.png?alt=media) **Figura 19.- Vinculación de un storyboard en PowerPoint con elementos de trabajo en VSTS** Para más detalle sobre cómo crear historias de usuario con VSTS y PowerPoint, visitar la página: . {% hint style="info" %} **Nota**: Si el usuario final puede consultar los requisitos, las historias de usuario facilitarán la interacción con él agilizando así el proceso de refinamiento del boceto, del *wireframe* y la maqueta. {% endhint %} ## Elementos visuales Los estilos para controles *TextBox*, *ComboBox*, cabeceras, botones, etc., iconos, imágenes y tipos de letra son algunas de las cosas que nos vienen a la mente al hablar de elementos visuales. Ya vimos en el capítulo 2, cómo con el control VisualStateManager podíamos aplicar estados y apariencias personalizadas a los controles estándares. Así mismo, los recursos y temas (o *themes*) van a hacernos más fácil la homogeneización de colores y estilos a lo largo de toda la aplicación. Entraremos en cada uno de ellos a medida que comencemos a desarrollar nuestras primeras pantallas en capítulos posteriores. En esta fase, nos centraremos en definir y plasmar nuestra idea del diseño y estableceremos todos estos aspectos y comportamientos. ### Patrones de Colores En primer lugar, trataremos de elegir la gama de colores que van a representar a nuestra aplicación, es decir, definiremos los patrones de colores apoyándonos en algunas herramientas: * Adobe Color CC (). Se trata de una aplicación web, la cual, en base a reglas cromáticas, nos sugiere unos patrones de colores con cierto sentido común. Podemos personalizarlos e incluyo seleccionar los más populares, o los más utilizados. Pero lo verdaderamente importante, es que nos ayuda a conseguir temas de colores que, de otra manera, sería difícil, y más aún, si eres de los que, como yo, “*no tenemos buen gusto para la elección de los mismos”*. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-30cda036b98f5e1ca3eb58a9c9cdcfba514f1fb5%2Fimage25.png?alt=media) **Figura 20.- Definiendo patrones de color con Adobe Color CC** * . Al igual que la anterior, esta herramienta, pensada inicialmente para aplicaciones web, nos facilita la elección de patrones de colores apoyándonos en reglas cromáticas (monocromáticos, triada, complementarios, compuestos, tonos, etc.). Bastará con elegir una muestra predeterminada y modificarla hasta dar con los colores que más nos gusten según la vista preliminar situada a la derecha. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-f2a6e3bdcd2dc2bccde8659c1d57f9663f2c0ef6%2Fimage26.png?alt=media) **Figura 21.- Definiendo patrones de color con Paletton.com** Una vez elegido los colores, podemos ver los valores preestablecidos (PRESETS), tal y como muestra la siguiente figura: ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-51cbfbc6a70b3813c1daf6c3311dfbd53e2a6163%2Fimage27.png?alt=media) **Figura 22.- Patrones de colores preestablecidos con Paletton.com** Y, por último, y aunque dispone de muchas más opciones, podemos ver algunos ejemplos (EXAMPLES…), resultado de nuestra elección, e incluso continuar haciendo ajustes sobre ellos. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-7bed13fa92ffb8f29cfe6b5da0d4eb5f33b32e75%2Fimage28.png?alt=media) **Figura 23.- Ejemplo de patrón de color ya definido con Paletton.com** Las ventajas de ambas herramientas es evitar elegir colores que puedan dar lugar a una lectura no legible de los textos, como puede ser el caso de colores excesivamente luminosos. En definitiva, nos ayudarán a conseguir una paleta de colores armoniosos. Además de estas herramientas y aunque de una forma mucho más minimalista, haremos uso de las muestras de colores incluidas en nuestras plantillas PowerPoint. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-d8a73b2af3511b797f8b00bf8430e55845bd2479%2Fimage29.png?alt=media) **Figura 24.- Muestras de colores incluida en las plantillas PowerPoint** Adicionalmente, tendremos la posibilidad de optar por el color de acento configurado por el usuario a nivel de sistema, así, si el usuario lo modifica, la aplicación reflejará el cambio aportando un valor extra de configuración. ### Tipos de Letra Representación gráfica o visual del lenguaje, cuyo principal objetivo es ser clara y legible. La fuente para el uso en todos los diseños Microsoft es **Segoe UI**, puesto que proporciona una amplia gama de caracteres y está diseñada para mantener la legibilidad óptima en distintos tamaños y densidades de píxeles. Ofrece una estética limpia, ligera y abierta. Ha sido pensada atendiendo al espesor, espacio entre letras, entre palabras, interlineado, alineación, finales de línea, párrafos, número de caracteres, alineación de sangría francesa, recortes y puntos suspensivos, texto principal y secundario y títulos completamente en mayúsculas. Además de las fuentes *Segoe UI*, existen otros tipos de letras recomendadas que garantizan su disponibilidad en todos los dispositivos Windows, e incluso también, podemos recurrir a otros tipos de letras no instaladas en los dispositivos. En este caso, la añadiremos como parte de los recursos (o *Assets*) de nuestra aplicación y seremos conscientes de que Windows 10 utiliza fuentes *True Types* (TTF) y puede afectar al rendimiento. Veamos a continuación un resumen de la tipología de letra a utilizar. **Tabla 2.- Resumen de tipos de letras recomendados** | Tipo | Estilo | | ------------------------------- | --------- | | Header (Segoe UI Light - 44) | Header | | Subheader (Segoe UI Light - 34) | Subheader | | Title (Segoe UI Semilight - 24) | Title | | Subtitle (Segoe UI - 20) | Subtitle | | Base (Segoe UI Semibold - 15) | Base | | Body (Segoe UI - 15) | Body | | Caption (Segoe UI - 12) | Caption | Al mismo tiempo que con estos tipos de letras predeterminados, tendremos que contar con el tipo de letra: ***Segoe MDL2 Assets***. Es esta la fuente que nos proporciona la mayoría de los iconos a incluir en nuestra aplicación. Para más detalle sobre ésta, visitar la página: . La aplicación *Mapa de Caracteres* (o *Character Map*) de Windows, es una herramienta que nos permitirá ver y obtener los caracteres de una fuente para representar iconos. Profundizaremos sobre ello en este mismo capítulo en el apartado Iconos. ### Imágenes Las imágenes constituyen uno de los papeles más importantes como elemento visual. Todos conocemos el dicho, “una imagen vale más que 1000 palabras”. Pues bien, las imágenes van a aportar la información, el colorido, el estilo y la identidad para nuestra aplicación. Para el diseño de todas nuestras imágenes podemos utilizar cualquier editor de imágenes, no obstante, **GIMP**, entre ellas y como herramienta gratuita, aporta todo lo necesario. Veamos cómo ir diseñando algunas imágenes: **Splash Screen** La pantalla de bienvenida o pantalla de inicio de aplicación (*Splash Screen*), contendrá principalmente el logotipo de la aplicación centrado. Recordemos que disponemos de varios escalados y se recomienda crear una imagen para cada uno ellos con el objetivo de proporcionar la experiencia de usuario más óptima. De no ser así, al menos para los escalados; 100, 200 y 400, y en su defecto, como mínimo, para el escalado 400. Utilizaremos la nomenclatura ya conocida y nos decantaremos por el formato “.PNG”. La tabla 3 recoge a modo de resumen toda esta información. **Tabla 3.- Escalados y tamaños de imágenes para el Splash Screen** | Nombre | Escala | Tamaño (Pixeles) | | -------------------------- | ------ | ---------------- | | SplashScreen.scale-100.png | 100 | 620x300 | | SplashScreen.scale-125.png | 125 | 775x375 | | SplashScreen.scale-150.png | 150 | 930x450 | | SplashScreen.scale-200.png | 200 | 1240x600 | | SplashScreen.scale-400.png | 400 | 2480x1200 | Puntualizaremos a continuación cuál es el proceso de generación automática de estas imágenes a partir de una inicial, previamente diseñada. 1. Utilizar GIMP para diseñar una imagen con un tamaño sugerido de 400x400. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-d06e1d0d28e71a336cf65ac036d70089355b6f85%2Fimage30.png?alt=media) **Figura 25.- Diseñando la imagen de bienvenida con GIMP** 2. Desde el editor del manifiesto de aplicación *Package.appx.manifest*, seleccionar la pestaña “Visual Assets” – “Splash Screen”. 3. Elegir la imagen previamente diseñada. 4. Indicar una carpeta de destino “Assets”, donde se generarán de manera automática las imágenes con los distintos tamaños, escalados y nomenclatura. 5. Pulsar Generar (*Generate*). ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-4c23150f445a7c3edfa75ba64c6078a6ad738445%2Fimage31.png?alt=media) **Figura 26.- Selección de imágenes para la pantalla de bienvenida** Al marcar todos los escalados, como resultado, se obtendrán las cinco imágenes con los respectivos nombres indicados en la tabla 3 y se incluirán en el proyecto en la carpeta de destino “Assets”. **Pantalla de bloqueo** Como ya vimos en el capítulo 2, la pantalla de bloqueo (o *lock screen*), es la pantalla que aparece cuando el dispositivo está bloqueado. Se recomienda conocer algunos aspectos al diseñar la misma: * Reducir la cantidad de texto de la imagen para que no entre en conflicto con el texto a mostrar sobre la misma. * Una imagen sencilla facilita la lectura del texto mostrado en la pantalla, así como la legibilidad de los iconos y notificaciones. * El logotipo y el texto de la pantalla deben ser pequeños para que no interfieran con la fecha, la hora o las notificaciones. * El logotipo, debería ser ligeramente **transparente**. * El texto, debería estar relacionado directamente con la imagen. * El foco visual debe ser la imagen en lugar del logotipo o el texto. * Proporcionar una imagen de fondo predeterminada para que se muestre en caso de error. Para nuestra aplicación Task\[in] no crearemos imágenes para la pantalla de bloqueo, por tanto, y a modo de ejemplo, las siguientes imágenes muestran la información del tamaño del área dedicada al uso de texto o logotipo como parte de la imagen. **Tabla 4.- Área dedicada a texto o logotipos en la pantalla de bloqueo** | WVGA (480x800) | WXGA (768x1280) | HD720p (720x1280) | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-582fe455f1d2158523d98778b1db4bbe24dc7452%2Fimage32.png?alt=media) | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-b2b4b663ecd547e75659c1720bbaf1c070e2a892%2Fimage33.png?alt=media) | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-d7c35bebfb59cdb66b234ef36d5d4e39edf5a533%2Fimage34.png?alt=media) | {% hint style="info" %} **Nota**: Al establecer una imagen de bloqueo más de una vez, ésta debería tener un nombre distinto. En caso contrario, dicha asignación fallará. Para móviles sólo se permiten imágenes inferiores a 2MB. {% endhint %} Recordemos también, según vimos en el capítulo 2, que podemos crear una página dinámica utilizando XAML a la que denominaremos *Splash.xaml* o *SplashPage.xaml*. **Tiles** En el capítulo 2 conocimos los diferentes tamaños y escalados de las imágenes para los Tiles. El número total de imágenes no es pequeño, concretamente 30 para cubrir todos los escalados y tamaños. Más adelante, en el apartado de Notificaciones diseñaremos nuestros *Tiles*, aun así y como adelanto para profundizar en el diseño de plantillas para *Tiles*, podemos visitar la página: . **Badge logo** El distintivo o insignia (o *badge logo*) que aparece junto al icono de la aplicación como contador de notificaciones, también dispone de distintos escalados y tamaños según se indica en la siguiente tabla, concretamente 5 imágenes. **Tabla 5.- Tamaños y escalados para las insignias o (badge logos)** | Nombre | 400% | 200% | 150% | 125% | 100% | | | ---------- | ----- | ----- | ----- | ----- | ----- | - | | Badge logo | 96x96 | 48x48 | 36x36 | 30x30 | 24x24 | | Ahora que ya sabemos cuáles son todas las imágenes que necesitamos, las generaremos al igual que hemos hecho para las de *Splash Screen*, con la salvedad de no generar éstas nuevamente. Nos aseguraremos, por tanto, de desmarcar en la lista desplegable “Assets\*”\*, la opción “Splash Screen”. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-b2fba5c8e1236c92ef7864428d5e91acc1775891%2Fimage35.png?alt=media) **Figura 27.- Generación automática de imágenes desde el manifiesto de aplicación** Como resultado de esta nueva generación automática, obtendremos en la carpeta de proyectos “Assets\Logos”, 45 imágenes con 45 tamaños y escalados diferentes tal y como podemos apreciar en la siguiente figura. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-1c9e193a2a95a8bc6f3fcffe3ebdfcce44d33b5c%2Fimage36.png?alt=media) **Figura 28.- Imágenes generadas automáticamente desde el manifiesto de aplicación** ### Iconos A diferencia de los *Tiles*, el resto de imágenes o iconos utilizados en la aplicación los incluiremos en: Botones, controles *ComboBox*, hipervínculos (o *HyperLinkButton*), o en plantillas (*Templates*) para los controles *ListView*, *GridView*, etc. Para generar estos iconos dispondremos de varias alternativas, dependiendo del tipo: 1. **SymbolIcon**. El icono se basa en una lista predefinida de glifos[⁴](/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/que-hemos-aprendido.md#notas) representados por el tipo letra: “**Segoe MDL2 Assets**” que a su vez son tratados como un enumerado. En la siguiente figura podemos observar para un control *AppBarButton*, un listado de valores posibles para su propiedad *Symbol*. La ventaja de esta alternativa es que hace fácil su selección. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-ed26b5050dd1350f6da3772dd594e7d3677de3cb%2Fimage37.png?alt=media) **Figura 29.- Selección del símbolo del icono desde las propiedades del botón** En código XAML. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-eafe305ca13ea637123e0b24b891c4c55512761d%2Fimage38.png?alt=media) **Figura 30.- Selección del símbolo del icono durante la edición del código XAML** 2. **FontIcon**. El icono se basa en un glifo de la familia de fuentes especificada, donde para la fuente ***Segoe MDL2 Assets*** obtendríamos los mismos valores proporcionados por el enumerado anterior. Por ejemplo, el carácter hexadecimal “U+E107”, se representa en código XAML con el valor: “”. ```xml ``` Para su representación en código C# y para un objeto de tipo cadena (o *string)*, ha de utilizarse su equivalente valor Unicode. Para el ejemplo anterior: “\uE107”. Usaremos la herramienta mapa de caracteres (o *Character Map*) de Windows para conseguir dichos valores. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-c2ec6f00e4ca0db83cb6fb24c662409247ca182c%2Fimage39.png?alt=media) **Figura 31.- Carácter “\” seleccionado en la herramienta Mapa de caracteres de Windows** 3. **PathIcon**. Representa un icono que utiliza trazados vectoriales como contenido. Presentan el inconveniente de no ser auto-escalables, por lo que hay que hacerlo manualmente utilizando alguna herramienta. *Metro Studio* es una opción y conoceremos cómo utilizarla a continuación. 4. **BitmapIcon**. El icono se basa en un archivo de imagen referenciada mediante una *Uri* específica. Esta alternativa presenta la ventaja de poder utilizar cualquier imagen, incluso una requerida por usuario final. Si éste fuera el caso, ésta sería nuestra selección. A modo de ejemplo, podríamos utilizar imágenes para representar a los elementos de un control de cualquier listado de selección: *ComboBox*, *ListView*, etc. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-9d4612641af70926e4bb437305346a43327c8f5f%2Fimage40.PNG?alt=media) **Figura 32.- Iconos para identificar los tipos de elementos en un control “ComboBox”** Para la obtención de todas estas imágenes contamos con muchas herramientas: thenounProject.com, FlatIcons.net, FlatIcon.com, IconShock.com, Pixeden.com, IconArchive.com, materialdesignicons.com, etc. Del mismo modo y de manera gratuita, contamos con una aplicación de escritorio **Metro Studio** (perteneciente a la compañía *SynchFusion*) totalmente recomendada, muy fácil de usar y con más de 7000 iconos que podemos modificar e incluso guardar y exportar como código XAML. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-5020766d4cda1eeaeba3a58fc12c0797fe77c969%2Fimage41.png?alt=media) **Figura 33.- Metro Studio. Editando un icono** Podemos incluso, editar cada uno de los caracteres de la fuente *Segoe MDL2 Assets*. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-91fe8de45a92bf3243f4eeba63ac1b239fe8e380%2Fimage42.png?alt=media) **Figura 34.- Metro Studio. Editar un carácter como icono** Sea cual sea la opción u alternativa empleada para la elección o diseño de iconos, estos van a ir aportando a nuestra aplicación mayor vitalidad con un objetivo final, “hablar sin decir una palabra”. Hemos diseñado algunas imágenes e iconos, hemos visto cómo a partir de una imagen (con tamaño 400 x 400) podemos generar otras muchas para distintos escalados, pero, sea como sea, dependerá de los requisitos y de la exigencia de nuestros elementos visuales, la alternativa a escoger. Podría ocurrir, incluso, que tuviéramos que diseñar una imagen ligeramente distinta para cada tipo de elemento visual. ## Prototipo El prototipo es la representación, de manera limitada, de la aplicación en cuanto a su funcionalidad y aporta mayor realidad y fiabilidad. Permite realizar pruebas reales o explorar su uso con el objetivo de comprender totalmente la aplicación o bien, parcialmente clarificando así los requisitos de la misma. Además de utilizar PowerPoint para hacer *Wireframes* o maquetas, podemos utilizarlo para incluir color, tipos y tamaños de letras, e incluso movimiento, por lo que, de alguna manera, también podríamos usarlo para el prototipo. Sin embargo, y como ya hemos comentado, una de las ventajas de implementar el patrón MVVM es que el prototipo podemos realizarlo actuando como diseñadores tanto desde el propio Visual Studio como desde ***Blend***, dependerá de nuestros conocimientos técnicos. Teniendo esto en cuenta podemos generar un prototipo 100% funcional y comenzar a codificar sobre él. ### Diseñar la experiencia de usuario Una vez elegidos los colores, temas, iconos, imágenes y todo lo que respecta al aspecto visual de nuestra aplicación, así como la interacción y navegación, lo combinaremos para conseguir el prototipo final. Usaremos algunas herramientas: * **Microsoft PowerPoint**. Continuaremos a partir de la maqueta, por lo que únicamente tenemos que añadir el movimiento y la navegación entre páginas. Bastará con hacer uso de animaciones. La desventaja es que el usuario no podrá interactuar a su antojo con este tipo de prototipos. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-4ea28189800474701b8751bb2842963fc0b672e9%2Fimage43.png?alt=media) **Figura 35.- Diseño de la pantalla número dos del wireframe con PowerPoint** * **App Mock**. Se trata de una aplicación que podemos encontrar en la Tienda de Windows y que ha sido desarrollada por *Telerik*. Cuenta con la mayoría de los controles para UWP predefinidos, y permite realizar diseños rápidos. Construye las ideas de las aplicaciones haciendo que sea tan simple como la edición de un documento Word. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-bbf9aa1e3cbd92fc3873981678d5a92ff759f896%2Fimage44.png?alt=media) **Figura 36.- Diseño de la pantalla número uno del wireframe con App Mock** * **Microsoft Project Siena.** Al igual que *App Mock*, su edición es tan simple como la edición de un documento Word, si bien, y además de incorporar un gran número de controles UWP ya predefinidos, incluye un mayor número de funcionalidades y mejoras: * Conexión a datos (un documento Excel con tablas, por ejemplo) y servicios web. * Composiciones gráficas interactivas y multimedia para crear personalizaciones. * Adición de lógica usando expresiones similares a las usadas en Microsoft Excel. * Publicación local de la aplicación para poder compartirla y mostrarla sin la necesidad de tener instalada la herramienta. * Totalmente gratis. ![C:\Users\juanlu\AppData\Local\Microsoft\Windows\INetCacheContent.Word\Prototipo - Project Siena.png](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-5a52b49c2843ce8d6115b9031c5a7cb5c58a79d7%2Fimage45.png?alt=media) **Figura 37.- Diseño de la pantalla número uno del wireframe con Project Siena** * **Blend**. Una gran ventaja de utilizar XAML en el desarrollo de nuestra aplicación es que Blend va a ser la herramienta predeterminada para diseñar tanto un prototipo funcional como la propia interfaz. Cuando comencemos con la implementación de la solución, tanto diseñadores como desarrolladores podremos trabajar en paralelo sin molestarnos mutuamente. Tendremos la ventaja de ir mostrando nuestro prototipo al usuario a medida que éste va cobrando vida en plena fase de desarrollo. El inconveniente, si es que se puede considerar como tal, es que se precisa de determinados conocimientos para su uso. La siguiente figura muestra el uso de Blend durante el diseño de la pantalla “Acerca de”. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-4d6d3656b37e13fb7330b70bec5a44ce3f40ac39%2Fimage46.png?alt=media) **Figura 38.- Diseño de la pantalla “Acerca de” con Blend** Observaremos más adelante, en este mismo capítulo algunos aspectos a considerar al trabajar con esta herramienta. ### ~~­~~Notificaciones Los mensajes son comúnmente mostrados en la pantalla en la que el usuario se encuentra en cada momento. No obstante, Windows 10 cuenta, como ya sabemos, con varios mecanismos para ello: *Tiles*, *Badges*, *Toast* y *Raw* y el centro de notificaciones. Por tanto, para nuestro prototipo también tendremos que tener en cuenta el diseño de ciertas de estas interacciones con el sistema. Principalmente necesitaremos el icono de la aplicación que hemos creado previamente y que se corresponde concretamente con la imagen *Square44x44Logo.scale-100.png*. **Tiles** Los Tiles son elementos característicos para nuestra aplicación que otorgan un alto y rico contenido de información a la par que atractivo en la pantalla o menú de inicio. Para su diseño utilizaremos la herramienta *Notifications Visualizer*, que podemos descargar de la Tienda de Windows. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-3bb3b3370c6651a9f0491bf159ea5bcca01fa59b%2Fimage47.png?alt=media) **Figura 39.- Diseño de Tiles con Notifications Visualizer** **Toast** En las últimas versiones de Windows las notificaciones *Toast* han sido mejoradas para hacerlas más adaptativas y: * Pueden incluir botones y cajas de texto para la entrada de datos. * Presentan tres tipos de activación * Posibilitan la creación de notificaciones para escenarios concretos tales como: Alarmas, recordatorios (o *reminders*) y llamadas entrantes (o *incoming calls*). Las siguientes figuras muestra un ejemplo de estas notificaciones para un teléfono móvil que se muestran en la parte superior y para un PC, abajo a la derecha, junto a la barra de tareas de Windows. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-4b47038890c9f1c9f399349f9b1b5446eff5ce0a%2Fimage48.png?alt=media) ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-8f6977d9076ed5cdc27d0da4b4d88049403c5681%2Fimage49.png?alt=media) **Figura 40.- Notificación Toast de tipo alarma en móvil y escritorio con opciones de posponer y descartar** En nuestra aplicación Task\[in], utilizaremos este tipo de notificaciones, a modo de alarmas para indicar el vencimiento de las tareas. De igual forma, al finalizar cada Pomodoro mostraremos una notificación *Toast* indicando así que este ha sido completado. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-ec3aed5b9cbe15ac124f8263b0d1d37d2df292f4%2Fimage50.png?alt=media) **Figura 41.- Diseño de notificaciones Toast con Notifications Visualizer** **Centro de notificaciones** En el capítulo 2 ya vimos algunos ejemplos del centro de notificaciones, si bien, en la figura siguiente, veremos cómo son mostradas las notificaciones de tipo alarmas que mostrará nuestra aplicación. ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-055fb7c5088ec179686d7ce65655c1e252cb97a0%2Fimage51.png?alt=media) ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-82aa5c90f8f966154b5831bf375609b9bfe7037f%2Fimage52.png?alt=media) **Figura 42.- Notificaciones de tipo alarma en el centro de notificaciones** Para más detalle, visitar la página: {% hint style="info" %} **Nota**: Es el momento de incluir en nuestros requisitos estos ejemplos y hacerlos formar parte de las historias de usuarios. {% endhint %} Una vez que hemos diseñados todas nuestras notificaciones, necesitaremos incluir en el proyecto las librerías de notificaciones *Microsoft.Toolkit.Uwp.Notifications*, pero esto, lo llevaremos a la práctica en capítulos sucesivos.