Windows (UWP) Designer in Visual Studio and Blend for Visual Studio

If you’ve been looking at the release notes for the Visual Studio previews, you’ll have noted that there’s some work being done on the XAML designer that now supports both WPF and UWP. I figured I would take this opportunity to go through and document some of the features that I use and some of … Continue reading “Windows (UWP) Designer in Visual Studio and Blend for Visual Studio”

If you’ve been looking at the release notes for the Visual Studio previews, you’ll have noted that there’s some work being done on the XAML designer that now supports both WPF and UWP. I figured I would take this opportunity to go through and document some of the features that I use and some of the new features that have appeared in the previews. Note that this isn’t an exhaustive list by any means – would love feedback on what other features you use and what you think is missing in the designer.

One of the reasons that the designer experience in Visual Studio and Blend is so relevant is that you can take the design you’ve done for your Windows app and port it across to iOS, Android, MacOS and even the web (using Web Assembly). All these platforms are available via the Uno platform – If you’re new to the Uno Platform, head over to and get started with building cross-platform mobile, desktop and Web applications.

New Project

Ok, so let’s start by creating ourselves a new Windows (UWP) project based on the Blank App (Universal Windows) template.

As usual, give the project a name to get started – you’ll be prompted to pick which target and minimum versions of Windows you want but for the purpose of this post I just went with the defaults.

Visual Studio Designer

Once created, depending on your setup of Visual Studio, you’ll probably have the MainPage.xaml already open. If not, find MainPage.xaml in the Solution Explorer tool window and double-click it to open it. Here you can see that I have the Toolbox on the left of the design surface and the Properties window, above the Solution Explorer, on the right side. I find this layout works well for working with the designer but you can easily customise the layout of the tool windows to suit how you work.

Design in Blend

We’re actually going to switch across to Blend for Visual Studio for the rest of this post. I prefer to do any designer work in Blend because I prefer to have the tool windows in a different position when doing design work, than when writing code. Switching between Visual Studio and Blend also gives me a mental switch to go between designer mode (well at least “layout-oriented work” mode, since I’m clearly not a designer) and developer mode.

It’s worth noting that the designer experience in Visual Studio and Blend is very similar – Microsoft made the decision years ago to build a consistent experience with the majority of functionality now available in both tools. Blend still retains a number of designer oriented features, such as creating visual states and animations with storyboards, that haven’t been exposed in the Visual Studio designer.

You can easily switch to Blend by right-clicking on the project or a XAML file in Solution Explorer and selecting Design in Blend.

As you can see the tool windows are labeled slightly differently in Blend and have a different default position. Again, feel free to reposition them to suit how you work.


If you look at the main design surface, you’ll note that the initial position of the MainPage is very small. Working at this zoom level will be quite hard as each of the elements will be small and hard to manipulate.

In the bottom left corner of the design surface there’s a series of icon buttons and a dropdown. Expanding the dropdown allows you to select from a number of predefined zoom levels.

Alternatively you can select Fit all, or Fit selection, in order to bring the whole page into view.

The other way that you can control the positioning of the design area is using the mouse:

  • Scroll up/down – Two-finger drag on touch pad, or scroll wheel on mouse
  • Scroll left/right – Hold Shift + Two-finger drag on touch pad, or scroll wheel on mouse
  • Zoom in/out – Hold Ctrl + Two-finger drag on touch pad, or scroll wheel on mouse

Adding Controls with Assets Tool Window

Let’s start to add some controls to the page. We’ll use the Assets tool window to locate the TextBlock control using the search function.

If I just click and drag the TextBlock onto the design surface, Blend will add the control where I drop it.

Objects and Timeline Tool Window

If we take a look at the XAML you’ll note that a very arbitrary margin has been set on the TextBlock

Layout – Reset All

Right-click on the TextBlock in the Objects and Timelines tool window and select Reset All from the Layout menu.

Now the TextBlock has been reposition to take up the whole page.

However because text flows from the top-left, the word TextBlock is in the top left corner of the page.

Edit Style – Apply Resource

Next, let’s increase the size of the text. Instead of manually setting FontSize, we’re going to make use of one of the existing TextBlock styles. Right-click on the TextBlock again in the Objects and Timeline window and select Edit Style, Apply Resource and then we’ll select HeaderTextBockStyle. You can read more about predefined styles and the use of typography here.

This gives our TextBlock a nice size, without hard coding font sizes and styles randomly throughout the application.

Design Surface

Up to now I haven’t given you much context for this app – we’re going to build a simple interface that shows a list of contacts. The TextBlock we’ve added so far will act as a header/title for the page, and then beneath it we’ll need a ListView showing the list of our contacts.

Drawing Grid Rows

