SharePoint Reviews

Sharepoint is Microsoft’s document sharing and collaboration tool. It allows you to share and manage documents, and to build websites – so it’s a content management system too. In my previous role I was strapped to the mast of Sharepoint: we needed to share files across the world, previously we used shared network drives, as a byproduct individual teams can also create websites. There were close on 100,000 of us at my previous employer.

The file sharing/content management schizophrenia can lead to horrible websites, on a normal website you might expect that following a link in a page will take you seamlessly to another web page to be rendered in your browser. Not in Sharepoint: the siren voice of the file sharing side means that all to often website authors are going to link you to documents – so you hit a link and if you’re lucky you get asked whether you want to open a document in Microsoft Office, if you’re unlucky you get asked to enter your credentials first. Either way it breaks your expectation as to what a website should do: hit link – go to another webpage.

For every function you can imagine Sharepoint has a tick in the box:

• Blogging – tick.
• Social media – tick.
• Wiki – tick.
• Discussion forums – tick.
• Version control – tick.

The problem is that whilst it nominally ticks these boxes it is uniformly awful at implementing them. I’ve used WordPress and Blogger for blogging, phpBB for discussion forums, moinmoin and Project Forum wiki software, source control software, twitter, delicious, bit.ly, Yammer for social media and in comparison Sharepoint’s equivalent is laughable.

This ineptitude has spawned a whole industry of companies plugging the gaps.

Sharepoint does feature some neat integration into Microsoft Office: viewing shared calendars in Outlook, saving directly to Sharepoint from office application but this facility is a bit flakey – Office will try to auto-populate a "My SharePoint sites" area but does it via a cryptic set of rules which can’t be relied on to give you access to all of your sites.

For the technically minded part of the problem is the underlying product but part of the problem is down to how your company decides to implement Sharepoint. My WordPress-based site looks pretty much how I want it, bar the odd area where my CSS-fu has proved inadequate. In a corporate Sharepoint environment other people’s design decisions are foisted upon me, although Sharepoint’s underlying design often seems to be the root of the problem

Take this piece of design (shown below), this is part of the new Sharepoint social media facilities but it’s ugly as sin, most of what you see for each Note is Sharepoint boilerplate (Posted a note on – View Related Activities – Delete) rather than your content, furthermore I have repeatedly set my dates to format dd/mm/yyyy in the UK style and this part of my site remains steadfastly on the US mm/dd/yyyy format.

Here’s another nasty piece of design.The core of the document sharing facility is the Document Library, below is a default view of one of my libraries (with some blurring). All of the Sharepointy magic for a document is run off a dropdown menu accessed via a small downward pointing triangle on the "Name" field, the little triangle is only visible when you float over that particular line, note also that if you click on the name in the name field then that takes you to the document – so you trigger two different behaviours in one field.

Other items in this table are hyperlinks but take you to entirely uninteresting content.

It didn’t have to be this way, the Document Library could functionality could have been integrated into the Windows File Explorer. Applications like the source control software TortoiseSVN and TortoiseHG do this, putting little overlays onto file icons and providing functionality via the right click menu. Windows 7 even has a panel at the bottom of the screen which seems to offer quasi-Sharepoint functionality – you can set tags for documents which could map to the "properties" that Sharepoint uses.

Users are familiar with the file explorer, Sharepoint discards that familiarity for a new, clunky web-based alternative. Furthermore users sharing files are often moving from a directory-based shared hard-drive scheme, Sharepoint allows you to use directories in Document Libraries but it breaks the property-based view which is arguably a better scheme but forcing users over to it wholesale is unreasonable.

In summary: Sharepoint suffers from trying to be a system to share documents and a system for making websites. It features a poor web interface for functionality which could be integrated into the Windows file explorer.

(I think I am getting better at outrageous headlines to drag you in to read the post! … please don’t leave)

I recently read Jeremy’s post about picking SharePoint social over Yammer “for right now” and wanted to weigh in on why I think they are not making the call I would have.  It’s all just personal opinion of course and Jeremy and I are close friends and no doubt he will attempt to convince me otherwise over a few beers shortly :)

In my humble opinion the only reason you should consider using SharePoint 2013’s social features over Yammer is if your organization is 100% unable to use a cloud based service.

Why?

Because there isn’t a future in SharePoint on-prem social features.  It’s just not what Microsoft does when it changes direction.

