Comienza por crear una nueva solución.

Ahora, ve con la interfaz, para hacer las cosas mas sencillas y rápidas, puedes copiar el XAML que sigue.

<Page x:Class="Abrir_Imagenes.BlankPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:Abrir_Imagenes"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d">

<Grid Background="{StaticResource ApplicationPageBackgroundBrush}">
<Button x:Name="btnAbrirImagen" Content="Abrir imagen" HorizontalAlignment="Left" Height="58" Margin="10,10,0,0" VerticalAlignment="Top" Width="222" Click="btnAbrirImagen_Click"/>
<Button x:Name="btnVariasImagenes" Content="Abrir varias imágenes" HorizontalAlignment="Left" Height="58" Margin="10,73,0,0" VerticalAlignment="Top" Width="222" Click="btnVariasImagenes_Click"/>
<Button x:Name="btnGuardar" Content="Guardar archivo" HorizontalAlignment="Left" Height="58" Margin="10,136,0,0" VerticalAlignment="Top" Width="222" Click="btnGuardar_Click"/>
<Image x:Name="imgSeleccionada" HorizontalAlignment="Left" Height="290" Margin="10,234,0,0" VerticalAlignment="Top" Width="422"/>
<ItemsControl x:Name="contImagenes" HorizontalAlignment="Left" Height="748" Margin="437,10,0,0" VerticalAlignment="Top" Width="919"/>

</Grid>
</Page>

Simplemente se trata de tres botones, una imagen y un contenedor de tipo ItemsControl que te servirá para mostrar los resultados en un paso posterior.

Primero comienza por el botón para abrir una sola imagen. El código es el siguiente.

async void btnAbrirImagen_Click(object sender, Windows.UI.Xaml.RoutedEventArgs e)
{
FileOpenPicker dialogoAbrir = new FileOpenPicker();
dialogoAbrir.ViewMode = PickerViewMode.Thumbnail;
dialogoAbrir.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
dialogoAbrir.FileTypeFilter.Add(".jpg");
dialogoAbrir.FileTypeFilter.Add(".jpeg");
StorageFile archivo = await dialogoAbrir.PickSingleFileAsync();
if (archivo != null)
{
var stream = await archivo.OpenAsync(FileAccessMode.Read);
BitmapImage imagenDevuelta = new BitmapImage();
imagenDevuelta.SetSource(stream);
imgSeleccionada.Source = imagenDevuelta;
}
}

Lo primero que debes notar es que el tipo de método es asíncrono, esto es de suma importancia para cualquier tipo de método que uses y consideres que va a utilizar llamadas asíncronas, después verás la configuración básica de la nueva clase llamada FileOpenPicker y que te servirá para abrir los archivos, por medio de dos enumeradores, podrás ajustar las propiedades para el tipo de vista que quieres de tus archivos y donde comenzar a buscar, a continuación asignarás el filtro (o filtros) del tipo de archivo que deseas obtener y ya al final, solo asignas el resultado del método asíncrono directamente a un objeto de tipo StorageFile (para esto es que es necesario que tu método sea asíncrono, ni privado, ni público, no querrás batallar con eso).

Con un condicional podrás asignar el valor devuelto a un objeto abstracto y ya pasar la información obtenida a un BitmapImage y para terminar, a la imagen que está en la interfaz. El resultado deberá quedar de la siguiente forma.

En el caso del segundo botón, el código es el siguiente.

async void btnVariasImagenes_Click(object sender, Windows.UI.Xaml.RoutedEventArgs e)
{
FileOpenPicker dialogoAbrirMuchos = new FileOpenPicker();
dialogoAbrirMuchos.ViewMode = PickerViewMode.List;
dialogoAbrirMuchos.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
dialogoAbrirMuchos.FileTypeFilter.Add(".jpg");
dialogoAbrirMuchos.FileTypeFilter.Add(".jpeg");
IReadOnlyList<StorageFile> listaImagenes = await dialogoAbrirMuchos.PickMultipleFilesAsync();
if (listaImagenes.Count > 0)
{
foreach (StorageFile elemento in listaImagenes)
{
Image nuevaImagen = new Image();
nuevaImagen.Width = 290;
nuevaImagen.Height = 422;
nuevaImagen.Margin = new Thickness(5);
var stream = await elemento.OpenAsync(FileAccessMode.Read);
BitmapImage imagenDevuelta = new BitmapImage();
imagenDevuelta.SetSource(stream);
nuevaImagen.Source = imagenDevuelta;
contImagenes.Items.Add(nuevaImagen);
}
}
}

