SharePoint

Information Architecture - Setup your term store to scale

December 19, 2016

In this post I am going to put together a list of best practices to consider when setting up a term store in Sharepoint Online. As you may already know term store is collection of term groups. And each term group consists of number term sets. Each term set contains a list/hierarchy of terms. Team group gives the flexibility in terms of access. You can assign permissions to users on their term group, rather than giving them access to the entire store. 
  • Always maintain a corporate/general term group which contains common term sets across organization. 
  • Every group/business unit should have a term group. Pin the terms from corporate term group as required into Business unit term groups. 
    • For example, you plan to maintain list of document types in common term group. Thus, there is a term set created. Marketing department want to use this term set. But, they want to add a few more terms. In this case, you should create another term set in Marketing department term group and pin the terms from common term group. You can add those extra terms to Marketing document type s term set. 
  • Always start with common term group, when approaching a new taxonomy requirement.  You can directly refer the term sets under common term group. This approach will ensure reuse and consistency. 
  • Lets say a term set is under department/business unit level, and another department/business unit requires the same term set. In this case move the term set to common term group. Refer the term set under common term group or pin the term set down to department term group. 
  • Another use case can be, one of the project's requirement is all satisfied with common term group. But, they don't need all terms under document types term set. The solution is to pin the terms from common term group to Business unit term group's new term set. 
  • Don't create a duplicate terms across term groups. It will ruin the integrity of term store and content consumption (search/tagging will obviously get confusing if a filter contains two tags with the same name)
  • Avoid "." in the term names. Search will return inappropriate results. 
  • Sharepoint Online only support strict hierarchies. Perfect example for this case is Nation and States. You can't have a state under multiple nations. On the contrast State and Rivers is an example of poly hierarchy. A river can flow through of multiple states. Or multiple states have same river. 
  • Don't go beyond three levels in Strict hierarchical term sets. 
  • There are hacks to achieve poly hierarchy in Sharepoint Online. But, the recommended approach is to create multiple term sets for each level. 
    • As per above example create on term set for Rivers and One for States.  
    • Create managed metadata columns for each of the term sets to tag the content.
    • Content admins may find it a little difficult to tag the content. But, the search/content consumption will be clean with this approach. 
  • Always enter a description and synonyms (Other Label). They will definitely help content admins when tagging the content. 
  • Don't create term groups at site collection level. You will soon end up chaos, if every site collection admin maintains their own term store. 
  • Until your company reaches a certain maturity hold the the governance centrally with IT. Because, deleting or renaming a term may have detrimental effects in the down stream applications/customizations. 
  • IT team should take consensus from other departments before editing or deleting terms in term store. To do this effectively, form a governance team with your key stakeholders and business users. 
  • Don't wait for taxonomy to be complete and refined. Get started with a basic structure and refine it as you move forward. 
References: 

ion-content

Ionic 1.x - Custom scrollbar in ion-content

December 17, 2016

Write once and deploy everywhere. And, Ionic does a super job at it. With Cordova, Electron you can almost deploy your HTML5 based app anywhere with 10 - 20% change to source code. That 10 to 20% is the place where you grip across multiple platforms and browsers is tested. 

If you consider user experience, mobile is different from desktop. Most of the components in Ionic scale well from mobile to desktop. my struggle was always with scroll in ion-content. 

The scroll ion-content provides is not desktop friendly. Its is the scroll for touch. How to make it desktop friendly? Easiest option is to let ion-content user native scrolling (overflow-scroll=true) and use CSS (overflow-y) to get the scrollbar. My thought was whether that will look sophisticated enough to mach Ionic UX. So I explored other JS based scrollbars. I searched for some angular scrollbars and I found the following interesting. 

But they don't go well with Ionic. After multiple attempts to change to code to work with Ionic, the results were mediocre. So it came down to going back to square one and keeping things simple. 
  • If native scroll serves your need, replace ion-content with normal div. In my case, I want ion-content inside ion-slide-page. 
  • Use CSS to power your scrollbar and use viewport units to define height
    • overflow-y: auto;height: calc(69vh - 44px);
  • My target was to get the scrollbar look good in IE11 and webkit browsers. 


Popular Posts

Twitter