Article
09/04/2015

April 2013

Volume 28 Number 04

ALM Rangers - A Treasure Hunt Through ALM Readiness

By ALM Rangers | April 2013

In this article,we introduce the sample Windows Store app, ALM Readiness Treasure Map, and share the design, coding and testing experiences of the Visual Studio ALM Rangers in building the app. It’s designed to provide a master catalog of the content available to help developers become proficient in Application Lifecycle Management (ALM) practices. The ALM Rangers are a group of experts who promote collaboration among the Visual Studio product group, Microsoft Services and the Microsoft MVP community by addressing missing functionality, removing adoption blockers, and publishing best practices and guidance based on real-world experiences.

What Did We Do and Why?

We have a confession to make: We love Visual Studio and Visual Studio Team Foundation Server (TFS). Microsoft produces some of the best software development tools available. We’re not just saying that because we work for Microsoft—we felt this way long before joining the company. These suites provide an incredible number of features but can prove daunting to new users. How do developers start learning to use these tools? This question presented itself to us in a slightly different fashion.

ALM Rangers present at TechReady conferences that typically have a number of sessions describing how to improve knowledge of Microsoft development tools. The conferences even hold interactive sessions where participants can provide feedback to the internal groups building these products. We found these to be exciting opportunities for developers and consultants. After joining the ALM Rangers team, we started exploring the published guidance and quickly realized there was a significant amount of content to digest; we were unsure of where to begin studying.

What we really wanted was a resource to help us become proficient in ALM practices. We began building the ALM Readiness Treasure Map Windows Store app to lead users through the materials on their journey to becoming experts. Figure 1 shows you the results of our work. It contains five categories, each with multiple topics of study:

Prepare
Quick intro
Guidance
Tooling
Workshops

Figure 1 The Treasure Map Windows Store App

These areas contain guides, hands-on labs, and videos to make it as easy as possible for users to pick up the skills they need quickly and effectively. Navigating the materials works particularly well on new touch-enabled devices, such as the Microsoft Surface.

To provide the optimal experience, we enlisted the help of an expert UX designer and senior developers to build the app.

The ALM Readiness Treasure Map Solution: UX Design Nuggets

Making a Good First Impression The treasure map tile (see Figure 2) is eye-catching and bright, with an orange background used to symbolize sand. Immediately, the user sees the theme of the app—this is clear because of the palm tree and the path leading to where “X” marks the spot of the treasure. The app title is clearly visible on the tile. Making sure that the tile depicts what your app is actually about creates a good first impression. The last thing you want is for users to open your app and be confused about why they’re using it and how it can help them.

Figure 2 The Treasure Map Windows Store App Tile

We’ve leveraged the splash screen (see Figure 3) to show a bit more of the app’s personality and to help ensure a good launch experience. The treasure map’s splash screen renders an extended path to the treasure, which is a smooth, polished loading experience. It’s uncluttered and straightforward by design, reflecting how the UX will be. In addition, a unique screen can help reinforce the brand.

Figure 3 The Treasure Map Windows Store App Splash Screen

The homepage—the treasure map itself—appears once the app has loaded. Again, our clear, content-focused design immediately confirms the purpose of the app. We wanted to make this page fantastic so the user would want to explore the rest of the app. The homepage is where the journey begins and, at a glance, the user knows this is going to be a journey. The titles are the source for navigation, and because of our “content over chrome” design, they stand out. The app’s content is emphasized by removing any non-functional elements. Anyone looking to find information quickly can find all the links on the screen without having to navigate through the app, which provides a great experience for all types of users.

Sometimes Overlooked, but Crucial The Windows 8 UI uses the principle of a grid system across all its apps. This principle promotes a clean, uncluttered design.

The Treasure Map app employs the grid system everywhere except on the homepage and the result is that content is highly visible—more content, less chrome. This content over chrome principle is one of the more unique principles of the Windows Store app style, where visual unity contributes to a great UX. The homepage is the only page that’s an exception to this rule. We’re portraying a journey and a pirate theme that we wouldn’t have been able to achieve without visual representations.