Prácticamente todo es lo mismo, la única diferencia es el método asíncrono, en donde podrás obtener varios archivos, los cuales serán almacenados en una IReadOnlyList de tipo StorageFile y después por medio de un ciclo deberás asignar el valor de cada resultado a cada nueva imagen.

El resultado debe ser algo así.

Por último el código del tercer botón es el siguiente.

async void btnGuardar_Click(object sender, Windows.UI.Xaml.RoutedEventArgs e)
{
FileSavePicker dialogoGuardar = new FileSavePicker();
dialogoGuardar.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
dialogoGuardar.FileTypeChoices.Add("Imagen JPG", new List<string>() { ".jpeg", ".jpg" });
dialogoGuardar.FileTypeChoices.Add("Imagen PNG", new List<string>() { ".png" });
dialogoGuardar.DefaultFileExtension = ".jpg";
dialogoGuardar.SuggestedFileName = "Nueva imagen";
StorageFile archivo = await dialogoGuardar.PickSaveFileAsync();

if (archivo != null)
{
//La acción ejecutada después de guardar.
//Aquí puedes obtener los datos del elemento recién guardado.
}
}

Aquí utilizas una clase de tipo FileSavePicker, ajustas sus propiedades de forma muy similar a la clase anterior y podrás ser capaz de abrir un cuadro de diálogo que te permitirá guardar un archivo del tipo que hayas especificado.

El resultado se ve en la parte inferior de tu aplicación.

Y así es como podrás utilizar estas dos nuevas funcionalidades en tus aplicaciones Metro.

Puedes descargar aquí el código.

Y no es que sea un problema nuevo. Las aplicaciones siempre han tenido que lidiar con diferentes tamaños de pantalla o de despliegue. Para una referencia muy actual, pueden revisar Responsive Web Design para darse cuenta de los problemas que los diseñadores de interfaces tienen que vivir día con día.

Regresando al tema Metro que nos atañe en este blog, Windows 8 se enfrenta con su propio conjunto de problemáticas “sui generi” que se derivan del problema base de que cualquier sistema operativo tiene que dar soporte nativo a múltiples pantallas presentadas por los desarrolladores de hardware. Y es que ahora, que las “ventanas” no gobiernan en la interface Metro, sino que los modos de “Snapping” y de pantalla completa son los paradigmas que van por delante, los diseñadores de la interface y experiencia de usuario (que en muchos casos son los mismos que el desarrollador) deberán enfrentarse a formas creativas de utilizar mucho mejor su espacio en pantalla y lograr una diferenciación de sus productos a través del uso creativo de dichos espacios, todo esto con el reto adicional de evitar que su aplicación deje de sentirse Metro. Este último punto es súmamente importante para lograr que estas aplicaciones siempre se encuentren inmersos en el sistema operativo y sus usuarios las sientan como nativas.

En un post muy interesante de David Washington, que trataré de resumir en este post para nuestros amigos latinos, se trata precisamente de estas problemáticas y se argumenta respecto de la filosofía que viene detrás de Metro en lo que respecta al soporte de diferentes tamaños de pantalla. Y es que ¿cómo no tener múltiples tamaños de pantalla, si Windows precisamente se caracteriza por dar soporte múltiples factores de forma? Windows 8 no será la excepción; encontraremos múltiples tamaños de pantalla, algunas táctiles y otras no, e incluso las nuevas pantallas de densidad comprimida entrarán en juego. Ya no será el territorio de tamaños por pulgada o factores de aspecto 4:3, 16:9, 16:10 que sólo importaban para poder ver más información, pero que esto no tenía que ver con la porción de lienzo que un desarrollador solicitaba al sistema para desplegar su pantalla.

