Talking Point

Bill English has posted a great piece on sites, areas and portals over in his SharePoint Café*.

I think there is a simpler core set of factors around point III. A new portal represents a more formal boundary than separate areas. Within an enterprise organisation these boundaries are generally pretty obvious, they are the business units, divisions etc. The needs of these divisions fall into 3 categories :-

• Some of these will use Portals to publish to their own members (e.g. an R&D function)


• Others will publish out to the rest of the organisation (e.g. HR)


• The hardest of the lot are groups that publish to both (e.g. IT).

It would be awkward for a division to have more than one portal so in the third case crafty use of area permissions should give one portal different looks to internal and external users.

This model also fits with the sizing limits of SharePoint Portal Server 2003. In a shared service farm you can sensibly house a few tens of portals (there is a true limit of something like 70 but things generally you don’t want to be running at the limit). When thinking about a Portal model in a large organisation you should be thinking “If I divided my company into 20 units what would they be ?“

In smaller organisations it can be much harder to determine these boundaries, often they don’t really exist. It’s generally blindingly obvious if you need multiple portals, if you are not sure you probably don’t need it.

Also it should be pointed out that sometimes a particular requirement may utilise more than one of these elements. For example, work in progress should be run in the collaborative team site environment,  
however once a piece of work is completed it should be promoted into a portal area. From what I’ve seen areas are generally best as shopfronts for final documents.

Steven

* Bill, did you know there is a SharePoint Café in Microsoft’s UK Offices ? They have some great remote control boats you can play with while sipping a latte. 

There has been a great deal of noise created in the SharePoint blog world by a posting made by Mike Drips entitled “5 Things Wrong with SharePoint”, this was then replied to by the whole cast :- Arpan, Paul, Andrew, Daniel, Ed, Scoble and Maurice and other I haven’t read no doubt. While the original article was rather flawed with either errors or what I would call flaky logic, it’s only right that the users point out the bad point of the product as well as the good. Rather than write a wish list for SharePoint 3, I wanted to point out things that could have been done better in OSPS2003/WSS with little more effort.

1. Error Messages – Some error messages in SharePoint are displayed as simple full page black Times messages on a white background, there’s no connection to a style sheet and no ‘chrome’ around the page. The most common time this appear is when a team site fills it’s quota. There is not apparent way to edit these messages, they come out of some .dll. This really smacks of laziness/rushing to ship the product. All error messages should be customizable, all inherit the default style sheet etc.

2. Dodgy Site collection model – Even the admin help file for SharePoint doesn’t seem to really understand how team site collections and top-level sites are related. I’m not sure I really know what to call a collection of top level sites. Technically it’s a pain as well. The model for self service creation of team sites seems to favor the creation of multiple top-level sites, for example the quota is allocated to each site collection rather than individual sites, however when you want to do something like share a list template you create it is constrained within you collection. Subsites really should exist in my opinion.

3. Product name – Despite the beating dished out to Mike Drips, I agree with him that the naming convention for OSPS2003 and WSS is rubbish and confuses customers. I think that the layout of the products does little to add to the clarity. It’s generally claimed that SharePoint is a brand, and the two products are elements of that brand, I can accept this, but why not start both product names with SharePoint. Also from the names one of the products is a service, the other is a server, how does that make any sense. It’s often claimed that WSS is a platform and OSPS2003 is an application built upon that platform, this isn’t really the case. There is a common platform between the two products, but they are both built up from here, a Portal in OSPS2003 isn’t entirely a superset of WSS features (for example, there’s no per list permissions in OSPS2003 but there is in WSS). I would prefer that we talked about a true common platform and then one product with portal features, the other with team features. They will work great together, but the identity is kept apart.

4. Admin UI – To start with a positive, the look-and-feel people did a good and consistent job of the admin UI for SharePoint, however what they were given to work with is a taxonomy that really makes little sense. I’ve lost track of how long I spend browsing around looking for a setting I’ve seen, probably even know by name, but can’t derive it’s location for the UI. The search UI is the worst of the bunch, what on earth is that simple mode that can never be reverted to for. There are also lots of functions which are all but lost. I recently discovered that if you go to the permissions page for an area there is an option hidden in what looks like an introductory paragraph to make the area only appear in the navigation for people who have permissions. Great feature, but lost due to the poor UI.

