A Matter Of Degree

First Look at Data from the SharePoint Maturity Model

A big thank you to all the folks who came out yesterday to the first ever SharePoint Saturday in Hartford!  The event was sold out and many of the sessions were standing room only.  The folks from New Horizons, Third M, and CTDOTNET did a great job organizing and running the event.

I presented the SharePoint Maturity Model (an updated version of the one I released on End User SharePoint back in November), and I want to extend a very special thank you to the attendees from my audience who turned in their SMM self-evaluations.  Your results are the seed of a data model that I plan to expand and build out in the coming months and years, to be a resource for those who are looking for answers to questions like:

• "For my industry and company size, how far along are similar organizations with their SharePoint implementations?"
• "After n years of SharePoint use, where do companies typically fall in the maturity model?" 
• "Is maturity correlated with number of years of SharePoint use, with SharePoint version year, or with investment in Enterprise vs. Standard?"

Although the data set is small and limited in the industries covered, I'd like to share yesterday's results here to give a sense of the potential of this assessment:

 

 

 

 
 
 
That last graph is making me smile - the insurance companies (which reported tens of thousands of users) are further along with their business process maturity, whereas the IT Consulting firms are big on the customizations - shocker!

My presentation from yesterday can be found on SlideShare. 

An Excel spreadsheet that you can use to graph your own maturity levels (with the format of the spiderweb graphs above) is available for download at http://bit.ly/SMMExcelTemplate.

Thank you again to everyone, it was a great day!

 

Thanks, Microsoft, for providing More White Guy

Thanks, Microsoft, for providing More White Guy, originally uploaded by sadalit.

Microsoft just launched the SharePoint 2010 Sneak Peek site - where the target audience seems apparent from the images they chose to represent the different roles.

When I think of all the women I know who use, configure, and develop for this software product, I feel this new homepage is a misrepresentation. It reminds me of reading an an article or textbook from the 1960s where every pronoun is "he" or "him." Why not mix it up a little?

See the full home page here: http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx

How to make "This Site" the default SharePoint search scope

A client recently asked how to make "This Site" the default SharePoint search scope from the simple search box on all pages.  "This site" does not appear as an option when you try to manage this via the GUI (Site Actions | Site Settings | Site Collection Administration section / Search Scopes), so you can't set it as the default there.

I found the answer on this thread on SharePoint Blogs / SharePoint University:

http://www.sharepointblogs.com/forums/t/16293.aspx?PageIndex=2

and I wanted to reproduce it here with a few additions.  User Monty Myers (monty.myers) posted the following; my additions are in red:

Add or Modify the following line in the OSearchEnhancedFeature.xml file located in 12\Template\Features\ : (The full path is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\OSearchEnhancedFeature, then open the SearchArea.xml file in NotePad)

This is the line of code you will add:

<Property Name="DropDownMode">ShowDD_DefaultContextual</Property>

The bold line below shows where the line of code needs to be added: 

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Control
        Id="SmallSearchInputBox"
        Sequence="15"
        ControlClass="Microsoft.SharePoint.Portal.WebControls.SearchBoxEx" ControlAssembly="Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
 <Property Name="GoImageUrl">/_layouts/images/gosearch.gif</Property>
 <Property Name="GoImageUrlRTL">/_layouts/images/goRTL.gif</Property>
 <Property Name="GoImageActiveUrl">/_layouts/images/gosearch.gif</Property>
 <Property Name="GoImageActiveUrlRTL">/_layouts/images/goRTL.gif</Property>
        <Property Name="UseSiteDefaults">true</Property>
 <Property Name="FrameType">None</Property>
        <Property Name="ShowAdvancedSearch">true</Property>
 <Property Name="DropDownMode">ShowDD_DefaultContextual</Property>
    </Control>   
</Elements>

After making the change, save the file and do an IISreset. 

Important:  when you customize the SearchArea.xml file, it is unghosted, meaning that future patches and upgrades could overwrite your changes.  As a best practice, you should create a feature to install this unghosted file to current site collections and deploy the change in this manner.

SharePoint lookup to document library can't see all documents, or only sees documents of a certain file type (Word, Powerpoint, etc.)