Ahora, el tamaño sí importa, como dirían en campañas políticas, comparaciones de monopolios, o terrenos financieros, o incluso en otros temas de los cuales no escribiré por pudor. Los desarrolladores ahora tienen que pensar en la mejor manera de aprovechar lo que comúnmente se conoce como el “real screen state”, ya que toda (la pantalla) completamente es para su aplicación. Esto me hace recordar los viejos tiempos en los que los desarrolladores planeaban en hojas cuadriculadas de 40×40 o 40×80 (para pantallas de alta densidad) cómo posicionarían cada carácter que se iba a desplegar en su pantalla, o en aquellas resoluciones de 320×240 que se empleaban en computadoras de 8 bits y que debían de ser cuidadosamente ocupados cada uno de los píxeles presentes.

¿Esto significa que el concepto de las ventanas (fundamento al nombre del sistema operativo) se ha perdido? No, definitivamente no es así. Y no es que pensemos en tener espacios de ventanas dentro de la interface Metro. En realidad, y mucho más cercano a nuestra realidad física, debemos pensar que ahora el tamaño de nuestra ventana es absoluto, inamovible (al menos mientras el usuario no la ponga como segunda aplicación o rote el dispositivo). Es como la ventana de nuestras casas, fija en tamaño, pero que nos deja ver un panorama mucho mayor de información. Nos podemos asomar a través de ella y elegir lo que deseamos ver de ese mundo que se presenta. Nos podemos alejar o acercar a ella, según la cantidad de información que deseamos (Semantic Zoom), por ejemplo. El cambio de paradigmas para usuarios y desarrolladores se preveé que sea lo suficientemente fuerte como para impactar los mercados.

Continuando con el tema inicial, y retomando del artículo de D. Washington existirán 2 principios que son consistentes en Windows 8 para los desarrolladores:

1. Ofrece a los usuarios finales una experiencia predecible, consistente y pulida sobre una gran variedad de tamaños de pantalla.
2. Habilita a los desarrolladores a construir fácilmente apps que se ven grandiosas en esa variedad de tamaños.

Esto se basa en que se busca cubrir muy diversas necesidades y ámbitos económicos para que los consumidores puedan adquirir el equipo con Windows 8 que mejor les acomode. Pero al final del camino, son las apps que corren sobre Windows 8 las que finalmente darán satisfacción a esas necesidades, y todo esto bajo diferentes tamaños de pantalla.

Factores que debemos tomar en cuenta, respecto de la pantalla:

• Tamaño de pantalla. Una pantalla pequeña, aun con una gran densidad puede ser dificil de leer si ponemos demasiados elementos por cm cuadrado.
• Resolución de pantalla. Nos determina la cantidad de información que podremos mostrar al mismo tiempo.
• Densidad de los pixeles. Está relacionado a la mezcla de los 2 puntos anteriores. Como se mencionó, hay que cuidar que nuestros elementos de contenido sean visibles.

En la siguiente imagen se muestran los tamaños más comunes con los que nos podemos enfrentar:

¿Qué tan pequeño es “pequeño”? Bueno, Microsoft recomienda que el tamaño base para una aplicación Metro sea de 1024 x 768. Y es el punto necesario de inicio para que las aplicaciones puedan ser bellamente diseñadas y no tengan que lidiar con problemas de “ya no cupo”.

Ahora bien, algo que es super interesante y además super útil, es la siguiente gráfica:

Se puede notar claramente lo que es el dominio de las pantallas widescreen, y que es la base de lo que se desea tener para Windows 8. Entonces, me preguntarán: ¿no se trataba de tener 1024 x 768? Y la respuesta es sí… ese es efectivamente el mínimo que “una aplicación” debe de soportar. Es decir, aunque vamos a contar con muchas pantallas de 1366 px de ancho, la diferencia en pantalla se debe a que tenemos una banda lateral para las vistas snap, aquellas aplicaciones que se anclan de manera lateral, y que están limitadas a 320 px de ancho.

