The Ribbon and the Classic forms will be phased out in Orion. It will be replaced by the far less visual Command Bar with much less features visible by default.

We’re seeing the ribbon hidden in Office applications too.

For an example of this, you can check out http://tomshardware.com

This feature is extremely easy to implement in SharePoint!

1. Create an XML “OpenSearchDescription” file, and store it in the style library.
2. Write a link to the XML definition file in your master page.

Update: It should probably be noted that there is a broken feature in the SharePoint 2010 basic search center which attempts & fails to inject a similar open search description using a file called “/_layouts/srchconnectorgenerator.aspx”. I’ve not seen this actually work (it throws up a correlation ID which I haven’t the time to investigate), and it doesn’t provide a link on the root site, so it’s unlikely to be picked up by chrome.

Should also note that this affects a similar (but less used and less useful) option in Firefox, and versions of IE below IE9:

Related ideas:

• “Pin to Start” metadata for IE
• Configuring “Apple Touch Icon”

In my testing with IE9, I have found that various pieces of functionality do not work as expected with these solutions. The reason for this is as follows: SharePoint 2010′s IE9 support was tested and developed for IE9 running in IE8 compatibility mode, but these solutions typically disable the compatibility mode, breaking basic SharePoint functionality in the process.

Specifically, the tag…

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

… has been either removed, or changed to one of these alternatives…

<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>

It would be great if this worked, but the unfortunate truth is that there are various pieces of critical SharePoint functionality which simply don’t work if this is changed. Solutions which change this tag do not stand up to basic functional testing. Here are just a couple of irresolvable breakages that occur when using IE9 in non-compatibility modes:

• Resolving people in the people picker doesn’t work
• “Non-enhanced” rich text column in edit mode
• The above issues can cause “OK” buttons in form dialog boxes to break (e.g. calendar dialog boxes)

(If you’ve found other functionality which is broken, please report it in the comments.)

I cannot think of an intranet deployment I’ve worked on where this would not be a “breaking” issue. This is stuff that’s in the ‘team site’ template (i.e. the calendar). The people picker and rich text fields are key functionality, used by various core templates inside SharePoint.

It’s all too easy to forget that we’re working on expensive, comprehensive enterprise software which is expected to perform reliability and quickly in a business context. I would encourage branders to become more familiar with the ways in which SharePoint is used and configured, and to test those scenarios thoroughly when attempting to radically change the appearance of SharePoint – even if that testing isn’t automated or easy.

It’s possible that modifying the underlying browser.compat in SharePoint may allow the use of HTML5 features – but there are no published sources that suggest this might work, and this would create an unsupported configuration.

In the mean time: use shims, and test responsibly.

Update: I contacted bind.pt regarding this issue: they have told me that they are aware of the issue, and have added an item on their knowledge-base which covers it. I have confirmed that this is still the case with their latest theme (Flexo) as of May 23, 2012.

My Related Gists: 

• On-demand (a.k.a. reliable) IE9 rendering for SharePoint 2010 Master Pages.
• Code sample: Modify Schaeffer’s v5.master to be IE compatible

Useful Shims

• CSS3 PIE
• jQuery.corner.js
• Modernizr

Video:

Well… Yeah. But don’t expect it to help much when it comes to SharePoint! We know that SharePoint vNext will have a Metro look and feel, but that doesn’t necessarily mean that SharePoint will be be joining Dynamics as a Windows-only ‘Metro Wall’ application. SharePoint has far too many legacy restrictions to become a pure Metro Wall + WinRT app. Reality check time:

• Development of SharePoint 15 is a huge effort, probably started well before WinRT was spec’d.
• Office 365 is sold as a cross-browser, cross-environment solution. It can’t rely on Windows 8 features. It has to work on Macs, Windows XP, etc.
• Office vNext doesn’t live inside the Metro Wall – it will be a desktop app.

So… hold up, and in the mean time, check out this neat client-side app stack diagram from the “Single Page Applications” guidance @ www.asp.net, and stay tuned for more tips!

A client-side application stack diagram from Microsoft.

Don’t forget to subscribe!

This is the first example of an enterprise app for the Windows 8 metro ‘wall’. More info about the demo is available at ZDNet.

The one hour keynote is available online behind a short registration form at msconvergence.com (demos start around 40 minutes in).

Click for full size

My guess: What a metro enterprise app might look like.