Before we can add the ListView, let’s create two rows in the Grid that the TextBlock is sitting in. Select the Grid in the Objects and Timelines window and then on the design surface, if you move the mouse cursor near the edge of the page, you’ll see the cursor change to one that’s got a small plus sign on it. Clicking at this position will add a row to the Grid.

Once added, you can then adjust the sizing of the row. In this scenario we’re going to change the row from 33* to being Auto, which will mean the row will be sized based on the height of the TextBlock.

Reset Grid.RowSpan in Properties Tool Window

One thing you may notice is that after adjusting the row size, the row seems to disappear. This is because in creating the row, Blend decided that the TextBlock was going to span both rows. To fix this, we can change the RowSpan on the TextBlock from 2 to 1 using the Properties tool window.

In this case, we’re going to select the Reset option, rather than setting it explicitly to 1. This will mean one fewer attributes in XAML that needs to be parsed.

Assets Button

Next up, we’re going to add the ListView to the second row. This time, instead of going all the way to the Assets tool window, we’re going to use the dropdown from the chevrons on the top left of the designer. This allows us to easily search and add controls, without having to open the tool windows – when doing a lot of design work I will often hide the tool windows (or even detach them and put them on a different monitor), so not having to open the tool windows to find a control is quite handy.

Runtime Toolbar

After dragging the ListView onto the page and making sure it’s sitting in the second row, I’m going to run the application to see what it looks like. Note that despite me not doing anything, the color of the title bar has aligned with my Windows theme (and yes, it’s pink because I’m using the setting where the theme is derived off the background I have set, which in turn is changed daily using the Dynamic Theme app).

Hot Reload

You’ll also note at the top of the window there is a toolbar that’s been added whilst I’m debugging the application. This toolbar has been available for a while but the Hot Reload indicator is a new addition. Hot Reload allows you to make changes to your XAML and for it to immediately take effect on the page when you save the XAML file (Hot Reload can be configured via Options off the Tools menu).

Display Layout Adorners

I’m going to toggle the Display Layout Adorners button (immediately adjacent to the left of the Hot Reload green tick).

Select Element

Next I’m going to click on the Select Element button (second in from the left) and click on the open space immediately below the TextBlock. As you can see, this highlights the whole area in a light blue (the layout adorner) which is the ListView.

Go to Live Visual Tree

Next I can click on the Go to Live Visual Tree button (first from the left) which will switch back to Visual Studio with the focus being set on the appropriate node in the Live Visual Tree.

XAML Editor

You’ll also note that the corresponding code in the XAML editor has been selected. As I start to type in the XAML editor I get intellisense showing me what options I have.

I’ve gone ahead and set a simple data template for the ListView which will determine what’s displayed for each item in the list. In this case it’s just going to print the word “Hi” for each item.

XAML Highlighting

Note that as I move the cursor around the XAML editor, the matching pairs of XML tags are highlighted, making it easy to see start and end of the blocks of XAML.

DataContext for Data Binding

Currently, despite setting a data template, the ListView isn’t going to show any items because I haven’t connected it to any data. To allow me to continue to layout elements on the page I’ve created some mock, or fake, data.

public class FakeData
    public Contact[] Contacts { get; } = new[]
        new Contact(){Name="Bob Jones",PhoneNumber="+1 442 002 3234", Photo="ms-appx:///Assets/Photos/p0.jpg"},
        new Contact(){Name="Jessica Phelps",PhoneNumber="+1 394 234 1235", Photo="ms-appx:///Assets/Photos/p1.jpg"},
        new Contact(){Name="Andrew Jenkins",PhoneNumber="+1 232 282 29321", Photo="ms-appx:///Assets/Photos/p2.jpg"},
        new Contact(){Name="Francis Davis",PhoneNumber="+1 92329 2923 923", Photo="ms-appx:///Assets/Photos/p3.jpg"},
        new Contact(){Name="Xavier Smith",PhoneNumber="+1 93483 3923423", Photo="ms-appx:///Assets/Photos/p4.jpg"},
        new Contact(){Name="Kevin Chow",PhoneNumber="+1 343 994 39342", Photo="ms-appx:///Assets/Photos/p5.jpg"},
        new Contact(){Name="Phil Stevenson",PhoneNumber="+1 885 367 44432", Photo="ms-appx:///Assets/Photos/p6.jpg"},
        new Contact(){Name="Heath Sales",PhoneNumber="+1 903 912 9392", Photo="ms-appx:///Assets/Photos/p7.jpg"},
        new Contact(){Name="Sarah Wright",PhoneNumber="+1 347 399 499234", Photo="ms-appx:///Assets/Photos/p8.jpg"},
        new Contact(){Name="Geoff Sans",PhoneNumber="+1 834 1232 01923", Photo="ms-appx:///Assets/Photos/p9.jpg"}