Como podemos observar, ahí caben las aplicaciones con su mínimo requerido (1024 px de ancho) y una banda siempre fija en 320 px. Entonces, se cumple el mínimo indispensable y todavía tenemos espacio para la vista anclada de aplicaciones simultáneas, pero en segundo plano de atención por parte del usuario.

Mucha gente se pregunta respecto de porqué estamos limitados a un ancho de 320 px. Y la respuesta es muy sencilla: se trata de que los desarrolladores no necesiten contemplar una infinidad de posibilidades que al final del camino hagan que se les preste atención a algunas y a otras no, ya que de esta manera terminaríamos con aplicaciones que únicamente estarían “optimizadas” para ser ocupadas en dispositivos muy específicos y que terminarían debilitando las ofertas en el Marketplace y a la plataforma en general.

Adicionalmente, los 320 px serán un lugar común para aquellos que han programado en Zune o para Windows Phone, ya que es este precisamente el ancho que tiene la pantalla, lo cual nos facilitará el poder compartir y transferir nuestras interfaces previamente diseñadas en estos dispositivos móviles. Una gran diferencia, eso sí, es que la altura de este espacio variará y en la mayoría de los casos será mucho mayor a los 480 px acostumbrados.

He aquí algunos ejemplos de aplicaciones en ambos modos, ancladas y en pantalla completa:

El caso inverso, de contar con pantallas de gran resolución, también es algo que debemos tomar en cuenta, ya que muchas veces nuestras aplicaciones no están preparadas para llenar el “espacio adicional” y entonces la experiencia en el uso del software se ve deteriorada.

En este tema, creo yo, debemos aprender del diseño responsivo y propuestas de interfaces líquidas que vemos propuestas en el mundo web.

Sin embargo, Windows 8 nos presenta herramientas y controles que permiten lidiar con este tipo de situaciones, a partir de técnicas y controles que aprovechan el espacio adicional, a través de la posibilidad de mostrar más contenido. Todo esto, gracias a que en Windows 8 podemos utilizar las técnicas de layout adaptativo de XAML y las características de CSS3 (aprobadas por la W3C). En ambos casos, su uso es conocido entre los desarrolladores actuales y su objetivo coincide con las metas que requerimos cubrir.

Si bien, todo esto es súmamente conveniente para el desarrollador de interfaces de interacción con datos y contenidos, existe un caso especial que quizá no requiere de adaptar su contenido respecto del tamaño de la pantalla: los juegos.  Normalmente en un juego deseamos que la escena permanezca mostrando el mismo contenido sin importar el tamaño de la pantalla.

Windows 8 nos da la ventaja de dar soporte a ambos modelos, según lo que decida el desarrollador. Esto permite tener experiencias de uso uniformes, de manera independiente del tamaño de la pantalla. El usuario no tendrá que pelear ahora con aplicaciones que no se adaptan muy bien al cambio de tamaño de su ventana individual.

Incluso, este problema puede verse cuando uno tiene una netbook con una resolución menor a 600 px de alto y abre cajas de diálogo del propio sistema operativo (Windows XP, por ejemplo) en donde el botón de Aceptar se encuentra por debajo del margen inferior y no hay forma de poder subir la ventana. Sin embargo, si alguien tiene nostalgia por el esquema de escritorio, éste se encuentra todavía disponible.

Otra problemática que vale la pena discutir, es la densidad de pantalla. Sobre todo ahora, que el tema son las interfaces touch, necesitamos pensar en que en una pantalla de 11.6 pulgadas podemos contar con resoluciones de hasta 2560 x 1440. Y es que no se trata de que únicamente la letra se percibe “chiquita” sino que también las áreas sensibles al toque se disminuyen, incrementando potencialmente los errores por parte del usuario, al tratar de “atinarle” al elemento seleccionado.

Windows 8 inicialmente podía escalar continuamente, es decir, mantener el tamaño en pulgadas de nuestros objetos de manera consistente en la pantalla. Una excelente característica, pero que trae consigo el problema de que la gran mayoría de las aplicaciones utiliza imágenes de mapas de bit, que no escalan y que terminan por verse borrosos en la pantalla.

