SharePoint Review

When to stop using SharePoint

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?

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More SharePoint reviews from users
Learn what your peers think about SharePoint. Get advice and tips from experienced pros sharing their opinions. Updated: April 2021.
479,323 professionals have used our research since 2012.
Add a Comment