I can go ahead and create an instance of the FakeData class as a Resource on the Page. This instance is then set as the DataContext for the root Grid element on the page (and subsequently the DataContext for all elements on the page).

The ItemsSource on the ListView is then data bound to the Contacts property on the FakeData instance. The running application updates immediately to show a list of “Hi” down the screen.

Hide the Runtime Toolbar

As we start to design the page, the toolbar at the top can often get in the way. If you click on the chevron on the right side of the toolbar, the first click will reduce the size of the Hot Reload indicator (removing the words Hot Reload). The second click will minimise the toolbar completely.

Let’s amend the data template for the list, this time data binding to the Name property.

The ListView is immediately looking better, showing the names of the people in the Contacts list.

Edit ListView Item Template

If your working in the designer there are a number of ways you can make changes to the data template for the list. In this example we’re using the dropdown at the top left corner of the design area. Clicking the down button, followed by Edit Additional Template, then Edit Current, then Edit Generated Items (ItemTemplate).

Objects and Timeline – Group Into

You’ll notice that the Objects and Timeline window updates to show the tree from the perspective of the data template. Right-clicking on the TextBlock I can select Group Into, followed by StackPanel, to wrap the TextBlock in a StackPanel.

TextBlock Button

Next, I can add a TextBlock to the newly created StackPanel but simply double-clicking the TextBlock button on the left of the design area.

XAML Suggested Actions

One of the newest additions to the designer is the XAML Suggested Actions. Anyone who’s worked in Word or Excel is familiar with the suggested actions toolbar that often appears to try to make more of the tools are accessible when you need them. in this case we can click on the lightbulb button to display an in-situ property editor.

In this case we’re going to click through to Create Data Binding.

Create Data Binding

From the Create Data Binding window we can traverse down to the PhoneNumber property on the Contact object.

Note that there’s a minor bug at this point because the data binding that’s created isn’t 100% accurate. Instead of data binding to the PhoneNumber property (eg {Binding PhontNumber}) the generated binding is with Contacts.PhoneNumber. Simply removing the “Contacts.” prefix is enough to get it to work.

Edit ColumnDefinitions

I’m going to follow a similar approach to before – select the StackPanel and group into a Grid. From the Properties tool window find the ColumnDefinitions.

Click the … to open the Collection Editor for the ColumnDefinitions. Here we’re going to limit the first column to 50 pixels and then leave the second column as *.

I’ve update the data template with the profile picture as an image. Simply add an Image control and follow the same process as before to setup data binding to the Photo property on the Contact.

WinUI – ProfilePicture Control

To improve the layout of the contacts I’m going to use the ProfilePicture control, which will ensure all the images are the same size.. Instead of using the built in control, I’m going to grab the ProfilePicture control from the WinUI toolkit. Using the nuget package manager, select the Microsoft.UI.Xaml package and install it.

Once you’ve added the nuget package, make sure you don’t ignore the readme file that’s displayed to remind you to include the appropriate runtime values.

We’re almost there, we just need to add the PersonProfile, which we can do by discovering it in the Assets window (even though its from a third party)

And so now we have all our contacts appearing.

Final Design

After applying some minor tweaks to the layout of the data set, we can have a nicer looking sample app.

Before I copied the final code to this post, I just wanted to format the XAML. From the Options window, you can configure how you want your XAML files to appear.

Then, once you have the formatting options the way you want them, you can invoke Format Document from the various places around the design surface.

Final XAML

And here’s the final source code

<Page xmlns=""
        <local:FakeData x:Key="DesignTimeData" />

        <ThemeResource ResourceKey="ApplicationPageBackgroundThemeBrush" />

    <Grid DataContext="{StaticResource DesignTimeData}">
            <RowDefinition Height="Auto" />
            <RowDefinition />
        <TextBlock Margin="16"
                   Style="{StaticResource HeaderTextBlockStyle}" />
        <ListView Grid.Row="1"
                  ItemsSource="{Binding Contacts}">
                    <Grid Margin="8">
                            <ColumnDefinition Width="50" />
                            <ColumnDefinition />
                        <StackPanel Orientation="Vertical"
                            <TextBlock Text="{Binding Name}"
                                       Style="{StaticResource BaseTextBlockStyle}" />
                            <TextBlock Text="{Binding PhoneNumber}"
                                       Style="{StaticResource BodyTextBlockStyle}" />
                        <Custom:PersonPicture Width="50"
                                              ProfilePicture="{Binding Photo}" />

And that’s it – hopefully you’ve learnt a bit more about how to use the XAML editor and the new designer features.

Productivity Musings on App Navigation, Information Density and Work Environment

This morning I set out to explore the most recent ramblings on app navigation. I expected to come across a bunch of designers talking about their sliding, popping, whirling interface. How they are going to radicalize the way we interact with mobile applications. The first thing I was struck with was that I needed to … Continue reading “Productivity Musings on App Navigation, Information Density and Work Environment”

