Whose SharePoint is It Anyway

By Daniel Antion posted 05-22-2012 09:54


Lately, I’ve been reading a series of articles and blog entries aimed at promoting techniques for building solutions faster by using “standard” parts and reusable components – good thoughts, but it makes me worry.

I worry because I’ve been around this business long enough to remember multiple times when the focus shifted to rapid development instead of custom development, and every time that happened, solution quality suffered. At the dawn of the PC era, I worked for a guy who said “Everything is VisiCalc!” We laughed, but I’m sure that if you peak around your office, you will see numerous “systems” deployed in a spreadsheet that deserve a better solution. In fact, I would argue that some of the simplest efforts to make “development” faster have often produced results that are not as good as what we deserve. The simplest thing I can think of is a template. Templates can be a great starting point, but whether it’s a Word document that gets sent or stored with unused fields, a Team Site in SharePoint with a perpetually empty calendar, or a PowerPoint presentation with an awkward two-line title; templates often don’t move from that starting point.

If your job is to develop SharePoint solutions, then you need to sit with the people who will use that solution and find out what they need to do. If you want to start with an example, that’s fine, but if you find yourself starting sentences with “you should be able to…” stop! When you drop a “standard” part on a new page, explain the functionality to the person who will work with it. If they say something like “oh, we don’t use…” or “we’re not required to…” or “do you know how we actually do…?” that’s your signal to edit the part. It might be nice to have every department using the same widget, but not if everyone is forced to deal with 2-3 metadata columns they will never use or have to wade through three or five steps that really don’t help them get to the end-point they have in mind. If you want to save time during development, employ standard methods, use libraries of standard functions, develop your own library of scripts so that your toolbox has the tools you can trust. By all means, build yourself some templates, but use them as a starting point, not an answer.

#templates #rapiddevelopment #sharepoint #SharePoint #userexperience #webparts


07-06-2012 12:15

It's hard to know what to point you to, without knowing a bit more about what the person who wants to do Rapid Application Development means. I can say that we had Lotus Notes, and we have a pretty complex applicaiton running it it, and I could easily duplicate that in SharePoint. In fact, I'm guessing it would be easier in SharePoint than it was in Notes. I'm just not sure if you're talking about prototyping an application in SharePoint or rapidly building a functioning application - you can do both.
I would check out nothingButSharePoint.com and http://sympmarc.com/ for more information on developing applications with/in SharePoint. I would be happy to answer any questions, but these are the palce I look when I need answers and, in the case of @sympmarc, the person I turn to for help during development.

07-06-2012 10:41

One of my customer is asking me to present how to do RAD on SharePoint because he could do something with Lotus Notes, it seems. Any thoughts on this?
Gopalakrishnan NT

05-23-2012 10:17

Well said, Daniel! I often trim the columns to fit the individual user's needs, even if it is merely to display fewer columns from a company template. The key point I got from your blog is to LISTEN to the users and make the tool fit their needs. It seems so simple, but is so rarely followed. Of course, this could be because so many IT departments do the work themselves without using a person with strong understanding of SharePoint, especially the easier stuff like customizing templates. Many tend to leave it in the hands of users to make changes that might be a bit intimidating to them. It's not rocket science, but it does take some effort to customize the basics like web parts, lists, libraries, and pages. And many just don't do it leaving ill-fitting solutions to their needs and SharePoint (undeservedly) gets the bad rap for it.