Report from the Field ?Answers to Your SharePoint Questions - Mauro Cardarelli Over the last month, I抳e had the opportunity to speak at several events about Microsoft抯 SharePoint Portal Server and Windows SharePoint Services. I抳e spoken with executives, business analysts, and developers. The popularity of this second generation product, across the organizational chart, has been very impressive. Having presented to almost 200 people, representing a myriad of corporations, as well as having visited and worked with several others, I抳e compiled a list of the most popular questions I抳e been asked. This article will detail those questions and my answers. What is the difference between SharePoint Portal Server and Windows SharePoint Services? When should I use SharePoint Portal Server versus Windows SharePoint Services? What is the best feature of this version? What is the biggest weakness? Do I need Office 2003 on my desktop? Is it easy to use? Can SharePoint portals be customized? Should I rewrite existing .aspx pages as SharePoint web parts? Where can I learn more about using SharePoint? What is your best SharePoint tip?
By far, this is the question I am most often asked. One of the hardest messages to convey is that while SharePoint Portal Server (SPS) and Windows SharePoint Services (WSS) share a similar name they are actually very different. My answer to this question has changed over time; I抳e tried to refine and simplify it. Forget the fact that SPS and WSS have different feature sets and different audiences. The easiest way to differentiate the two is to focus on the user抯 navigation: A SharePoint Portal Server site is meant to be a starting point to guide the user to a specific destination. As an example, think of a page with lists of URL抯 to various active projects, each grouped in specific categories. A Windows SharePoint Services site is meant to be a final destination. It is where a user would go to get information and/or collaborate.
This is typically the first question asked as organizations build out a portal architecture. Windows SharePoint Services sites are great for project or product based information. They should have a small group of active participants and are often very focused around specific, time-sensitive content. SharePoint Portal Server topic areas have a broader presentation of data as well as a bigger audience. Since it is possible to incorporate both SPS and WSS into a portal, one of the challenges in initial architecture designs is to decide what content goes where. Training material is an example of content that is suited for either. An SPS topic area could reference various sites and/or documents related to training material. A WSS site could alternatively be used, targeted to a specific corporate group. The decision on the preferred site often comes down to available features.
Personally, I think the best feature of this version of SharePoint is the fact that it uses a SQL Server repository. Not only does that help with scalability and performance, it allows easier access to all the data that SharePoint stores. This makes custom development with SharePoint much more powerful. All the data that SharePoint presents, from user information to documents to images, is stored in its databases.
This is a tough one. There is no doubt that I have come across a bug or two. None have been very big. I think the toughest part to overlook is the interface for search results. SharePoint has a very powerful search engine, one that crawls all its content as well as specific file shares, Exchange public folders, or external websites. The challenge is presenting the data in a way that makes sense to users. We have all been spoiled by Google. The SharePoint interface, while showing the right results, is sometimes confusing. I抳e done some custom development around search results presentation that has helped some of our clients. A common request is to highlight the search word in the full text match. Another request has been to show relevancy strength.
This is another point of great confusion. You do not need Office 2003 on your desktop to take advantage of all the features SharePoint offers. Internet Explorer 5.5 or higher is all you need. But, if you are using the document management component, having Office 2003 helps. SharePoint integrates very well with the base Microsoft Office products to allow seamless extraction and submission of Office documents. If you don抰 have Office 2003 on the desktop, the process is still possible but slightly more manual. The bottom line is that if you want to use the document management capabilities of SharePoint you should at least have the Office 2003 搗ision?(i.e. deployment in the next 6 to 12 months).
SharePoint is very easy to use. Microsoft did a great job in building the administrative tools right into the presentation. Functionality is consistent across the product so the learning curve is accelerated. I often tell people that you do not have to be a technology resource to use and/or administer a SharePoint portal.
SharePoint portals offer a high degree of customization. The interface can be altered in one of three ways: (1) using the standard SharePoint administration to add web parts, change text, and apply themes (2) altering the cascading style sheet for more advanced presentation control (3) using FrontPage 2003 for even more control of page design and layout.
SharePoint web parts are like .NET server controls. From a coding perspective, they have a very similar look and feel to standard .aspx pages. I tell developers that if they are building a new web part from scratch it is best to use a web part template and take advantage of the easy deployment and runtime properties. If you have an existing .aspx page, it is possible to build a simple web part wrapper around it to avoid the redesign. As an example, this would work if you had an existing .aspx page that accepted URL-based parameters. It is very easy to configure a web part that can pass parameters to that page.
One of the challenges in working with SharePoint early on was the lack of documentation. That made it very hard to understand all the features and how and where they worked. Things have improved a little with time. Some new technical books have begun to make it to market. Websites like www.msd2d.com offer great contributions on SharePoint knowledge. Training facilities like New Horizons have begun to offer great introductory classes on SharePoint deployment and administration.
This one is easy?do a good job with your initial architecture. SharePoint is very much template based. When you construct the proper templates, it is very easy to quickly build out your portal. The challenge is getting the templates right. The other piece, as mentioned in a previous question, is designing properly to leverage both SharePoint Portal Server and Windows SharePoint Services. The key to a successful portal implementation is flexibility and scalability (from a content perspective). You get both with a good design.