When Microsoft takes a bet on something big there are never two options to pick from. There is only one option and the rest is dead to them.  Rightly or wrongly, whether you like it or not, for good or bad … that’s just the way it works.  This basically means that after that speed it approximately takes for one synapse to fire Microsoft and all its muscle (sales and otherwise) stopped selling on-prem social and started selling the new cloud social story like it was never any other way.  You won’t hear anything pitching on-prem social over Yammer and it will only be used as a fall back position if the organization cant use the cloud for whatever reason.

“What should I use for social?  Yammer or the SharePoint newsfeed?”  My answer has been clear: Go Yammer!  Yammer is our big bet for enterprise social, and we’re committed to making it the underlying social layer for all of our products.” – Jared Spataro, Senior Director – SharePoint, Microsoft Corp – 19th March 2013

Update 19th March 2013:  If you want more of a nail in coffin then look no further then Jared’s latest update on the Enterprise Social Roadmap. The quote above is from this post Yammer and SharePoint: Enterprise Social Roadmap Update. If you read that 90% of the post is dedicated to Yammer with a fraction dedicated to “If you are old and clunky and stay on-prem then here is a skinny bone to chew on”.

“Cool” you might say.  “That doesn’t change what you can and can’t do with the product.  On-Prem is still my bag baby!”

If you look at the features, pros and cons and line them up side by side on-prem SharePoint social will win the sprint today … by quite a long margin.

But mark my words … it won’t win the marathon.

Here is my prediction for the next couple of years.  SharePoint on-prem social features might be lucky to get a few new features. Maybe a some in the next update, maybe a few the one after.  But where we really quit the crap and bring on the meat will be in SharePoint + Yammer integration. This is obviously not rocket science given MS just spent $1B+ dollars on it. Everything social in SharePoint Online will be ripped out and replaced/backed by Yammer with deep integrations that don’t exist today.  100% effort will be put into this experience as a first class citizen vs. the on-prem story… sad face … I like on-prem too … but like I mentioned above on-prems dead baby.

Eventually there will be no Yammer. It will just be SharePoint Online with a lot more rocking social features built by a team that deeply understand Enterprise social.  MS didn’t buy Yammer for their customers (they were mostly already SharePoint customers anyway) … they bought them for the kudos in enterprise social and the team of people who get it. Microsoft needs to win enterprise social big time and Yammer are the A game.

So why would I say don’t invest in on-prem social with the SharePoint features you get in 2013 if you can at all help it?

I would put money on there not being a great upgrade story on-prem to whatever comes next in the cloud … if at all. There could be one IF you are using SharePoint social features in 365 today … maybe.

Maybe I will have to eat my hat some day when I look back at these words … but if I were made to pick a winning horse today I would be betting on Yammer and having a smoother path to niceness with future releases.

Sure, this might mean having a muddled and semi painful story now as Jeremy points out in his post. This might mean you need to educate users around using Yammer, doing some work to federate for authentication purposes so you don’t have two logins, doing some integration work to make it easier to post stuff to Yammer from SharePoint etc.…   at least until MS pull the next round of SharePoint integrations with Yammer out of the hat and make things a lot less confusing etc.…

But at the end of the day I would be ok with that vs. being backed into a corner that you cant get out of or have a harder time getting out of.  Even if that means living with a less integrated experience today.

Who knows … I could be 100% totally wrong (in some ways I wish I will be) but maybe I wont and I hope to have saved a few of you from writing a kilotonne of migration code trying to get all those posts, likes and follows moved over to Yammer … but having said that I am sure AvePoint will have a nice migration tool ready for that eventuality anyway … so maybe all this is moot :) PS: AvePoint migration tools rock by the way.

PS: The real moment I will freak out about Social in the enterprise will be when Facebook finally gets around to releasing an Enterprise offering walled garden style social experience for organizations.  I have thought for a while now that it would be “any moment now” … but nada so far.  If that happened and they offered light weight document collab etc.… it would be a game changer.  But maybe zuck is holding off while him and Steve continue their wee love fest while trying to stiff Google. Time will tell I guess.

Disclosure: The company I work for is a Microsoft partner

If you were expecting me to have a real change of heart since my last review 4 years ago, you are probably going to be disappointed. This is the least favorite option of the 3 products I am reviewing in this roundup. I will do my best to explain why.

1. Cost

The great news is that now with Sharepoint you have some really nice pricing options. One of my original gripes with Sharepoint was that it was extremely costly. You had a lot of upfront costs + per user costs + hardware costs + expensive Desktop software costs (Visual Studio, etc.).

