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.
- Why it was not suitable for our sample (this one)
- Architectural view on using Office UI Fabric
- Scenarios and solutions to use Office UI Fabric
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.
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
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.
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.
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.
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.