This question from a client this week - why is it that when I lookup from a list to a document library, I only see Word documents even though there are Excel and PDF files in the document library too?

The client was using a multi-select lookup field, but the same thing happened with a single-select field. 

I recreated the scenario with a document library like this:

 

And in my case, the lookup returned only three choices:

 

It's not a content type or file type issue, it's simply that the Title field was not filled out for all the documents.  When the Title field is blank, the lookup acts as if those documents don't exist. 

I have often wondered why you're not allowed to look up to the Name field of a document library.  To my mind, you should be able to, since Name is the primary key field for the document library, just as Title is the primary key for other kinds of SharePoint lists.  But since it's not possible in this version, it's another example of why it's a best practice to fill out the Title field of documents, either on upload or after the fact.

Issues with Manage Content and Structure Move / Copy functions in MOSS 2007

I like the convenience of using Manage Content and Structure to move batches of files from one document library to another, while maintaining their metadata (custom fields as well as metadata like "modified by" are brought over from the source library to the target library).

However, I have been seeing some strange and concerning results, mostly having to do with content types.  In a recent example, I had a library of documents with a yes/no checkbox to allow for displaying certain of the documents in a view on the home page.  Another library needed to be merged in with this one, which had the same yes/no checkbox (same column name).  I recommended that my client move the files from one library to another using Manage Content and Structure.  After she did this, she reported that the documents from the merged library were not apperaing on the home page view even though she had checked "Yes."

When I looked more closely at the document library, I saw that there were now two identical fields for the yes/no choice in the same document library.  SharePoint had copied one over and kept the original - and the values were different in each field.  (In the field properties, I saw that the system had appended "0" to one of the column names on the back-end.)

In this case, it was a simple matter of making sure all the data matched from one column to another, and then deleting the duplicate column.  But in some cases (e.g., when the Move function added the "Publishing Start Date" and "Publishing End Date" fields to a document library) I've had to switch on "Allow management of content types" and hide the extra fields that were added during the move process so that my end-users wouldn't be confused by the newly-added fields.

Consider this a word of warning - Manage Content and Structure may beat Explorer View in terms of convenience and speed when moving batches of files, but it can cause unintended outcomes that could take you more time to troubleshoot and fix in the long run.

Not possible to use customized view with a KPI List

I'm trying to get a very simple KPI list working for a client's home page, and am finding that I am unable to customize the list view in any way.  Lots of questions about this out there, but no answers I could find. 

One forum respondent suggests using the "Display multiple indicators columns" section, but these options are grayed-out for me, as they are for others.

What I want to do is remove the "Goal" and "Value" numbers and add the "Detail Link" to the view so that it displays title, traffic light indicator, and link. 

I can get halfway there - the "Goal" and "Value" columns can't be hidden in a standard way (i.e. by removing them from the view) but can be suppressed by checking the "Show only status icon" checkbox in the Modify Web Part tool pane.  Not intuitive,  but OK.

But for the "detail" link - When I customize the views in the original KPI list I get some very buggy behavior - i.e. the view does not reflect my modifications even though my custom settings are saved when I return to "modify this view" mode. 

It's not possible to convert the Key Performance Indicators web part to a data view in SP Designer, as you can with most other list and library web parts.  The same is true for the KPI Details web part.

Extremely frustrating.  I could create my own conditional formatting using custom code, however my goal is to deliver an easily-maintainable solution to my client, using as much out-of-box functionality as possible.

If anyone has found a workaround for this, please let me know!

Opinions about the Quick Launch bar in SharePoint / MOSS 2007 / WSS 3.0

Note:  the opinions expressed in the list below are not necessarily those of the author, but rather those of a selection of the author's clients.

Regarding the items on the Quick Launch bar navigation on most sites:

1. The People and Groups link is confusing and needs to be deleted.
2. The headings don't fit my organization.  (e.g. We call our locations "sites," so the heading for sub-sites can't be called "Sites.") 
3. The headings are confusing.  I don't understand the difference between Documents and Lists.  I really don't care what the difference is.  And why is there a Discussions heading if there is no content under it?
4. I can't find what I need.  (Translation:  The Quick Launch bar and its contents are invisible.)

