SharePoint – Top 10 Ways to Train Users

The following are the 10 top items to consider in regard to SharePoint end user training:

1)      Create short quick guides (4-12 pages) of applicable features (uploading files, views, using calendars etc.)

 

2)      Create short videos on key aspects and make sure the videos are organized by topic area. Make them available via easy to find subject titles

 

3)      Create a blog and then post key items which the system can do – have good clear categories available so users can find information quickly

 

4)      Create guides 20-50 pages for those whom will be acting as site owner/content owners

 

5)      Run lunch and learn live and remote based sessions – keeping subject matter one hour in duration

 

6)      Offer – live training one hour to 90 minutes in duration which encompass showing users needed functionality

 

7)      Create a custom self-help by overriding the ? with one’s own content (could be a custom wiki/blog)

 

8)      Create live classes and offer a curriculum teaching basic users (covers navigation, terminology, simple basic items in regard to what SharePoint can do, etc.)

 

9)      Create live classes and offer a curriculum for content owners (covers editing/adding pages, creating lists and views, etc.)

 

10)   Create live classes and a curriculum for site owners (covers editing/adding pages, creating sites, handling permissions and site features which can be enabled, etc.)

Video:
 

SharePoint Purchasing Travels – Capital vs. Expense

In my travels – around the world of purchasing SharePoint – I’ve had a variety of experiences. Typically – my experience has been I’m sent a very complicated spreadsheet from a re-seller or directly from Microsoft. I’m then based on the numbers in the spreadsheet – trying to negotiate the best price per seat as well as per server license. Since a large majority of my experience is based with on premise I’m keen to the fact that every user that attaches or will possibly attach to SharePoint needs a license.

Now, if I’m running a standard edition only – typically this is easier because all the users will need a license. Now, if I’m running an enterprise edition – it’s a bit more complicated because not only do all users need a standard license but they will also need an enterprise user license as well. This in my view is a complicated aspect that many don’t realize.

I will say however that the model has gotten easier as Microsoft now provides an enterprise framework, however even though this appears to be marketed for the cloud based organization, it can be utilized for on premise and cloud. Example if one purchases 100 user licenses under what is known as an E3 (Enterprise 3) license those licenses can be utilized for either on premise or in the cloud. This makes getting users the needed tools quicker and easier.

In regard to cloud, those who rely on a capital vs. expense budget are in luck. Under newly established accounting principles cloud based can be capitalized if one can make changes to the software/system and also if the service can be controlled from an on premise point. Therefore, if one is in an hybrid situation where SharePoint is installed on premise and OneDrive for Business is in the cloud – the case can be made that the cloud standard are met and can capitalize expenditures instead of using an expense.

Historically, a vast majority of the SharePoint work I’ve done is expense (training, user licenses, service agreements and support and enhancements) while I’ve capitalized the following -> server licenses, virtual machine licenses, virtual machine racks, and software licenses.

Every organization may think differently on this front but in my view it’s an important one to think about to account for as it’s not always about what SharePoint can do, but how to get it!

Video:

SharePoint Disaster Recovery Thoughts

Lately – the subject matter of SharePoint and disaster recovery has been an interesting one which I’ve had several discussions about in my various SharePoint travels. This is indeed a serious subject that many times is not thought out, nor planned – nor even tested or accounted for. However – in my view the opinion should be that as much time is spent in setting up and architecting a SharePoint site, this same amount of time – should be spent in thinking about a disaster recovery strategy.

I see two views on this matter – the first is what I will call the “poor version” of disaster recovery and this involves essentially backing up and then shipping offsite the SharePoint databases each night. This plan also would include shipping off the snapshots of the virtual machines as well – so that a server and database set can be restored if necessary.

The second view and more expensive model involves taking a back-up each night of the whole entire farm and then having that farms copy of assets go to a local storage hub as well as offsite. In this model when I’m talking farm – I mean the whole farm – virtual machines, databases, configurations, site collections, sites, document libraries and lists, etc. In this model if someone deletes a whole site – it could be recovered in full – regardless of the size of the site. Also if someone deletes a library or list it can be recovered. Additionally a policy under this model could be put in place to have the data be stored for 90 to 120 days – which would be double the standard 30 day – end user recycle bin and then 30 day administrator recycle bin – that is currently available.

