You might have recognised that the workbench of the SharePoint Framework has a responsive design tester included. In this blog post, I take a look what possibilities we have to properly test the responsiveness and the user experience of a web part.
There are also some pitfalls included if you entirely rely on the integrated too.
The modern experience is responsive by default, but it doesn’t mean that your web part will be. Especially with the new team sites and communication sites, the behaviour of web parts is as tricky as it ever was. Office UI Fabric doesn’t help you to achieve a significant user experience because it is out of their scope and offers only smaller components or full-page scoped methods, but nothing in between as needed as in web parts.
The surrounding design of a web part, for example, is defined by Office UI Fabric and even the grid system is provided by that toolkit.
When you write a web part, you might worry more about how the same web part behaves in different containers already defined by the overall page design in SharePoint.
Time to show you a trick how this container pages optimisation is possible in the SharePoint Framework and show the basics.
In Office 365 there is a great mechanism that allows you to implement a corporate wide branding on the suite bar. The customer can apply their logo and their corporate colors there.
On Monday I thought to myself what if I can make the suite bar less distracting than it is. The solid black and blue combination draw a lot of attention on every load while browsing the various portals and applications.
I customized my suite bar in the admin center to have a white background with the logo in the center of the page. All content pages in Office 365 so the white background, I thought, will seamlessly integrate the ribbon on the page instead of standing out.
While working on a responsive design project based on SharePoint 2016. I discovered a nice workaround how to remove the “Read more” tag. Since SharePoint 2013 the collapsed task form is an issue to many customers. It hides by default some important fields of a task and the extra click you have to do is not that nice at all.
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.
Recently Waldek Mastykarz (@waldekm) and I developed a sample for the Office Pattern and Practices. This sample query contact information by using the Microsoft Graph. We also optimism the user interface for mobile use.
While Waldek took care of the technical development of this sample I was responsible for the user experience and user interface design.
It’s easter and let’s hide a small easter egg in SharePoint that will enhance the user experience a little bit.
Microinteractions are small interactions or animations to give a visual feedback to the user. The following graphic explains the base principle of such interaction.
Definition of Microinteractions
A Trigger initiates a microinteractions. The Rules determine what happens, while Feedback lets people know what’s happening. Loops and Modes determine the meta-rules of the microinteraction.
Let me show you a small microinteractions in action by animating the gear icon that can be found in the suite bar of SharePoint.
In the last blog post on how to use the Office UI Fabric table and showed how making the table responsive too. This time I like to show what can be done to make the checkboxes fixed in its position.
Many people recently discovered a new enhancement in Office 365 and especially SharePoint. The suite bar is now responsive if “First Release” option on your tenant is activated.
Responsive Office 365 suite bar rendered on mobile device
The first people that blogged about this responsive improvement were Wesley Hackett and Marc D. Anderson.
The current implementation works well on desktop but not on mobile devices.
Actually the current suite bar lacks of one important thing. The viewport meta tag is currently not implemented in SharePoint or Delve. This tag is responsible to render the page correctly. The display of modern devices has a higher pixel density than the normal desktop computer. The viewport meta tag helps the browser to scale web sites properly. Is this html tag missing in the header of the html document the website will be rendered as a desktop version, but everything is tiny and unreadable unless you pinch and zoom.
If you have a new Lumia 950 for example the pixel density is 314 pixels per inch. Desktop monitor in reality has pixel densities beyond 72 pixels per inch but thus the actual base size your browser renders the web site. All CSS values are calculated based on this.
On mobile devices without a proper viewport meta tag the web site will look like the desktop version, but really tiny and therefore unusable.
This brings us back to the new shiny responsive suite bar. A good example when a web site wasn’t tested on a real device. Works perfectly on a desktop browser but not on mobile. Someone might have forgotten to include the view port on the master page. On my phone, SharePoint will be rendered like this.
Suite bar rendered on mobile device
As mentioned earlier, it is currently only available for first release subscriptions. So currently nothing to worry about. I hope this will be fixed in the final release and we currently see an early beta version of the suite bar.
Where can the problem be spotted. Simply everywhere in Office 365. Here is a detailed list:
Outlook and Calendar use device detection. Some sort of Device channel to work responsive.
The only first an real native responsive apps are currently Sway and blog post on Delve. Both are equipped with a correct viewport.
The new suite bar gives a nice outlook on coming up design features. I expect to see more improvement in the near future. Currently, SharePoint in Office 365 and SharePoint 2016 is built upon XHTML 1.0 and not HTML 5. Once the doctype have been converted an all functions work on HTML5 I guess we will see more adoptions to come out faster and more reliable.
From my perspective the new suite bar is a fast shot. I also have concerns about the usability. On mobile the waffle aka app launcher is hidden behind the three dots in the suite bar. To switch between SharePoint and Mail or Calendar users have to tap twice. This forces to learn user a new behavior because the app launcher was one of the essential improvements recently.
On the tablet devices the app launcher is jumping from left to right. This is actually a no-go. User will get confused. A small resize of the window is enough to show this effect. You don’t even have to be on a tablet device.
If you think about to change the master page of SharePoint to make this work. In Office 365 editing the master page is not recommended to do so. I guess this issue will be fixed by Microsoft sooner or later.
In case of a publishing page SEO meta tag injection can be use to add a proper meta tag. For a javascript based solution to add the viewport meta check out the solution provided on OfficeDev Pattern & Practices.
If you have other concerns, feel free to comment on this blog post.