Para corregir esto, se adaptaron 3 tamaños de escalamiento, que permiten que los desarrolladores puedan incorporar 3 tamaños de bitmaps para los recursos de su aplicación de manera perfectamente predecible:

1. 100% que es el tamaño original.
2. 140% para pantallas HD.
3. 180% para pantallas de alta densidad (quad XGA).

Estos porcentajes están optimizados para los dispositivos existentes en el mercado. Y aunque los tamaños suenan extraños hacen sentido perfectamente respecto de la forma en la que funcionará con los dispositivos existentes en el mercado.

Para los muy curiosos, y en general, para entender cómo es que se decidió este tema en Windows 8, en la siguiente gráfica vemos como estos porcentajes tratan de cubrir el hardware existente actualmente, así como dispositivos que estarán disponibles en el futuro cercano:

D. Washington hace un breve comentario en su post respecto de la nueva iPad, para la cual Apple ha decidido un factor de escalamiento del 200%. Aquí indica que esto hace sencilla la vida de los desarrolladores de app y para los desarrolladores del producto, ya que únicamente se tienen que soportar estas 2 variantes. Windows 8 implementa en su lugar un escalamiento que es invisible al usuario final, basándose en las dimensiones de la pantalla, sin intervención del usuario, del administrador de sistemas o del propio fabricante.

Los desarrolladores únicamente debemos preocuparnos en tener gráficas que se vean grandiosas en estos 3 tamaños de escalamiento y de manera “mágica” Windows 8 las empleará según sea necesario para dar la mejor experiencia al usuario final.

Entonces, al final del camino, todo esto se trata de una visión de mercado en donde el desarrollador no se sienta limitado. Lejos de ser un “ya no puedo redimensionar mi ventana”, se trata de un esfuerzo que permite que nuestras aplicaciones puedan verse grandiosas en diferentes tamaños de pantalla y en diferentes densidades, sin limitarnos y sin tener que tener código que piense en todas las posibilidades, y que cuando estas no son cubiertas, nuestra aplicación falla ante los ojos del usuario cuya combinación de configuración de hardware escapó ante nuestro código. Entonces estamos llegando de repente al 100% del mercado con interfaces y experiencias consistentes.

No sólo Windows 8 soporta el escalamiento de manera natural y transparente al desarrollador, sino que también da soporte a estándares como SVG o arte desarrollado bajo XAML que permiten escalar imágenes vectoriales sin pérdida de calidad hacia cualquier tamaño. De igual manera, existe el soporte para “CSS3 resolution media query” o para responder ante eventos del sistema (por ejemplo un cambio de orientación del dispositivo o cambio de pantalla para proyección) que permiten la recarga de las imágenes al tamaño más adecuado.

Pero, ¿yo como sé que realmente se ve bien mi aplicación? Bueno, pues VS11 cuenta con Simulador de Windows, que permite a los desarrolladores correr sus aplicaciones en diferentes tamaños de pantalla.

De igual forma, Expression Blend 5 ofrece opciones para diseñar apps en diferentes tamaños de pantalla y densidades. Y su canvas es actualizado de manera automática.

Entonces, esto nos lleva a tener que pensar en 3 tamaños fundamentales para todas nuestras aplicaciones:

• 1366 x 768 – como pantalla mínima.
• 1024 x 768 (al convivir con una aplicación ajustada en snap).
• 320 de ancho, cuando sea nuestra aplicación la que esté ajustada o en modo snap.

Adicionalmente, deberemos pensar en la forma en la que nuestros contenidos se comportarán de manera natural cuando el usuario gire la orientación del dispositivo.

Las maneras naturales del interacción propuestas por Microsoft para los dispositivos se encuentran de la siguiente manera:

• Desplazamientos horizontales para posiciones apaisadas (que es la situación normal de la mayoría de monitores de PC de escritorio).
• Desplazamientos verticales para posiciones verticales.

Es decir, los movimientos se sienten más naturales, cuando estos están en armonía con los lados más largos en el dispositivo.

Pensemos en el Windows Phone. Sus desplazamientos son a lo alto del aparato. No hay desplazamientos laterales para desplegar elementos de contenido, sólo para cambiar grupos de contenido. Esto de manera intuitiva hace sentido para nuestro cerebro.

