Cómo preparar (en todos los tamaños y resoluciones) maquetas y gráficos de interfaz de usuario para una aplicación de Android en PS

He visto preguntas similares hechas aquí, pero no respondieron mi pregunta al 100%. Así que por favor tengan paciencia conmigo.

Ahora estoy comenzando un proyecto de diseño de aplicaciones para iOS y Android. Llevo un tiempo diseñando para iOS, pero Android es algo totalmente nuevo para mí. Android tiene tantos dispositivos con tantas resoluciones y tamaños diferentes que en este punto me resulta bastante confuso saber por dónde empezar.

¿Es posible crear sus elementos para la resolución más alta y luego usar algún método para reducirlos a otros tamaños más pequeños? ¿O TENEMOS que hacerlo manualmente y crearlos para cada uno de los diferentes tamaños? ¿Cuáles son las mejores prácticas y el flujo ideal para cualquier requisito multiplataforma? ¿Hay alguna manera de reutilizar fácilmente los activos gráficos de iOS? tia :)

Respuestas (2)

Sí, y deberías hacerlo. Los elementos de diseño de Android se pueden generar con un generador de 9 parches . Un sistema donde todas las resoluciones se suministran en base a un png.

El generador de nueve parches le permite generar rápidamente nueve parches simples en diferentes densidades de pantalla, en función de la ilustración de origen especificada.

Su diseño debe ser lo suficientemente flexible para respetar este sistema. Pero todo esto está muy bien documentado , por lo que repetirlo aquí parece fuera del alcance: Directrices de diseño de Android

También considere leer esta introducción:

Mientras trabajaba en mi primera aplicación de Android, encontré que el parche 9 (también conocido como 9.png) era confuso y mal documentado. Después de un tiempo, finalmente me di cuenta de cómo funciona y decidí armar algo para ayudar a otros a resolverlo.

Básicamente, 9-patch usa transparencia png para hacer una forma avanzada de 9-slice o scale9. Las guías son líneas negras rectas de 1 píxel dibujadas en el borde de la imagen que definen la escala y el relleno de la imagen. Al nombrar su archivo de imagen name.9.png, Android reconocerá el formato 9.png y usará las guías negras para escalar y llenar sus mapas de bits.

ingrese la descripción de la imagen aquí

En cuanto a la mejor práctica de Mockup: use la resolución de su dispositivo de prueba , o más bien, en su tamaño dp (el MDPI o la relación de aspecto no multiplicada de la pantalla) .

Llevo un tiempo diseñando para iOS, pero Android es algo totalmente nuevo para mí. Android tiene tantos dispositivos con tantas resoluciones y tamaños diferentes que en este punto me resulta bastante confuso saber por dónde empezar.

Si tiene un buen flujo de trabajo para iOS, estará en buena forma.

Densidad de pixeles

iOS tiene tres objetivos principales de densidad de píxeles:

  • 1× (sin retina).
  • 2× (Retina).
  • 3× (Retina HD, que ahora mismo solo es iPhone 6 Plus).

Android es realmente similar:

  • 1 × (realmente ya no se usa).
  • 1,5 × (realmente ya no se usa).
  • 2× (xhdpi).
  • 3× (xxhdpi).
  • 4× (xxxhdpi, aún razonablemente raro, pero en algunos dispositivos de gama alta).

Por lo general, es 1×, 2× y 3× para iOS, y 2×, 3× y 4× para Android. Muy similar.

Si desea construir sus documentos de manera que se amplíen y reduzcan fácilmente, deberá utilizar principalmente formas vectoriales y estilos de capa si está utilizando Photoshop. Si está usando Illustrator... bueno, probablemente no debería usar Illustrator. Es excelente para crear diseños de impresión y SVG para la web, pero tiene algunos problemas que significan que puede ser menos que ideal si espera obtener archivos PNG como activos de producción.

¿Es posible crear sus elementos para la resolución más alta y luego usar algún método para reducirlos a otros tamaños más pequeños?

Debe evitar el escalado de mapas de bits a toda costa. Se ve horrible: no cree activos xxxhdpi como PNG, luego bájelos en mapa de bits. Debe escalar el documento mientras todo sigue siendo capas separadas y construido utilizando formas vectoriales y efectos generados (como estilos de capa).

Me gusta mucho trabajar sobre todo en la escala 1×. Esto significa que tiene un documento de menor resolución, pero todo se escala hasta 2×, 3× y 4× perfectamente. O bien, podría trabajar en 2 × e intentar asegurarse de que todo aterrice en una cuadrícula de píxeles uniforme, etc. Hay algunos enfoques diferentes con ventajas y desventajas. Si ha construido bien su documento, debería poder cambiar el tamaño del documento y saltar entre las densidades de visualización según sea necesario.

Exportador

¿O TENEMOS que hacerlo manualmente y crearlos para cada uno de los diferentes tamaños?

Definitivamente necesita tener varios conjuntos de activos para las diferentes densidades de visualización, pero existen bastantes estrategias para automatizar mucho el proceso.

Generator es una forma de hacerlo: https://blogs.adobe.com/photoshopdotcom/2013/09/introducing-adobe-generator-for-photoshop-cc.html

Utilizo divisiones y construyo documentos con todos los activos dispuestos en una cuadrícula, por lo que puedo exportar por lotes, escalar el documento y volver a exportar. Es un poco más difícil, pero significa que obtengo un mayor control sobre el proceso.

¿Cuáles son las mejores prácticas y el flujo ideal para cualquier requisito multiplataforma? ¿Hay alguna manera de reutilizar fácilmente los activos gráficos de iOS?

Definitivamente puede reutilizar ciertos activos, pero probablemente debería asumir que tendrá que rehacer la mayor parte de la aplicación de una manera nativa para la plataforma. Al menos, para aprovechar las funciones de la plataforma, como las imágenes de 9 parches de Android:

https://developer.android.com/tools/help/draw9patch.html

Tamaño físico y relación de aspecto

iOS usa el diseño automático para ayudar a atender dispositivos de diferentes tamaños. Esto significa que puede crear una maqueta para el iPhone 6, pero con un poco de trabajo, debería poder obtener el mismo diseño para todos los tamaños de iPhone usando Diseño automático en Interface Builder.

Android tiene un sistema similar (¡ish!) en forma de diseño declarado XML.

Es posible que esto no sea algo que realmente construya, pero debe tener en cuenta que deberá atender partes de la aplicación para expandir, contraer, ocultar o mostrar, según el tamaño del dispositivo.