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?

Interactive Charts using Google Visualization API (via SharePoint JavaScripts)

Proposed by Alexander Bautz, a client side charting solution for SharePoint that relies on the Google Visualization API.

To understand the difference between the Google Chart API and the Google Visualization API, check out this page:
http://code.google.com/apis/charttools/docs/choosing.html

This is a solution for creating charts directly from SharePoint lists using Google Visualization API. The solution is a CEWP-solution and requiring no other than a few script references. All code and data are processed and rendered in the browser. No data is sent to any server.[…] You can pull data from any existing list view (even from personal views – for personal use), or using a custom CAML-query … Read More

via SharePoint JavaScripts

Client side scripts: how will they behave in 2010?

If you’ve been using some of the client side code available on Path to SharePoint, or other similar blogs, you might be interested in what’s going to happen when you migrate to SP 2010. I can’t provide a final answer, and we’ll see exactly how they behave when we have access to the final release. But for now let me share some preliminary results from my tests on the beta version.

Scripts that don’t need to work in 2010

First, I’d like to make it clear that some scripts are not supposed to migrate. SP 2010 comes with a bunch of new features, and some of them will address existing issues or limitations. For example, the Gantt chart in SP 2010 is more user friendly, and includes a dynamic scale. If you are using my script to dynamically resize the Gantt chart, simply drop it when you upgrade. This will make a smooth transition, as you’ll continue working in SP 2010 the same way you did in 2007.

Now how about the rest, those scripts that you’ll still want after the migration?

Scripts that rely on remote calls

These are scripts that use Web Services, the URL protocol, RSS, or other XML or HTML sources. The image Rotator and the cross-site list snapshot belong to this category. So do the scripts that use Marc Anderson’s SPservices library.
From my tests, I expect these scripts to directly work in 2010, or only require minor adjustments.
How to identify such scripts? They use the XMLHttpRequest object (look for example at the code of the image rotator), or, if written with jQuery, an Ajax function (for example load function in the cross-site list snapshot).

Form pages

Are you using code to tweak item creation pages (NewForm.aspx), display pages (DispForm.aspx) or edit pages (EditForm.aspx)? I haven’t found any significant difference between 2007 and 2010, so here too I would expect them to continue working.
I only have one script in this category (item ID in display and edit form), and it worked fine in my test.

Code that modifies SP home pages or Web Part pages

The majority of my scripts belong to this category. What they do is let the standard SP page load, then run to enhance it with color coding, animations, and other features. The most popular are the Easy Tabs and the HTML Calculated Column. Let’s review the main challenges and see how we can address them.

New structure and styles

SP 2010 sees significant changes to the page design. In the HTML, the layout is now based on divisions (div elements) instead of tables. This follows best design practices, but the pages seem to have gained some weight in the process.
SP 2010 also comes with new class names.

For class names, the fix is relatively easy: just replace the old names with the new ones. For HTML changes, scripts that are traversing the page structure will need to be rewritten. This is the case for the Easy Tabs, where I use div elements in the new version, instead of cells in SP 2007. My beta version of the Easy Tabs works with lists, but currently doesn’t work with calendars. I traced the issue back to a bug in the SP beta version (conflict between asynchronous updates and minimized Web Parts), and I’ll need to check this out in the final SP release.

Asynchronous updates

Another major change is the introduction of asynchronous content update. In SP 2007, refreshing content means refreshing the whole page. This is not the case in SP 2010, where some portions of the page can be added or modified after the page loads. Calendars for example are loaded asynchronously. For standard lists you can choose asynchronous load as well, and include periodic refreshes.

Most of the scripts I have written, or found on blogs, run once, either in the flow of the page or after the page has loaded. For example, “Text to HTML” will look for all the HTML strings in the page, and turn them into actual HTML. But what if later an asynchronous update pushes another HTML string on the page? Well, too late, it will just remain as is.
The easy way to address the issue is to disable asynchronous updates. By doing this you simply revert to the 2007 behavior. Note that AFAIK this option is not available for calendars, which are always loaded asynchronously.

If you keep asynchronous updates, you’ll need the client side script to run everytime the content gets refreshed. There are a few options to achieve this.

1/ Brute force
The easy way is to run the script at regular short intervals (for example every 100 ms). OK for small scripts and modern browsers (excludes IE 6 and IE 7).

2/ Duck punching
This refers to a technique where you append your own customization to an existing script. In our case we would append our custom script to the function(s) that render content on the page.
This is for example what I already do in SP 2007 with the Text to HTML script, to make it work with grouped views and the preview pane.

3/ XSLT
With SharePoint Designer, you can control the rendering of Data View Web Parts via XSLT. By including your customizations within the XSLT, you make sure they’ll be applied every time the view is refreshed.
Here too this is a technique I am already using in SP 2007 with the Content Query Web Part and Data View Web Part (see my blog posts on KPIs), as well as in my drop-down menu.

