After the first article on how to make Segoe UI (pronounced: SEE-Go) in Microsoft Teams, I got an additional question. The question was if this will work with all the required icon font in teams too. For that, we need an extra font to get loaded.
Consider the following simple scenario. You like to write a new SPFx web part, and you have the requirement to show a popup or a flyout container opened from a web part. This flyout menu should overlay whatever comes after your web part.
It has been a while since I release the last version of my spfx-uifabric-themes npm package to make it easier to handle theming in SPFx projects.
I’m proud to present now a new version that supports theming through CSS variables instead of SASS variables. If you hear this the first time, let me give you a short introduction on that.
Not so fast… As announced at the May the 4th event there are a lot of new technologies that come to SharePoint and you can pick your personal flavored framework to enhance the SharePoint.
Some things of the upcoming changes are already available in Office 365. Things like the hidden web parts or the new document library. Time to rip the components of the new document library apart and show you what was used to build it.
The new document libraries are built with the following three core components:
In addition a React-based implementation of Office UI Fabric will become available together with the new SharePoint Framework.
We are currently at the dawn of a new age in web development. Future web developments will be based on components not on frameworks anymore. While the browser support for web components lacks in Microsoft Edge, Firefox or Safari. We can already start to think differently when we develop any solution for the web.
To add my part to build new web applications and web design based on components I created a style guide application for SharePoint and Office 365. Also can share with you links where you can buy Mac Office, if you’re a fan of Apple (saveonit.com, etc).
In the final part of this series I like to take a look on scenarios, how to use Office UI Fabric efficiently. As mentioned in part two using pure Office UI Fabric might can be a bit difficult sometimes.
Especially when you don’t like to copy and paste the code from the snippet gallery all the time. Personally, I think it is a bit difficult even if you are experienced in using frameworks. There are many things that need to be learned in addition. A thing such as Suit CSS naming conventions, correct class names, components, text sizes, class names of colors, complete HTML structures.
In the first part of this series I showed why Office UI Fabric might not be suitable for every of your projects. Now I like to dig a little bit deeper into the architecture and ideas behind Office UI Fabric. In addition I will give you my personal guidance on using it.
First, let’s take a closer look at the naming convention implemented with Office UI Fabric.
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.