Archive | MOSS

PDC09 Session Picks

Posted on 17 November 2009 by Alex Katsoulas

PDC09 started and there are two sessions that all should attend.

Build a .NET Business Application in 60 Minutes with xRM and SharePoint” in 502A on Thursday at 12:45 PM

Managing the Solution Lifecycle for xRM Applications” in 515A on Tuesday at 12:30 PM

For those are not in PDC09, all keynotes will be streamed live and all sessions will be delivered on demand here.

Comments (0)

Sharepoint 2010 – A developer’s view

Posted on 11 November 2009 by Alex Katsoulas

In few days the official beta of Sharepoint 2010 will be released, but here you may get detailed information about all features. My best pick is the one describing how to execute code in Sandbox.

Comments (1)

Tags: , ,

MOSS no more…

Posted on 06 May 2009 by Andreas Vamvatsikos

The announcement by Microsoft for the naming conventions of the Series “14” Server products marked the end of our beloved MOSS acronym! The Office buzz world is not a part of SharePoint’s name anymore , since it will now be called Microsoft SharePoint Server 2010.

This does not mean that Office integration will be left out, it just means that Microsoft decided that the “Office” brand name will now be only related to client side products (a wise decision that will reduce some of the confusion that was caused by the “Office Servers” product line). The beta or a partner preview will be available in the last quarter or 2009 but no features were confirmed. So all conversation was about the new acronym (no serious Microsoft Product has been left without an acronym for a long time). MS is out of the question, MSS is taken by Microsoft Search Server and as Thomas Rizzo wrote on his blog  (“SharePoint is SharePoint is SharePoint”) we are left with no acronym.

I have a real hard time accepting this, so what about …. MSPS ?

 
SharePoint is SharePoint is…

Comments (0)

Tags: , , ,

To folder or not to folder? That is the question.

Posted on 30 March 2009 by Andreas Vamvatsikos

Since most of us grew up in a word of DOS and Windows, our desire for folders and tree-like hierarchical structures is vast. We just make folders and subfolders to categorize information it has become … natural. Most of us do not want to let folders go, even when migrating to a new world like document management and SharePoint.

SharePoint provides the functionality to create folders within document libraries and so the most natural impulse when migrating from that dusty file server, is to just recreate the folder structure.
But to really get the most out of MOSS one must utilize metadata (custom columns). Metadata create a dynamic categorization system within document pools and allow for infinite personalization through views. Metadata use also turn search from guesswork to an intuitive task.

To be frank the folders we all use in file systems are metadata for the files they contain, just single dimensional. The “Projects” folder denotes that all documents contained in it are project related documents. Since this is not enough we rely on subfolders (client name or project type perhaps) and info in the filename (specific project name f.e.) to add more “metadata” to the document. This process that can quickly be chaotic and as the number of files grows it becomes unusable.

This can easily be alleviated by using a true metadata structure in SharePoint (two custom columns “Client” and “Type” in the ProjectFiles document library would be enough for the above example). So the document visibility is increased but also the structure can be “re-organized” (through views and filtering) without any manipulation of the documents files themselves. Teams working on the same file-set can also benefit from this approach. So the Sales department can view documents sliced per client or budget, but the IT department can view the documents per Product or Project type. Metadata is the way to keep everyone happy while at the same time avoiding multiple copies of files (and emails flying around trying to find the correct version).
Another thing against folders is that even if they are there, they cannot be used for filtering.

Just to add a technical limitation to all the business and design ones, the maximum document url length in SharePoint is 260 chars. This can be easily reached if the existing folder structure is big or really descriptive.

So it is obvious. No folders in document libraries, just metadata. Well … there is one single detail that folders have on their side, you can define access rights on them. So if you want to reduce the number of required document libraries or you have trouble dealing with access rights maybe a single layer of folders is ok. You will have to add metadata anyway probably just to get the views your users will desire (yes you can add metadata to a folder through customization, but it is not copied automatically to the documents that are placed inside it).