4/ Monitor content updates
If you don’t have control on the code, then your best bet is to monitor the page content and react to changes. What makes this method difficult to implement is that the methods to monitor changes are browser specific.
Just like for method 1/, the code needs to run at short intervals. But this time it is smarter, as it won’t go through the whole rendering process if no change has occured.
Monitoring can be done directly on a Web Part, or indirectly by tracking page changes that are triggered by content updates. For example, in SP 2010 you can monitor the notification area, which gets updated when new content is loaded, like calendar events. Here is a sample script:

<script type="text/javascript">
var watchnotif = document.getElementById("notificationArea").getElementsByTagName("span");
var count=watchnotif.length;
setInterval ('Update()',100);

function Update(){
if (watchnotif.length != count) {
count=watchnotif.length;
...run scripts on new content...
}
}
</script>

I’ll provide specific examples in future posts, and reusable scripts later this year, after the official SP 2010 release.

Introducing the SharePoint User’s Toolkit

In the past few weeks, I have upgraded several of my scripts, and made them available here:
http://sp2010.pathtosharepoint.com/sharepoint-user-toolkit/
[09/14/2010: link updated to the new Toolkit location]

I am calling this central place the “SharePoint User’s Toolkit“. From now on, this is where I’ll publish my client side scripts and other enhancements to the standard SharePoint UI.

The SharePoint User’s Toolkit is still under construction. In particular I am working on adding more documentation. Also, expect to see ~10 more tools added in the 2-3 months to come. Behind the scene, I am going to migrate the site and have it hosted by my partner, fpweb.net, to guarantee availability and performance.

For now, my content mainly targets SharePoint 2007 users. Some scripts may work in SharePoint 2003, but you’ll have to check them out by yourself, and they might require some adjustments. Note that a couple scripts, like the Image Rotator, have been tested successfully in SharePoint 2010. After the official release I’ll add more information about SP 2010 compatibility, and when needed I’ll release adaptations specific to SP 2010.

If you have an issue with one of the scripts, or want to suggest enhancements, please send me an e-mail. I usually respond within 24 hours.

If you have a specific need that is not covered by the current free tools, check out the list of upcoming online workshops or register for a one-on-one session on the Path to SharePoint home page.

If you are a SharePoint consultant and would be interested in a custom copy of the SharePoint User’s Toolkit, feel free to contact me to start a collaboration!

Cross-Site List Snapshot, version 2.0 beta

Last year I published a simple method to display a SharePoint list in another site. I am releasing today version 2.0 beta of the jQuery script:
http://sp2010.pathtosharepoint.com/sharepoint-user-toolkit/Pages/Cross-Site-List-Snapshot.aspx
[09/15/2010: link updated to the new Toolkit location]

I have renamed it “snapshot”, to better reflect its (limited) capabilities. The snapshot created on another site doesn’t have all the features of the original view, for example context menus or expand/collapse buttons will not work. But at least this allows you to view the list items, and preserves the hyperlinks.

The main improvements in version 2:
– the script now works for both lists and calendars
– there won’t be any conflict if you place several scripts on the same page
– a form helps you select your options, and includes a debugging utility

How to get the script?
Fill out the form, and click on the “Save to Disk” button. Once you have your script, you can add it to a SharePoint page via a Content Editor Web Part (preferred solution: upload the text file containing the script to a SharePoint library, then link to it from the CEWP).

Notes:
– if you don’t have Flash 10 installed, you won’t see the “Save to Disk” button. In this case, just copy and paste the code displayed in the text area.
– the target Web page needs to be on the same domain as the original view. If the view is on http://www.domain1.com, you can display a snapshot on any page that belongs to http://www.domain1.com, but not on http://www.domain2.com for example.
– keep in mind that it is a beta version, for evaluation purposes.

 To report an issue, leave a comment below, or send an e-mail to Christophe@PathToSharePoint.com.

Why this script?
SharePoint doesn’t offer a convenient way to display information from a site in another site. This script gives you a workaround to accomplish this.
Other solutions:
– the Page Viewer Web Part (but doesn’t give a clean layout)
– Data View Web Part and Content Query Web Part (for advanced users, and only work within the same site collection)
– Web services and URL protocol (also for advanced users, and only work in authenticated environments)
– RSS feeds (requires you to rebuild the view on the target page)

Where can I find instructions?
The page is still under construction. For now, see last year’s article, and the context help available on the form. I’ll publish a tutorial later this month.

Tutorial: add color coding to your SharePoint 2007 calendar in 15 minutes

May 2010

Environment: SharePoint 2007 – wss or MOSS (no SharePoint Designer or third party application required).
Audience: confirmed end user, power user.
Permission level: design or full control.
Estimated time: 15 minutes.

