Saturday, April 12, 2014

Word Cloud: Information Chaos vs. Information Opportunity

I created a Wordle word cloud of AIIM's eBook “Information Chaos V. Information Opportunity: THE information challenge for the next decade”.

Download this word cloud as a hi-res PDF

These are the top 100 words in the paper. I replaced “IT” with “informationtechnology”, or else it would have been filtered out as a common word. I also made everything lowercase so words would be counted together regardless of case.

Wordle: AIIM: Information Chaos vs. Information Opportunity

Saturday, March 22, 2014

Improving SharePoint Designer's Code View

Typeface preferences are subjective. That said, some fonts are just more readable than others. This is true even in "code view". Code editors should generally use a monospaced font (a font where each character is the same width), as this allows us to see patterns within lines of code more easily. But your font does not have to be awful. Like Courier New. Why subject ourselves to an outdated, serifed, monospaced font like that? We have better options!

This is the default view of code in SharePoint Designer, using Courier New, 9pt:

Image of SharePoint Designer 2013 in Code View using Courier New at 9pt

Ugly. Hard to read. In my humble opinion.

To change the code view font settings, go to the File tab, then choose Options. Click the "Page Editor Options" button. Then select a different monospaced font. In the examples below, I chose Consolas and set it to 8pt. The font size change is a different issue, but I like it because I can see more lines of code on the same screen.

Image of SharePoint Designer 2013 Page Editor Options dialog

Now my code view looks like this:

Image of SharePoint Designer 2013 in Code View using Consolas at 8pt

Cleaner. Easier to read. In my humble opinion.

There are other fonts you can try as well. Just make sure you can easily distinguish the characters, such as "o", "O", "0" and "i", "l", "1". The following image shows five fonts set to 8pt:

Image of a table of monospaced font examples

Notice that Consolas is slightly skinnier, allowing you to see more code in less horizontal space. Also notice how clearly distinguishable the numeral "0" is from the letter "O". The lowercase "g" is a little weird compared to the others, but I can live with that given the other benefits.

Happy coding!

Sunday, March 2, 2014

Fixing Enterprise Wiki Page Titles and URLs in SharePoint 2013

Enterprise Wiki pages in SharePoint 2013 (as with SharePoint 2010) are pretty easy pages for users to create and author. There are a few things that bug me and other standards advocates out there, chief of which (for me) are the title and file name problems.

Problems with Enterprise Wiki Page Titles

Create a new page called "My New Page" in an existing page by enclosing that title in double square brackets:
This will create a dashed underlined link that, when clicked, will prompt the user to create the missing page. Easy enough.

Problem #1: Spaces in File Names

The page title is used to create the page's name (i.e., file name), which will contain spaces (even though the form lies and tells us it will replaces spaces with hyphens). The spaces will often be encoded as %20, and this does not follow good URL conventions.

Problem #2: Changing URLs

If the page's author decides to edit the page's name, even if just slightly, it results in a different URL for the page. That is definitely not following web conventions of URLs not changing, and will lead to broken links for any place where you've added the full URL of the page manually as a link.

Problem #3: Unchanging Page Title

The page's actual title attribute will stay whatever the page's initial name was (unless the author actually edits the page's properties). This is not unlike the problem in Office documents where we see and change the file name, often using one file as a template for many others, but the "title" remains the same (and therefore is wrong for all the copies).

Solution for Enterprise Wiki Pages

This solution involves two small code changes and a new Authoring habit.

Modify EnterpriseWiki.aspx

I almost always recommend against changing any OOTB SharePoint files. But in this case, this can be done easily and does not risk breaking anything else or causing significant upgrade issues later.

Open the site in SharePoint Designer 2013, and open this file:
Note: It is a good idea to make a copy of this file somewhere, even if it's just your desktop. You know, just in case.
  1. Find the content place holders with IDs PlaceHolderPageTitle and PlaceHolderPageTitleInTitleArea.
  2. Edit the SharePoint:ListItemProperty for both content place holders by adding a new property called Property with the value of Title.
  3. Next, find the SharePoint:FileField control with ID PageNameInEditMode
  4. Add the following code just below that line:
    <b class="ewiki-pagename-align"><SharePoint:FieldLabel FieldName="Title" runat="server"/></b>
    <SharePoint:TextField id="PageTitleInEditMode" DisableInputFieldLabel="true" FieldName="Title" runat="server"/>
    It should look like this:
  5. Save and close.
Now the page will display the Title property instead of the Name (i.e., file name). The edit form will show both the Name and the Title (similar to list view edit forms). You can test it by changing the Name of a page and then looking at the displayed Title and tab Title compared to the URL.

Edit Page Names When Authoring the Content

  1. Create wiki pages as normally done with the square bracket method. In our example, it is [[My New Page]].
  2. Save and view the page with the new link, and click on the dashed underline to create the new page. Ignore the URL it gives you on that page; it is still wrong.
  3. When editing the new page, modify the Page Name to conform to your URL naming conventions. You can use camel case (e.g., "MyNewPage") or convert spaces to hyphens (e.g., "My-New-Page").
  4. Save the new page.

Automatic Link Updates

Now you have nicer URLs and Titles, but what about the links that reference this new page? These get updated automagically.

To test, go back to the page on which you created the link by adding it in square brackets. The link should now have no underline or a solid underline (depending on your site's CSS), indicating that the file does indeed exist. Click the link, and you should get to your new page. Then check the URL in the address field of your browser against the title on the tab and page.
Quicklaunch and global navigation also get updated if this link appears in either.

Using Square Brackets for Links

You can still use double square brackets for linking to your pages this way, but SharePoint uses the page name, not its title, for this. So to make links show nicely, get used to typing "[[My ", etc. to find your page, and then type a pipe (|) and the page title or other link text you want to display, then close your brackets "]]". Example:
"[[MyNewPage|My New Page]]"

One small quirk occurred in my original testing: The page's link from the Quicklaunch did work, but the actual URL of the link was different. Instead of:
the URL was:
This URL is the "term-driven" URL that exists when using Managed Navigation. The problem is that these don't seem to be automatically updated when you change the page's name. So if you used Managed Navigation, you will probably have to manually update your terms' URLs in the Term Store Management Tool for the site collection.

I hope this is helpful. I had been reluctant to use the Enterprise Wiki site collection template in SharePoint primarily because of the above problems. Now I expect to use them more. There are some other enterprise wiki features that would be nice (I used Atlassian Confluence for a while, and that was really nice and flexible), but this will work for now.