Por otra parte, la pantalla en una computadora con Windows 8 estará, normalmente, orientada a desplazamientos horizontales. En la siguiente gráfica podemos distinguir estas diferentecias fundamentales en los formatos de dispositivos y se puede comprender el porque las líneas naturales de movimiento se “siente bien” cuando uno lo piensa.

De todo esto, se puede concluir porqué las aplicaciones ajustadas (o en modo snap) tienen su flujo natural hacia arriba y hacia abajo. Muy similar al Windows Phone. Esto es debido a la similitud que el espacio designado tiene (320 px) con los tamaños manejados en los teléfonos (480 x 800 px). Yendo un poco más allá con este tema, se puede ver en algunos sitios el tema de una posible, pero muy lógica, convergencia en Windows 8 con sus dispositivos. Es decir, se trata de la posibilidad de correr de manera nativa las apps disponibles para Windows Phone. Esto podría suponer un acceso inmediato a más de 70,000 aplicaciones del Marketplace en el momento de salir al mercado con Windows 8. Sin embargo, es necesario recordar que esto es parte del molino de rumores. De igual manera que el golpe maestro que terminaría de darse con una tablet PC en $200 dólares a mediados del siguiente año, si los rumores fueran ciertos.

Retomando el tema inicial de los tamaños de pantalla, también es importante tomar en cuenta que no sólo existen tamaños de pantalla, sino de pantallas. Sí, y es que si bien nos recordamos las últimas versiones del sistema operativo de Mac dió algunos dolores de cabeza en escenarios de múltiples pantallas. En el caso de Windows 8, esto no está resuelto del todo, pero me parece que no va mal. Para ver un video y comentarios respecto de este tema, les invito a ver el siguiente enlace.

Entonces, para nuestras aplicaciones en pantalla, necesitaremos pensar, como mencioné anteriormente, en las diferentes orientaciones de la pantalla. En este otro excelente post de D. Washington, se complementa lo que tenemos que tener en cuenta al pensar en nuestros usuarios móviles, principalmente.

Recordando que Windows 8 se adapta a múltiples factores de forma, es natural que la inclinación u orientación de nuestro dispositivo sea parte del diseño de la experiencia de usuario para nuestras aplicaciones. Windows 8 nos proporciona una base sobre la cual podemos partir para este objetivo, la cual está fundamentada en los siguientes principios:

• La experiencia se adapta por sí misma a todo tipo de factor y tamaño: pantallas pequeñas, pantallas anchas, laptops o desktops.
• La experiencie toma ventaja de los formatos de pantalla ancha para multi-tarea y video en pantalla completa.
• El dispositivo puede ser sujetado e interactuado en la forma que el usuario considere más comfortable.
• Los desarrolladores  tienen la oportunidad de crear una aplicación que corre en todas las vistas y orientaciones en diferentes factores de forma con un mínimo de esfuerzo.

Es este último punto en el que existe una promesa muy fuerte y que implica un sentido de “realizas mucho con poco esfuerzo”. Lo cual no se debe tomar en el sentido de “ya no hagas esfuerzo, porque solito lo hace”. En realidad, como con cada avance de tecnología, esto nos permite tener más tiempo para crear una aplicación con alta funcionalidad y una presentación elegante y bella.

Para esto, Microsoft tuvo que hacer un gran esfuerzo examinando los tipos de uso que se hacían de este tipo de dispositivos, así como de las interfaces de usuario. Se realizaron pruebas en los terrenos de:

• Factores antropomórficos como tamaños de mano y pulgares.
• Factores ergonómicos como fatiga y repetición.
• Factores de hardware como accesibilidad a botones físicos.
• Factores ambientales, como preferencias de lugar para el uso de los dispositivos.
• Factores físicos, como estar de pie, sentado en un sillón o sentado en un escritorio.