This morning I set out to explore the most recent ramblings on app navigation. I expected to come across a bunch of designers talking about their sliding, popping, whirling interface. How they are going to radicalize the way we interact with mobile applications. The first thing I was struck with was that I needed to get out of my own mobile-centric thought process. I immediately extended my investigation to include desktop, tablet and of course web. After coming across various sites about different navigation constructs, my thought process wandered off. I soon found myself reflecting on some of the design decisions that we live and work with daily. This lead me to some productivity musings that I think generate more questions than answers.

Mobile is Not Desktop

The launch point for my productivity musings was that a couple of the sites reminded me of the panorama and pivot controls from Windows Phone. I think some credit should go to Microsoft’s Metro Modern Fluent (whatever it’s now called) design system. The Panorama and Pivot controls, when done well provided an immersive experience that let users rapidly dig into information.

Fast forward to Windows 8 and Microsoft decides to expand the Windows Phone design system to big-Windows….. #FAIL. We tried. We really did try. And in some cases we produced some amazing applications. However, fundamentally the design system wasn’t designed to scale. The Panorama didn’t have the right information density for a desktop application. One of the reasons that the Mail and Calendar apps for Windows were never able to take on Outlook, is that the information density is just too low.

Stupid Apps

I feel we would be remiss for not chastising Apple for a generation of “stupid apps”. When the iPhone came out, it set about revolutionizing what the world meant when it said smartphone. It was like all the devices prior to it weren’t smart. This simply isn’t true – there were plenty of devices in market that from a functionality perspective were smart. What Apple did was to bring smartphones to the masses. They did that by dumbing it down. Apps did one thing. You could run one App at a time. You can only get Apps from the App Store. There was only one devices that had Apps, the iPhone.

This lead the way for a new breed of developers, “App Developers”. These were developers who were able to string a couple of screens together and call it an app. These developers were in a league of their own. Web and desktop developers looked over and saw “App Developers” making money from apps that did one thing. Ina lot of cases the apps didn’t even do that one thing well, in other words, stupid apps.

Over time the mobile ecosystem has evolved. App Developers have matured and today most app developers build apps for both iOS and Android. Apps themselves have evolved and increased in complexity and sophistication. AI and Machine Learning is being integrated to allow mobile applications to solve a range of tasks. However, despite all this innovation, the majority of mobile apps still do only a small number of functions.

Information Density

As my productivity musings continue, if we look at apps designed for desktop, we can see that they have more functions and much higher information density. Apps such as Word, Excel, VS Code and Photoshop are heavily optimised for mouse and keyboard. As such there is a much high information density, allowing more data to be presented and manipulated on any given screen.

Of course, there’s a trade off between ease of use and information density. Actually, let me correct that somewhat. It’s not necessarily ease of use that decreases with increase information. Rather, it’s the ability for new users to learn an application. Take Excel for example. There are plenty of spreadsheet alternatives out there. I’m continually amazed by the number of people that use Google Sheets. This is because they’ve only ever learnt the first 10% of spreadsheet capabilities. Those that you pick up when you first start using a spreadsheet. Most users barely get past using a spreadsheet as a glorified list making tool. If you look at how spreadsheets are used in finance or engineering, it’s staggering how much data can be calculated, displayed and interpreted on a single screen.

What struck me about the links that I read regarding navigation, is that very few of them deal with high information density. All the designs seem to be focused on building slick interfaces that work well with a single hand, or respond well when the browser is resized. There’s almost no mention of how to deal with complex data sets, or multiple windows, or the learning process for complex applications.

Multiple Windows

At this point, my productivity musings turned towards a pet annoyance, which is the lack of support for multiple windows. Since around the time of Windows 8, it seems that most developers have forgotten that both PC and Mac support applications with multiple windows. Both Apple and Microsoft realise the significance of the window metaphor. Whilst it was Microsoft that adopted the name Windows for the OS, both companies continue to support and evolve the window metaphor.

It should be noted that in Windows 8, Microsoft made a daft move by trying to push apps full screen. How did it make sense to have an operating system called Windows that doesn’t support applications running in a windows? Unfortunately I think the lasting impact of this, coupled with the birth of app developers who knew how to build “stupid apps,” has meant that we’ve had to put up with a host of single-windowed apps.

Take for example this comment from Derik about wanting to pop out an editor window to drag to another screen:

Desktop apps, for both PC and Mac, need to start by thinking in multiple windows. Don’t just make it an after thought.

Window Management