Typography is sometimes overlooked and many people don’t realize how much it can strengthen the brand of the app. Using fonts correctly and consistently helps achieve clarity and gives a clean, uncluttered look that makes the app easier to read and therefore use. The recommended fonts are Segoe UI (primarily used for UI elements like buttons), Calibri (used for reading and writing, such as in e-mails) and Cambria (for larger blocks of text). We used Segoe UI for all text other than the headers. For those, we used Blackadder ITC to establish a stronger theme (see Figure 4). We do break the font rule here, because we wanted the app’s appearance to be consistent with a paper-based map, as this helps to reinforce the pirate theme. So, in this case, it does work well.

Figure 4 The Typography We Used in the Treasure Map Windows Store App

Seamless and fluid navigation is crucial to provide that ease of use and great UX. Two forms of navigational patterns are recommended: the hierarchical system and the flat system (see Figure 5). The hierarchical system is what most apps use. It’s the most common and will be the most familiar type of navigation to many users. It’s also the best system to create that fluid feel yet still be easy to use. The flat system is used mainly in games, browsers, or document-creation apps, where the user can only go backward and forward at the same hierarchical level. The Treasure Map app uses the hierarchical system, and we believe that it uses it well. The homepage would be classified as the hub, and each section creates the first hierarchical branch, from where each section then creates another hierarchical branch. For example, from the homepage, the user can navigate to the Prepare section, where the user can explore other Prepare subsections.

Figure 5 Recommended Navigational Patterns

Usability It’s important to assess the UX of the app to improve the design so that the app is:

Easy to use
More valuable to users—for example, in the features it can offer
More desirable to use

Assessing your design gives you confidence that the app has an outstanding UX and that users will find it useful, usable and desirable.

So how do we assess the UX of the app? There are many ways to do this, but two common ones are self-assessments and cognitive walkthroughs, as shown in Figure 6.

Figure 6 Assessing the UX of the App

	Self-Assessment	Cognitive Walkthrough
Why	This is based on the goals that you want the user to achieve or find. It ensures that the design is on track with your main intentions.	This is a little more structured around the specific tasks that a user might want to fulfill, for example, to find information about “VM factory tooling and guidance.”
When	It’s a good idea to do self-assessments every sprint, or when each goal has been reached; they last up to 30 minutes.	During the design process, and through every sprint.

There are four success metrics that will help in both the self-assessment of the app as well as the cognitive walkthrough of the app. These are:

Great at: What’s the app great at? What are the focal points of the visuals?
Usable: What should users be able to understand, know or do more successfully because of the app?
Useful: What do you want the users to value?
Desirable: What parts of the app do you want to delight users or make them love?

We used both self-assessments and cognitive walkthroughs. The self-assessments were carried out through each sprint and reviewed at our weekly stand-ups. The cognitive walkthroughs were carried out during the design process and through every sprint. Assessing the UX of our app helped us to understand the desire and emotional connection to experiences that a user may acknowledge.

To sum up UX design:

Make sure that the tile depicts what your app is about.
Create a unique splash screen to reinforce your brand.
Write content with a clear focus.
Use the recommended grid layout to create a simple and clean design.
Don’t forget about typography. Use the recommended fonts where possible, such as Segoe UI, Calibri or Cambria.
Have a clear navigation pattern. Choose from either the hierarchical system or the flat system.
Assess the usability of your app throughout the development cycle.

The Coding Jewels

Before coding started, we set forth a series of coding goals for this project. These goals became the mantra for how we designed and developed the codebase.

Adaptability: Requirements can change, features can be added or cut, and designs can be thrown away in favor of something completely different. Adaptability is the name of the game!
Simplicity: Simplicity is essential for many advantages in software design, in particular for maintainability and fixability.
Testability: Quality assurance must be a high priority for every project, and the codebase must allow for comprehensive and “simple” testing.
Performance and fluidity: The app’s UX must be positive from the start. The app must display information in a timely manner, must always be responding to user input and mustn’t lag.
Team environments: Rarely is an app built by an individual contributor or even an individual team. We made sure that the app was built in a way that could be scaled to many more team members.

