A Matter Of Degree

SharePoint 2010 - Global Navigation Tabs wrap!

I have been working with the beta 2 release of SharePoint 2010 for a few weeks now, and just today realized what I was seeing:  the Global Navigation tabs now wrap when there are enough top-level sites that they don't all fit across the width of the page!  No more scrollbar when you start to have "too many" sites!

 
  
When I think of all the client requests I received about this, and the custom development I saw implemented to achieve it, I'm very happy this is a feature of the new version - although the dark side of this is that folks may now be tempted to leave good Information Architecture principles aside and build top-level sites to their hearts' content.  I think the dreaded homepage scrollbar of MOSS 2007 was a major factor in keeping top-level tabs to a minimum, as well as keeping the names of those tabs short and to the point, neither of which is a bad thing.  With more freedom to build and name sites without the penalty of making the page too wide, site admins may be tempted to stray from the generally recommended 4-8 top-level tabs and potentially cause usability problems (especially if drop-down navigation comes into the mix).

But enough governance.  Global tab wrapping is a seemingly small but often-requested piece of functionality that ultimately makes SharePoint 2010 a more flexible tool.

Key Points from The Laws of Simplicity, by John Maeda

Maeda's SIMPLICITY, originally uploaded by Pretz.

I just finished reading The Laws of Simplicity, by John Maeda. It describes ten "laws" and three "keys," two of which I found particularly striking and relevant:

Law 6 - Context - "What lies in the periphery of simplicity is definitely not peripheral."
To illustrate this law, Maeda describes a meal he had at a friend's apartment, where all the furnishings and surfaces were white. When the meal of sushi was served, the bright colors and interesting textures of the food stood out in clear contrast to their surroundings, and Maeda's friend told him, "The taste of this meal is affected by the room we sit in." Maeda expands this notion to doing work - "The 'taste' of any activity we face might be mixed in with the distaste of the clutter of our desk. But coincidentally the uplifting smile of a nearby child can sometimes help us to tune out any messes at hand. Being attuned to what surrounds us in the ambient environment can sometimes help us manage what's immediately in front of us. Synthesizing the ambient experience of simplicity requires attention to everything that seemingly does not matter."
For me, this law captures in words the experience of doing project-oriented work as a consultant. Customers hire my company to achieve a specific goal, and I go in to meet stakeholders, gather requirements and start building toward that goal. In a statement of work it's all pretty basic, but in the periphery of my time with the customer, so many factors affect the work:

• The other demands and constraints on the time of the resources I need at the client site
• The financial health of the company (e.g., recent layoffs and the threat of a second round)
• The general level of training and tech-savviness of the end-user community
• The degree of cohesiveness or dysfunctionality of the customer's IT team
• The work space (nice conference room or storage area?)

I could go on, but it's enough to say that I'm happy to have found a concise way to sum up all the complexity around building straightforward, usable solutions for the client.


Law 10 - The One - "Simplicity is about subtracting the obvious, and adding the meaningful."
This one applies to life as much as to work, and is self-evident enough that Maeda only spends a page and a half on it. It's a great ruler by which to measure any effort toward simplification.