Thus, this is a broad topic but my goal is short posts to get you thinking!

Project Methodology - Waterfall vs. Agile for SharePoint Projects

In regard to project management methodologies and SharePoint – for a long time I utilized a pure Waterfall methodology where requirement analysis, system design, implementation, testing, deployment and maintenance was done. Since a large majority of the SharePoint work I’ve done to date involved migrating content from one system to another or from one SharePoint version to another – this methodology appeared to work well in these projects – however pros and cons were evident. Essentially since content always needed to be reviewed the requirement was well known it was move content from this SharePoint location/version to this SharePoint location/version. At the system design phase – the Waterfall and SharePoint do work a majority of the time because it is known what the said systems base will be utilizing. The only aspects from a systems standpoint is that from one version to another – different features typically needed to be turned on to support needed functionality. Great example being site publishing. Testing using Waterfall – seemed to always be slow as test scripts either needed to be written or a load test needed created in the designated application (example: Load-runner, Team Foundation Server, Stress Stimulus etc.) Additionally, deploying using Waterfall seemed to produce a fair amount of documents surrounding lists of various items that needed turned on, configured for, migrated, moved etc. Then maintenance using Waterfall – really always seemed to leave a lot to be desired as guess work into what was really being asked for a lot of times – resulted in sites and subsites that didn’t meet user’s requirements and thus – had to be scrapped.  

Now coming to age – it appears SharePoint and an agile project methodology – work well. The notion of creating work that is broken down into 5, 10, 15, 30, 60, 90 day sprints is ideal.  For the larger work an epic – usually work that spans a quarter (or 90 days) works well for SharePoint because typically this is how long the complex world of SharePoint to migrate a site or create it – spans if all the bells and whistles of content analysis, design, graphics, training and testing are to occur.

An example of an epic maybe: [SharePoint 2016 – IT Site]

A feature which would be a core item that needs to be included in the project and associated with this epic maybe: [SharePoint 2016 – IT Site] – Create IT site

Stories are core working pieces that need to be built and are part of a feature – so example items are:

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT project list page

Tasks will then appear under each story so in this example case these would be:

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Therefore putting this down on paper with the epic/feature/story/task – the project mapped out would look as such where the indenting depicts where the item fits in regard to this methodology:

[SharePoint 2016 – IT Site]