So now that we had our goals defined, how in the world did we achieve writing an app in such a short time—working part-time—while not only meeting the functional requirements, but also our non-functional requirements as well? Luckily for us, this wheel has been built before and the construction of our app was a matter of applying proven patterns and practices to our app:

C# and XAML: We decided to use C# and XAML, primarily because the majority of the contributors on this project are familiar with this approach. This includes the languages themselves as well as the tooling and support for them.
Model-View-ViewModel (MVVM): This is a pattern for separating your presentation layer from your business logic from your objects. We chose this particular pattern because the C# and XAML technologies lend themselves very well to it. But more important, with a single pattern, we were able to begin chiseling away at our non-functional requirements. The goals that MVVM most positively affected were adaptability, testability, team environments and simplicity. Adaptability is improved in that you can interchange any of the functional pieces of your app. Perhaps a new presentation for a particular view model has been finished, and you can instantly replace it without changing any other code. Testability is improved because each core functional piece of code is separated into its own individual responsibilities, which means tests can be written against those directly and automated. Team environments are improved because you have a defined set of contracts among the app’s moving parts, allowing teams to work in parallel with one another. Simplicity is improved in that each moving part is its own defined moving part and interacts in a specific way. For more information, see “What’s New in Microsoft Test Manager 2012” at msdn.microsoft.com/magazine/jj618301.
Resources: Following the spirit of MVVM and separation of roles and replaceable parts, we decided to add resources for the definition of our fonts, buttons and other similar design elements. This helped improve team environments, simplicity and adaptability.
But what did we do about performance and fluidity? We followed the async/await pattern for long-running processes. This is one of the areas where developers might struggle in building Windows Store apps, but it doesn’t have to be. Luckily, Windows Store apps using C# and XAML are powered by the Microsoft .NET Framework 4.5, which lets you easily include asynchronous workloads into your app through this pattern. If it’s so easily done, why do folks struggle with it? The answer to this question usually boils down to using logic that’s long-running and isn’t provided out of the box by the .NET Framework. An example of this could be logic to calculate plot points for a chart based on complex mathematics. A full understanding of async and await is crucial for providing a fluid, high-performing app. For more information, see “Async Performance: Understanding the Costs of Async and Await” at msdn.microsoft.com/magazine/hh456402.

Other considerations included:

Touch language: From a development perspective, this couldn’t be any easier. Nearly every out-of-the-box control supports touch in all of the ways that you expect. From a coding perspective, this was the easiest part of the app to build for.
Charms: Interacting with the charms was simple as well. Register these in your appxmanifest and add in the event handlers to each page for the specific charms you want to register, such as Search or Share. We had no issues dealing with charms. They worked well, like a charm should work.
Tiles, splash screens and orientations: All of these were handled in the appxmanifest and then through event hooks in the app at the app level. It was straightforward, and everything is detailed in the sample code.

How It All Really Worked Here’s how things worked out in actual practice:

MVVM commands: MVVM was fantastic in theory. However, in reality, it proved a bit different from the usual Windows Presentation Foundation (WPF) and Silverlight development, particularly for implementing commands, because our old samples didn’t work. Luckily, Command<T> was fairly easy to implement in the new framework and can be seen in our sample app. But our woes didn’t end with commands, because ListViewBase items don’t have an attached command property! We decided to solve this for demonstrational purposes in two ways:

First, we decided to solve this problem using an unused property:

<ListView Grid.Column="2"
          SelectedItem="{Binding Selected,Mode=TwoWay}"

The property to which it’s bound returns “null” and doesn’t throw any exceptions (even if you turn all exceptions on), which is nice, but the key is in the set. In the set, instead of setting anything, we make a navigation call and pass as a parameter the index of the selected item.

