5 experience-related things I’d love to see in SharePoint vNext

It’s more than two years since the last version of SharePoint has been released. Comparing to SPS 2003, MOSS 2007 brought us a very rich environment with tons of new features. As we all might expect, the SharePoint product team is really busy with the new version of SharePoint and I assume that many of us can’t wait to get their hands on it. Looking at the calendar however, it’s probably going to be at least the end of this year until the public release of the new version of SharePoint will see the daylight. Since there’s still some  time left, I’ve decided to share with you a couple of things I would love to see in SharePoint vNext.

Initially I wanted to write one article. During the brainstorm however I’ve found out that there were quite a few things I’d love to see in SharePoint vNext. That’s why I decided to split the whole thing: Part #1 – Experience.

**Please note **All the things I’ve described below and will describe in the following posts are things which I would love to see in SharePoint vNext. I really have no idea of what the SharePoint Product Team are working on for the new version and there is no guarantee that you will see any of these features in SharePoint vNext,

More Silverlight please!

Silverlight is really cool and allows you to create great experience for web applications: ways easier than you would do using HTML and JavaScript. Since the very beginning the Silverlight team are trying to do their best to provide a cross-browser support for Silverlight. So far all modern browsers support it. Because there is no browser dependency it is a lot easier to create a seamless cross-browser experience using Silvelright. WSS 3.0/MOSS 2007 interface works properly only in Internet Explorer 6+. Replacing the current UI with Silverlight would enable more users to fully benefit of all the functionality that SharePoint provides.

One of the challenges I could imagine could be to make the Silverlight-based interface pluggable so that developers can customize it to meet the solution requirements: like adding/removing buttons, etc.

…and less Ribbon

People all over the Internet have been speculating for quite a long whether the new version of SharePoint would or would not include the Ribbon. Probably the main reason that people were talking about it in the first place was that it was already present in most of the Office 2007 clients and because SharePoint integrates with the clients it would be “cool” to have a seamless experience. Well it wouldn’t.

SharePoint was, is and will remain a web application accessible through a web browser. We already have a toolbar, do we really need yet another one? So imagine having the Ribbon beneath the browser’s toolbar: where would the content of the page begin: somewhere in the middle of your screen? Waste of space if you ask me. I really don’t expect everyone to work with SharePoint in the full screen mode so unless you can make SharePoint’s Ribbon integrate with the one Internet Explorer would have (I don’t expect Chrome, Firefox, Safari and Opera to implement a Ribbon control just because SharePoint has it), don’t include it in SharePoint. Unless it is optional so that the customers can decide themselves whether they want it or not, don’t make it the default toolbar.

Benefit of jQuery

SharePoint 2007 heavily relies on JavaScript. It’s nothing wrong to use technology that is available of course, besides the fact that SharePoint’s JavaScript is really a disaster.

First of all it’s really huge. SharePoint is a rich platform with tons of functionality which partly relies on client-side technology, but still: does it justify a few hundreds of kilobytes of JavaScript? It doesn’t. Sure you don’t always need all of it, and you can compress it, but it is really a lot of KB that you need to push down the pipeline to the end users to get the UI to work.

Second of all SharePoint JavaScript is badly structured. If you’ve been ever working with JavaScript there is a big chance you had a look at some frameworks like YUI, jQuery, and have read some of Robert Nyman’s articles on JavaScript. JavaScript in SharePoint resembles none of the examples you have seen: it’s really poorly structured and difficult to follow. Because of this, you cannot understand it, benefit of it and minify it to decrease the page payload.

So couldn’t the SharePoint Team restructure the JavaScript and see whether some of the pieces could be replaced with jQuery based snippets? In the last few months we’ve seen how jQuery have been integrated in Visual Studio, so Microsoft definitely sees its added value. I’m pretty sure using it to leverage the SharePoint UX would simplify a few things and give developers some new possibilities. Don’t believe me? Check out how easily Paul Grenier tweaks SharePoint UX using nothing more than jQuery and a couple of lines of JavaScript. Sweet!

UI!… Calling UI!

As I’ve already mentioned SharePoint UI strongly relies on JavaScript is 100% supported by Internet Explorer only. Unfortunately parsing JavaScript is not what IE does the best. Too much JavaScript results in non-responsive UI what confuses the end users who keep on clicking the buttons just to find out that they need to wait a moment for the IE to get through all the JavaScript.

As far as I can tell, users don’t mind waiting a little after starting an action, as long as they are given the feedback that their request has been received and that something is going on in the background. The weird thing is, that some places in SharePoint do provide such feedback. Why not implement it everywhere then?

Another thing that the WSS team could to is to simplify the HTML markup. The more HTML is being served the longer it takes to download, parse, render and customize it. The more complex it is, the more difficult it is to understand it in case there is something wrong. It would be really cool if the SharePoint’s interface was simplified.

Do it, do it at once!

It’s quite odd that it actually takes two steps to create a Publishing Page in SharePoint. First you create a document and then you can proceed with filling in the page details. I’ve worked with a couple of Content Management Systems and I can tell you: I have never seen such approach before.

SharePoint developers among us almost immediately would try to explain how the SPListItem and SPFile are being created and the page is being instantiated… Guess what? The end users don’t care. When they want to create a page they want to have it done, instead of switching between two different screens and entering data in two places. It is confusing I admit. It would be cool if the MOSS team could do something about it too…

Wrap up

So these were the 5 experience-related things I’d love to see in SharePoint vNext. In the next post I will focus on development. Stay tuned and feel free to share your opinions, ideas and concerns.

Technorati Tags: SharePoint, SharePoint 2007, WSS 3.0, MOSS 2007