A new location for the SharePoint User’s Toolkit

The SharePoint User’s Toolkit has a new official page:
http://sp2010.pathtosharepoint.com/SharePoint-User-Toolkit/

The old location will remain active but won’t be updated anymore.

The new site is based on SharePoint 2010 and hosted by fpweb.net. Thanks to the support of fpweb.net, I expect the new site to be more reliable and offer a better user experience.

The SharePoint User’s Toolkit is a collection of tools designed to help end users build advanced customizations. It includes for example the Easy Tabs and an Image Rotator. It will continue to grow, with new tools added every month.

Regular users of the Toolkit will notice that several solutions are not in beta anymore. I haven’t actually made any changes to the code, the beta versions are becoming official simply because no issue was reported in the past few months.

Page Redirect

The last addition to my SharePoint User’s Toolkit: a “Page Redirect” script. It allows you to redirect your users to the correct location, when they try to access an outdated page.

Get your custom copy here:
http://sp2010.pathtosharepoint.com/sharepoint-user-toolkit/Pages/Page-Redirect.aspx
[09/14/2010: link updated to the new Toolkit location]

The script includes several options: pop-up message, timer, inline message, and the choice to display or hide the current page content. It works in both SharePoint 2007 and 2010.

This solution is suitable for you if you need to redirect specific pages. For other redirect options, check out the following links:
http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=48
http://www.tonstegeman.com/Blog/Lists/Posts/Post.aspx?ID=102

Easy Tabs: Even Better with Print Friendly!

Author: Kerri Abraham, Revenue Cycle Sharepoint Coordinator, Mercy Medical Center.

Several months back I was tasked with a training build for our highest turnover position.   The main function of the job was a 7 screen registration process, and because of government regulation and business requirements, every field on these 7 screens needed thorough instructions.  The information I was to work from was half a paper ream thick as hard copy!  First step was a severe edit of the information and then solid structuring to make it useable to staff.  My thoughts went right to the Easy Tabs!

I started with organizing according to the 7 screen requirements, and soon realized that wouldn’t be enough, staff might still be overwhelmed with content.  Taking advantage of the natural breaks in the process it broke out a bit further, until finally that half ream of hard copy was just 17 wiki pages of instructions.  Using the Blog to Wiki publishing technique, I utilized a color coding strategy to keep the look consistent across all the pages and links at the bottom of each page moved staff through the steps.  Initially the trainer can walk new hires through the process using these handy links, but shuffling through the links to find the spot they are caught on (while the customer stands waiting) is unrealistic.  That problem was resolved with the Easy Tabs

By modifying the view of the wiki content and filtering it on ID, then adding them one after the other on the page, changing each of the web part’s titles to reflect the contents, and then implementing Christophe’s Easy Tab solution I was able to get all 17 pages of information neatly tucked up under each other on the page.  Keep in mind that the native content of the wiki does not roll up under the tabs, that gives the display as below.

This worked out perfectly, staff could keep this page up as they worked, if they were stuck on a step in the process, they could click the tab and immediately find their information.   When I sent a picture of my use of Easy Tabs to Christophe, he suggested that I add the Expand All tab, but call it ‘Printer Friendly’, as a way to appeal to  the trainer’s needs who was really impressed with the wiki, but still  attached to hard copy.  Up to this point she was printing each page separately because without page breaks the information was confusing the way it ran together.  Easy Tabs v5 completely solves that issue with ‘Printer Friendly’ plus page breaks.  Now this documentation prints just like a procedure manual.  The trainer is thrilled with the results!

I can offer a few tips for creating this kind of procedure manual with the wiki:  use the Advanced Web Parts gallery to quickly add multiple web parts.

The default display under native wiki content is ‘no Title’, so ‘Appearance’ on each addition will need to be adjusted to display as tab.  Note the only columns checked to display are Wiki Content and Edit.  Filter wiki content on ID.   Consider adding the column of ID to the Wiki Pages/All Pages view of the library to make it easier to identify ID.  The rest is simply a matter of perseverance in repeating the steps and setting the toolbar displays to none for a nice clean look.

I have a feeling this is only the beginning…  A comment Dux Raymond Sy recently made in a video recording about “printing a project plan” got me thinking.  I am a fan of Dux, so I’ve been using Sharepoint for project management for quite some time, but “printing a project plan” suddenly struck a new cord!  So I went to work rebuilding my project site template to include Christophe’s Easy Tabs, and while I was at it, I incorporated some color coding into the task list as well.  I restructured all the lists and libraries on a Web Part page.  In addition to the standard lists, again I utilize a wiki library, exposing just the content field, which is part of the site template and includes several project related forms that provide the project managers with an easy to edit alternative to Word documents (and now even more printer friendly under the tabs.)  The results were dramatic especially since I used the new color options with Easy Tabs v5!  