Second, we decided to create an attached dependency property of type ICommand. The sample implementation is in the class “ItemClickCommand” within the folder “MVVMSupport.”

Multiple view states lead to massive view files: Our view files became extremely large and more difficult to manage, primarily due to multiple view states. A different layout per view state is generally required, and you could even have different views for different display dimensions or changing dimensions, and so on. Our approach was to split them up into multiple .xaml files, using one .xaml file per view per state. For example, if we had a view called “HomePageView,” we’d have “HomePageView.xaml” inside a full, snapped and filled folder, each one in the folder for its state.
Adapting in the real world: This was a good story. After we had developed the large parts of our app—switching data providers, switching UIs and adding new charm interactions to all of the appropriate places—adapting it to changing requirements became a piece of cake. Issues were easy to track down, and much of the planning paid off because the designers could work in parallel with the developers and the sponsors.

To summarize this section, from a coding standpoint, Windows Store apps are straightforward to develop properly. Following a few predefined rules, mentalities and patterns lets you create a good app quickly. The primary concerns are app view state, app lifecycle state, charm interaction, fluidity and ensuring that you code in a way that allows your design team to iterate designs at will. For more information, see dev.windows.com.

Testing and Verifying Solution Quality

One of the core acceptance requirements we defined from the start was to raise the sample code quality and be part of our overall quality dog-fooding program (see aka.ms/df_tooling). Stringent quality gates for geopolitical, namespace, code analysis and StyleCop (see stylecop.codeplex.com) compliance helped us produce a better solution, albeit only a sample.

Testing should not be an afterthought and is as important with samples as it is with mission-critical solutions. It’s easier to enforce code quality, and to manage user expectations and requirements from the start, rather than be faced with hundreds of compliance bugs and irate testers and have to deal with feature and code churn during a belated quality-improvement cycle.

Because the intention was a quick sample solution, we primarily adopted a “black box” testing strategy focusing on behavior as part of the system and user acceptance testing (UAT). The former was manually performed by the team, focusing on expected features and non-functional requirements, and exploring edge-cases where the internals were understood. The community was invited to assist with the UAT validation, performing exploratory testing based on real-world scenarios and expectations, and unearthing bugs and missing, impractical, and unclear features.

As shown in Figure 7 (with the numerals here corresponding to the red-circled numbers in the figure), we typically used the Microsoft Test Manager exploratory testing feature (1) and the simulator (2) to evaluate the sample solution on a Surface-type device, captured detailed comments (3) and recorded the test session (4) for future reference.

Figure 7 Exploratory Testing

In the future, we’ll seriously consider the definition of more-structured test cases and the use of Microsoft Fakes to help us implement the unit and smoke testing. This will allow us to automatically and continuously validate feature changes and associated code changes.

What’s Next?

We will evolve the ALM Readiness Treasure Map app, and we’re considering an online update feature for the readiness reference assets. For more information, see “Understanding the Visual Studio ALM Rangers” at aka.ms/vsarunderstand; “Visual Studio ALM Ranger Solutions” at aka.ms/vsarsolutions; the ALM Readiness Treasure Map sample code at aka.ms/almtreasure; and the app itself in the Windows Store at aka.ms/vsartmapapp. We welcome your candid feedback and ideas!

Anisha Pindoria is a UX developer consultant with Microsoft Consulting Services in the United Kingdom.

Dave Crook is a developer consultant with Microsoft Consulting Services East Region, where his focus is Visual Studio and Team Foundation Server.

Robert Bernstein is a senior developer with the Microsoft Consulting Services Worldwide Public Sector Cyber Security Team.

Robert MacLean is a software developer nestled in a typical open-plan development office at BBD (bbd.co.za).

Willy-Peter Schaub is a senior program manager with the Visual Studio ALM Rangers at the Microsoft Canada Development Center.

Thanks to the following technical expert for reviewing this article: Patricia Wagner (Microsoft)