While many of those costs still exist for the server version, Microsoft recently added Sharepoint Online which has a much simpler pricing system. I actually reviewed both the Sharepoint Online $3 user/mo plan and the server edition on Rackspace which offers a free trial. I will detail some of those differences as we review this product.

The enterprise server edition is still pretty pricey even if you use Rackspace. Using Rackspace is a way to cut down on your company’s IT costs since you will be outsourcing some of the difficult IT infrastructure to Rackspace. That being said you would still likely have some of the same licensing costs even if you use Rackspace or another hosting provider.

SP online offers $3/mo per user costs with no minimums and they also have a $7/mo option (with a few more features) as well. Crunching the numbers for a small 30 person company you’re paying $90/mo and for a 100 person company you are paying $300/mo. This to me seems a lot more reasonable as pricing goes compared with Jive.

2. Ability to Customize

This is where your Sharepoint version matters. With the online product you have the ability to change the look and feel of the site and add apps to the site including apps from the app store (which offer free and paid apps).

Customizing the theme

Adding apps to a site

Furthermore, a big customization aspect is the ability to add multiple site collections and subsites (which has been a strong selling point for years). You can create public sites, private sites and sites that are subsites of others. You can imagine how this is appealing to large businesses with many departments. And remember you can do all of this now online without all of the expensive hardware, IT support, etc. that used to be required to run Sharepoint.

With the server edition you have much more flexibility to customize Sharepoint. Sharepoint runs on ASP.NET. If you have ASP.NET developers on staff, you have the ability to create features using ASP.NET and deploy them to the server. This has also been a big selling point for Sharepoint.

I was very critical of this aspect of Sharepoint in my original blog because as I found then, SP was much more difficult to customized (via development) than what was advertised. Even with several expert ASP.NET develoers and a windows server admin on staff we had difficulty doing simple development tasks. Numerous SP defenders responded to my original post saying these issues have been fixed over time. I no longer have Visual Studio and I no longer work on Sharepoint sites so I can’t comment on these improvements. I can say that for organizations that have ASP.NET developers, the server edition will certainly be an advantage. For businesses that don’t have Microsoft-developers, now they have an online edition only version which will likely be a better fit.

3. Overall features

As I started playing around with Sharepoint 2013 I also read some reviews to compare my experience. A quick Google search provided favorable reviews that are worth mentioning:

• TechRadar.com: “SharePoint Online 2013 Review”
• InfoWorld: “SharePoint 2013: A low-key update you'll love”
• Ars Technica: "Review: Exchange and SharePoint 2013 ready for cloud—yours or Microsoft's"

After reading these reviews, I discovered what I experienced and what I read were significantly different. It took me a long time to figure out what was going on. And I have built an entire Sharepoint site. I have created and deployed SP features. I have read Sharepoint books and I am familiar with the Sharepoint vernacular. I still had a difficult time figuring out how to navigate Sharepoint.

Sample site administrative homepage

To be fair, with a large platform like Sharepoint there is going to be a learning curve, especially for administrators. TechRadar puts it this way:

It takes time to figure out everything you can do, and to get the most out of it you need to get everyone to put their documents and thoughts and analyses into SharePoint sites.

So that for me is the first issue I have with Sharepoint. It just does not seem user-friendly to me. My feeling is that many of these blog reviews compare Sharepoint with itself, as opposed to comparing Sharepoint with competing products. If you strictly compare Sharepoint with prior versions you could argue that SP has improved in all aspects. But SP is no longer the only enterprise-level offering. In that light, it’s really more of a fair comparison to evaluate SP against other products with similar features.

Here is an example. I see an app for “Custom List”. This is a feature familiar to SP users but maybe not quite as clear to non-SP users. So I add the Custom List app to my site. I am not 100% what it’s for but I take the plunge and add the Custom List.

Screen grab of the “Custom List” content area.

I start adding items only to come to the conclusion, “Now What?”.

After adding a few items

This feels a little bit like Drupal taxonomy but I am not 100% certain. I vaguely remember using it somewhat like taxonomy when I worked on my last SP site, some 4 years ago.

When I click on the options area my hunch is that there are some awesome things I could do if I only knew how. And so maybe a good Sharepoint book would help me out right?

Click on menu options for an item

But then that’s the issue isn’t it? As the TechRadar reviewer mentioned that a social intranet like this is only useful if everyone is interacting with it. And SP in my opinion is just too difficult to entice everyone in an organization to use it.

