App Analytics – Dev Portal
App Analytics is essential for any software application by showing insightful metrics for the business and customers. Windows Store apps can be downloaded from a variety of sources with a global market reach. The Windows software team wanted the App data to be transparent, so marketers knew how successful their application is performing.
RATINGS AND REVIEWS
Ratings and reviews allow customers to share their opinions through the Windows App Store, and give the App an overall star rating. Shoppers rely on this content to make informed purchase decisions.
Windows Store App Analytics
I was responsible for designing various key App analytics pages to be used throughout the platform, including Downloads, Usage, Purchases, Conversions, In-app Purchases, Financials, and App Quality. The data needed to show analysis/insights on a much more granular level, including source path tracking, store listing pages, Store spotlight pages, and Social references while aggregating the data from top locals.
Metro UI Kit – Loading Spinner
My contribution to the Windows 8 Metro UI kit was the loading spinner. The original 8-24-bit (.gif) loading spinner animation was dated. There was a time when loading spinners didn’t even have a transparent background that was rampant across the Windows ecosystems. I partnered with a dev 1:1 to align with Windows 8 (OS) operating system. I could say millions of people at one time have seen the Windows 8 loading spinner for the web.
MICROSOFTS DIGITAL TRANSFORMATION
WINDOWS – METRO DESIGN LANGUAGE
When I was on the Windows Experience Design Research Team (XDR) part of the team’s mission was to reimage every customer touchpoint digitally for the Windows OS and Web Apps to modernize those experiences. The entire Windows Design Org. was responsible for introducing the Windows 8 Design Principles and Metro Design Language as the foundational building blocks to modernize the Windows ecosystem.
App Analytics – The Beginning
I transitioned to the App Analytics team after designing and shipping the App Developer Platform. I created the initial style guide for all types of histogram charts including Line, Area, Bar, and Pie charts to be used across the platform. I had to tweak the Windows brand colors to pass accessibility standards at the maximum threshold without compromising too much color.
When I joined the Windows Store Dev Portal I was presented with a PowerPoint concept deck from a product manager from the India Development Center (IDC) showing the dashboard. I spent the next few years art directing and influencing product decisions while working remotely. Another challenge was redesigning a prebuilt .js chart library system (high-charts). At a high level, I needed to reskin the default library into something that fits the Windows Metro Design Language.
WINDOWS (XDR) RESEARCH CASE STUDY
Windows Apps API Documentation
To personally tailor our documentation to the developers’ needs and requirements, thus improving app quality. Let developers set their preferences so the developer documentation can deliver an experience that meets their individual needs, regardless of whether they are first-time visitors or have been developing on Windows for 10+ years.
Re-architecting the navigation would increase productivity and reduce developer frustrations. Developers will have more time to focus on important tasks such as writing code, instead of spending extra time scouring search engines, hubs, blogs, and MSDN looking for software APIs.
My proposal is a complete redesign of the navigation and functionality based on filter controls (drop menu) + Subset controls + Hide/show disclosure triangles. The outcome is a complete overhaul to a dated tree model structure and the use of modern web controls. In a world of object-oriented programming, the tree navigation model (Parent/Child nesting) is unintuitive for development, especially when the associated (siblings) APIs drop out of context.
In the proposed new navigation tool, the APIs seamlessly bucket together and vertically grouped. A dev can expand and scroll through every level of the TOC without navigating up or back down – all while using fewer clicks and keeping corollary APIs visible and clickable. I built POC prototypes to present concepts to internal developers to validate the model UI model.
Concepts & Prototypes
Supersets/Subsets: When a filter is selected, the navigation control loads associated namespaces (the primary subset). Then when a namespace is selected, the APIs within that (the secondary subset) are displayed, so that the secondary subset is based on the Primary selection:
1. Namespace – Primary subset
2. Classes/Objects – Secondary subset
3. Members – Tertiary subset
4. Corollary – Additional Reference
Comparison with existing tree UI navigation model: The following diagram shows the current model and the new model side by side. In the current “tree” model, you have to expand parent nodes if you want to see neighboring (aka “corollary”) APIs. The expander must be clicked every time you load a new page. Many developers are unaware that the expander exists; without it, you must navigate up a level (reloading the page) every time you want to see APIs alongside the one you landed on.
Top Customer Pain Points
The current reference section TOC frustrates developers and hinders the development process. As hundreds of APIs continue to come on board, the TOC will grow and the current tree UI model will continue to be cumbersome for developers trying to find specific APIs.
P1 – I need the Dev Center to retain basics about my dev environment
P1 – Show me related classes, properties, and members without losing context
P1 – Context is lost if levels are hidden and neighbors as reference
P1 – I want to sort/filter APIs by language
P2 – Currently fixed page width is restrictive due to lengthy documentation
Developer Feedback Research
1. I wish the Dev Center could retain basics about my dev environment and when I search for content the site should reflect the primary language I use.
2. Need the ability to filter on platform development – I want to see related classes, properties, and members without losing context. The TOC control takes a lot of time to load and find related APIs.
3. Search results are not what’s expected – Searching for an application programming interface (API) often doesn’t land within the top search results. There is a lack of trust due to cross-site navigation doesn’t behave as expected.
I was lucky enough to have a dedicated researcher assigned to understand the developer’s pain points. To begin, I outlined two likely scenarios in the ongoing hunt for the right API.
He’ll first search using keywords in Google until he finds an API that bears a strong resemblance to what he needs. He’ll then forage by browsing reference pages (and all related “See Also” pages) for sibling APIs, to build a mental map of the API surface. Ultimately, Dev 1 wants to be confident that he’s using the optimal, best-matched API for the task. For example, in implementing a flyout menu, Dev 1 reviewed related APIs to check whether the best solution may be a subclass of the API he was looking at.
Then, he’ll learn the API and follow the link from the API page to the applicable code samples, download them, and play with the samples to learn the API space – and confirm he’s indeed found the right API. About 80% of the time, he’ll find what needs to identify the right API and know how to use it, through this strategy.
If he can’t find the right API or class using IntelliSense, he’ll next search his browser bookmarks (via autocomplete), and then search MSDN via Google. He’ll pick the class or function that looks highest-level or most relevant, and browse through the QuickStart, Code Samples, and Guides to understand the API.
If it’s still not clear how the API works, Dev 2 looks harder for code samples. He’ll start with a Samples Gallery search, and if that doesn’t work, he’ll search through a downloaded .zip file of our code samples. If Dev 2 still isn’t sure how to use the API to implement his feature, he’ll try searching Google and/or Stack Overflow more broadly. If he still can’t figure it out, he’ll just abandon implementing the feature. Dev 2 has also abandoned features that are less important to him that would have added polish to his app – such as a neat visual effect or transition – when it’s not clear from the online docs what he needs to know to implement them.
Improve Search – MVP
This section walks through a typical usage scenario for a developer arriving from a search landing (parachuting in) on a deep API reference page, and adding checkboxes to the navigation control to quickly and easily navigate to a different presentation API.
Overview & Scope
Windows store APIs are the backbone of any app and for Windows apps to be successful developers must be able to quickly and easily find relevant APIs, thus improving the app quality and speeding up development time.
Conclusion: Devs are confused by the MS namespaces and finding the correct platform APIs. From developer feedback the AppBar API control uses similar namespaces for two different platforms; devs are frustrated by not being able to quickly pivot to their type of platform from so many languages (VB, XAML, HTML, JS, C, Win32 + DirectX, etc.) when searching.
Developers have a hard time finding relevant code examples quickly, the dev content resources are spread over multiple sites which is virtually impossible to find. App quality suffers due to a lack of needed documentation.