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.

Multi-Monitor

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 https://docs.microsoft.com/en-us/windows/uwp/design/layout/show-multiple-views).

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 https://myapps.microsoft.com, 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 builttoroam.com). 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 builttoroam.com 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 (https://workplace.fb.com/) – we configured this within the builttoroam.com 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:

image

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

image

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:

image

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”

image

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

image

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.

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:

http://channel9.msdn.com/Shows/Inside-Windows-Platform/A-First-Look-at-Building-Windows-10-Universal-Applications

http://blogs.windows.com/buildingapps/2015/03/23/windows-10-developer-tooling-preview-now-available-to-windows-insiders/

http://www.microsoftvirtualacademy.com/training-courses/a-developers-guide-to-windows-10-preview

http://dev.windows.com/en-us/whats-new-windows-10-dev-preview

http://microsoft.github.io/windows/

http://blogs.msdn.com/b/somasegar/archive/2015/03/23/visual-studio-tools-for-windows-10-technical-preview.aspx

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)

image

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.

image

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
http://developer.windowsphone.com/en-us/design

Windows
http://msdn.microsoft.com/en-au/windows/apps/hh779072.aspx

Android
http://developer.android.com/design/index.html

iOS
https://developer.apple.com/library/ios/design/index.html

 

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

http://uxmastery.com/

In particular the book Everyday UX is worth purchasing:

http://uxmastery.com/everyday-ux-remarkable-people-telling-their-stories/