Learning curve aside, one of the big selling points for Microsoft is it’s integration with other Microsoft products. Now I should mention that Jive (and probably others) also have some Microsoft integration. I did find with the online version of had some Office integration that the server edition did not (maybe because I was using a barebones version perhaps)? I found this to be a pleasant experience.

Adding a SP document

Adding a Microsoft Word doc

Office 365 is Microsoft’s online suite of products meant to compete with the very popular Google Apps suite. At Mediacurrent we use Google Apps and love it! I have looked at Office 365 and my impression is that there’s no compelling reason for companies to pay the added cost unless they have already been in the Microsoft ecosystem / upgrade cycle for many years. That being said, for a full blow-by-blow comparison check out this recent comparison from PCWorld: “Office showdown: Microsoft Office 365 vs. Google Apps.”

Conclusion

My conclusion is that Sharepoint is better in it’s current form but not significantly better than the competition. I would not be able to recommend this product to anyone who is not already entrenched in the Microsoft ecosystem. What I mean is that for companies who use Microsoft products for years, run Windows servers, and who perhaps who have even used past versions of Sharepoint, I would certainly think that those organizations would be more comfortable with this product. I am sure I will get feedback from such people who will tell me that I am overly critical of Sharepoint. I just want to reiterate that companies that have ASP.NET developers and run Windows servers, for that audience Sharepoint is probably your best bet. For other organizations I am pretty sure it wouldn’t be the best fit.

To me the best feature of Sharepoint is the ability to create multiple site collections and multiple subsites, with permission inheritance. And you can have it all plug into Active Directory. This is really how you can harness the power of Sharepoint. I also think that Sharepoint is much more suited for intranet sites and public sites. That being said, there is certainly an advantage to using one system for all.

Inmagic recently blogged about the limitations of using SharePoint for library applications, and this prompted me to write this post sharing my recent experiences setting up a SharePoint site for a library catalogue.

We have been working with a client to create a SharePoint 2010 site for a new resource library to manage codes, standards and related documents.  SharePoint is this client’s preferred platform, and as their processes for getting approval for any new software such as a proper integrated library system are onerous, time consuming and often futile, it was decided to just accept the limitations of SharePoint. 

Once it was established that we would need to design a library catalogue in SharePoint, I went searching the web for advice and suggestions.   This in itself is not easy, as a core concept in SharePoint is “Libraries”,  so it is hard to differentiate terminologies and find results relevant to SharePoint usage in a corporate Library setting.  However the references I did find were mostly concerned with how unsuitable it was, although none gave any detailed specifics of particular issues.  I found one SharePoint based library system advertised, but the vendor website is no longer active, and I chatted to a reputed ILS vendor who mentioned spending three years trying unsuccessfully to port their ILS to SharePoint. 

The prospects for designing a catalogue in SharePoint for our client were therefore not promising!  I started our project with SharePoint 2007, but very fortunately the client was able to upgrade the site to SharePoint 2010 mid way through.  I would never attempt to design a catalogue (or anything else) in SharePoint 2007 again.   However with either version, there are still many frustrations, especially as in our situation we were not allowed access to SharePoint Designer which allows editing the underlying website and HTML.  We were required to work with our client’s templates, stylesheets and site structures to ensure a consistent branding across all their SharePoint sites. All comments below are therefore based on just the out of the box functionality available to a site administrator. 

Designing any site in SharePoint needs a thorough planning process, and discussion of this is beyond the scope of this post.  However for anyone contemplating designing a catalogue in SharePoint, here are some factors to consider.

Specifying content types:

• Most corporate library catalogs will include different types of material, i.e. books, reports, journals, videos, websites etc.  Some of these may require columns (fields) unique to a specific type.  For example you will probably want to add a Frequency column for a journal but not for the rest.
• By default, all columns show in all displays regardless of whether they have data.  (This reminds me of the original library systems which have now all long since hidden any empty fields!)
• To get around this, we set up different reusable Content Types each inheriting from a core set, and different views (display forms) for each type of material.
• Depending on your version of SharePoint and your specific site settings, there may be a lengthy list of content types and existing site columns to choose from.  There is a very rudimentary description of the expected content for each column,  but no indication in advance of parameters such as if the column type is pre-set, i.e as single line of text, multiple line of text, choice, lookup etc.  Changing a column from one type to another after the fact is often not an option.  Some may also have unexpected settings, e.g. the Route to External Location column.  There is no indication when adding it to your content type that this is a Required Yes/No column, or that it is a  persistent or “sealed” column that cannot be deleted!   There are 28 or so of these persistent columns including others with innocuous sounding names such as Article Date.
• SharePoint has several reserved column names that cannot be changed. Therefore “Author” in SharePoint terminology is the person creating the resource (record), not the author of a book. It’s not difficult to add a new column for BookAuthor or equivalent, but on the default search results, all records include this SharePoint Author column which is of course inappropriate in a library context. “Date” is also included by default too, but this is the Date entered not a Publication Date.