As I envision the 2009 release of SharePoint, I'm wondering how these common complaints will be addressed.  In MOSS 2007 it is easy to change the navigation headings on a site-by-site basis (not so for WSS), more complicated and risky to change them globally (i.e., your edits to the onet.xml file that governs these headings could be overwritten by an upgrade or patch).  Are headings needed at all?  Should MS do away with the Documents / Lists / Pictures / Discussions model and let the site owner structure the quick launch bar as content is created?  Or define the headings at the outset, the way the Site Map's categories can be defined and then accessed every time a site is created?

Or, given #4, is the quick launch bar a flawed concept?  I have witnessed end-users look for content on a site and never glance at that section of the window, and I have heard the same story from my content-owner clients - "I told him exactly where the link was but he still came back and said he couldn't find it."  I've worked with SharePoint long enough that I strongly support the local content / global content model, but many clients seem to want static content (e.g., a "hot list") in the left nav as well as across the top of the page. 

The Quick Launch Bar and its headings - useful or not?  What do you think?

The SharePoint Infrastructure Update - what we're recommending

On July 15, 2008, Microsoft announced an Infrastructure Update for Office Servers.  There were a number of issues with the release, and our SharePoint team recommended that the update could be applied to simple farms with one web front end server and custom development, for more complex farms, it was advisable to wait for a rollup of subsequently issuefixes.

That time has arrived.  The cumulative update was announced on September 29, 2008, and has received the blessing of our senior SharePoint resource. 

The update includes the new Enterprise Search features that were shipped in Search Server 2008 and Search Server 2008 Express (which had not been part of MOSS 2007), including the Federated Search capability, a unified administration dashboard and several Search performance updates.  It will also fix some known issues, such as the post-SP-1 issue where a workflow cannot be triggered by incoming email to a list or library. 

We are strongly recommending that our clients create a development Sharepoint environment which mirrors their production environment, so that the cumulative Infrastructure Update can be tested there before touching Production.

Please note that the update is not a single process, but involves several steps which depend on your environment and which must occur in a particular order, listed below, which is taken directly from the SharePoint Team Blog:

To keep all files in a SharePoint installation updated, we recommend customers to follow the path below:

1. Windows SharePoint Services 3.0 Service Pack 1

2. The 2007 Microsoft Office Servers Service Pack 1

3. The Windows SharePoint Services Infrastructure Update x86 x64

4. The Microsoft Office Servers Infrastructure Update x86 x64

5. KB 953397: Excel Server Security Update x86 x64

6. KB 955586: Document Lifecycle Workflow Update

7. August Cumulative Update for Windows SharePoint Services 3.0 (Global)

8. August Cumulative Update for Windows SharePoint Services 3.0 (Local)

9. August Cumulative Update for Microsoft Office Servers

After applied all these updates, run SharePoint Products and Technologies Configuration Wizard or “psconfig –cmd upgrade –inplace b2b” in command line. This need to be done on every server in the farm with SharePoint installed.

The version of databases should be 12.0.6327 after all these updates.

 

 

 

Make your SharePoint Designer workflow-generated email better-looking and more usable

Today I needed to include a link back to the current item in a SharePoint Designer generated workflow, and found this MS Office Online how-to that gave the steps I needed, plus much more, including how to dynamically select users or groups to receive the email, include an image, etc.  A great reference that I'll be turning to again and again.

Mesh - for when the word "web" is already taken

A client turned me on to Live Mesh today - a Microsoft product which promises to "put you at the center of your digital world, seamlessly connecting you to the people, devices, programs, and information you care about—wherever you happen to be."  Upshot: you add the devices you use (computers, mobile devices), add files, and then you can access those files from any of the devices. 

 

It's designed for collaboration (you can share a folder with others, similar to MS Groove or to the now-defunct Tubes), and as with Windows Live Spaces, you'll see updates about what has recently changed within your mesh.   Unlike Windows Live Spaces, you can't post a public file for consumption by anonymous end-users; it's an invite-only model.

It's still in Tech Preview, which means the feature set is not, ehm, complete:

   

Also, mobile devices can't be added yet.  When they can, things should get interesting!

More Information:

LiveMesh Team Blog