0- Before you start
1- Select your colors (5 minutes)
2- Create your calculated columns (3 minutes)
3- Set up your calendar view (2 minutes)
4- Render the colors (5 minutes)
5- If you want to undo your changes
6- A note for SharePoint 2010 users

0- Before you start

To follow this tutorial, you need a calendar created in SharePoint 2007 (wss or MOSS).

 In my example, taken from Mark Miller’s community calendar, items are organized in categories:
– Online Event
– Online Workshop
– Training
– Conference
– User Group
– SharePoint Saturday
– Other 

I have created a choice column, called “Category”, to store these choices. Note that for this tutorial seven is the maximum number of choices. If your choice column has more options, only the first seven will be color coded.

A choice column is the natural option to organize items in categories. You can also use any column type that contains text or numbers, like content type, text column, calculated column. Note that columns of type Lookup will not work for this tutorial. 

Usability tip: People can distinguish up to ten different colors that are assigned to different categories, but it may be safer to use no more than five different colors for category coding. (source: rightpoint))

If your choice list includes more than seven choices, this follow up article will show you how to proceed.

Ready? Let’s see if we can get our color coded calendar in less than 15 minutes…

1- Select your colors (5 minutes)

To choose your colors, simply fill out this online form. In my example:
– choice column: Category
– choices: paste here the choices from the choice column
– display: Title (the event title will be displayed on the calendar)
– keep the default value for the other options (except if you are on a non-English SharePoint farm)
– Use the color pickers to select your colors for each choice

Note: the semi-transparent background will not be rendered in older browsers (like IE 6). 

After selecting your options, scroll down to the bottom of the form. You’ll see two formulas (pale-green text areas). Leave this page open or save your two formulas, we’ll use them in the next step. 

Note: you can choose to group the two formulas into one by unchecking the “Separate Color Column” checkbox.

While we are on this page, let’s grab the script that we’ll use later for the rendering:
– click on the Download tab.
– right-click on the last file name TextToHTMLlite-v2.1.1.txt, and select “save target as…” to save it to your computer.
– upload the file to a SharePoint library in your site or site collection. The location doesn’t matter, as long as your users have read access to the file.

Note! the download section displays 4 files; pick the last one for this tutorial.

2- Create your calculated columns

On your calendar page, select:
List > List Settings

On the List Settings page, create two calculated columns (use the “Create column” option for this):
– First column, named “Color”: paste the first formula.
– Second column: named “Display”: paste the second formula.

3- Set up your calendar view

Staying on the settings page, under Views, click on your calendar view. In the settings page, choose to display the “Display” column. Save your changes.

  

Now, go back to your calendar view, and you should get an ugly result like this:

Don’t worry, we are going to fix this in step 4.

4- Render the colors

We can now use the script we grabbed in step 1:
– go to your calendar view, and switch the Web page to edit mode:
Site Actions > Edit Page
– Click on “Add a Web Part”, and add a Content Editor Web Part to the page
– drag and drop the calendar view above the Content Editor Web Part (the order is important)
– in the Content Editor Web Part, click on “open the tool pane”
– under content link, paste the URL of your TextToHTMLlite-v2.1.1.txt file (remember, you stored it in a document library in step 1). 

If you now exit the edit mode, you should see your calendar in color.

5- If you want to undo your changes 

A key advantage of this technique is that all our customizations were made through the SharePoint UI and can easily be undone. If later you want to revert to the initial view:
– remove the Content Editor Web Part from the page
– go to the view settings page and replace Display with Title as the displayed column.
– delete the two calculated columns.

6- A note for SharePoint 2010 users

In SharePoint 2010, the script from step 4 will not work because calendars are rendered asynchronously. Alternate options can be found in this post.

Updates [09/08/2010]:
– Links now point to the new location for the SharePoint User’s Toolkit
– Link to follow up article for more than seven choices
– Note for SP 2010 users

Update [12/06/2010]:
Brendan Newell published an article based on this tutorial, with a couple additional tips. For example, here is the style in SharePoint 2010 to remove the default background from the event:

<style type="text/css">
.ms-acal-selected, .ms-acal-item {
  background:none;border:0px;
}
</style>

The article also mentions a resizing issue, which AFAIK is linked to the default calendar, not to color coding.
Check out Brendan’s article for more information!

Quick update: Image Rotator in SharePoint 2010

Today I decided to test in SharePoint 2010 the Image Rotator I released yesterday. I just followed the instructions and filled out the form:
http://www.pathtosharepoint.com/sharepoint-user-toolkit/Pages/Image-Rotator-Lite.aspx

It worked like a charm, I didn’t notice any difference in behavior between SP 2007 and SP 2010.

Of course, we have to wait until the final SharePoint release in a few weeks to confirm it. But this is pretty good news and I couldn’t wait to share the result!