So I spend my days talking with CEOs, directors, and IT pros “in the trenches” and working with them to align SharePoint with their business, to deploy and configure and support the platform, and to generally be an “übergeek.” But once in a while, I get to be my own customer. This weekend was one of those times.
I’m working on an exciting event that will bring some of the industry’s top experts to cities across the USA and Europe this spring. Wrangling speakers, abstracts for sessions, cities, and schedules was going to be a Herculean feat. So I ate my own dog food, spun up a SharePoint server at GoDaddy, and got to work.
Within eight hours, I had a fully functional web application on which speakers could submit sessions, update contact information, review and agree to contracts, and on which I could select sessions, lay out a schedule, and do all the other logistical work required to prepare for the events.
My colleagues could edit abstracts, keep up-to-date with the latest information about the events, and it had all the security and workflows it needed to support our collaboration. It integrates with Office, so I can dump information into Excel and other apps for “crunching.”
My Inbox, which was being deluged with emails that were becoming tougher and tougher for me to manage, heaved a sigh of relief. Everything’s now in one place, for all of us, and we can all drop in when we need to work on the events, rather than sifting through heaps of email threads.
Hooray for SharePoint!!! I know that it would have taken weeks to develop a web app to do all of this, without SharePoint.
A tip or reminder of sorts came out of the experience: One of the little things that I was reminded of while rapidly developing my own solution with SharePoint was that I am regularly asked about ways to do “related lists” in SharePoint. There’s lots of information about this online, but there’s one small but important piece that is often overlooked.
In many situations, mine included, you do not NEED related lists in SharePoint in the same way you do in other databases, because you can relate the lists at the presentation layer. For example, I needed to be able to look at a speaker and see all of the speaker’s abstracts for sessions. SharePoint lets me add a lookup column to the Abstracts list that looks up the Speaker column from the Speakers list.
That’s great, it’s helpful, but it’s not always mandatory because I created pages with which I and other users of the app can interact with lists. The pages have web parts, and the web parts can be connected.
When you create connections between web parts, you’re basically creating ad hoc relationships. Select a speaker in Web Part A, and see the session abstracts for that speaker in Web Part B. And the web parts will let me show any and all fields from the lists, not just the limited number of “projected” field types supported in SharePoint 2010.
So just as a little tip, chill out about relationships, because there’s more than one way to get a “relationship” in SharePoint. Sometimes the answer is so easy (Web Part connections) that you forget it’s even there.
It was an absolute joy to build a solution for myself in SharePoint 2010. No code, and I only did a couple of minor SharePoint Designer modifications just for the heck of it (to make headshot photos size consistently in a list, I changed the HEIGHT and WIDTH attributes in the XSLT of the list view).
This is why I really love SharePoint—because it enables people to do their work more effectively and efficiently, which hopefully means they have more time to live. (Now if I only hadn’t had to do this on my weekend.) Have a great week, everyone! There’s actually snow on our volcano here in Maui, so I’m off to take pictures of the rare sight. Aloha!
