App Analytics – Dev Portal
After completing the development platform, I was moved to the App Analytics team. The Developer Platform needs a way to measure App Analytics, and I was responsible for designing the first App Analytics application journeys. The team wanted the App data to be transparent so marketers could see their application’s success.
App Analytics – Pivot Pages
I shipped all the supporting analytics pages in less than a year. The platform has various key App analytics pages, including Downloads, Usage, Purchases, Conversions, In-app Purchases, Financials, App Quality, and In-App Advertising. 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 locales.
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 was dated technology. I partnered with a dev 1:1 to update the dated loading spinner with the new Windows 8 (OS) operating system loading spinner. Millions of people have seen the Windows 8 loading spinner for the web at one time.
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 digitally reimagine every customer touchpoint for the Windows OS and Web Apps to modernize those experiences. The entire Windows Design Organization was responsible for introducing the Windows 8 Design Principles and Metro Design Language as the foundational building blocks for modernizing the Windows ecosystem.
App Analytics – The Beginning
After designing and shipping the app developer platform, I created the initial style guide for all histogram charts, including Line, Area, Bar, and Pie charts, to be used across the platform.
Design Challenge
When I joined the Windows Store Dev Portal, an India Development Center (IDC) product manager presented me with a PowerPoint concept deck showing the dashboard and described the vision. I spent the next few years art directing and influencing product decisions while working with the offshore team. The other change was having to refactor the systems library UI kit. At that time, Microsoft didn’t have any prebuilt react component libraries. We had to build the systems library besides building the technology. Luckily has already worked on the framework 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.
Navigation starts with the Superset/Subset filter controls. A drop-down menu is used for the Platform, and the other is for the Presentation model. The initial version will include the Windows 8 App platform using the following presentation models JavaScript, HTML5, XAML, and DirectX.
Conceptual Overview
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 Research Feedback
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.
On-Premise Field Research
I was lucky enough to have a dedicated researcher assigned to understand the developer’s pain points. First, I outlined two likely scenarios in the ongoing search for the proper API.
Developer 1 needs to identify and learn the right JavaScript API to accomplish a specific development task. He starts by investigating which API is right for his needs.
He’ll first search using keywords in Google until he finds an API that strongly resembles 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 fly-out 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.
Developer 2 starts by finding the right class/API. When he isn’t sure what JavaScript API or class to use, he’ll start by typing stuff into Visual Studio to see whether IntelliSense helps him find it. But often, it just gives a list of every object available – this doesn’t help him.
If he can’t find the proper 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 unclear 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 isn’t sure how to use the API to implement his feature, he’ll try searching Google and/or Stack Overflow more broadly. He’ll abandon implementing the feature if he still can’t figure it out. Dev 2 has also abandoned less essential features that would have added improvements to his app – such as a neat visual effect or transition – when it’s unclear from the online docs what he needs to know to implement them.
Improve Search – MVP
This section describes 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. For Windows apps to be successful, developers must be able to quickly and easily find relevant APIs, thus improving app quality and speeding up development time.
Research: 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. Research validated that developers are confused by the MS namespaces and are not finding the appropriate APIs for their application.
Hypothesis: Developers have difficulty finding relevant code examples quickly. The dev content resources are spread over multiple sites, making it virtually impossible to find them. App quality suffers due to a lack of needed documentation. Plus, Windows has numerous dated support systems.
