For the Windows Store to be successful, we understood that we needed to create tools that would enable developers to be successful—at creating great apps, listing these apps in the Store, keeping track of how the apps are doing, and updating the apps over time. We approached the submission process by looking at developers as our partners, sharing a common goal of connecting people to as many great apps as possible.
In this post, I’ll share with you the goals that influenced our choices when designing the application submission experience.
Design iteration and learning
In addition to defining the set of baseline scenarios that we knew we had to deliver, we took several early design prototypes into the usability lab to get direct feedback from a diverse cross-section of developers. We also took the time to listen to as many developers as we could, asking them to describe any difficulties they encountered when submitting apps to other platforms.
Developer expectations are as diverse as the apps they write. Some developers arrive hungry for information and want to fully explore every option, while others are looking for a streamlined experience that takes only a few minutes. We established that setting time and complexity expectations up front is important and that we needed to provide a straightforward path toward submission while still offering flexibility in how developers explore and consider their options. We also learned that the process of thinking through the options for publishing an app—basics like markets, price, trials, and in-app offers—frequently inspire developers to add new features and change some code.
We broke down the submission process into two phases. At first, the developer is in the driver’s seat, learning, submitting, and reviewing their own data, working at their own pace. However, once you submit the app for certification, you are in the passenger seat, tracking the progress of the app, but unable to affect that progress or outcome in the same way as before. We needed a plan to increase confidence in this second phase, while transparently tracking the status of the app during the certification process.
We wanted to be sure that you would be able to submit your apps incrementally, and complete the process over several sessions. We needed a system that would predictably and reliably save data even when that data isn’t perfect yet, as you sometimes need to move on to something else and pick up the process again later.
Design goals
Because we wanted to focus our engineering efforts on the problems that were going to impact the most developers the most frequently, some of the key goals we picked were:
- Encourage developers to visit the Store developer portal before they start coding
- Help developers comply with the Store technical requirements
- Reduce concepts and repetition by pulling information directly from the app package
Encourage developers to visit the Store developer portal before they start coding
One of the consistent themes to come out of our usability tests was that if developers waited to visit the Store developer portal until after they finished coding, they would usually be inspired to change their code slightly as a result of decisions made during the app submission flow. Similarly, developers need to know that the name of their app won’t already be in-use by the time they finish coding and are ready to upload. By allowing developers to reserve a name before they are ready to submit the app, we add an additional level of predictability, as the name is guaranteed to be unique and reserved for your use.
One advantage of allowing developers to reserve app names in advance is that it brings them into the developer portal site earlier in the process, and exposes them to some of the other options and requirements that they’ll need to keep in mind as they code.
The link to the Store portal from Visual Studio deliberately does not deep-link directly to the name reservation page, but rather to an overview page that sets the context for the app submission process. We felt that it was important to be transparent and upfront about the entire process of submitting to the Store, setting expectations visually that there are multiple concepts to cover, and including rough estimates of about how long each step might take.
Note that, although only the first section is enabled, the links that allow you to learn more about each step are always available. So you are free to dive right in, but you can also take your time to learn more about each option.
We also ordered the steps on this page very deliberately, grouping the concepts that might inspire you to change your code conceptually earlier in the process, to help facilitate the consideration of these questions before we ask you to upload your app packages.
I’ll briefly touch on three of these concepts:
- Markets – My colleague Aayaz Bhorania mentioned the global reach and opportunity of the Windows Store in his blog post, but there’s something about the act of actually selecting the markets for your own app that drives the point home in a way that makes localization look like the next feature to add (by the way, you’ll see a short list of markets in the video because I’m using a beta version of the portal, but the list will be getting much bigger very soon).
- Monetization – The Store provides full support for trials, including both a built-in time based trial and an easy method of including feature-differentiation for trial users. Using in-app purchase, users can unlock new app capabilities without losing context. Coding these trial and purchase-based features is easy—but it needs to be planned and tested.
- Services – Here is where visiting the portal early can really help your testing efforts. Windows 8 has some great built-in push notification technology that allows your app experience to extend right to your app’s tile on the Store screen. When you reserve a name for your app, the Store generates a unique app identity and provisions your app for push notifications. From the Advanced Features page, you can find all of the information you need to align your local project with the identity details that the Store assigns. This enables you to test your app—including hooking up the notifications end-to-end —before you publish.
Help with Store technical requirements
In order to create a consistent consumer experience, we needed to establish some constraints around certain app package details. For example, we decided that in order for consumers to reliably find, acquire and provide feedback on an app in the Store, we needed to ensure that all apps had a unique name as seen by consumers. For various technical reasons, the unique identity for each app must include some details that are app-specific and some details that are developer-specific.
After considering and rejecting several designs where we tried to communicate all of this complexity to the developer on the package upload page—without distracting from the upload itself—we decided to provide an automated option, and move this information closer to the development environment. Using Visual Studio, you can authenticate to the Store, view a list of your apps, select the app that you’ve already defined on the Store portal, and create a package that aligns with all of the app-specific and developer-specific details that the Store requires.
As the Store does some basic package validation immediately after upload, using this experience from Visual Studio provides a predictable way to align your package with Store constraints and have your package successfully accepted the first time you upload it to the Store.
We also provide increased predictability when it comes to apps passing the full Store certification process, by providing you with the Windows App Certification Kit, the same technical tests that the Store runs during app certification. By running this locally before uploading an app package, you can find technical issues early on, and increase confidence that your app will pass technical certification.
Pull information directly from the app package
To streamline the experience and prevent you from having to enter the same data multiple times, we pull as much as we can directly from your app packages. Visual Studio provides tools to help developers declare certain details in the package, such as the languages that your app supports and the logos that you want your customers to see. Sometimes these relationships are complex, as some apps include assets for multiple resolutions, various high contrast ratios, and multiple languages, with some overlap and fallback between these different contexts. Rather than attempt to replicate this complexity on the Store portal and ask you to define it twice, we read this data directly from the package, and treat the package as the master copy.
Our choice here affects the timing of some of the submission events—for example, since you’ll be asked to provide localized app listing data for each language your app supports, you’ll need to upload a package in order to enable that section of the submission experience.
Once the Store portal reads the supported languages out of the uploaded package, the Description sections are enabled, in this case one section each for English and French:
Let’s take a look at one of these description pages, which is the input screen for most of the localized text and images that customers will see on the app listing page in the Store.
The first thing you’ll notice is that the page is pretty long. To help you get through this long form, we built in what we call the “go catch your bus” capability. We heard from a number of developers that when they encounter a large form like this with multiple required fields, it sometimes feels like the data integrity needs of the system were given more design consideration than the experience of the person having to input the data. Normally this shows up when the page doesn’t let you save anything because there’s something partially incomplete or that contains some invalid data.
We want you to catch your bus, so we allow you to save your data in whatever state it’s in. We’ll know if it’s invalid, and we’ll make sure you don’t accidentally submit the app for certification until the issue has been fixed. You can come back tomorrow confident that you can continue the process of refining your message to consumers about how your app provides real value. We think that’s important enough that we support your doing it on your timeline.
We also consciously used a “save” metaphor across the entire experience, because we wanted to reinforce that you could come back later and pick up where you left off. You might notice that on some of these pages there isn’t always a piece of data to save, but we found that consistently using a “save” button reinforced a sense of security and predictability that you could leave and return at any time.
Tracking certification status
There are a lot of factors we had to balance when the submission shifts to the tracking stage. It’s a particularly sensitive part of the scenario, and your time to market is important. After being in the driver’s seat during planning, coding, testing, and submission, suddenly the context shifts and you have to wait for a result. We knew early on that this was a critical piece of the experience, and that if we designed it well, we could increase both developer confidence and satisfaction in the process of submitting apps to the Windows Store. And we know that the other steps we’ve taken—making the Windows App Certification Kit available to run before you submit your app, providing guidance in plain language in our app certification policies—help provide predictability and consistency, but still don’t answer the immediate question of “what’s the status of my app?”
Our goal on this page was transparency—here’s your app, here’s what stage it’s in, here’s how long that usually takes. You can watch your app progress through the certification process, using the same visual language that we use elsewhere on the portal to tell you at a glance how close you are to making your app available to millions of Windows 8 users.
Here’s a quick look at what is happening behind the scenes during each of these stages.
- Pre-processing. This is where we’ll check to make sure we have all of the appropriate details that we’ll need to publish your app. This includes checking the status of your developer account and, if your app has a purchase price or any in-app offers, we also ensure that we have all of the paperwork on file so that we can pay you. We know that sometimes this paperwork can take a few days to complete, which is why we allow you to work on your app submission right away, even if some of these forms aren’t complete yet.
- Security tests. We’ll check everything you submitted for viruses and malware.
- Technical compliance. We’ll use the Windows App Certification Kit to check that your app complies with the technical policies. This is exactly the same technical certification assessments that are included in the SDK and that you can run locally before you upload your package.
- Content compliance. Our team of testers takes a look at your app to check that the contents comply with our content policies. Since there are real people looking at your app, this process can take longer than the other steps.
- Release. This stage goes by very quickly unless you’ve specified a publish date in the future. If you request from the Selling details page to wait until a particular date before your app reaches customers, then after you pass the other tests, you’ll remain in this stage until that date arrives.
- Signing and publishing. In this final step, we’ll sign the packages you submitted with a trusted certificate that matches the technical details of your developer account. This provides customers with the assurance that the app is certified by the Windows Store and hasn’t been tampered with. We’ll then publish your app packages to the Store, along with all of the other data that will be visible in your app listing page, so that millions of Windows 8 users will be able to find, acquire, and enjoy your app.
I hope you’ve enjoyed reading about some of the learning and thinking that went into the design of the Windows Store app submission experience. I look forward to continuing this conversation, and to seeing your apps in the Windows Store.
@Courtesy - Jonathan Garrigues
No comments:
Post a Comment