[SharePoint 2016 – IT Site] – Create IT site

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list page

 [SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Thus, it’s easy to see why the Agile methodology lends itself to SharePoint in a much broader way – as features, stories and tasks can be created as the project itself evolves. Since SharePoint lends itself to creating sites of business value – by using an Agile methodology users will have real working sites with the needed requirements more quickly and can therefore, change items as needed as the sprint progresses. Because of this – I’ve found that Agile is a better project methodology choice for SharePoint projects then Waterfall.

SharePoint - Public vs. Private Site

An overview of public vs private sites.

Public Sites – A site referred to as public will by default be available in a read only format to all users whom have access to the said Internet or Intranet site. The home page of the Intranet is an example of a public site.

Private Sites – A site referred to as private will only be available to those users whom have been granted access. Such sites will contain team collaboration information which should be shared only to applicable users. An example of a private site would be an IT Private Site which would contain content and diagrams which only IT team members would be able to see and collaborate on.

Overall, a good rule of thumb would be to have a private site created and available for applicable team members to create master content in (example as a .doc or .docx format) – then if such content is to be viewed on a public site – it should be created as a .pdf then uploaded/moved to a public site. This way, master documents are kept on the private site – then only posted in a .pdf format to a public site when content is to be shared to a wider audience.

SharePoint Definitions - Common

The below are some common SharePoint definitions that are often asked:

Active Directory - a directory service from Microsoft utilized in SharePoint for grouping user login accounts in named groups.
Activities -  tracked updates related to a specific user. They are often related to the users social interaction within SharePoint (such as tagging, rating, etc).
Check-out: To lock a file while editing it to prevent others from overwriting or editing it inadvertently. Only the user who checks out a document can edit the document.
Content Type - a named and uniquely identifiable collection of settings and fields that store metadata for individual items in a SharePoint list. One or more content types can be associated with a list, which restricts the contents to items of those types.
Document Library - a configurable list in which documents and folders can be stored. The document library has special settings above and beyond a folder such as versioning settings, workflow settings, and information policies.
Follow - ability to subscribe to receive that user’s updates.
Hash tag – way to organize tweets. Users simply prefix a message with a hash tag to enable others to discover relevant posts. One commonly used hash tag is to utilize a user’s name example #Kevin O’Neill.
Home Page: A Home Page is the main page of a SharePoint web site; it provides a navigational structure that links the site components together. The home page has two major navigational areas: the top link bar and the quick launch bar.
Library: A library stores files as well as information about files. You can control how documents are viewed, tracked, managed and created in libraries.
List: A list is similar to a library, except that it is a collection of information where a team or department can store, share and manage information (not files).
Metadata - data about data. Metadata describes how and when and by whom a particular set of data was collected, and how the data is formatted.
mySite/OneDrive – a single page portal that contains the user’s personal sites, links, etc. My Site consists of both a public and private view. The private view is intended as a personal workplace for the individual end user. The public view, on the other hand, acts like a business card that can be accessed by other portal users.
Page – used to display or summarize information and links within a site or sites.
Public Site - a site created in SharePoint which is available to all users as well as the information it contains is relevant to all users.
Private Site - a site created in SharePoint which is available to targeted designated users as the information it contains is relevant to only members of a said team or project.
SharePoint Designer - a tool which allows administrators to modify pages, and customize their SharePoint sites in more powerful ways than the out of the box graphical user interface.
Site - a complete web site stored in a named leaf of the top-level Web site.
Subsite - a named subdirectory of the top-level Web site that is a complete Web site. Each sub site can have independent administration, authoring, and browsing permissions from the top-level Web sites and other subsites.
Survey - a Web site component that enables users to respond to a set of questions specified by the creator of the survey. Results are tallied in a graphical summary. Surveys provide a way to poll portal users for input on a subject. Surveys support a wide variety of response types from simple Yes/No answers to free-form text.
Tag - keywords that are assigned to content. Tagging pages to share with others is social bookmarking.
Term Set – a designated listing of metadata tags to be utilized for a particular area, department, project or initiative.
Versioning: The process of creating a numbered copy of a file or an item whenever a revision is saved to the library or list.
Web Part: Web parts are basic building blocks of a web part page. A Web Part can be reused, shared and personalized by all users who have permission to access it.
Web Part Page: a special type of page on a SharePoint site that contains one or more web parts.
Workflow - the automation of business processes, where business documents and tasks are passed automatically from one user to another for action, according to a set sequence.

SharePoint 2013 Survey Word Wrapping with CSS

The other day – I had a user request asking how in a SharePoint 2013 survey – it’s possible to turn word-wrapping on – in regard to the text in questions?

So knowing that the master page being utilized was customized – I cobbled through some search sites and found bits and pieces of what was needed to obtain the text wrapping.

Therefore, to fully implement this – here are the steps to follow:

1. From the opening page of the survey whose page is overview.aspx click the Respond to this Survey link.
2. Then from the Gear select Edit page -> click the link Add a Web Part -> Media and Content -> Content Editor -> click Add.
3. On the right hand side – click the drop down arrow and select Edit Web Part:
   
4. Place the cursor into the content section of the web part
    -> in the ribbon select Edit Source.
   5) Copy and paste in the code below into the window and click the OK button
   <style type="text/css">
   .ms-formlabel, ms-vb nobr {white-space: normal; width:660px;} #MSOZoneCell_WebPartWPQ2 .ms-formlabel {word-wrap:break-word;}
   </style>
5. On the far right hand side under the Content Editor properties expand the Layout then place a checkmark next to Hidden:
6. Scroll down then select on the right hand side – Apply then OK.
7. Click in the ribbon the Page tab -> Stop Editing -> Stop Editing. The first page of the survey provided the code was entered correctly should now display the word wrapping.
8. If the survey has page separators meaning it will have more than one page – then click Next.
9. Repeat steps 2-7 for each page separation and now word wrapping will be present across the full survey.