Redefining the intranet site experience with SharePoint in Office 365
At Microsoft Core Services Engineering and Operations (CSEO), we’re responsible for providing and maintaining the infrastructure and technology that enables effective collaboration throughout the intranet for over 200,000 Microsoft users. Our primary platform for content-driven collaboration is SharePoint for Office 365 and its ability to integrate with the rest of the Office 365 suite provides immediate integration into our cloud environment.
Recent advances in SharePoint have dramatically improved the quality, accessibility, performance, and usability of the platform for our users and publishers. New features—like communication sites, SharePoint hub sites, and modern groups—are now combined with foundational elements—like the user profile store, search, and taxonomy—to build the backbone of the Microsoft intranet.
Improvements in the platform, new development capabilities enabled by the SharePoint Framework (SPFx), and client-side web parts mean that it’s never been easier for us to develop and publish attractive, highly functional intranet sites. In less than a year since we started using communication sites internally, more than 55 percent of our internal publishing sites have switched over to communication sites in SharePoint for Office 365. And it’s all accessible from your pocket by using the SharePoint mobile app.
The SharePoint landscape at Microsoft
SharePoint has been the primary collaboration platform for our intranet and extranet solutions that have served our users for years. SharePoint has been our default platform for intranet sites at CSEO since building our first corporate communications portal in 2003. Historically, we hosted on-premises SharePoint Server infrastructure in our on-premises datacenters and perimeter networks, but since the internal rollout of SharePoint Online in 2011, we’ve gradually converted all our major sites for internal functions such as HR, Finance, Communications, Sales, and Learning to run in the cloud on SharePoint Online.
Traditional design and deployment
For years, SharePoint was designed to provide a robust platform on which interesting sites could be built. Although powerful, the default sites had some shortcomings:
- The default site template was very non-descript and basic. If our developers wanted to build an attractive site, they had to go above and beyond the default template. This meant customization and extra work for developers and an extra step in the publishing process.
- Sites were not responsive by default. The traditional site types were designed for a PC browser, and the mobile rendering of traditional sites often produced unattractive or partially non-functional results on mobile devices.
- Sites were not accessible by default. Accessibility in the default templates wasn’t up to the standards we wanted. Our intranet sites didn’t provide proper interaction with tools like screen readers or high-contrast color schemes by default. It took design and developer effort on each site to make it accessible.
To mitigate some of these challenges, CSEO engineering teams developed SharePoint site design packages that gave site owners a head-start on building an attractive, useful, accessible, and responsive site experience. By applying site designs, we could jumpstart the build process while saving businesses time and development budget. The site designs were effective, but they required ongoing development and maintenance.
Our move to the cloud
Microsoft has been a cloud-default organization since 2015. Our organization runs on cloud computing—that’s reflected in how we’ve treated our SharePoint infrastructure. We’ve moved our SharePoint infrastructure out of our on-premises datacenters and into Microsoft Azure and Office 365 to take advantage of cloud agility, scalability, and reliability across our IT infrastructure.
Cloud-based collaboration provides several basic advantages to our organizations:
- All sites and tools are in one service, from one vendor.
- Personal and business sites are all within the same administrative and functional scope.
- All sites are designed, developed, and managed with the same toolset and in the same environment.
Hybrid cloud content management
Our current environment is still hybrid by design, but the vast majority of our SharePoint infrastructure is cloud-based. There are several reasons we retain data and apps in the on-premises environment, including:
- Keeping content in a geographic region to meet regulatory requirements.
- Maintaining functionality with older business information systems and apps.
- Keeping highly customized content that needs further development or re-structuring before being migrated to the cloud.
The majority of our SharePoint infrastructure runs on the cloud.
Enabling self-service and creative collaboration
Our primary goal in our move to the cloud and adoption of SharePoint Online is to create an environment where our users can embrace creative collaboration and feel empowered to do so in the best way for them. Our move to the cloud has enabled a greater level of self-service for our users, and as we move toward the modern SharePoint experience, our self-services capabilities and creative collaboration opportunities are increasing.
As part of our governance and security procedures, we manage site creation capabilities very closely. With SharePoint Online, we can let our users create and administer their own sites, determine what kind of sites they can create, and specify the location of the sites.
The journey to modern SharePoint sites
SharePoint Online has continued to evolve into a complete and modern collaborative tool, and we’re using the latest features of SharePoint Online to drive collaboration and a better user experience across all our sites.
Our move to modern sites
For Microsoft, moving to modern sites means putting greater capabilities into our users’ hands while removing the traditional IT barriers to a truly self-service and user-friendly SharePoint experience. With SharePoint Online, we now enable user experiences that:
- Are accessible by default. Modern sites offer built-in support for ideal color contrast, alternative text, and other features that make them accessible to as many of our users as possible.
- Are responsive by default. Modern sites are designed to accommodate a wide range of devices and platforms, so that they’re attractive and useful—regardless of how our users access them.
- Are attractive without needing a power user or developer. Modern sites are simple to design and deploy. We don’t need to enlist developers or additional IT support to get our sites up and running the way we want them.
- Enable our self-service culture. Any user can create a useful, attractive, responsive site without requiring services from IT or a developer
The following screenshots are examples of SharePoint team sites, both classic and modern.
Figure 1. Default team site experience, classic sites versus modern sites
Communication sites and site designs
We’re using communication sites in SharePoint Online as the default building block for sites that host our major internal business functions going forward. Communication sites provide a great place to share information with others. We can share news, reports, statuses, and other information in a visually compelling format. Communication sites use the modern SharePoint template and the modern user interface, which we enable at the tenant level wherever possible. Site designs offer some major benefits to the sites that use them and the content creators that are working with the sites:
- Sites are accessible by default. Accessibility is built into communication sites and site designs, so developers don’t have to spend extra time ensuring compliance with accessibility feature requirements.
- Sites are responsive by default. Similar to accessibility, communication sites and site designs are responsive by default, so our developers don’t have to spend extra time on coding a responsive site.
- Look and feel is consistent and attractive throughout a collection of sites. Modern templates offer an attractive design out of the box. The connection of hub sites for navigation, design, and look and feel mean that it’s much easier to maintain an attractive and consistent user experience throughout our sites.
- Site and page design requires less developer time. This benefit is huge for us. The design and implementation process for a modern site is much simpler than before. Our users have been creating their own sites and content at a far greater rate than before, which means our developers don’t need to be engaged for as many site design and creation tasks, freeing them to focus on core development tasks that are vital to SharePoint operations.
The following screenshot shows the default SharePoint communications site template.
Figure 2. The SharePoint communication site default template
SharePoint Framework web parts
We’re using the SharePoint Framework (SPFx) to create web parts and pages across all our SharePoint installations. SPFx provides an open development model, so our engineers can design content that works well with SharePoint in Office 365 sites and sites that are still using previous versions of SharePoint. SPFx web parts and pages can be used in an older portal site—when the site is migrated to SharePoint in Office 365, it can be brought across as-is. There’s no need to re-learn, re-train, or re-write.
Embracing an agnostic, open platform
SPFx is also platform agnostic, which is a huge advantage for us. We can have our best engineers developing for SharePoint regardless of their preferred development platform. They don’t have to learn a new integrated development environment (IDE) or toolset—they can simply use what they’re most comfortable with.
SharePoint Framework web parts provide several specific development advantages, including:
- It runs in the context of the current user and connection in the browser.
- The controls are responsive and accessible by nature.
- It is framework-agnostic.
- Performance is reliable.
- End users can use SPFx client-side solutions on all sites, including self-service team, group, or personal sites.
- SPFx web parts can be added to both classic and modern pages.
- The biggest tangible benefits that the SharePoint Framework web parts brought to us are that we’ve saved both money and time. Specifically:
- When we need a web part, nearly every web developer can now be a SharePoint developer with limited ramping up of skills needed.
- Common patterns used across the internet work in the SharePoint world saving a lot of time in building our solutions from scratch.
Using SharePoint hub sites, we maintain a hierarchical structure and carry design elements across related sites. Hub sites help us meet the needs of our organization by connecting and organizing sites based on project, department, division, region, or other factors. This makes it easier for our employees to:
- Discover related content, such as news and other site activities.
- Apply common navigation and branding across associated sites.
- Search across all associated sites.
- Aggregate news content across all sites.
To achieve these results, we’re using a couple features of hub sites:
- Shared navigation. Hub sites are connected back to the parent site with the hub site navigation bar. It provides comprehensive navigation across a set of hub sites. We frequently customize the hub site navigation bar to fit the specific needs of each hub.
- Search across the hub. Content on a hub site and any of its associated sites are returned in the search results and users see only the content to which they have access.
The following graphic shows an example hub site that’s built around a major business function—in this case, Human Resources (HR).
Figure 3. An example of a hub site built around a major business function such as HR
Building intranet sites on a reliable and agile foundation
Our approach to modern design and functionality in SharePoint Online is dependent on a number of foundational features and functions within SharePoint Online and the greater Office 365 landscape. We’re taking advantage of several aspects of modern SharePoint functionality to make the intranet site experience even better for our users.
Personalizing the experience with the user profile store
The user profile store is a repository that contains user data that can be used to power workflows or customize the content that’s displayed to end users. There are three sources for the data found in the user profile store:
- Azure Active Directory (Azure AD). Azure AD is the default directory source for data in the user profile store. By default, 24 Azure AD account attributes are imported to the user profile store.
- User-supplied data. All licensed users can provide data from their Delve user profile page, which stores its data in Azure AD.
- Bulk import API. Most powerfully for our internal sites, we’re also using the bulk import API to populate an additional 30 attributes of user profile information from internal HR and retail store data sources into the user profile store. The imported attributes are a combination of both raw data (such as the store number that a retail employee works in) and calculated data (such as which top-level organizational manager a user reports up to in the org chart). With this, we can ensure that all the user data that’s relevant to our organization is in one place for SharePoint Online to access.
Creating new attributes with calculated data fields
SharePoint Online provides the ability to create calculated fields within the user profile store. With calculated fields, we can combine fields or perform logical and mathematical operations on one or more fields to create data that isn’t otherwise represented in the user profile store.
Using audience targeting
The user profile store gives us the opportunity to use audience targeting features for our SharePoint sites to ensure that our users are getting the most relevant and necessary content. Audience targeting helps us to deliver the most applicable and current content, improve search and taxonomy, and provide a better sense of how and how much our users are consuming content. Some examples include:
- We can use an attribute in the store that contains the date a user started with Microsoft to determine whether they should be considered a new user. Based on this, we can provide tutorial content on certain pages, provide new hire task lists for certain sites, and make sure the user is exposed to exactly the information on our sites that a new user would want to see.
- We can use calculated fields to create a field that combines a user’s region with their department to direct them to relevant workshops or training opportunities in their region.
The following screenshots show how we use region-based content targeting for an internal site.
MSWeb as it appears to a user in Redmond
MSWeb as it appears to a user in Australia
Figure 4. Region-based content targeting on the Microsoft internal Corporate Communications portal, MSWeb. Users in different regions see different top stories and highlights.
The modern SharePoint site enlists comprehensive aggregation for search. When connecting sites together and implementing hub sites, search for hub sites aggregates to the parent site—this provides an aggregation of content that can be organized to best fit our needs.
Learning from our migration
Enabling modern SharePoint as the default platform within our Office 365 tenants for new sites was a straightforward process, but more consideration needed to be given to existing sites that weren’t using the modern design. Migration of these sites was examined on a site-by-site basis. Our tenancies contain thousands of site collections, and we needed to determine which sites were good candidates for immediate migration and which ones required more preparation before migration was an option.
Our migration approach
In planning for our migration, the user experience took precedence. We wanted our migration tasks to provide the environment that would best facilitate the best collaborative experience for our users and interfere as little as possible with that experience. The first part of the migration was establishing the best candidates for migration and how we would facilitate migration.
Using the SharePoint Framework in migration
The SharePoint Framework foundation was critical in allowing us to provide a firm cutover point for using the modern interface and communication sites as the defaults for our sites. Because SPFx is backward-compatible, web parts created using SPFx could be used in sites that aren’t built on the site design or converted to the modern user interface. We didn’t need to lose any creation time keeping legacy sites current before migration. When we needed a new web part in a legacy site, we simply used SPFx and brought over the web part when the migration occurred. Because of this, we were able to establish SPFx web parts as the default before we migrated a single site and many of the web parts that required changes were moved to SPFx while still in their legacy state. This greatly simplified migration of the site as a whole.
Migrating complex sites
For some of our larger and more complex sites, we had to consider and adopt a refactoring of the site and site collection as part of the migration. Refactoring allowed us to take a look at each site and how sites were connected and related before migration. If we wanted those relationships or connections to change, we built that process into the migration, so our migrated sites and hub sites were properly organized after the migration completed. For example, when we migrated MSW, our internal company site, refactoring was built into the migration. The process included important tasks that should be carried out on all large or complex sites:
- Determine which site collections and related components are essential to the site.
- Build out larger subsites as hub sites to allow more autonomy and control.
- Use the hub site model to aid migration. Leave older content in the previous site and build out new content as hub sites.
- Link together hub sites to aggregate content and search. Branding and navigation can float down to child sites while searchable content floats up to parent sites.
- Consider a loosely federated and aggregated design rather than a design that is more rigid and monolithic.
Creating components and designing for reuse
We create a lot of web parts to suit our specific needs in SharePoint. Custom web parts help us provide a directed and comprehensive user experience without sacrificing user experience or design elements. We always consider reusability when we create new web parts. If a web part can be used for other parts of the organization or fulfill a need in other sites, we want to design it in a way that enables it to be reused. We have many web parts that are built with a more general and broad approach in mind that are reused and potentially customized in different places throughout our SharePoint site landscape.
Benefits and looking forward
The greatest benefit for us has been reduced requirement for development and IT intervention. Our users can now create attractive, useful, accessible, and responsive sites using default tools and site creation processes. Our business groups are driving their own site creation and design, and they’re able to maintain more current and complete sites with less effort. We don’t have to enlist extra IT resources or incur additional development delays or extra costs, which saves us time and money.
We’re continuing to migrate our intranet publishing sites to SharePoint in Office 365. In the coming months, we’ll move closer to converting all our publishing sites to SharePoint—this will increase cost savings, save time, and provide our organization with attractive, useful, accessible, and responsive intranet sites.
For more information
Microsoft IT Showcase
© 2018 Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.