We’re approaching the end of my productivity musings. At this point I went on a slight tangent along the idea of multiple windows and thinking about the way that they’re managed. Both Windows and MacOS have mechanisms for closing, opening, restoring, minimising, splitting windows. However, the one thing I routinely notice among Mac users is that they struggle with basic window management. Perhaps they’ve never bother to spend the time to work out how to manage windows; perhaps it’s harder to do on a Mac. Personally I stick with Windows as that’s where I’m comfortable. If you can’t manage your application windows effectively, that’s on you to learn how to do it.


Moving on from multiple windows we get to multiple monitors. This one is a criticism of companies that choose to invest in finding the right staff but then fail to equip them to do their job. If your staff do work that’s heavily computational, make sure they have a desktop PC or Mac to work on. Regardless of whether you equip them with a desktop or a laptop, when your staff are working at a desk, they need to have at least two external monitors to work on and ideally external mouse and keyboard. You’ll spend a little more up front setting up their work station but you’ll get that back in productivity within the first month, if not the first week!

That’s Not a Mouse!

If you decide that you’re going to supply MacBook or iMac or some other Apple product to your staff, please make sure you do the right thing and buy them a real mouse and keyboard set.

A mouse has more than just a single function. Go get a mouse that will really get the job done.

A keyboard isn’t a work of art. Go get a keyboard that will really make you productive. It doesn’t have to be split like in the following image but it is worth considering split keyboards as they are supposed to be more ergonomic.

Productivity Musings in Summary

This post is a bit of a ramble about the hits and misses of app development. However, it’s worth consider where we are in the software development industry. Are we so focused on the latest technology; the latest hot trend; the latest design metaphor, that we’ve lost the ability to build productivity software?

App Navigation Links

The following are a selection of links that I browsed when investigating some of the latest trends when it comes to navigation within applications. Whilst they’re not strictly a productivity musing, they did form the genesis for this post and I’d recommend taking a read as they may influence how you design the experience of your next application.

Functionality and Usability beats Visual Design and Animations any day of the week!

Functionality and Usability beats Visual Design and Animations any day of the week!

Since Windows 10 was released I’ve periodically opened and attempted to use the Mail and Calendar applications that come preinstalled and in theory provide an integrated experience. As far as UWP applications go, there aren’t many that I look to as great showcases of what the platform is capable of but I figured that Microsoft would invest in their first party applications (there’s also Maps and a few others). It’s taken a few iterations but both Mail and Calendar are actually working quite well – they both support multi-window (although it’s a tad annoying that you can’t tell it to open items in a new window by default), and the UI generally has a lot of polish. However, that’s pretty much where the fairy tale ends.

The reality is that the Mail and Calendar applications are separate applications, and thus when you attempt to do things like “create a meeting from an email”, something that’s a simple drag and drop in Outlook, you are completely out of luck. Further more, despite quite a lot of effort having gone into the visual design, I still find that I’m struggling with basic things like scanning my email and seeing which items are read/unread and which ones I should be focussing on.

I know that these applications aren’t designed as a complete substitute for Outlook but I do wonder who makes the decisions on where the investment in these products is spent. Is there no focus on productivity, or is it just a competition to have the best looking design?

Who broke my messaging app?

Who broke my messaging app?

Prior to the iPhone the majority of applications written were for desktop based devices, whether they be for a Mac or PC, or in some cases both. With the iPhone we saw an entire industry of mobile app development opening up from being a very niche, specialist field, into a field full of imposters who claimed they knew how to build a mobile application, just because they were now able to build and publish an iPhone app. The first generation of iPhone applications weren’t anything special and in fact if you compared the sophistication of most iPhone applications from that era to those being written for other mobile platforms, they were definitely a case of “beauty over brains” – You have to hand it to Apple, as they really did make it easy to build high quality apps that looked great, even if they suffered from a lack of substance.

So hang on, how does this relate to my messaging app? Well, whilst the quality and complexity of mobile applications has increased, one thing that hasn’t is that they are all single window. Due to the screen real estate, mobile application have a single window. With the introduction iPad and other tablets, we saw the use of split screen and master-detail style layouts but even these were all contained within a single window. In the context of a messaging application, whether it be Skype, Messenger, WhatsApp, Twitter etc, the layout is all basically the same – you have a list of contacts and/or groups, you tap into a contact or group and are taken to a chat interface where you can message. In the case of devices with more screen, often the contacts/groups will be listed in a pane on the left or right of the current conversation but in both cases, if you have multiple conversations going, you have to switch between active conversations.

I have nothing against the single window view when working on a mobile device, and I think I’m ok with it on a tablet device but when we graduate to a laptop/desktop we enter a world of inefficiencies and poor user experience. My mobile comes with me virtually everywhere I go but when I’m working, or at home surfing the internet, I’m typically on my laptop (as an aside, I’m running the Surface Book 2 i7 15” and it’s an amazing bit of kit – highly recommend it!). I’ll often have a combination of Messenger, Skype, Teams, LinkedIn and Twitter open and will switch between conversations within each as required. However, typically at any given point in time I’ll be involved in one or two conversations, and it’s really annoying to have to keep switching between these conversations and whatever else I might be doing. For example I might be having a couple of DM conversations on Twitter but at the same time catching up with what’s been happening on my main feed – this means I have to keep switching between conversations, rather than being able to keep them both open at once.