Formatting views:

• Most default views in SharePoint are columnar which is perfect for many types of information but does not work well with variable library data where for example, a title can be very short in one record, and very long in the next.  There is no easy way to force a set column width unless you have access to SharePoint Designer.
• There is a Datasheet view option which is very similar to Excel and would be great for quick editing, but SharePoint does not support this type of view if your content type includes any Managed Metadata columns. 

Managed Metadata:

• Managed Metadata provides a new taxonomy capability in 2010 which mitigates some of the other negatives when working with SharePoint. 
• We are using this new column type in several ways:
  • As a controlled vocabulary for our LC Subject Headings so that our technician can start typing and any matching terms are displayed. 
  • Synonyms or abbreviations can be included, so we use this for Publishers so that they are findable by both their full name and their acronym.
  • Terms can be added in a hierarchy so we use this for specifying a general Location and then a specific Office where the items are stored.
  • Multiple terms can be added to a record quickly, and new ones added either on the fly, or through the Term Store.  (However there is no way to batch add an existing list without SharePoint Designer.)
  • Best of all, we can use these Manage Metadata columns as Search Refiners to produce a faceted search results page.
• The downsides are that you cannot import records from a spreadsheet or use a Datasheet view if the list contains any Managed Metadata columns. 

Search Refiners:

• We were able to set up several custom search scopes and set the default search to the Library Catalogue only.  
• Our custom search results page is set up with multiple Search web parts including a Refinement Panel.  Choosing which columns to use as refiners is picky requiring editing a popup XML Editor, but at least it can be done without requiring SharePoint Designer.  However we have not been able to force a consistent order for displaying these refiners, so if a result set mostly belong to the same material type, that refiner is not considered important so it appears lower down the list. 

We have had to lower our expectations regarding what we will be able to accomplish without SharePoint Designer or any IT support. Fortunately the collection is predominantly virtual, so we have not had to think about printing spine labels or shelf lists sorted by LC Classification.  We now have a functioning catalogue and some workflow created with InfoPath forms to support requesting and approving new orders, but there is no question that a purpose built integrated library system would be preferable. 

It may appear that migrating an existing library system to SharePoint or starting a new catalogue would be a cost saving measure if an organization already has SharePoint.  However, as there are no commercial library packages offered on the SharePoint platform, any system will have to be developed and maintained internally.  This reminds me of the many library systems set up over the years in Microsoft Access that end up unsupported when the particular developer leaves. We have converted many of these Access databases to standard library software, but this can be a time consuming process as often the records have limited fields or authority control, requiring us to upgrade the cataloguing. 

The problem with SharePoint social is all or nothing. Some organizations doesn’t want to enable the personal sites but keep newsfeeds and follow!

Also SharePoint social doesn’t have any alerting features. So when someone mentions you don’t receive any email and you have to check the news feed. No way of sending direct message like twitter. I feel MS decided to stop in the middle of journey because of yammer acquisition

For a few years now I’ve been pushing myself to see what is possible with SharePoint 2010. Some of these things are small, out-of-the-box (OOTB) solutions: creating custom search scopes, customizing table styles, and messing with itemstyle.xsl. But more often than not, the solutions I like to create are the ones that go beyond what SharePoint does OOTB. I rely heavily on SPServices for a lot of these solutions. It’s a great tool that does everything I need to do with lists in SharePoint. More recently I’ve been using SharePoint’s REST service and wiring in things like Backbone.js to create some interesting solutions.

Side note: if you want to see some great front-end solutions using SharePoint, check out the book Black Magic Solutions for White Hat SharePoint.

Where is the line?

I was training a SharePoint newcomer last week in New York. My trainee had a strong developer background, and just needed to get familiar with SharePoint for an upcoming job. As I was explaining things to her, I started to talk about a few custom front-end solutions that I’d built, and she latched on to those (coming from the developer world). But as I was explaining things to her, we started to discuss the legitimacy of doing some of these things in SharePoint. When does it change from a “SharePoint solution” to a “solution that uses SharePoint as a relational database”?