To conclude, in my opinion try to avoid folders at all cost unless access rights management makes them an unavoidable necessity.

Comments (0)

Tags: , ,

SharePoint 14 feature wish-list

Posted on 26 March 2009 by Andreas Vamvatsikos

With the next SharePoint Version (referred to as vNext up to now, it is going to be v14 it seems) getting closer, it is a good time to post my personal wish list of new features.  So here goes in no particular order:

·        Cleaner Page Rendering so that pages render faster, in more browsers and coding for MOSS is easier.

·        More “Polished” look for lists and especially for the forms that are produced automatically by the Workflow engine. It would make them a worthy offering for more solutions if f.e. silver light was utilized.

·        More flexibility in List functionality (it seems MS are working on something as was mentioned briefly by Bill Gates here http://www.microsoft.com/Presspass/exec/billg/speeches/2008/03-03SharePoint2008.mspx)

·        Better offline support, especially for mail archiving solutions but for simple document lists as well. Microsoft should get a lesson from the excellent Colligo addon on this.

·        Mobile client support, mobile browsers must be supported with a limited view of libraries at least. I would even be fine with a native Windows Mobile client, it is better than nothing.

·        Out of the box PDF support, yes I know it easy enough right now, but should be there by default!

·        Groove integration, just to get rid of the annoyance to explain to customers why on earth this is not already implemented :)<

·        More themes and master pages available out of the box.

·        Full site-collection backup/restore/migrate functionality (preferably with an UI) on a farm level. Really required for large scale installations or scenarios with different development and production systems.

·        Column (metadata) security filtering, it would be nice to be able to define which columns a specific security level can view.

·        Dynamic Update of related fields when a field changes in the form, for forms that are produced automatically by the Workflow engine.

·        Permissions on views, a real must have.

·        More customization possibilities for Search and search results, available without coding.

The big pain point of BI seems sure to be resolved now that a large segment of PerformancePoint will be integrated in SharePoint’s Enterprise version but this is a completely different rant! 

Comments (2)

Tags: , , ,

Increasing your chances for a successful SharePoint project

Posted on 24 March 2009 by Andreas Vamvatsikos

There are five rules of thumb that every SharePoint Project team must keep in mind in order to have a clear chance for success.

Plan big, start small
Microsoft Office SharePoint 2007 is a platform with a vast array of capabilities and features which is a good thing … until someone tries to use them all in an single project. So plan big since MOSS gives you the background to do so, but pick a couple of business focused quick wins for your first project. Don’t try to solve all of the client’s data, search, collaboration and process problems at once, the project will just never end. Get an ally within the client team, pin-point one or two problematic areas with their document or process handling and provide a solution just for that, either as a small start-up project or even as a pilot of a broader implementation.
This makes it much easier to keep the project on time and in budget but also to get the “buy in” from the end users that you will need later, when trying to deliver solutions to more complex problems.

Educate your developers
As I already noted MOSS is a platform. As such it has a wealth of Out Of the Box features that can be utilized in any solution. It has even more features that can be downloaded through Microsoft and the Codeplex Community in the form of application templates and web parts. You can even buy components from various vendors to facilitate a solution. All of the above components and features are extremely customizable according to your solution design and the user requirements.
This is something your development team HAS to understand and embrace. It is sometimes difficult to convince a developer with .Net mentality to try and find a way to implement things in the above described “SharePoint way”. If you find the team launching Visual Studio and going through the “Dim x as …” routine something is probably wrong.
With that said, there are actually some extreme cases where coding is indeed needed but they must be treated as exactly that, extremes.

