A client reported user grief in that when users clicked from static hyperlinks they had put on their SharePoint team site page Content Editor Web Part, which pointed to specific nodes on a Managed Metadata treeview menu, subsequent clicks of the browsers back button would not have the normal effect of returning to them from whence they came. In fact the back button in the browser really does nothing at all.
The reason is there is a # symbol at the tail end of the URL. The # symbol is traditionally used to denote anchor tags in HTML. In modern web applications it’s commonly used in AJAX techniques .
In the particular case of links to the nodes in the left-hand managed metadata menu, those links include a tag #serverfilter with a bunch of parameters after that that tell the web browser to go to the specific node in the menu. Unfortunately, as the client discovered, Internet Explorer and some other browsers do not handle browser history normally when navigating via the # tag. Even though you are apparently loading new page content, the browser disagrees, because you are not actually loading an entire new web page – just a dynamic portion of Javascript that is displaying new content.
An example of such a URL is below – the offending #serverfilter and the variables it delivers are bolded.
One of the biggest problems when using AJAX in web development has always been maintaining application state. In a Javascript heavy site (like SharePoint) one might want to do all sorts of things that alter the state of the user experience. For example, opening up modal dialogs (popups) over the page to request input from the user, etc. Because these state changes are occurring only with Javascript the browser is technically unaware of what is going on. If the user decides to hit the back button thinking they are just going back to before they opened a popup, they’ll be surprised when it takes them several steps backward to the last point where their browser actually made a full request. Similar issues occur when they refresh the page. The dynamic state is totally blown away and a new page request is made.
Since the basics of web navigation have always implied that a “new page” is what forms a single unit of web history, you’re not getting the back action as expected when direct linking to items in the Managed Metadata menu tree. Unfortunately this is not a SharePoint-specific problem, it is endemic with lot’s of newer web applications online today from various vendors.
While I personally have coded workarounds for this type of problem in the past, it was for very specific, simple application scenarios (not like the huge complexity of SharePoint). In the case of out-of-the-box (mis)behavior like this I would advise simply that this unexpected back button behavior is the way it is and that users will have to adapt to selective back button history response (as they probably have on other online web applications).
I created the following Excel worksheet to offer a cross-comparison of the Document Management features and capabilities of SharePoint vs. other DMS on the market.
Credit to Wikipedia for the main categories and fundamentals. Obviously the grading system is opinion-based however I added extensive comments in to each of the SharePoint score cells to back up my points.
Edit data only in color coded cells – white cells contain formulas and should be left alone)
Note: If you need to add factors or categories, please see the example tab for more instructions
Title your options: replace “Option 1”, “Option 2” with your option titles
Title categories for consideration in column A : replace “Category 1”, “Category 2” with your category labels
Add factors for decision in each category in column B (for a job, this might be commute, pay, etc.)
Assign weights to categories (column C) so that they add to 100 (see below cat weight column for total). This forces you to understand how important these categories are to you relative to each other
Assign weights to each factor within the categories (column D) so they add to 100 (see above factor weights for total). When assigning weights to factors, concentrate on their relative importance, ignoring factors in other categories
Note: when your weights add up properly, you should have no more red totals visible.
Fill out blue areas with scores from 0-10
Note for negatives, reverse your thinking (so a high score on a negative like Risk means it’s NOT risky)
Note that as you edit scores, the weighted averages are shown as subtotals and absolute totals along the bottom.
For “yes/no” factors, use 0 for no, and 10 for yes.
A basic issue – the client has their Active Directory DisplayName populated in the style of “LastName, FirstName“. Legacy business requirements dictate that the DisplayName stays in that format – but the SharePoint champion comes along and indicates that it would be preferable to have the SharePoint 2010 UI show the users DisplayName in the standard “FirstName LastName” format.
After quickly toying with the idea of using Jquery or some other front-end patch to just reverse the names – complications arose – number one being the data in the DisplayName field in AD was inconsistent, with various flavours and styles of data that was mashed together over the years. Active Directory is aptly named- people will mess up this data actively. Not to be trusted. The solution:
1. Set up the SharePoint 2010 User Profile Synchronization and use custom field mapping.
2. Create a new profile property in AD called customDisplayName and give it the values Firstname Lastname 3. Map the new customDisplayName property to the SP DisplayName property.
So, the end result should be that users would now see their DisplayName throughout the SP application populated with the AD field data “FirstName LastName”
Getting User Profile Synchronization itself planned, configured and deployed is a big task. This post will let help you plan out your first moves.
( .xls download )
Profile sync worksheet tab of the specifies information that you might need to gather if you have not already configured the SharePoint Server infrastructure. It is used with the Configure profile synchronization topic on TechNet. The Property mapping worksheet tab is obsolete; it has been replaced by the User Profile Properties Planning worksheet.
NOTE: When performing the intital setup, it’s important to remember that MS best practice is to not have your Active Directory Domain Controller on the same server as SharePoint. So you need to follow a different path if you are using a dev server with AD and SQL all wrapped into the one server, than if you would be deploying to a production setup with AD DC on a separate server. Spence Harbar in particular notes this in a few places but it will confuse the hell out of you with the AD setup requirements unless you understand the distinct setup paths required for both scenarios.