In searching for an image to illustrate this post, I found this bonus bit of advice (which as a quote returns no results in Google and isn't specifically tagged with its keywords in Flickr):

"Design is not to be poured like gravy over a mistake."

MOSS 2007 folks - If you're using the Site Directory web, put an alert on your Sites list!

I'm at a client site today, finishing up a MOSS 2007 intranet for launch this week.  I just viewed the Categories tab on the client's Site Directory when logged in as an end-user.  We customized the categories to reflect the organization, and filled them out with links for each division.  As an admin I can see five links under a particular division, however the end user could not see any of them. 

The Sites list (which can be found under the Site Directory tab, by choosing View All Site Content) can be manually built to include links either inside or outside your intranet, but also receives automatic entries anytime someone creates a site and checks "List this new site in the site directory." 

 

These entries go into a "Pending" state even if they're created by an admin (which could be defined as in the "Owners" group, and/or having Full Control rights over the site, and/or a Site Collection Adminstrator). The result is that only admins can see the Pending links. If there are content owners with Manage Hierarchy rights who are out there creating sites, the admins have no way of knowing when new links have been added to the Sites list.  The Site Directory is being populated but none of the end users will be able to see the additions. 

To ensure that your Site Directory is up-to-date and useful, set an alert on the Sites list to notify at least one of your site administrators when a new link is added.  This seems like simple common sense, but my thought in posting this is that if it hasn't occurred to me in 2+ years of working with MOSS 2007, there's a chance that others have missed it as well.

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?

Software as a Service, and Surprises

Yesterday morning as I was getting ready to leave for work, my husband came into the kitchen, iPhone in hand, and said to me, "Updater!" 

"Huh?"

"So many updates - what are you doing?" 

All he knew was that overnight, "something changed," and now he was seeing updates he'd never seen before - activity from my Delicious, Twitter, LinkedIn, Youtube, and Flickr accounts, as well as posts to this blog.  Turns out he was talking about the New Facebook, though he didn't know it.  I hadn't changed my level of activity, or considered any of this activity to be a secret, but when it was aggregated in one place and switched on overnight, the sheer volume of it was shocking to him.  That morning, the phrase "web 2.0" was introduced in our household, spawning a dialogue about the demise of face-to-face interaction and local community (his angle) and the human drive toward (and tremendous advantages to be reaped from) sharing and learning through networks (mine).

The destruction/evolution of our society aside, this conversation seemed significant to me because it was such a powerful example of the way the software-as-a-service model which we're adopting more and more can deliver some pretty disruptive punches. 

The online apps we use all the time release updates often with no warning; we might wake up to a different interface than we used the night before, or an unwanted new feature (the Twitter "Hot Political Topics" bar, anyone?), or more radical changes if the app went from beta to the next numbered version.  For the developers, it's all about improvement; but for human end-users, change usually isn't comfortable. 

That's one thing if the agreement is between an individual and a provider, and the service is free.  At the enterprise level, it's another. The upsides and downsides of SaaS are much discussed, but mostly the discussion centers around economics, flexibility/scalability, and security.  I haven't found a lot of consideration given to the need many user communities have for communication, marketing, training, and overall hand-holding as software evolves, and how likely (or unlikely) the SaaS providers are to handle this need. 

Do you have a Software-as-a-service story to share on this subject?  I'd love to hear it.

Props to my colleague Mike G. for planting the seed that grew into this post.

MOSS 2007 + PowerPoint 2007 = no slideshow view from browser

Today one of my clients alerted me to this issue:  There is no easy way to view a PowerPoint presentation as a slide show directly from a SharePoint document library, and without the slideshow view, any embedded links in the file aren't clickable.  Read this thread at SharePoint University for more detail.

In the end, there seem to be two options (assuming you're not interested in hacking the registry for all users):

1. Train your end users to go through these steps: 

         Open the file in PowerPoint and switch to slideshow view

         or

         Right-click on any URL and select Open Hyperlink from the drop-down menu (no CTRL-click!)

2. Save the presentation in an alternate format, and maintain two copies.

Upshot:  pain for the content owner, or pain for the end user, your choice.

File downloaded from sharepoint document library replaces spaces in file name with underscores

I have been noticing for some time now, in several MOSS implementations, that spaces in filenames are replaced with underscores on file download/upload from SharePoint.  I was blaming this on SharePoint SP1, since I started to notice it around the time of that release, however this discussion on MSDN indicates Internet Explorer 7 is the reason.

To see the behavior, find any document in a SharePoint document library with spaces in the filename, or upload one.  Then download the document to your desktop - you can see that the underscores are added in the "Save As" window.

If you are working quickly and not expecting this filename change to happen, you would save the document to your desktop, make edits, and then re-upload it later.  Since you didn't actively change the filename, you would expect the document to save over the original in the document library.  This is the way SharePoint has traditionally worked.  But what you end up with is two copies of the document in the document library. 

 

Disclaimer - I'm sure we can all agree that the best practice in general is to check out / check in your document rather than downloading it to your desktop.  (The underscores are not added during checkin/checkout.)  But what if someone else has the document checked out, and you can't reach them to ask them to check it back in, and you're under pressure to make edits right away?  Or what if you thought you were just taking a copy, but the edits you make on your desktop turn out to be the preferred version?    Or what if you haven't fully tested the offline sync capabilities of MOSS 2007, and you want to be absolutely sure the document is accessible when you're offline?  These and many other real-world situations could lead to this downloaded-file scenario, which could lead to multiple copies of the same or similar documents in your SharePoint environment, which is exactly what most of us are trying to avoid. 

The MSDN thread proposes a workaround, although I will argue that the adding of underscores is not necessarily a bad thing, expecially since SharePoint can cause problems when working with filenames that include spaces.  I think it's important to be aware of this download behavior and to work toward minimizing the multiple-copies effect - emphasize checkin/checkout vs. download in end-user training sessions, for example.

Eleven ways to make your SharePoint implementation more user-friendly

 

Based on my two years of working with customers' MOSS 2007 implementations, and some of the great ideas my customers have had, here are eleven ways to improve the usability of your SharePoint implementation for your end-users. (Note: These five suggestions work for MOSS 2007; not all work for WSS 3.0. You may need web server administrator, Site Collection Administrator, and/or "full control" permissions in your portal to perform these customizations).

 

1.      Make the banner logo link to the Home page.

Hopefully Microsoft will include this functionality in the GUI in the next version, so that you can link to Home when you add a logo image to the header, but for now the quick and easy way to do this is to edit your master page and insert the following code in the following place, and then save, check-in (publish) and approve the master page:




        <td id="GlobalTitleAreaImage" class="ms-titleimagearea">
<a href="http://yourportalname/Pages/Default.aspx">
<SharePoint:SiteLogoImage id="onetidHeadbnnr0" LogoImageUrl="/_layouts/images/titlegraphic.gif" runat="server"/>
        </a></td>

2.      Remove unused web parts from the Web Parts gallery.

When your content owners are adding web parts to their pages, there are web parts which may be confusing to them, or which you may not want them to use until they receive training. You can set permissions on web part files so that they will not appear if the user doesn't have rights to see them. To do this, from the top level site of your portal, choose Site Actions / Site Settings / Modify All Site Settings. Click the link for Web Parts in the Galleries section. You will see the Web Parts Gallery which is a document library. For the web parts you want to hide, click the Edit icon, click Manage Permissions, click Actions / Edit Permissions, and remove the permissions for those groups who don't need to see the web part.

3.      Use the Table of Contents web part on empty top-level sites to avoid blank pages.

If you have sites grouped under a top-level site, such as Departments or Practices, but you don't have any content to display on that top-level site, your users may click on that tab and see a whole lot of nothing on the home page. You can place the Table of Contents web part here to display a dynamic site map of everything under that top level.

4.      Link directly to a list form without using a too-long URL.

When you convert your paper forms to SharePoint lists, you will probably want to link your end-users directly to the data-entry form for the list, rather than to the list view that shows the existing items. However, the "New Item" URL is very long, and it won't fit in the URL field of a SharePoint links list, with the result that a user will click on the link to get to, say, an office supplies request form, but they will receive an error when they try to save the form because the URL is incomplete. To solve this, try my colleague Florin's solution for making tiny URLs in SharePoint. You can include the tiny URL in a Links list URL field with no problem.

5.      Make sure all the content is in the same place on similar pages.

Seems like a no-brainer, but as content owners take over and your intranet grows organically, different power users will have different ideas about how their sites should be organized. To get a consistent look across all department, client, project, or location sites, create a custom template at the outset, build all the sites using this template, and train your content owners to use it if they need to create a new site in that category.

6.      Look at the Site Usage Report for your sites.

What are people accessing? Could you move popular but deeply-nested items to a higher level, or expose them better via links or web parts? To access Site Usage reports, this functionality needs to be turned on in Central Administration (in two places – Operations / Usage analysis processing, and Shared Service Provider / Usage Reporting). You can then view the reports on any site at Site Actions / Site Settings / Site Usage Report.

7.     Put default values in list fields (columns) to help validate data.

Although there is no true validation capability in an out-of-box SharePoint list form, you can show your users how you want data to be entered with the default value (in the column settings). For example, for a phone number field, you can include a default value that shows whether or not you want parentheses, dashes, or spaces to be included in the number. This will work along with the description field to tell your users how you'd like them to fill out the field.

8.     Always add a description. Everywhere.

Columns, lists, libraries, sites, templates, and many other SharePoint features provide an optional Description field at the time of creation. It's a best practice to fill this in with a brief sentence that describes the item, even if you're just prototyping, because this description will guide the end user later (and appears in places you may not expect). For example, when you create a document library, the description for that library appears in the Add A Web Part menu. On a site with multiple libraries, the description you enter will help the end user choose among the libraries to place the right one on the page.

9.     Move items around on the Quick Launch bar so it makes more sense.

The Quick Launch bar is dynamically generated and displays content as you add it to the site; however you have control over how the items appear. For example, when you create a sub-site, it always appears at the bottom of the Quick Launch, but if it receives heavy traffic and/or you want to highlight it for your users, you can move the link to the top. To do this, go into Site Actions / Site Settings / Navigation, and in the Navigation Editing and Sorting section, you can click on any item and move it up or down in the listing. And while we're on the subject of Navigation -

10.     Add a heading in Navigation.

The Quick Launch bar is created with standard headings (Documents, Lists, Surveys, Sites) to group your content, but you don't have to use these. You can group the Quick Launch bar in the way that makes sense for your site and organization – for example, by phase:



To do this, go into Site Actions / Site Settings / Navigation, and in the Navigation Editing and Sorting section, you can edit existing header names, or delete them and add your own.

11.     Target some content.

This one can be more complicated to set up than the above suggestions, because some prerequisites need to be in place, but it can really add value. Two common examples of where this can be useful are 1) if you have an announcements list on your portal home page where some items are intended only for certain geographical locations or organizational roles, or 2) if you have a links list of mission-critical applications and information, and some of these links are only used by certain groups within the organization. If you have AD security groups (or SharePoint audiences) set up correctly, you can deliver this content to the users who need it, with the result the others don't even see it. For a detailed how-to, read Microsoft's online guide about targeting content in general, and if you're considering targeting a links list, read this essential how-to on getting the Content Query Web Part to display the links list correctly.

 