Now the project managers can quickly print off just the Web Parts they need, or the entire project documentation with just a few clicks.  Maybe regular hard copy reports are needed to communicate at Shareholder meetings?  Create a web part page just for report out, adding the desired web parts with list views and dashboards that can be tucked under Easy Tabs and printed in a moment’s notice.

I have number of other ideas in the works for these tabs as well, meeting minutes and agendas with easy printability, printable lists displayed in “Preview Pane” style, a telephone directory based off a contact list built with Easy Tabs v5, why, I’m just getting warmed up!

I think the new options make an already great solution into an awesome feature. What do you think? Someone recently told me “Printing web parts kind of goes against the purpose of electronic data capture doesn’t it?” Help me prove them wrong. There are countless uses for print friendly! I’ve listed out my ideas, now it is your turn, how are you using the Easy Tabs?

Easy Tabs: version 5 is out!

Version 5.0 (beta) of the Easy Tabs is now available in the SharePoint User’s Toolkit:
http://sp2010.pathtosharepoint.com/sharepoint-user-toolkit/Pages/Easy-Tabs-v5.aspx
[09/14/2010: link updated to the new Toolkit location]

The main improvements:
- The Easy Tabs now work in both SP 2007 and SP 2010.
- Stylesheets are directly included in the code; for SP 2010, the colors can be modified in the Easy Tabs builder (see above screenshot).
- New “Print preview” option to display the Web Part zone in full screen.
- Better compatibility with third party Web Parts.

Like its previous versions, the new Easy Tabs script doesn’t have any external dependency (no jQuery or other external library; tabs rendered using the default SharePoint images).

There is still room for improvement, and as usual I hope to read your feedback in the comments section. The main issue with the current version is that it doesn’t work for SP 2010 calendar views (I might be wrong, but I blame Microsoft for that). Also, I keep in mind the comments made last month by Matt Bramer and Mark Miller, but I haven’t yet figured out how to implement this in a user friendly way.

Special thanks to Sean Wallbridge, MVP, for his active support; Christina Wheeler and Kerri Abraham for their feedback on usability; and Jimm Johnson for his thorough tests on third party Web Parts.

Working Hard on the Easy Tabs v5

In the past couple weeks, I have been working on the Easy Tabs v5. I have completely rewritten the script to make it more generic. The objective is to accomodate various layouts, including SP 2007 Web Part pages, SP 2010 Web Part pages, and wiki pages. I am also taking this opportunity to include some of the options mentioned here (see the comments).

My script is in good shape, but still has a couple issues, linked in particular to wiki pages and Microsoft bugs. Today I sent the latest draft to the readers who have volunteered to test drive the new version.

Also, I am preparing another gift for you: I recently built a variation of the Easy Tabs for a group at Hewlett-Packard, and the manager has agreed to make the code public. I’ll publish it a month or two, after I make it compatible with SP 2010. This variation allows multiple Web Parts under a same tab, which makes it suitable for dashboards for example.

Remember to subscribe to my RSS feed if you are interested in the latest updates!

For the record, the current Easy Tabs script for SP 2007 is available here:
http://www.pathtosharepoint.com/sharepoint-user-toolkit/default.aspx

HTML Calculated Column: solutions for SP 2010 (Part IV)

This series assumes that you are familiar with the “HTML Calculated Column” . 

Part I: fallback to SP 2007
Part II: edit in SharePoint Designer
Part III: deal with individual Web Parts
Part IV: brute force 

At the end of part III, we were left with this question: how do I know when I need to run the Text to HTML script? 

In this post I’ll provide an easy answer: I don’t know. Updates to the page can come from the asynchronous load of a calendar view,  the asynchronous update of a list view, expanding grouped items, a response to a Web service call, etc.

Not knowing when or where updates happen, my only solution is to scan the content of the page at regular intervals. Not the most elegant or performant choice, but a bulletproof approach that will cover all cases.

My sample code:

 
<script type="text/javascript">

// Copyright (c) 2010 Christophe Humbert - Path to SharePoint

