Centric connect.engage.succeed

Building an interactive floor plan using out-of-the-box SharePoint components (and some JavaScript) – Part 1

Geschreven door Erik Nell - 06 september 2016

Erik Nell
I thought it would be nice for this blog to describe an actual project I did from start to finish. Because it turned out to be quite a long text, I decided to split it into parts. This first part will describe the problem and my thought process in coming up with a solution. In later parts I will go into further detail about the technical implementation. Please note: to protect my client, I cannot show the actual solution. It might contain sensitive information. Therefore, I have rebuilt the solution (with some simplifications from the real implementation) and used dummy information. Also note that the original solution was built for SharePoint 2010. However, it migrated perfectly to the Office 365 environment I used for this demo.

The business case

The client I’m working for is a local branch of a multinational corporation. Their plant has three buildings of which two have multiple floors. There are a lot of conference rooms spread around the buildings and people were having trouble finding them. We had already made all these rooms available for booking in Outlook, so people were already familiar with the rooms. The trouble was that many didn’t know the physical location of these rooms. The need for clear, up-to-date, and extensive information regarding conference rooms was compounded by two other things:

  • Due to the nature of the company, staff turnover is quite high. People from all over the world come to work here for a couple of months and then leave for another branch.
  • The internal layout of the building is subject to constant change. Departments move from one building or floor to the other and conference rooms come and go.

The most logical place to present this information was our local intranet, built on SharePoint. This intranet was introduced a couple of years ago for mainly the same reasons as stated above. We wanted to have a central place where colleagues could find all relevant information regarding the local plant. Among a lot of other functions, we have a visitor registration system for the receptionists and an incident reporting system for facilities management (maybe something for a future post). This conference room overview, as we imaginatively called it, would be a nice extension of the functionality.


Conference room information will be primarily presented from floor plans, with a separate plan for each floor clearly showing where conference rooms are located. When clicking on a conference room, a popup will appear, showing additional information such as capacity, available resources (screen, whiteboard, phone etc.), and photos of the room to aid recognition.

Because the information is subject to change, a flexible solution was needed. Conference rooms come and go or change drastically in terms of their capacity, equipment, or other features.

Figure 1: Final look

Figure 2: After clicking on a conference room

The most important factor

The most restricting factor for this solution was money (isn’t it always?). We didn’t have sufficient budget to buy additional software (or hire a graphic designer – something I still regret, but more on that later) and time was limited. We had to make do with what we had available. Luckily, SharePoint offered (almost) everything I needed out of the box.


Allow me to go off on a tangent for a bit here before I return to the central theme. I have been a big fan of client-side development for years, even before Microsoft started on this path. I still have a copy of Marc D Anderson’s The Middle Tier Manifesto from 2010 in my desk drawer. Unfortunately, the link to the original document in that article is broken, but I found a copy on SlideShare. Still nice to read after so many years, and surprisingly relevant.

Marc’s crowning achievement was his wonderful SPServices utility. It’s basically a wrapper around the horribly convoluted SOAP calls that you had to do at the time. This was before REST came around.

For me, it all started out of necessity; the SharePoint environment (sp2007) at a client I was working for was pretty locked down for non-admins. Getting managed-code solutions deployed on the server would have been a challenge, let alone getting it done on a regular basis. Using client-side development and deployment gave me almost the same results without the hassle.

Over the years, the situation improved, but I still find myself using this technique most of the time. There are a couple of reasons for that:

  • The projects I do are relatively simple and short in time span.
  • I act as a single developer here, so there is no need for extensive tooling to collaborate on a shared code base.
  • Over time, I really got the hang of this way of working and I developed quite a code base of JavaScript utility functions to help me out in generic situations.

Basically, this approach lets me write the functionality I need using JavaScript, css and xsl and store the source files in a SharePoint document library. Using the humble content editor web part, I inject the JavaScript on a page and hey presto: my single page application is ready. Works like a charm 

I can hear some of you shudder at the thought of not using any source control system, or structured development pipeline, but I think it is justified for this kind of quick (and dirty) solution.

All this made it natural for me to take this approach for the current situation too.

So, what I needed for the solution was:

  • Floor plan drawings. One for each floor. Because we couldn’t hire a real designer, I had to do this myself. I managed to churn out something using Visio. It’s no Rembrandt, but it is functional. Still, I think that if we ever get the chance to hire a professional for this, the results would be 10 times better. But that would also mean that each time the building layout changes we would have to re-hire this designer. Good for him/her, bad for our budget. So I had to settle on something that was easy to maintain for a non-designer like me.
  • A list for storing generic conference room information.
  • A list for storing information about the floor plans themselves, including a link to the actual floor plan drawing.
  • A document library (or picture library) for storing the photos of the rooms and the floor plans themselves.
  • A way to display the floor plans and get the popups with additional info working. Basically, this will be JavaScript, xsl and css. This turned out to be the bulk of the work.
  • A place on the site to store the JavaScript source files so they are accessible for regular users. The most logical place for this is a document library that you lock down to read only. An additional bonus is that you can enable versioning and you have a very rudimentary form of version control for your source files. I already had such a library from a previous project, so all I needed to do was create a new folder in this library.

After discussing this with my manager, he gave me three weeks to build it. A tight schedule, but I managed it.

This is the end of part 1 of this series. In the next part, I will go into further detail about the lists I used and how it is all tied together using JavaScript.

About Erik 
Craft Expert Erik Nell is part of Team Office 365 within Craft, the development programme for IT professionals (powered by Centric). If you would like to follow his blog, 
sign up for Craft updates.


  • Independent
    Jeff Travis
    04 oktober 2016
    Great article, really looking forward to Part II.
Schrijf een reactie
  • Captcha image
  • Verzenden