Educate your users
Starting from pre-sales, users must have a clear view of how SharePoint will benefit themselves and the company, how it is going to take some effort and stress away from them, so that they are willing to go a little out of their way (and their established habits) to use it. They have to be educated to the whole metadata and search paradigm (don’t be shy to give the Google example even if they are an MS competitor) but at the same time assure them that they will still perform most of their tasks through their beloved MS Office.
After Roll-out do not try to train everyone in everything! Prefer role-based training according to how users are expected to utilize the SharePoint implementation. Finally be prepared to communicate the positives of the implementation and get ready for a storm of questions that must be answered. Unanswered questions tend to lead to a lot of user resistance to system adoption.

Plan for business not for IT
Since IT is usually vocal, you may end up designing a business system based only on IT input, which is exactly the opposite of what you should be doing (I should know, have been guilty of this a couple of times). SharePoint was designed with business data and processes in mind and is built in a way that some of the customization and the administration can be handled by business users.
So you must set up a group of key users in the requirements phase, that can close the gap between the business needs and IT, that can describe processes, define roles and responsibilities and bring some specific “company know-how” into the project, since every business is unique in its structure, function and needs. Document the processes, templates and metadata (avoiding IT complexity and terminology) and get a consensus before proceeding to implementation. Missing process steps or messed up templates and useless metadata will lead to an unusable system.

Design for user friendliness, be prepared for change
A user friendly implementation is key to success. Try to keep as much of the offered functionality as you can within MS Office, users love the impression that nothing really changed in the way they proceed with their everyday tasks. Site Structure and navigation must be simple and – got forbid- nice looking! Spice up sites and site collections with some images or charts, don’t just pile up lists. Even in lists provide intuitive views, don’t rely on users to create them. Set up a site for social interaction within the company to lure users in increasing adoption and acceptance.
However build all that with a well thought out structure of Content Types, Site Columns List templates and Web Parts at the site collection level. This way you are going to be ready to adapt quickly
to the unavoidable change that all businesses undergo sooner or later.

Lastly remember that even if MOSS is a platform offering solutions to many business problems it does not offer solutions to ALL the business problems!

Comments (0)

Tags: , ,

SharePoint success reasons and future headaches

Posted on 20 March 2009 by Andreas Vamvatsikos


Microsoft Office SharePoint Server (MOSS) is a great success and its 2007 version (the third iteration of the product) has even become Microsoft’s Best Selling Server. MOSS was made such a success by a combination of four things:

  • A well defined set of business-focused capabilities and features
  • Integration into a well known, widely used and liked framework
  • The ability to extend its functionality by customization and programming
  • Microsoft’s powerful marketing

The first two points make MOSS attractive to enterprises because it gives them the features, manageability, desktop integration and scalability to meet corporate needs. The Microsoft Brand name also helps as well as possible licensing deals that are in place for other Microsoft Products and make MOSS an easy executive decision.
The third makes MOSS attractive to end users that more or less continue to work the way they were used to, but also creates an entire ecosystem in the market for specific add-ons and vertical solutions.

Microsoft with SharePoint actually invented a market segment that was previously covered with combinations of different products filling the Document management, collaboration and portal management roles. MOSS integrates all three components into o single offering bundled with excellent Microsoft Office and Active Directory Integration. Helped by massive Microsoft marketing and an (almost) free basic version, it dominated its own market segment.

And that is how problems start emerging. As MOSS finds its way into more corporate environments and IT departments acknowledge its flexibility and start customizing it, they start coming close to its design boundary. SharePoint was designed to offer MS Office integrated document management with easy to use collaboration features and workflow support. Surely the product can do many more things through customizations but the further away from its core, the more difficult implementations get.
So if the Microsoft Marketing machine keeps pushing MOSS as the one tools to solve all enterprise problems, publicity around SharePoint could start getting less positive as overoptimistic projects based on it fail.

New features in the next version are surely needed but there is also a need to strengthen existing features and functionality and not to add even more breadth to the product, blurring its boundaries even more.

SharePoint is an excellent platform for the things it was designed for, it would be a shame for Microsoft to negate that by trying to make in into the Application Server it never had.

Comments (0)