Let’s say you are using jQuery, SPServices, and maybe the Google Charts API. You can hook into a list, display a really great chart, and put it on a SharePoint page. That’s a great use of SharePoint. It’s a single page, accessing a single list, and enhancing the experience for the end user. Now say you have several lists that need charts. So we put several charts on the page. Easy. But how about when it comes time to organize all of these charts (say we have 30)? Now we need to add some UI elements that organize the charts in, say, tabs, or maybe an accordion. Ok, that’s great. But now instead of hardcoding in all of our lists to our scripts, we want one list just to organize our other lists. So now our code is much cleaner, we get all of our chart references from one list, and we organize it on the page with one cleaner, bigger script. At this point we have now made a list into a relational connection to other lists. But this is fine, even SharePoint allows this, right? (think Lookup fields)

So where is the line? How many lists must be connected before we pump the brakes and say, “wait…things are getting a little hairy”. See, in my opinion, SharePoint is a great place to store data. It’s also a great place to store data from external sources. It’s a great collection point for everything from a SQL server with lists of students, or to a connection to a 3rd party Gradebok. That’s what SharePoint is great at, being a central point of contact for many different systems. So the logical next step is to build things on top of this central point in order to interact with the data, right?

My personal line

All of my solutions are front-end, nothing server-side for me. But I recently ran into the limit of what I felt comfortable doing using javascript and SharePoint. A client of mine was building a re-enrollment process for the following school year. This process involved parents logging in, seeing their children on the page, and then initiating a re-enrollment form for each child. The form was build using javascript, jQuery, SPServices, and a host of other little plugins (for validation, navigation, etc). It was based on at least 3 lists, one that stored parent data, one that stored student data, and a connector list that connected families together. Functionally, the app worked. There were bugs like anything else, but overall, it worked.

Here’s the problem I had with it. In order to give parents rights to see their data, as well as their child(ren)’s data, we needed to give them access to the parent and student lists. This meant that for that period of time, all parents (if they knew the address) had access to all the data for all other parents. Now, this school is a fairly tight-knit community. There was nothing more in those lists that couldn’t be found out through the directory and doing a little digging. But nonetheless, it was all right there, in an easily exportable format. The intranet is password protected, but who is to say a parent with malicious intent couldn’t have really caused a headache for a lot of people?

But for the sake of argument, let’s say that the list is obscured somewhere or somehow the parents couldn’t directly access it. Well that still leaves a hole on the javascript side. Because it’s javascript, all of my code is loaded in the browser for any tech-savvy user to check out and study. If they weren’t deterred by sloppy code :), then they might be able to get in there and see what’s happening. At very least they can check the requests sent through the console. Once they have this code, they could modify it however they want and run it on their browser. How about if they could figure out how to impersonate somebody else by hardcoding in a username? What if they figured out a way to delete all other re-enrollment forms?

All this aside, we weren’t really worried because a) the time period was so short, and b) the stakes weren’t too high. That said, this was definitely a clear line for me in where I stop using SharePoint. Keep in mind, that’s when “I” stop using SharePoint. A back-end developer could have a field day with this project. Put everything server-side, secure it to the logged-in user, and you’ve got a much better system.

When to stop designing

The other question I have is: how far do we veer from the ‘spirit’ of SharePoint? Branding a master page, making a site look ‘not like SharePoint’ is one thing. But how about these custom solutions? I generally start with a blank HTML file, add in the javascript I need, and then wrap it in some ASP goodness to make it look like a page on my site. But how about the UI elements? Do we use SharePoint list views, or do we built our own repeating table with HTML and javascript? What should we do? Do we use SharePoint forms? Do we only go so far as to create forms in InfoPath? Do we completely customize every aspect of the form because we can “do it better”? I think at some point we need to leave SharePoint alone, let it do what it does, and relegate ourselves to ‘enhancing’, not always ‘replacing’.

SharePoint has its faults, many, many faults. But I think we are doing ourselves an injustice to use SharePoint for some of these solutions. While we may be thinking, “look what I can do with SharePoint,” maybe we should take a second and think “should this be done in SharePoint”? There are faster ways to do things. There are more efficient ways to go about linking data from relational tables.

So where is the line? Where is the line for you? When do you stop developing front-end and go a different route? What are your personal limitations?

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

What other advice do I have?

Which deployment model are you using for this solution?