Workaround for the MOSS 2007 This Week In Pictures Web Part Slideshow Function

Most of my clients want to incorporate a rotating-image web part on their intranet home pages, and most of them dislike the MOSS 2007 out-of-box This Week In Pictures web part because when you click the link for "View Slideshow," the slideshow opens to display the first picture in the image library, not the image the web part currently displays. Aside from developing your own web part or purchasing one from a third-party vendor, there is no way to make that slideshow link point to the currently-displayed picture (There is no view choice field on the web part, and changing the sort order of the "all items" view has no effect on the slideshow).

One of my clients recently designed a workaround to this issue. She asked me to put a workflow on her Picture of the Week image library which would move past pictures to a second picture library. This workflow is a simple one to build in SharePoint Designer; see screenshot below. When she adds a new picture, she changes a metadata field on the previous picture from "Active" to "Past." This change kicks off the workflow, which automatically copies the previous picture to the Past Pictures library and then deletes it from the current picture library. The result is that the "view slideshow" link always points to the picture that is displayed.

This way you can upload multiple photos that are associated with the main picture (for example, a series of pictures from a company outing), and they will be shown together in the slideshow. We put a "View Past Pictures" link under the web part so that employees have easy access to the archive of previous pictures.

Gripe about the field description placement in SharePoint