Now I think you can see where I’m going with this – I run an operating system that I think most of you will have heard of…. Windows…. not “Window” but “Windows” <<- plural!!

Why is it that very few modern applications make use of multiple-windows? Well, it’s because of the iPhone – for the last decade app developers (and don’t forget all those app designers who can’t comprehend how an app can use multiple windows) have been building apps that only use one window because building iPhone applications was where the money was, and still is. It doesn’t help that Android apps are also predominately single window.

Let’s go back a few years an look at some user interfaces that have been discarded in favour of the now pathetic single-window messaging app experience:

Do you remember mIRC?

Whilst it was technically one window, it did support having multiple conversations open at the same time using child windows.

Related image

Do you remember MSN/Live Messenger?

It had multiple windows that you could open an arrange how you like. In fact you could force a window to stay on top of everything so it didn’t get obscured by other windows you might be switching between.

Image result for live messenger multi window

So where to from here?

Well the good news is that Windows app developers already have great multi-windowing support out of the box – you just need to build your application to take advantage of it (see

The bad news is that I doubt any of the major messaging services will take advantage of this in the short term, so we’re going to be stuck with a sub-optimal experience. Neither Skype and Teams, both Microsoft products, have any form of multi window support. Messenger still looks like it has been thrown together by some intern at Facebook, so I doubt we’ll see any innovation there. Twitter is a PWA, so I’m not sure how easy it will be for it to take advantage of multiple windows – having said that, as a PWA it can access any of the Windows 10 APIs, so there should be no reason why it can’t spawn additional windows.

Improving the Azure Active Directory Sign-on Experience

Improving the Azure Active Directory Sign-on Experience

I was talking to a customer the other day and had to log into the Azure portal. Normally when I launch the portal I’m already signed in and I’m not prompted but for whatever reason this time I was prompted to authenticate. Doing this in front of the customer lead to three interesting discussions:

– Use of two factor authentication to secure sign in
– Separate global administrator account for primary organisation tenant
– Company branding for Azure AD sign in

Firstly, the use of two factor authentication (TFA) is a must requirement for anyone who is using the Azure portal – if you are an administrator of your organisation, please make sure you enforce this requirement for anyone accessing your tenant/directory/subscription. This applies to staff, contractors, guests etc who might be using your Azure portal or the Office 365 portal. In fact, in this day in age, I would be enforcing two factor authentication for all employees – note that Outlook and Skype for Business are still stuck in the dark-ages and don’t access TFA sign in. For these you’ll need to generate an application password (go to, click on your profile image in top right corner and select “Profile”, click through to “Additional security verification,” click on the “app passwords” tab and then click “Create” to generate an app password.

Ok, next is the use of a separate global administrator account – this is in part tied to the previous point about using TFA. If you’re a global administrator of your tenant and you enable TFA, you won’t be able to generate app passwords. This is essentially forcing you down the path of best practice, which is to have a separate account which is the global administrator for your tenant. If other people in your organisation need administrative permissions, you can do this on a user or role basis within the Azure portal – our preference is to assign permissions to a resource group but there is enough fidelity within the portal to control access at the level you desire.

The other thing we’ve also enforced is that we do not host any Azure resources in our primary tenant (ie in our case Given the importance of Office365 based services we felt it important that we isolate off any resources we create in Azure to make sure they’re completely independent of our primary tenant. The only exception to this is if we are building internal LOB applications (ie only apps for Built to Roam use) – for these we include the app registrations within the tenant so that we can restrict sign in and at the same time deliver a great sign in experience for our employees. For example we’re using Facebook Workplace ( – we configured this within the tenant in Azure AD to allow for a SSO experience.

Now, onto the point of this post – the last thing that came out of signing into the portal in front of the customer was that they were startled when we went to sign into the portal and our company branding appeared. To illustrate, when you first land on the portal sign in page you see:


After entering my email address, the sign in page changes to incorporate the Built to Roam branding


This not only improves the perception (for internal and external users), it also gives everyone a sense of confidence that they’re signing into a legitimate Built to Roam service.

In order to set this up, you need to navigate to the Active Directory node in the Azure portal and click on the Company branding. If you’re using Office 365 you should already have access to this tab. However, if you’re not, you may need to sign up for Active Directory Premium – you can get started using the Premium trial:


Once you’ve opened the Company branding tab (if you have just activated the trial, you may need to wait a few minutes and/or sign out and back in again in order for the Company branding tab to open) you can click on the link to “Configure company branding now”


There are a number of options and images that you can configure:


After saving the changes, if you attempt to sign in, you’ll notice the new images/colours etc appear. In this case, you can see that the welcome text at the bottom of the sign in page has been changed to what I entered in the company branding tab. Unfortunately because I didn’t set the sign in page image, the default is used, so you can’t see the red (#FF0000) background I set – you can see glimpses of it if you resize the page. This can be fixed by simply uploading a transparent image.


The ability to customise the sign in experience is just one way to improve the experience for you staff and customers.

Dynamic Layout with the Windows Platform

Dynamic Layout with the Windows Platform

Today there have been a number of announcements in regards to the Windows 10 universal app platform, including the availability of the tools preview:

Microsoft have been talking for quite some time about Windows 10 being a single platform that developers can target and have applications run across a multitude of different devices ranging from phone, to slate/tablet, to desktop and even up to Xbox and Surface Hub. This has in part been achievable to a less degree with previous iterations of the framework and as developers we’ve learnt to maximise the reuse along the way. However, for the first time a single executable will run across all devices without recompile. Is this the nirvana that we’ve all been looking for? Here are a couple of things to consider:

– There are still going to be device differences – whilst the core will be common, there are extension sdks for different platforms. Developers will have to query for the existence of contracts before invoking specific extension methods.

– Previously there was a forced break between phone and full screen (ignoring split mode) tablet/desktop, which was convenient for designers. Windows 10 introduces a significant challenge for designers as they have to scale up/down the user experience to handle all manner of sizes and shapes.

– The restricted form factors of the past lead themselves well to a page based navigation, although the page sequence often differed between Windows Phone and Windows. With Windows 10 the page based navigation model doesn’t lend itself well to resizing and adapting to different screen sizes.

The last point is worth expanding on. When an application is resized down to the size of a phone the experience should be similar to a phone application where navigation appears to be page based, including a back button to navigate back between pages. As the application is resized up, initially it would be acceptable to simply scale the size or amount of content being shown. However, at some point there is too much screen real estate available which is either being wasted (voids of empty space) or content is oversized (assuming content continues to scale). Now a different approach is required which will involve presenting more content on the screen. This additional content, which may have been on a different page when on the phone or smaller layout, now needs to be rendered on the same page – this completely breaks the page lifecycle model that most applications are based on, leading to an open question as to how best to handle resizing of applications?

Breaking up the User Experience to Allow for Reuse across Windows and Windows Phone

Breaking up the User Experience to Allow for Reuse across Windows and Windows Phone

Last post I talked about the basic flow of the Real Estate Inspector application (overly simplified of course as it’s a sample application) and I eluded to the need to have a different user experience for different form factors and to allow the user experience to adapt as screen size varies. This problem is going to escalate as we go into the Windows 10 timeframe where a single application will need to deal with a number of different form factors.

The first page to deal with is the login page – the big difference here is that on Windows Phone it’ll be a separate page, whereas on a larger screen it’ll be displayed as a modal style dialog across the current page. In both cases the login page/view will double up as a profile page for the currently signed in user, as well as perhaps any settings that may apply to the current user. Either way this is going to be a simple view that doesn’t need to vary substantially between form factors.

The main page of the application is relatively straight forward as it will simply show the properties that the user has access to. The only difference might be that when the display is portrait (ie similar ratio to a typical phone) the properties could be in a list, whereas when there is more screen real estate the properties can be expanded into a tile array. One of the issues associated with tile array is that there isn’t an implied order; well this isn’t quite true but it’s harder for the user to know whether the order is across-then-down, or down-then-across, at least until they attempt to scroll the screen and then it becomes easier to follow. Luckily in this case the properties aren’t in any particular order.

image  image

If we did decide that properties needed to be ordered, we might adopt a layout similar to the new Photos app on Windows 10 where it uses vertical grouping to imply some level of ordering. For example properties could be order by suburb, or could be ordered by upcoming inspection times (date or week groupings)


Now comes the hard part – what does the Property page look like. A Property has both details of the Property itself, as well as a list of inspections that have been carried out. Each inspection will then have to be made up of any number of rooms/areas where inspection information needs to be recorded. The experience on the phone might be:

– User clicks on a Property on the main page

– Property is displayed in a pivot with the details making up any number of pivot items, and the list of inspections being on a separate pivot item.

– Clicking an inspection opens up the inspection, showing a summary of the inspection (eg who did the inspection and date/time) and then a list of inspection rooms/areas – this again could be a pivot

– The inspection room/area would be a simple page made up of a number of form fields.

This layout also works well on tablet/desktop when the application has been reduced to a rough 16:9 portrait layout. However, here’s where things start to get more complex – as the screen size and orientation changes the challenge is how best to use the available real estate. The following image illustrates how expanding the page width or height can lead to unused screen space. I’m not implying you always have to make use of every bit of screen real estate but you also don’t want your application to feel like it is wasting screen space.


Starting with the tiled layout on the main screen, if the user taps on one of the Properties there are really three options:

– There is enough space to present a vertical list of Properties, Property details and list of Inspections as three columns

– There is enough space to present a horizontal grid of Properties (1 or two deep), with Property details and list of inspections as two columns under

– There isn’t enough space to present the list of Properties, in which case only the Property details are displayed, along with a Back button to allow for navigation back to the list of Properties.

Here you can see the break down of the developer experience already – we have three distinct user experiences, two of which are done on the same page, whilst the third would normally involve a page navigation (similar to what would happen on the phone).

The complexity escalates even further when you consider that the user might decide to dynamically resize the layout, going from just Property details out vertically where the grid of properties appear at the top, and then horizontally where the list of properties re-orientates to a vertical list, making better use of the screen size. I don’t see an easy way to deal with this dynamic resize operations given the relatively primitive controls the Windows platform offers out of the box.

View Models for Split Frame Windows

View Models for Split Frame Windows

In my previous post I talked about adapting the application UX for varying screen size. Currently the navigation model relies on a one to one mapping between pages and view models. However, with the need to support a split screen (eg list on left, details on right) and to continue to support the List/Details page model without too much rework, I need a mechanism for supporting multiple view models. The simplest approach is to again match what I did with the UI layer – the ListAndDetailsPage would have its own view model eg ListAndDetailsViewModel which would contain references to instances of the ListViewModel and DetailsViewModel (these would typically be used to match the ListPage and DetailsPage).

This approach could be taken a step further by having separate view models for the ListControl and DetailsControl – these could be based on a different base view model as they would only ever be created as child view models (ie you can’t navigate to them). In the coming posts I’m going to look at the layout of the real estate inspector sample app and build out the UX using this approach.

Navigation, View Models, Pages, Frames and Universal Windows Applications

Navigation, View Models, Pages, Frames and Universal Windows Applications

Over the past couple of month Microsoft has been laying the groundwork to get developers excited about the upcoming universal application model that will ship with Windows 10. The promise of a single executable that will just run anywhere seems to be the holy grail. However, just because an application will run anywhere, on any devices, doesn’t mean that the user experience is optimized. Take for example a simple list-details windows phone application which presents a list of items, which, when an item is tapped, navigates to a new page with the details of the item. On a desktop with a large screen it doesn’t make sense to navigate to a separate page in order to display the details of the item. Instead, the screen can be split with the list on the left and the details of the selected item displayed on the right.

The simple app navigation model I discussed previously assumes simple navigation between view models, and thus between pages on the Windows platform. However, it’s not that simple; as we just saw instead of navigating to a new page, the selected item is presented in full on the right side. This means we need to contemplate a more complex set of navigation rules, allowing for different navigation paths through the application dependent on available screen real estate. In fact to handle the scenario with a list on the left and details on the right, it may be necessary to consider sub-views with corresponding sub view-models.

Taking this example, let’s assume that we start off with two pages: ListPage and DetailsPage. When we have more space we want to extend the ListPage to include details for the selected item. It doesn’t make sense to duplicate the layout, which would result in a maintenance headache. Instead what we can do is to start extracting portions of the UI into usercontrols that can be reused. For example we might have ListControl, which displays the list of items, and DetailsControl, which not surprisingly displays the details of the item. Clearly these map to the existing ListPage and DetailsPage but now in the case of larger screens we have two options: we can either add the DetailsControl to the ListPage so that, space permitting, the details can be displayed on the right; or, we can create a completely different ListAndDetailsPage which as you’d imagine has both the ListControl and DetailsControl. Now a distinction could be made between phone and desktop platforms to navigate to the appropriate page.

The last challenge is how to handle resizing Windows – in Windows 8/8.1 this problem didn’t really exist. Well it did if you included snap/split mode but very few developers really went to any lengths to refactor their UX and it really only resized the display width-wise. In Windows 10, users will be able to more dynamically adjust the size of the Window and it is up to us application developers/designers to determine how the application behaves. Take the list-details example – with a minimal window, the application should almost mirror the UX of the phone. However, since we have the ListAndDetailsPage the UX will have to adjust the layout, rather than simply navigating to a new page.

There’s clearly a lot to think about and the holy grail of a single application is still going to take a lot of refinement to get right – time to find yourself a great UX person to add to the team!

Getting Started with Design for Windows, Windows Phone, iOS and Android

Getting Started with Design for Windows, Windows Phone, iOS and Android

Here’s a summary of some of the design guidelines for the various mobile platforms:

Windows Phone





Another great resource on user experience design is the UX Mastery website

In particular the book Everyday UX is worth purchasing: