For this, I stared to develop a project I call MyBoard – a SharePoint Single Page Application (SPA) that turns any SharePoint list into a list board (Kanban) complete with drag-and-drop and easy access widgets for managing the cards on the board. This is now a fully working “app” (not a SharePoint App) that I am using in several different projects where we needed to manage a list of work items across a small group of people. It’s simple and efficient and all it takes to get it going is uploading one single ASPX page to a document library. Oh, yeah: and it works on SP2010 and 2013 (and probably even SP 2007 if the proper document header is used).
In working this app, I have ended up with several reusable components that I’m sure I’ll take advantage of in future projects. Some of which I’m also thinking of also making available as open source projects on github – along side some of my other projects, including the SharePoint widgets library.
I like Trello. It’s clean, fast and efficient as it allows you to apply several action on the cards via each card’s menu. With that service as the model, my requirements for MyBoard were the following:
- simple to setup and configure including support for zero-configuration
- adaptive of site’s existing data (lists, Document libraries)
- multi-user support and bookmarkable urls
- integrated into the site’s look and feel
- quick actions available from each card
The app works by having the user select the current site’s List to be used in retrieving data for display, along with the list Column that will be used to build the Board. The Column needs to of type Lookup or Choice, so that its values can be used as the Kanban board’s columns.
A little more on these, including what I have learned and where I currently stand with them:
Simple to Install, Setup and Configure
As I already mentioned above, the entire app is contained within a single ASPX file, which includes all needed dependencies include a private version of jQuery – thus there is no issue or conflict with deploying this to a SharePoint site that already uses jQuery. You drop that file into a Document Library and everything else is configured from the app once you click on the file.
This single file is the result of the build process, which uses grunt as the task execution tool. It takes all if the code files, it combines them into one file, minimizes it and finally inserts the code into the ASPX file. In addition, I have a grunt task that also copies the built ASPX file to the document library on SharePoint – essentially “deploying” the app. Grunt tasks were strait forward to setup and there are tons of examples online on how to achieve any task. I did have to write some functions for embedding contents of one file into another, something that I could not find good example on. There are tons of concatenation examples – but I needed to include the content in specific locations. Perhaps I’ll write about that in the future.
The project source, however, is laid out very differently on disk, with several individual files. For development and debugging I have a special ASPX file that loads each file individually so that I can easily use the browser development tools to focus on the set of functionally I’m working with rather than having to browse through a long list of code all in one place.
So this allowed me to become very familiar with Grunt – just as Gulp is starting to gain some ground. I have not tried it, but the approach it uses seems allot more attractive to me: code-over-configuration. Perhaps that tool is another excuse for me to create a new project where I can apply it.
Adaptive of site’s existing data (lists, Doc libraries)
I wanted the app to be able to use the site’s existing data and not impose a specific format to be followed or predefined structure. The only requirement is that the List or Document Library have a column of type Lookup or Choice, which is needed to build the board. This design makes it feasible to use this app immediately with existing site’s data.
The only portion of this design I am not happy with is how slow the editing of a card is. When editing the card content, the SharePoint list Edit form is shown in in a dialog, thus loading all the bloat that makes up that form. I may implement my own edit form and add some of the features found in Trello (like inline editing, and progressive saving).
Multi-User support here simply means that updates by others users are near-instantly seen by others whom may also have the card displayed on their board. For this I built a library that provides data persistence between the SharePoint list data and the web application. This layer is so cool (if I can tune my own horn here) that I know use it on all SharePoint projects that needs to get data out of SharePoint lists.
It uses the GetListItemsSinceToken API operation and depends on Knockout.js and it’s Observables to achieve its automatic insertion and removal of items from the query result as well as the notification of any bound listeners. You use it the same as SPServices GetListItems, but you get back a Promise that resolves with a Knockout observable array containing the list item matching the defined filter. From that point forward the query continues to check the list for changes on the query used on input and reflects that on the results array if any are found – which in turn are reflected on the UI if the Observable Array is bound to the UI (presentation/view). This library also provides a custom binding called SPField that handles the display of sharepoint data – including the format of it (like lookup, Date Values, etc.).
I’m considering releasing this library as open source via github. The code is pretty solid right now, but I need to spend some time documenting the external API and provide some usage examples – maybe even a sample app.
In addition to having constantly updated data displayed on the board, the app also needed to support the ability for the user to “preserve” the setup, so that they did not have to create it on every page visit. This is supported with two approaches:
Predefined Board Setups
An administrator (one having write permissions to the folder where the MyBoard ASPX file is stored) can create boards and then save them as predefined setups. These show up on the Ribbon menu, under the ‘Board’ button:
This is a very common approach with SPAs – using the hash portion of the URL to represent the “page” the user is visiting – also called routes. MyBoard uses the Sammy.js library to achieve this functionality and thus any user can create and configure a Board and then bookmark the page. As they configure the board, the URL is updated to “maintain state” and thus will recreate the view once loaded again. This also makes it ideal to send the url to others, if wanting to share information. Here is an example of such a URL:
Integrated into the site’s look and feel
This is a work in progress, but the primary thing I wanted to accomplish was to utilize the Ribbon to provide navigation and controls for this app. With time, I’ll look to also use the styles used to brand the given site so that the entire apps feels integrated.
This is yet another library that I’m thinking making available as open source via github. For the most part, much like the data persistence library, the code is pretty solid. The documentation effort, however will be significant and will delay when I make this available (I don’t like to release a half-baked library :) ).
Quick actions available from each card
Having to open each card just to make a small changes, like setting a value in a column is overkill. Simple tasks like that should be possible right from the card menu – just like Trello. So each cards menu (currently) supports:
- assigning users to the card
- email the card
- showing the cards direct URL
Other actions that are In the backlog and will be implemented sometime in the near future are:
- set categories (labels)
- subscribe to alerts
- ability to set any single value columns (those of type Lookup or Choice)
Most of these action are possible only after the user configures the board, which once created, allows the user to set which of the selected list columns will support the action (ex.: which column should be used as the card Assignee, which column should be used for labels, etc.)
So what am I going to do with this app?
Right now I’m keeping this app private and using it in a few projects. I was thinking about converting it to a SharePoint App, but I’m not a VisualStudio person and with my ever decreasing focus on building tools/apps on SharePoint, not sure that will happen (Ps. Would love for Microsoft to support packaging SharePoint apps outside being forced to use their own toolset). The thought of putting up for sale has crossed my mind. Nothing outrageous, but a small fee. But perhaps in the end, I might make available a free “closed source” limited functionality version with an option to license the full version. That last option may be the one I ultimately pursue. It will give the opportunity/excuse to convert this project to use Require.JS and split up the code into modules. Once they are in place, using a (Grunt) build task that creates both versions will be fairly strait forward.
If you have made it this far in reading, let me know what you think I should do it. Do you think there is a market for a paid version?
Special Thank You
I have asked a set of folks who are much more involved with SharePoint than I am, to evaluate this app and received some feedback – specifically from Stefan Bauer (@StfBauer, blog at http://www.n8d.at/blog/). His UI/UX constructive feedback was outstanding and although I have not yet followed up on all of his feedback, I will at some point in the future.