Some of my clients are complaining about the placement of the field description in SharePoint forms, and I agree with them. When you create a field, or column, you have the opportunity to enter descriptive text that will appear on the form, which can be valuable in telling your users how they should fill out the field. However, this text appears below the field data, which is inconvenient for single-line fields, but which really poses a problem when the fields are more complex:

Your instructive field description gets lost, and may even make users have to do double work if they read your instructions after they've already entered data (not to mention the fact that if you're converting a paper form, you'll have to think about the descriptions as you enter them and not use terms like "below").

One of my clients was ambitious enough to create a custom form specifically to solve this problem. She placed the descriptive text below the field name, using a slightly different type style for the description than for the field name. The hitch is that custom forms need to be created from scratch; you can't modify a list's existing New, Edit, or View forms in SharePoint Designer to make a relatively simple change like this. If you want the descriptive text to appear consistently on both New and Edit forms, you'll have to create two forms. In my client's case, the investment of time and effort was justified because her internal customers gave the description placement high priority in their requirements, and because the form is a fairly long one which will be used regularly by every employee in the organization. But smaller, simpler, or less-frequently-used forms may not justify the extra hours it would take to customize them.

Now here's the really maddening thing. Microsoft has placed the field descriptions under the field name on some of their own internal forms, for example, the Change Column form for any list or library:

Which raises the question: If Microsoft's form designers decided that this was a good placement for the field description, why don't end-user list and library forms have the same layout? Why are content owners forced to work with (or around) a less-intuitive design?

This is one of the big items on my wish list for the next release.