¿Porqué mencionarlos de manera detallada? Por que yo creo que esto puede darnos pistas esenciales de lo que motiva las decisiones de diseño del sistema operativo y que, al final del camino, influyen enormemente en las decisiones que debemos tomar para que nuestras aplicaciones se sientan nativamente integradas a Windows 8. Por ejemplo, al inicio Microsoft pensaba que el uso de la orientación vertical o acostada era más por preferencia personal. Pero el resultado fue consistente y sorprendente: conforme los usuarios se acostumbran al uso del dispositivo, la orientación se volvió dependiente del tipo de contenido.

“Si el contenido y la experiencia se sentían mejor en formato acostado, la gente usaba de manera natural la app en ese modo”.

Washington nos da un par de ejemplos específicos:

1. Para ver una película es preferible una vista acostada, que elimina las barras negras.
2. Para la lectura de un artículo o libro, se prefiere la vista vertical, que minimiza el desplazamiento.

Un tema súmamente importante aquí es que debemos tomar en cuenta que aunque nuestra aplicación no esté pensada para más de una orientación, el usuario puede tener dicha expectativa. Además, siempre es agradable descubrir que tu aplicación responde a todos los gestos.

Entonces, Windows 8 está pensado en las siguientes características:

• Que se rote fácilmente el dispositivo y se adapte a la mejor postura ergonómica.
• La rotación será representada por Windows de manera rápida y fluida.
• Windows rota de manera predecible en el sistema operativo y en las apps, manteniendo al usuario en control.
• Los desarrolladores pueden construir fácilmente un distribución en pantalla de alta calidad intencionalmente diseñadas para modos acostados y verticales (landscape y layout), dependiendo de las experiencias que quieran habilitar.

Microsoft determinó que al tomar el dispositivo con ambas manos en orientación acostada, los dedos pulgares se encuentran directamente sobre las esquinas inferiores. De esta forma, el sistema operativo acerca diversas funciones al usuario de manera natural. Nuestras interfaces podrían tambien hacer uso de este detalle.

La rotación de los equipos es un detalle que también ha sido cuidado, y es ¿quién no ha sufrido con algún celular que no interpreta el giro correctamente? En Windows 8 contamos con un algoritmo que espera a que el acelerómetro registre una posición estable antes de interpretarlo como una rotación. Esto da mayor estabilidad al comportamiento de nuestro dispositivo. Sin embargo, esto se hace dentro de un periodo corto de tiempo, de tal forma que el dispositivo da la sensación de responder rápidamente.

En la siguiente gráfica, podemos ver cómo funciona esta estrategia.

Vemos cómo existe un micro periodo en el que se espera a que el acelerómetro se estabilice y posteriormente se interpreta el giro. Durante el giro, no es nuestra interface viva la que se muestra, sino una captura del último estado de pantalla, lo que permite al sistema operativo mostrar una animación que se vea ágil. Y al término del giro, se muestra la nueva disposición de nuestra aplicación en pantalla. A este comportamiento, se le suma un botón para bloqueo del giro, que permite al usuario tener el control sobre el comportamiento de giro.

Ahora, un pequeño paréntesis para los que tienen su alma en el código. Las estrategias que se emplean para el control del giro y cómo adaptamos el diseño de la interface ante este evento, son las mismas que se emplean para el uso de snapping en las apps. El desarrollo en HTML5 usará queries de media para ligar la configuración de la pantalla a la orientación del dispositivo. El desarrollo en XAML responderá a eventos de vista. En ambos casos, si utilizamos los controles provistos por la plataforma, estos se adaptarán de manera automática. Todo esto lo podemos probar desde el simulador en VS11.

En resumen, cuando desarrollemos para Windows 8 debemos ser cuidadosos de aprovechar las ventajas que se presentan para el uso óptimo de los espacios en pantalla, de las características visuales de los diferentes dispositivos y sobre todo para que nuestras aplicaciones luzcan hermosas ante.

El proceso en general fue bastante sencillo, transparente y muy rápido.  Con este post quiero compartirles los pasos que seguí y el orden en que los fui siguiendo, para que les pueda servir de base en sus propias instalaciones.

1

Descargar el archivo .ISO de Windows 8 Consumer Preview.  En mi caso seleccioné la versión de 64 bits, pero también tienen a su disposición la de 32 bits.