// Find all Web Parts in the page
var listWP=[],calWP=[],divs=document.getElementById("MSO_ContentTable").getElementsByTagName("div");
var count=divs.length;
for (i=0;i<count;i++) {
try {
if (divs[i].id.indexOf("WebPartWPQ")==0){
if (divs[i].innerHTML.indexOf("ViewDefault_CalendarView")>=0) {
// Calendars
calWP.push(divs[i].id);
}
else {
// Other Web Parts
listWP.push(divs[i].id);
}
}
}
catch(e){}
}

function TextToHTML(NodeSet, HTMLregexp) {
var CellContent = "";
var i=0;
while (i < NodeSet.length){
try {
CellContent = NodeSet[i].innerText || NodeSet[i].textContent;
if (HTMLregexp.test(CellContent)) {NodeSet[i].innerHTML = CellContent;}
}
catch(err){}
i=i+1;
}
}

var regexpA = new RegExp("\\s*<([a-zA-Z]*)(.|\\s)*/\\1?>\\s*$");
var regexpTD = new RegExp("^\\s*<([a-zA-Z]*)(.|\\s)*/\\1?>\\s*$");

var WP = new Object;

function UpdateWP() {
if (calWP.length>0){
for (i=0;i<calWP.length;i++) {
WP=document.getElementById(calWP[i]);
if (WP.innerHTML.indexOf("&lt\;")>=0) {TextToHTML(WP.getElementsByTagName("a"),regexpA);}
}
}
if (listWP.length>0){
for (i=0;i<listWP.length;i++) {
WP=document.getElementById(listWP[i]);
if (WP.innerHTML.indexOf("&lt\;")>=0) {TextToHTML(WP.getElementsByTagName("td"),regexpTD);}
}
}
// Check every 200 ms, forever
setTimeout("UpdateWP()",200);
}
UpdateWP();

</script>

The beginning of the script is taken from part III.

Note that I have included a quick check – if the Web Part doesn’t contain any “<” character then there’s no need to run the full Text to HTML function.

The 200 ms interval is a trade off between refresh needs (we hope that the naked eye won’t even notice the HTML strings) and browser performance. For IE 6, you may have to increase this number.

Like the other articles in this series, consider this sample script as experimental and handle with care.

In the next episodes, we’ll try to be more subtle, and provide optimized routines to address specific situations.

HTML Calculated Column: solutions for SP 2010 (Part III)

This series assumes that you are familiar with the “HTML Calculated Column” .

Part I: fallback to SP 2007
Part II: edit in SharePoint Designer
Part III: deal with individual Web Parts

My current Text to HTML script, written for SharePoint 2007, works as follows:

  1. find all hyperlinks (A tags) on the page
  2. if a tag contains an HTML string, convert it to actual HTML
  3. find all cells (TD tags) on the page
  4. if a tag contains an HTML string, convert it to actual HTML

I played with some more efficient scripts, but my tests showed that there was so little to gain that it was not worth the trouble.

In SharePoint 2010, things are different: because of asynchronous updates on the page (details here), the script needs to run more often, and performance optimizations will have a significant impact. So I chose a different approach to reduce the size of the loops:

  1. identify all the Web Parts on the page
  2. sort them out, to separate calendar Web Parts from the others
  3. for the calendar Web Parts:
    1. find all hyperlinks (A tags) in the WP
    2. if a tag contains an HTML string, convert it to actual HTML
  4. for the other Web Parts:
    1. find all cells (TD tags) in the WP
    2. if a tag contains an HTML string, convert it to actual HTML
  5. rinse and repeat steps 3 and 4 as needed

The script:


<script type="text/javascript">

// Christophe Humbert - Path to SharePoint

// Find all Web Parts in the page
var listWP=[],calWP=[],divs=document.getElementById("MSO_ContentTable").getElementsByTagName("div");
var count=divs.length;
for (i=0;i<count;i++) {
try {
if (divs[i].id.indexOf("WebPartWPQ")==0){
if (divs[i].innerHTML.indexOf("ViewDefault_CalendarView")>=0) {
// Calendars
calWP.push(divs[i].id);
}
else {
// Other Web Parts
listWP.push(divs[i].id);
}
}
}
catch(e){}
}

// Apply Text to HTML as needed

</script>

The question now is how to “apply the Text to HTML script as needed”. I’ll provide some suggestions in the next episodes. We’ll see in particular that the behavior of calendar views is different from other Web Parts.

A note for the jQuery fans

In jQuery, getting all the Web Parts can be done with a single selector:
$(“#MSO_ContentTable div[id^='WebPartWPQ']“)
What you need to understand is that the above line, although shorter than its JavaScript equivalent, will take the same time to execute. So there is no benefit from using jQuery here.

Follow

Get every new post delivered to your Inbox.

Join 261 other followers