The design and approach for the EMS have been approved, a skeleton solution is checked-in to TFS in Visual Studio Online, and the solution is successfully deploying several core branding and business logic artifacts to on-premises and O365 SharePoint.
The next things to focus on are: cleaning up the basic branding implementation and getting more site content types developed and deployed.
There’s a lot to manage with branding for this solution. Before I start implementing the menus, logo placement, font/color restyling, etc…there are a few housecleaning tasks to address. In this solution, we’re using Bootstrap to provide our responsive framework as well as to build many UI components such as modals, icons, and custom fonts. And, we’ll be branding both custom pages as well as system pages. When tying Bootstrap into system pages, you’ll find a few places where the SharePoint UI is negatively impacted. I address those low-hanging fruit immediately before doing any other UI work.
System Pages Before
Here are a couple of UI components that need to be fixed up when Bootstrap is tied into the system page design.
- Various dialogs – note the red markup: crowded text/check-box, truncated [X], shrunken file/browse controls, font is bolded, etc.
- The ribbon – various icons and drop-downs are altered as seen under “Current View”. The bottom third of the drop-down menu is cut-off.
- And, with older SharePoint installations such as SharePoint 2013 on-premises, you’ll see other core navigation components altered. For example, the “+” symbol for “new document” in doc-libs intersects with its bordering circle. O365 suffers from various regressions to system list view pages as well – see the image below where the search icon intersects with the box border:
System Pages After
With a few lines of CSS, these issues are resolved. After evaluating Bootstrap’s impact, look into implementing minor updates to the SharePoint UI that are required such as hiding the left-navigation and updating base colors. There’s more to follow of course, but take small steps so changes can be evaluated thoroughly. This image shows a combination of desired changes and fixes:
- It’s hard to see because of the modal fading, but a grey theme has been applied.
- The ribbon is fixed.
- Left hand navigation is removed.
- Search and other system UI are fixed up.
- Dialogs are in much better shape.
Another serious consideration around the system page branding approach is Microsoft’s right to seriously modify the default experience. As of now, the branding changes Microsoft is making in O365 are detrimental to existing system page customizations using the System Master Page and CSS at the core of this methodology. Expect that it’s going to make more and more sense to use SharePoint as a service available to Provider Hosted Apps and similar implementations wherein you (the developer) have full control of the UI and leverage REST and the CSOM for rich custom experiences. For now, if you want to force classic mode, which can be expected for awhile with larger enterprise customizations, you can specify the setting in the SharePoint Admin center:
Custom Layouts and Navigation
Note above that I removed the local (i.e. left hand) navigation completely. Later on, we’ll add-and-remove more system and custom components…as both the default and based on users’ roles. Broadly speaking, navigation components and IA implementation will be designed to allow people to quickly and intuitively move between key modules in the EMS.
Some navigation-centric decisions may be purely UI and graphics design driven too, but the philosophy I emphasize is to focus navigation around concerns with user experience. We want users focused on their primary tasks and not with the broader SharePoint ecosystem nor lower priority (or irrelevant) EMS functionality. As we train for and expand the functionality of the portal in a controlled/governed way, we’ll also make sure to re-evaluate which parts of SharePoint and the EMS should be bubbled up to higher class UI and entry points.
So, to reiterate, our starting navigation menus, page navigation “widgets”, site layout and overall IA will be driven to:
- Get students to the knowledge base apps and their personal document libraries.
- Get teachers to student management apps and students’ document libraries.
- Provide intuitive search/discovery.
- Get admins into the back-end configuration pages.
- Adapt for mobile and desktop as appropriate.
Several wireframes are used to represent pages in various states and to zoom in on shared and custom components. Previous posts show similar examples, but now behavior is being defined, iterated-upon, and moved through the approval cycle.
Keeping focused on time and budget, we can implement the approved items now while we wait for additional approval on the more robust and complex page layouts, IA, and design patterns.
Initial navigation is integrated throughout the custom and system page framework. The responsive behavior is seen through the dynamic menu layouts and 2×3 versus 3×2 grids. Images in the grids below are samples, but these components are connected through CSS; things are configured so that images can be swapped in-and-out easily through SharePoint lists.
This initial wire-up already has us deploying site columns, content types, and page layouts. We’ll now build on this supporting framework to continue developing the rest of our EMS.
Next Posts: continuing to build out the branding framework as well as logic oriented components and backend IA.