MNteractive.com

There are so many little things that will drive you nuts with SharePoint the more you use it. One of these things is the admin/edit interface. Traditionally, you have the front-end interface that the audience sees, and you log into an entirely different interface to edit the content. This seems to make sense to me, as it doesn’t burden the content author with having to also be the content designer. Afterall, isn’t that what a CMS is for? In SharePoint, however, what you see while surfing your sites is the same that you see while editing your sites–with the difference being that SharePoint has to cram more crap on the page when you are in edit mode. To be fair, this isn’t that big of a deal when you are working on a typical collaboration site. You see the list of documents, need to modify, so you might as well modify the actual list you see.

The problem is when you want to use SharePoint as a content management system. If you are doing that, you are likely using it to publish a web site that has a custom template (likely a custom MasterPage). This is a chore in and of itself, but, as a SharePoint developer, trying to figure out what SharePoint does AFTER you go into edit mode is next to impossible. When you click EDIT THIS PAGE SharePoint will add a page publishing bar across the top of your page, take your page template, replace that with a larger table, put your page template back inside that table, then add yet another TD to the right of that to place the web part tool pane.

What happens is that your nicely laid out page that was, say, 900 pixels wide is now 1300 pixels wide when in edit mode. This now requires the end-user to scroll horizontally and vertically across the page to actually edit the area they want to, and then go find the OK/SAVE options way up in the web part ToolPane.

While you COULD just buy everyone new 30″ wide-screen monitors, I figured there MUST be a better way, so I began digging through the rendered HTML and CSS and came up with a workable solution that takes this ToolPane and anchors it to the top of the viewport, and then sets it so you could roll-it-up out of the way if needed.

My method is a hack, for sure. The components are a .js file (plus one other .js to fix CSS issues in IE6), a .css file, and a few lines of code you’ll need to add to your masterpage(s). BEFORE you dive into this solution, you may want to first try out the ‘Floating ToolPane for SharePoint’ solution provided by Vincent @ thekid.me.uk. Vincent’s solution is slightly different, but tries to solve the same exact problem. Vincent’s fix is deployed as a SharePoint solution, so it’s very easy to install if you have access and rights to central administration and the server itself. His technique is produces a slightly different UI in that he floats the ToolPane so you can move it, and allows you to minimize it at the bottom of the viewport if need be.

I discovered his solution halfway through tackling mine and decided to plow on through anyways. If you don’t have access to the server itself, but can access your site through SP Designer, this solution will probably work for you. If you have some Javascript skills, you can likely modify what I have to make the ToolPane do whatever you want it to do.

Let’s use a visual:

If the above doesn’t make sense, here’s an image that will hopefully explain things better. Click on the image to see a full-size version.

How to use this:

1. Download the ‘sharepoint_fixed_toolpane.zip’ file from this site which contains the .js file and .css file, along with a .png file that we use for a fancy drop shadow.
2. Download fixed.js from DOXdesk. This is a .js file that fixes IE6′s inability to comprehend position: fixed
3. Read through the CSS file and JS files if you so desire and make modifications as necessary. I’ve tried to comment them fully to make it fairly easy to figure out what is going on.
4. Upload these files to your SharePoint site/collection. You could put them in any document library that you’ve given all visitors read access to. You could also put them on a separate server, if you desire. In my case, and for the rest of the example, we’ll use two document libraries created at the top level site ‘admin_css’ (put float-fixed-toggled-tool-pane.css in there) and ‘admin_js’ (put float-fixed-toggled-tool-pane.js and fixed.js in there). The shadow_20.png file was added to an image library named ‘admin_images_portalwide’.
5. Open up the masterpage(s) you are using in sharepoint Designer
6. Add the following lines to your masterpage just before the </header> tag:
   
<!– floating toolpane –>
<script src=”/admin_js/float-fixed-toggled-tool-pane.js” type=”text/javascript”></script>
<link href=”/admin_css/float-fixed-toggled-tool-pane.css” rel=”stylesheet” type=”text/css” />
<!–[if lt IE 7]>
<script src=”/admin_js/fixed.js” type=”text/javascript”></script>
<![endif]–>
<!– /floating toolpane –>
7. Change the BODY tag from this:
   
<body scroll="yes" onload="javascript: if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();">to this:

   <body scroll="yes" onload="javascript:wrapToolPane(); if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();">

   (We’re adding the ‘wrapToolPane()’ function call.)

8. Save/check in/approve the master page and take it for a test run.

What this does:

After the page loads, our javascript function is called. This function locates the HTML that sharepoint produced from earlier javascript and ‘plucks’ it out of the document. It then creates some custom html wrappers, puts the ToolPane HTML back inside that, and renderes it back to the page. Our CSS file (along with the fixed.js file for IE6) then floats the ToolPane above the page content and fixes it to the upper right of the page.

An additional Javascript function allows the end-user to roll-up/expand the ToolPane as needed via the link across the top of the ToolBar.