Share My SharePoint Pain
I just posted my first SharePoint "how to", which describes showing metadata inside a folder. It's a lengthy post full of many, many screenshots detailing the laborious process of doing something I had assumed would be fairly simple.
While writing it I was mindful of keeping it focused on SharePoint so it would remain a useful resource that a SharePoint developer might stumble upon one day and find useful. That's why I didn't write it from the perspective of a Domino developer.
If you're purely a Domino developer it won't be of much use to you, obviously. However, you might want to give it a once over. Even if just to feel smug about the fact you're not a SharePoint developer. You might even find it enlightening, as it offers a glimpse of "the dark side".
A Domino Perspective?
The article describes how to arrange Lists in a folder-based hierarchy and then display a description of the current folder as you navigate the structure.
In Domino terms this is like having a View of parent/response Documents. The view would contain two Forms - one called "Folder" and one called "Item". The Folder Form would have a field called Description on it and when you opened a document based on it this description would appear along with any child Documents (Folders and/or Items) that shared the same $REF.
It would be fairly easy to implement in Domino. In SharePoint it was a massive headache. For me anyway. Whether a seasoned pro would find it a breeze I don't know.
What I am finding is that OOTB (out of the box) it's quite impressive. But as soon as you go OOTO (out of the ordinary) and try to extend it, you better hope you know what you're doing.
Skip to the 
You can subscribe to an individual
I've done some work in Sharepoint and I can say that I find it incredibly frustrating. I think of it as the poor mans' Notes and I'm glad to say that Sharepoint development isn't something I need to do for a living. I think Sharepoint is useful but I always felt constrained by what I know can be done in Domino and the speed it can be done.
By all means, if Sharepoint skills are something you need to pay the bills then it's something you need to learn but I'm glad to say that I'm not in that position and won't be going over to the 'dark side'!
Reply
That is why I always say that there are (imho) many good reasons to move away from Domino but hardly one to move from Domino to Sharepoint.
Reply
Jake,
I had similar experiences with SharePoint at my last place of work. The execs were sold on the OOTB stuff with the promise of it being customisable. It was a nightmare to do the simplist of things. I think they are having doubts about it now after spending £100k+ on an outside company to lead the development, and being over 6 months past the original planned launch date (and with no concrete completion date scheduled in the near future!).
The company that were brought in as the SharePoint experts were also very against using the SharePoint UI to build things. We had to create all of the custom Content-Types, lists, etc via XML files in Visual Studio so as to package them as part of the Solution file. I couldn't believe that this was seriously how we had to develop - everything had to be updated manually in loads of different XML files; there was no automation anywhere.
After 3 months with it I still felt like I was only just finding my way around. I was relieved to get out of it in the end. I'm always keen to learn new technologies, but for my own sanity, I couldn't imagine myself ever wanting to work with SharePoint again.
Other complaints:
- It was horrendously slow.
- Minor changes to the XML files would often mean having to blow away all the sites, sub-sites, test content, etc you had created (Luckily the SP experts had created scripts to do a lot of this for us, but it was still annoying and time consuming).
- Everyone working directly on their own server was not practical - it was a right faff to get updates from other people's code.
- SharePoint would often screw up during the solution deployment meaning that we would lose hours trying to sort it.
- The code it generated was truly awful! SP2010 was no better there either.
Hope your experiences with it are better than mine were!
Reply
How is the non-IE browser support in SharePoint? I'm thinking of diving in myself, but in our organization at least, not working on Safari or Chrome is a deal breaker.
Reply
Not so good it seems.
I started diving in to the SharePoint UI through Chrome. It seems to work for the most part but the odd thing wouldn't. Since I moved to using IE it all seems to work.
The layout and general functionality seems to be ok in other browser but I've found only IE can do everything you need to as a developer.
Reply
I think 2010 is much better in this respect, and also with accessibility too.
Reply
Welcome in the wonderful world of sharepoint. I've made the same experiences... Everything you can simply customize works fine, but never try to do more. Examples:
Categorized view for multi-valued fields -> not possible
Scheduled agents (and running on all items of a list) -> only with lots of tricks
Customize the view or edit form of an item -> promised to work with sharepoint designer, but not stable...
Customizing in test environment with sharepoint designer (esp. workflows) and deploy them to your production -> not possible, you have to work in production (should work in SP2010...)
So every time I started to develop something as simple as my tons of lotus notes applications I ran into massive problems; and most worse: I didn't get answers in the internet!
In my opinion sharepoint is not a development platform. You can give it to your customers and let them custumize it per browser; perhaps you buy or develop some nice webparts for them... but that's all.
Reply
Your last point about giving it to your customers to customise - that's exactly what I've seen happen and now we have departments across the company, across the world all running their own versions of the same thing to massively varying levels of quality because now "everyone's a developer". Nothing is consistent and has been put together with all the ability of the novice enthusiast. I'd say this is Microsofts goal. Give the world sugar coated poison.
Kind of brings me back to my Lotus Notes 4 days!
Reply
As a company that does both Domino and Sharepoint (has for years) and has done migrations from one to the other and the opposite, you are in for 'fun times' as we joke.
One suggestion: stay far away from SharePoint workflow. Use it for learning and when you want to do anything real with customer projects - go straight to Windows Workflow. It means bypassing SharePoint Designer and using C#, but you won't want to kill yourself after about 2 days of workflow hell.
Reply
"What I am finding is that OOTB (out of the box) it's quite impressive. But as soon as you go OOTO (out of the ordinary) and try to extend it, you better hope you know what you're doing."
Well said Jake, you already learned SharePoint's most important lesson.
My very rough advise is to not use Sharepoint unless at least 80% of the OOTB functionality of SP can cover your application needs. Anything less than that a custom .NET app can be a serious candidate, with optionally its front-end integrated into SP.
Reply
Don't worry help is at hand, I have just received this from Microsoft
Sear Sean,
Running a successful web-development agency today is more challenging than ever. Fortunately, help is at hand - with the Microsoft web stack.
Our web products are a set of integrated tools that enable your agency web team to rapidly craft and share compelling designs and rich internet applications.
Supporting these products are powerful, robust servers that can connect far-flung teams and handle rich, data-driven websites. These servers offer easier management, lower costs - and more impressive websites for your customers.
With SharePoint Server 2010, you can publish rich websites and intranets, search for content, manage content and create applications.
Better still, you can take your web development to the next level with a SharePoint Server 2010 edition that best suits your business needs.
For example, if you're a small or medium-size organisation looking to build public internet sites or basic extranets, SharePoint Server 2010 for Internet Sites, Foundation Edition may be perfect for you. Alternatively, you might want to step up with SharePoint 2010 for Internet Sites, Standard Edition.
Reply
I think my old blog expressed similar pains. :)
Just one response, to John Head's comment to go straight to Windows Workflow -- I disagree, respectfully.
I am very much leaning towards NO SharePoint customizations. I've found that once you need to delve down to .NET, you may as well just write ASP.NET apps. And once you customize, you take on a much heavier maintenance load for your apps.
Workflow is not a sweet spot for SharePoint. But K2 is a very nice, if expensive, solution to workflow that integrates extremely smoothly with SharePoint.
So my current thinking is:
Do SharePoint OOTB, in particular when the function being served is truly collaborative. Use K2 for workflow. If that doesn't meet your needs, custom ASP.NET development.
And if your system is transactional vs. collaborative, use custom ASP.NET.
Reply
Use ASP.NET or .NET custom application only if its enterprise level solution. .NET is an over kill for department level forms based application with or without workflow.
If Domino is not an option you might want to look for PHP/Coldfusion or any scripting based technologies.
.NET is way too high in the learning curve. Not worth it for non enterprisy application.
Reply
Sharepoint is not worth the aggrivation. Save yourself now while there is still time
Reply