5. Silly dependencies on Office 2003 Pro – Nearly every list view has a View in DataSheet link, but this only operates if the user has full Office 2003 Professional. Most of the client side features of SharePoint work just fine with Office 2003 Standard, it’s entirely arbitrary and punitive to make this component a Pro only feature. At the least the error message should be clear “This feature doesn’t work because someone in marketing decided you should pay the extra $100 for Office Pro”.

I think OSPS 2003 and WSS are great products, if an organization uses Office (and who doesn’t) then SharePoint is of huge value and little cost. The development of the current release was a huge undertaking by Microsoft in a short time period so there are significant limitations and lack of polish in many areas, I wish they would address them in service packs, however given the next version is only a little over a year away we will have to hope that there is more time to perfect the final product. As I’m involved in the testing of Office 12 I’ll be giving the product teams plenty of feedback in this area.

<rant>I would also point out that Mike’s article is not a blog, it doesn’t have a concept of trackbacks, so he may be entirely unaware of the responses people have made to him in their personal blogs. That’s pretty poor ettiquette (at some point Mike’s going to search for his name and be amaized by what he finds), responses/rebuttals should have been made in the comments on the site he posted.</rant>

After a slow start, we are now rather spoilt for choice when it comes to blogging templates for SharePoint. As well as the one which gets hidden in the bowls of FrontPage, Maurice Pranther wrote a series of articles with samples (http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=89) and Jim Duncan is developing a more advanced template at (http://dev.collutions.com/blogs/sample/default.aspx). Combine this with the multitude of list to rss tools you would think that every bloggers desires were filled.

Well sorry, no.

You see the thing is I write a blog to be viewed by people internal to my employer. I’m not writing about stuff that’s company confidential, really I’m just reposting the interesting snippets from the 30 or so weblogs I subscribe to, but I’m putting them into the context of our organisation. I’m told by my readers that this is pretty valuable, rather than getting information cold they get to see something pre-filtered and commented on by the technical architect for that area. SharePoint was clearly the place to start, we’ve already got it, it’s a standard service, all the security, access, scaling, backup etc all exist, I would be crazy to use anything else.

However, until Microsoft ship a free RSS reader in some future Windows version (longhorn was the last rumour I heard) there is no likelihood of my organisation spending money to purchase an RSS reader or adopting a free one from an unsupported source. This means my readers will all be reading my blog in Internet Explorer for the next 2-3 years. I can’t expect people to keep coming back to the site to see my latest pearls of wisdom, they need to have a way of combining my blogs with that of others. Now the SharePoint way of aggregating push information is through subscriptions, generally sent as emails. So I get people to subscribe to the list which makes up the postings to the weblog, sounds easy. Now this is where the wheels start getting wobbly on this wagon.

The FrontPage template I used does not use the standard forms for the list to create it’s displays. The actual page which is the view page for the list doesn’t show comments or much else. The subsciption however always point to this form, so it’s wht my viewers see. After some fiddling and using excellent advice from Mr Pranthers posting I’m able to create something that allows them to see and add comments, well I am supposed to be an MVP so it would be a bit poor if I couldn’t get that far. This is now starting to fly, I’ve subscribed to the comments list so I get notified when someone posts a comment, often they are asking a question so with a bit of fiddlin around I can reply.

The problem is they don’t know I’ve replied so ask me the same question next time I see them around the office. They need to be able to subscribe to replies to their own questions only. The only way I can think to do this involves rather a lot of custom coding, something I don’t like. So near and yet so far, I can nearly create something great using standard templates and some relatively minor stuff in FrontPage. What I need is for SharePoint 3 to come with a blog out-of-the-box with the following features :-

• Visitors can use subscriptions to be notified about posts and replies to comments


• Subscription messages which show the first few lines of any post/comment


• A rich client for making postings, how about an infopath form, I need the ability to spell check before uploading. Or perhaps an email from Oulook ?


• RSS functionality OOTB for when readers do start appearing.


• Oh, and I want Pings/TrackBack functionality.

If anyone has better ways to achieve this then let me know in comments …

I must admit that I’ve now become quite sceptical about all search vendors. They all claim to have the latest, greatest algorithms but really are all based on the same fundamental technology.

 

All searches are about the same when it comes to identifying documents which match the search parameters, SharePoint does this just fine, see how your search brings back 200+ documents, the file you wanted is in there, just on page 44 rather than where you want it.

 

The place where searches try to differentiate is in the ranking of these results, putting what you need on the first page. All the products I have seen just seen seem to use variants of the same type of formula relating the results to the frequency/significance of the words you are looking for. I can’t see why one would be especially better than any other. It’s an easy thing to try, most of these folk will provide evaluations or come with a demo version you can try onsite.

 

I don’t really believe that the view improvements such as relating documents together or graphical visualisation is really that great from a users perspective. They don’t use this functionality from Google, they just want to type a word and get a reply.

 

You will find some definitions around on how Google’s Page Rank technology works (http://www.iprcom.com/papers/pagerank/), it’s worth understanding so you can understand how you will never be able to recreate this on an intranet of only thousands of employees.

 

I’m waiting for search to start considering information beyond the simple lexical analysis of the documents. Why can’t the search know about me, and tailor my search results to put the IT Department expense claim form before the Finance Department Expense Claim form ? Why can’t the search learn that last time someone searched for X the document they wanted was on page 4, and the next time move the document up the ranking ? etc.

 

Until then, I know I’m going to get the most bang-for-buck by tailoring SharePoint search through thesaurus, best bets, noise-words, search scopes etc. For example we recently discovered that making a default search only consider the document created in the last 3 months made a big increase in user satisfaction. I strongly believe get better search results by paying for someone to manage search actively than paying $$$ for a specialised search package.

A number of people have posted about the publication yesterday of new WSRP webparts and services for SharePoint 2003 (Daniel McPherson, Patrick Tisseghem) . I guess a number of people are wondering what on earth WSRP is about and why are people excited about it ?

A large part of the benefit of a portal comes from aggregating together information from other sources. On it’s own SharePoint 2003 does a great job of bringing together unstructured data such as word or excel documents through individual team sites into an overall structure.

This is great for the ‘information worker’ type employee that Microsoft talk about so often. Depending on you organisation you probably have people who aren’t ‘information workers’, perhaps people who use a Accounts Payable (AP) system 8 hours a day, or a helpdesk using a case tracking application etc. etc. These people still use tools like Word, Outlook etc but it’s not their prime application to work in.

Portals can help these workers by integrating between these different types of data. If their AP system can be exposed as a webpart, and you can put this in a page for AP Clerks next to a view of a shared document library, calendar etc. then they can work in the same place all day. Features like webpart connections could also allow context to be passed between separate system. When a user selects a supplier in the AP webpart a document library could sort to show letters sent to that supplier.

Most major applications come with their own Portal offering. SAP, Peoplesoft, Oracle all have their own products, but don’t have the deep integration with Office applications that Microsoft provide. These vendors will not write in support for SharePoint themselves as it would take away from their sales of their own portal products.

This is where standards come in. Customers see benefits in standards, once I’ve agreed that an application should produce output to a particular standard I know I can change that application and as long as the support of standards is the same. Vendors tend to adopt standards, often trying to take the high ground  over the competition by explaining how they don’t lock you in to their technology.

The WSRP standard defines a way in which a webpart can be delivered from a remote system (it stands for Web Services for Remote Portlets). One example of this would be a portal which supports publishing WSRP could communicate with a different portal which can subscribe to WSRP, and a portlet/webpart which was only written for the publisher could then be shown in the client.

Continuing my example, if my AP system had it’s own portal, but supported WSRP, I could then take any of their portlets and show them within webparts in SharePoint.

The published examples provide both publishing and subscribing to information through SharePoint. This means you can integrate a WSRP portlet into SharePoint, or use a SharePoint webpart in another vendors portal if it also supports WSRP. Both examples are a little rough, it would be better if Microsoft made this functionality part of the supported product rather than providing developer examples, fingers crossed for SharePoint v3.

Microsoft now join IBM, Fujitsu, Apache, Oracle, Plumtree and Sun in having products that supporting WSRP. BEA, Citrix, Vignette, SAP, and novel have also made noises that support will be coming. It will get more interesting next year when the rather limited WSRP 1.0 standard is updated to 2.0, and introduces concepts such as webpart connections.