0 comment

Why not use Office UI Fabric? – Part 1

This question Waldek and I had to answer a couple times after the Mobile Quick Contact PnP sample has been released. There are several good reasons to use Office UI Fabric but there are also some scenarios currently not well covered. While the last blog post was more on how we built it, this tells more the story why we haven’t chosen Office UI Fabric.
Right after I started to write this blog post I noticed the overall considerations might be broader then cover it in a single blog post. I decided to split this single blog post into the following three chapters.

First, let’s take a look at the reasons why we haven’t used it in our sample.

The user experience perspective

Before you start to design or sketch an application. Sit down for a moment close your code editor, design tools and think how the user should interact with your application.
This decision also should be made apart from frameworks, code and ready-made design elements. Design in general is not to make something look pretty. It is about problem solving.
The first step in this process is to search for references how others solved the problem first and how you can improve this solution.
In our case the goal was simple. We wanted to create a contact application that consumes the results of a Microsoft Graph query. The main inspiration actually came from already existing phone book applications built in any phone. So we sketched out the contact card and all the interactions first.

Our Contact Card

The contact card, we built in this sample was tailor-made for several reasons.
Regular contact application of phones has a separate list view and a detail page to show additional information.
In our case I wanted to display the contact details directly in the context of the search result. This provides a faster switching between different contacts. The result that was provided by the Microsoft Graph already contained the required information.
The change between list and detail view was implemented through a simple CSS3 transitions. The animation was triggered by adding and removing a class.

Office UI Fabric Sample

Office UI Fabric Sample

In addition to this I wanted to create some sort of quick action that allows to start a call or other actions directly from the list view. The goal: “Keep is simple, stupid” (KISS).

Office UI Fabric – Contact cards

Office UI Fabric provides contact cards to render the list items and a detail view, but using them might be tricky.

Office UI Fabric Persona Cards

Office UI Fabric Persona Cards

There are several different variants available of those items. Some have squared profile images and some use circles as profile image. Currently the information in Office UI Fabric when to use which kind of persona card is unknow. Choosing by favor might cause inconsistency in the user interface.
In addition the persona items don’t state what size works best on mobile, tablet or desktop scenarios. In responsive scenarios normally one size fits all and defined by context the size changes. When you take a closer look you will might find some UI elements that currently are too small on touch devices.
Office UI Fabric serves a great vocabulary of the Office Design language. The grammer to speak that design language is currently something missing. It would be great to see more on the user experinece ideas and considerations in future.

Office UI – Transition between list and detail view

As mentions in our card design we used an easy pattern to transition between list item and detail view.
In case of Office UI Fabric to accomplish the same behavior the HTML structure of the list item and detail view needed to be rewritten each time the state changes.
It would have been possible, but can be more error prone. To provide the same smooth transition additional JavaScript would have been required.
Let’s take a closer look at the persona cards and how they work on a mobile device. Let’s assume I’m in a hurry and like to view all available information of a contact. In case of the persona cards the information is hidden behind tabbed controls. To access additional information to a contact each tab needs to be selected individually.

The Search Box

The search box pattern was defined to have a fixed width of 180px. To support responsive scenarios the search box should always use the size of the parent container. This makes sure that it scales properly across different devices.

Office UI Search Box

Office UI Search Box

In addition, currently a search button is missing. To execute a search or query against the Office Graph the user needs to press the ‘Enter’-Key or the ‘Go’-button on the keyboard of the device. To have such behavior is nice to have but at least an equivalent button on the user interface should be provided.

Final thoughts

I really like Office UI Fabric and we used a lot inspiration for our sample from this toolkit. It is a really valuable resource for custom development when you like to provide a consistent look and feel to Office Applications. This toolkit is definitely something for the future, but for our sample application, it had only limited support. Especially when the application requires a custom additional user experience it is hard to accomplish. Office UI Fabric work currently best for custom Office add-in. It perfectly integrates with the user interface of every Office application and allows much faster development for such kind of applications.
In our case the challenge was to build custom standalone application that consumes Microsoft Graph and is optimized for mobile use. The overall CSS was only 6 kilobytes small. Beside the fact that the same user experience would have been much harder to accomplish, the size of CSS file would have been much larger when Office UI Fabric has been used.
Stay tuned for the next blog post. Next I will take a look on additional architectural consideration to use Office UI Fabric efficiently.