Por: Gus Salloum, Gerente de Programa, Tienda Windows
Cuando se registrar para una cuenta en Windows Dev Center, su meta es casi seguro enviar una aplicación, que ésta sea certificada, y distribuirla a sus usuarios potenciales. En este texto me gustaría enfocarme en el envío y certificación de aplicaciones para la Tienda Windows, y compartir con ustedes algunos de los consejos más importantes para mover este proceso de la manera más eficiente posible.
#1: Asegúrense que su aplicación cumple con los requerimientos de certificación
No importa la etapa en la que están sus aplicaciones, asegúrense de revisar de manera regular los requerimientos para la certificación de aplicaciones para la Tienda Windows, que pueden cambiar. (De hecho, los actualizamos antes de que se publicara este texto)
Cuando planeen aplicaciones para la Tienda Windows, tengan en mente los principios centrales detrás de la certificación: las aplicaciones necesitan proveer valor a los usuarios potenciales, comportarse de la manera que se espera se comporten, poner a los usuarios en control, y ser apropiadas para una audiencia global. Si diseñan sus aplicaciones alrededor de estos principios y revisan los requerimientos específicos, ya han avanzado un gran trecho hacia una eventual certificación.
Al mismo tiempo, deben tomar en cuenta que cumplir los requerimientos de certificación de la Tienda no necesariamente significa que su aplicación cumplirá otros requerimientos, como guías de contenido impuestas por un proveedor de anuncios. Asegúrense de revisar los requerimientos de cualquier servicio que utilicen además de la Tienda.
#2: Creen con antelación su cuenta de la Tienda
Las aplicaciones no pueden ser certificadas hasta que no hayan completado el registro de su cuenta Windows Dev Center. Las cuentas de la compañía tienen pasos de verificación que pueden tardar unos días en completarse. Esto es necesario porque las cuentas de la compañía pueden aprovechar privilegios adicionales en aplicaciones, como utilizar certificados de usuario compartidos, autentificación empresarial, y la librería Documentos.
También recuerden completar las formas de impuestos necesarias para su país de origen, que es un requerimiento para aplicaciones pagadas y compras en aplicación. Sin las debidas formas de impuestos completadas, las aplicaciones certificadas no serán lanzadas y no recibirán el pago de sus ganancias.
#3: Reserven con anticipación los nombres apropiados para su aplicación
Los nombres para su aplicación son reservados en el Dashboard del Dev Center y aplican tanto para la Tienda Windows como para la Tienda Windows Phone. El nombre que podrán utilizar en una aplicación ciertamente afecta muchos aspectos de su diseño y branding, así que reserven su nombre con anticipación en el proceso de desarrollo e incluyan cualquier número de nombres localizados que necesiten para los idiomas que su aplicación soporte. Podrían encontrar que, por supuesto, otros ya hayan reservado el nombre que ustedes tenían en mente, así que hacer esto con anticipación les da tiempo de encontrar nuevos nombres.
Tomen en cuenta que la Tienda distingue entre los idiomas que tienen soporte por la aplicación – como se puede ver en el manifiesto de la aplicación – y los mercados en que la hicieron disponible, que están indicados en el Dashboard del Dev Center. Aunque también es posible hacer que el japonés esté disponible en una aplicación en Francia, o viceversa. En esos casos, podrían localizar el nombre de la aplicación también. Pero no es necesario localizar y reservar nombres de aplicaciones para mercados en los que tal vez, de otro modo, no localizarían la aplicación.
Verifiquen que tienen los derechos para utilizar el nombre que elijan. Sean en especial cuidadosos cuando utilicen nombres de otras compañías, como en el caso de que utilicen sus servicios en la aplicación. Cada empresa tendrá sus propias políticas sobre cómo su marca puede ser utilizada por terceros, y si infringen alguna de estas políticas podrían solicitar que su aplicación sea removida de la Tienda.
Para más guías sobre esto, vean Cómo nombrar tu aplicación
#4: Envíen aplicaciones de alta calidad que ofrezcan un valor único a los clientes
Cuando construyan aplicaciones, piensen sobre cómo cada una contribuye a fortalecer su catálogo general y la calidad de la Tienda Windows en general. Hemos encontrando que los clientes recompensan las aplicaciones creativas y útiles, y tienen poco interés en aplicaciones sin terminar o los resultados de experimentación temprana. Los invitamos a no enviar variaciones de las muestras que proveemos en el SDK de Windows. Esas muestras existen para educarlos en el uso de la API Windows y proveer fragmentos que pueden utilizar para características específicas. Sin embargo, no son para los consumidores, su intención es proveer puntos de inicio para una aplicación que el cliente utilizará.
#5: Declaren sólo aquellas capacidades que en verdad necesita la aplicación
Un cierto número de API de Windows Runtime está protegidas por capacidades que ustedes declaran en el manifiesto de la aplicación. Es importante que declaren sólo aquellas que en ese momento necesita la aplicación. Podrán agregar más capacidades para actualizaciones futuras de la aplicación cuando utilicen sus API relacionadas.
Las capacidades declaradas se muestran directo a los consumidores en la página de su aplicación en la Tienda Windows como se muestra a continuación. Esas capacidades necesitan hacer sentido a los consumidores, en especial aquellas que tienen ciertos asuntos de privacidad como el uso del micrófono, cámara, y geolocalización. Si hay alguna duda en la que su necesidad de una capacidad sea obvia, expliquen su uso de esta en la descripción de la aplicación.
Declarar capacidades para las librerías de Fotos, Videos y Música del usuario es por lo general necesario sólo si su aplicación presenta una vista completa de galería de los contenidos de la librería. Si su necesidad es sólo abrir o salvar archivos individuales a esas ubicaciones, es mejor utilizar los recolectores de archivos para ese propósito, pues permiten al usuario seleccionar cualquier ubicación en esas librerías o en cualquier otro lugar en su sistema de archivos y proveedores de almacenamiento de archivo.
También deben estar conscientes de que hay tres capacidades de usuario especial que garantizan un proceso más lento de certificación. Estas son la Librería de Documentos, Certificados de Usuario Compartido y Autentificación Empresarial. Las aplicaciones que utilizan estas deben ser enviadas a través de una cuenta de la compañía (no una cuenta individual), y también están reservadas para escenarios específicos y requieren justificaciones escritas. Para más, vean las declaraciones de capacidades de la aplicación.
Además, las aplicaciones que declaren la capacidad de Librería de Documentos sólo pueden ser enviadas desde cuentas de desarrolladores que han adquirido un certificado de ingreso con código de Validación Extendida (EV) (vean tipos de cuentas, ubicaciones, y tarifas). Evitar declarar la capacidad de Librería de Documentos para configuración de almacenamiento de archivos (en su lugar utilicen sus carpetas de datos de la aplicación), salvar documentos, o hacer cualquier cosa fuera de los escenarios permitidos, porque intentar hacer eso provocará rechazo. Para salvar y abrir documentos en la Librería de Documentos o cualquier otra ubicación, sólo usen los colectores de archivos en su lugar porque los usuarios pueden elegir cualquier ubicación que quieran a través de ellos, que incluyen Documentos.
#6: Incluyan políticas requeridas de privacidad
Una política de privacidad es requerida para todas las aplicaciones habilitadas para la red, que incluye todas las aplicaciones que declaren la capacidad de Internet (Cliente) en el manifiesto. Esta capacidad está activa por defecto en las plantillas de proyecto de Visual Studio, así que recuerden quitar la marca en la caja del manifiesto del editor si no lo necesitan.
Su política de privacidad debe ser publicada en una URL que sea pública de manera accesible. Ustedes proveen esa liga cuando llenen los detalles de su aplicación en el Dashboard del Dev Center, y el Dashboard implementará esto si han declarado cualquiera de las capacidades de red relacionadas.
La liga luego aparece en la página de descripción de su aplicación en la Tienda, y deberían agregar un comando en su panel de Ajustes que lance su URL de política.
El requerimiento 4.1
de los requerimientos de certificación de la aplicación para la Tienda Windows provee las especificaciones de lo que su política de privacidad debe contener. No proveer una política de privacidad provocará que falle la certificación de su aplicación.
#7: Tengan cuidado cuando soliciten calificaciones de los usuarios
Debido a que las calificaciones y reseñas son visibles en la página de su aplicación en la Tienda Windows y afectan la capacidad de su aplicación de ser descubierta, muchos desarrolladores invitan de manera activa a sus clientes a dejar sus comentarios. Por supuesto, las buenas calificaciones son importantes, pero las aplicaciones no pueden ofrecer recompensas por calificaciones o reseñas positivas. Deben permitir que los consumidores tengan su propia opinión y que la expresen de manera honesta. Después de todo, la retroalimentación genuina les ayudará a entender cómo mejorar su aplicación.
Cuando inviten a la gente a que dé sus comentarios, eviten utilizar cualquier palabra que sugiera una recompensa, pues podría ser motivo de rechazo. De hecho, ni siquiera es posible determinar a manera de programación qué comentario ha sido dejado, por lo que no hay forma de activar un premio. Lo más que pueden hacer es enviar a un usuario a la sección de calificación y reseña de su aplicación en la Tienda como se los muestro a continuación.
JavaScript:
var uriString = «ms-windows-store:REVIEW?PFN?name=» +
Windows.ApplicationModel.Package.current.id.name;
Windows.System.Launcher.launchUriAsync(new Windows.Foundation.Uri(uriString));
C#:
using Windows.ApplicationModel;
using Windows.Foundation;
using Windows.System;
String uriString = «ms-windows-store:REVIEW?PFN?name=» + Package.Current.Id.Name;
Launcher.LaunchUriAsync(new Uri(uriString));
#8: Prueben su aplicación de manera meticulosa
Este es sencillo. Si su aplicación no es funcional, fallará en la certificación. Por otro lado, una funcionalidad completa, requiere que prueben una variedad más amplia de condiciones que podrían encontrar en su trabajo de desarrollo. Las pruebas de primera mano son también importantes porque cualquier actualización que hagan a su aplicación para reparar bugs requiere que la aplicación vaya a través de todo el proceso completo de certificación de nuevo.
Primero, asegúrense de probar en una variedad de hardware con diferentes capacidades. Esto incluye dispositivos sólo táctiles, dispositivos habilitados para el tacto, y dispositivos sólo para teclado y mouse (cuando aplique). También prueben en sistemas x86, x84 y ARM – nunca asuman que porque su aplicación funciona en uno lo hará en los demás.
Prueben su aplicación en una variedad de tamaños y orientaciones de pantalla, así como en diseños angostos (vean las Guías para reajustar el tamaño para diseños angostos). Para este propósito, pueden utilizar hardware real que esté disponible para ustedes, pero también empleen el simulador de Visual Studio que pueden configurar para diferentes tamaños de pantalla y factores de escala. Luego prueben su aplicación cuando el dispositivo esté desconectado de internet y/o en una conexión medida. Damos por hecha la conectividad con mucha frecuencia y se nos puede olvidar muy fácil sobre todos los escenarios de consumo donde la conectividad no está disponible. Así que si su aplicación requiere conectividad para funcionar bien, asegúrense que falla de manera graciosa y alerta al usuario esa condición, en lugar de congelarse o comportarse de una manera que confunda al usuario.
Recuerden también cambiar la utilización del objeto CurrentAppSimulator, que utilizan durante el desarrollo para trabajar con la API de la Tienda, al objeto CurrentApp. Si lo olvidan, no pasarán la certificación. También tengan en cuenta que algunas API de la Tienda lanzarán excepciones cuando el dispositivo esté fuera de línea y la información de licenciamiento no esté disponible. Asegúrense de tomar esas excepciones, en especial para las compras en la aplicación, porque por lo general no verán este tipo de excepciones cuando usen CurrentAppSimulator.
JavaScript:
//Use CurrentAppSimulator during development
var currentApp = Windows.ApplicationModel.Store.CurrentApp;
// Without a try-catch block, the app may crash
try {
appListing = currentApp.loadListingInformationAsync();
} catch (e) {
// Handle exceptions
appListing = null;
}UnlockNewLevelsUX(appListing);
C#:
using Windows.ApplicationModel.Store;
// Without a try-catch block, the app may crash
try
{
#if DEBUG
// Load listing from the simulator configuration
appListing = await CurrentAppSimulator.LoadListingInformationAsync();
#else
// Get the listing data from the Windows Store
appListing = await CurrentApp.LoadListingInformationAsync();
#endif
}
catch (Exception)
{
// Handle exceptions
appListing = null;
}
UnlockNewLevelsUX(appListing);
#9: Apliquen WACK a su aplicación (corran el Kit de Certificación de App Windows)
Cuando envíen su aplicación para certificación, la primera cosa que sucede es que la Tienda la corre a través del Kit de Certificación de App Windows o WACK. Esta herramienta detecta muchos problemas comunes, cualquiera de ellos que pudiera causar que su aplicación sea rechazada de inmediato, pero no recibirán esos resultados. Pueden ahorrarse una tonelada de problemas, y obtener reportes detallados si corren la herramienta por su cuenta. Está incluida en el SDK de Windows y la pueden encontrar si buscan “Cert Kit” desde la pantalla de Inicio.
WACK hace diferentes pruebas a la aplicación (vean la siguiente imagen), y les provee un reporte detallado al final del proceso. Deben revisar cualquier problema que el reporte identifique antes de enviar su aplicación.
Corran WACK durante su proceso de desarrollo en lugar de esperar hasta el final. Sería más fácil corregir problemas antes, y correr WACK les dará cierto nivel de pruebas de regresión.
Tomen en cuenta que también pueden elegir correr sólo pruebas específicas en WACK, como se muestra a continuación. Una prueba completa puede tomar entre 10 y 15 minutos tiempo en el cual deben interactuar con la aplicación o la máquina como un todo. Si trabajan en un problema específico que una sesión previa de WACK identificó, podrán acortar el proceso al volver a correr sólo ciertas pruebas.
#10: Mantengan la verdad en
su
publicidad
Cuando llenen toda la información descriptiva para la página de su aplicación en la Tienda – incluyendo su descripción, lista de características, y capturas de pantalla – sean honestos sobre la experiencia de su aplicación para el consumidor real. Asegúrense de que quienquiera que sea el que escribe este copy de mercadotecnia esté alineado con lo que aplicación hacen verdad – no listen características, por ejemplo, que podrían ser implementadas en el futuro, y no muestren características en capturas de pantalla que no han sido implementadas.
Asegúrense también de revelar restricciones geográficas, esto es, identificar características que tal vez no estén disponibles en algunos mercados. Por ejemplo, los requerimientos legales podrían limitar ciertos datos que ustedes no podrían ofrecer desde sus servicios de backend, lo que limitaría la funcionalidad de la aplicación.
De manera similar, revelen cualquier requerimiento de hardware como periféricos necesarios para que el usuario experimente todas sus características y capacidades.
También deben revelar la extensión de la localización. De manera ideal, deberán proveer versiones localizadas de su texto descriptivo, características, búsqueda de palabras clave, capturas de pantalla, declaración de privacidad, y así para cada lenguaje que declaren en el manifiesto de su aplicación. Si tienen cualquier ubicación parcial, sin embargo, asegúrense de revelarla. Esto incluye que negar ese contenido que la aplicación recibe de sus servicios podría no estar localizado para el idioma del usuario.
#11: Elijan una clasificación de edad apropiada para su aplicación
Su clasificación de edad representa los tipos de contenido que los usuarios pueden esperar ver en su aplicación, y qué tan adecuado es ese contenido para los niños en especial. Esta clasificación determina si su aplicación aparece en la Tienda Windows cuando los filtros de edad aparecen.
Las clasificaciones de edad y los temas de tableros de clasificación en la documentación describen a fondo qué tipos de contenido son apropiados para cada clasificación de edad. Algunos países y regiones también requieren una clasificación de un tablero de calificaciones, por lo general para juegos, lo que puede involucrar enviar un certificado de clasificación con su aplicación. Por lo general, esto significa ir a través de un proceso en línea de auto clasificación para obtener el certificado, pero algunos países requieren que envíen su aplicación para revisión, así que dejen un tiempo adecuado para este proceso. El siguiente tópico tiene ligas a todos esos tableros de calificación.
Sean en especial cuidadosos con aplicaciones que permitan compartir de manera poco controlada, cualquier tipo de información persona o que accedan a redes sociales, ya que esto requiere que su aplicación sea clasificada para 12 años o mayores. Compartir “de manera controlada” significa que la aplicación incluye controles parentales o requiere permiso de los padres para utilizar características para compartir, que deben ser identificadas de manera clara y explicadas en sus Notas para Pruebas (vean el #12 a continuación).
Si su aplicación requiere contenido sin filtrar de un servicio en línea, en especial uno que permita a los clientes subir algo por ellos mismos, la clasificación de edad de su aplicación debe cumplir con cualquier control que sea habilitado por ese servicio. De otro modo, es posible que contenido que sea inapropiado para la clasificación de edad de su aplicación pueda a aparecer en la aplicación y provoque que falle la certificación.
Por último, sin importar la clasificación de edad de su aplicación, su contenido descriptivo para la Tienda Windows, incluyendo capturas de pantalla así como su nombre de publicación, deben ser apropiados para una clasificación 12+. Por ejemplo, un juego con clasificación 16+ debido a violencia gráfica no puede incluir imágenes que muestren violencia porque ésta no está permitida para la clasificación 12+.
#12: Usen el campo ‘Notes to Testers’
El último paso para enviar su aplicación es proveer cualquier nota que necesiten a los encargados de las pruebas para ejercitar de manera adecuada su aplicación. La prueba manual de una persona es la última fase de certificación, y esa persona necesita saber cómo utilizar de mejor manera y experimentar su aplicación, cómo acceder a cualquier característica escondida, y qué cuentas de prueba pueden usar cuando se requieran registros. Para actualizaciones de la aplicación, también expliquen qué ha cambiado desde su último envío. Esto es en especial útil si no han cambiado ningún código – tal vez recién hayan actualizado detalles de listado o agregado un nuevo conjunto de recursos localizados.
Y recuerden que a través de esas notas hablan con una persona real, sean amables.
Para más, vean Proveer información a encargados de pruebas para certificación.
Conclusión
Los desarrolladores por lo general cometen el error de concentrarse demasiado en los trabajos internos del código de su aplicación y muy poco en el más largo proceso de hacer que la aplicación esté disponible para los usuarios. El proceso de certificación de la Tienda Windows está diseñado para asegurarse que las aplicaciones que aparecen listadas en la Tienda están listas para los usuarios potenciales. Al entender el proceso antes de tiempo, serán capaces de evitar un número de errores que podrían causar que la aplicación sea rechazada de la certificación.
Para más ayuda en temas de certificación, vean Evitar fallas comunes de certificación y Resolver errores de certificación en la documentación, o visiten el foro de Publicar Aplicaciones de Tienda Windows en MSDN.
