SharePoint is an amazing tool, the sheer breadth of options coupled with the familiarity which it has to other popular products in the office suite (MS Word, MS Excel etc.) makes it a top choice for corporations looking for a content management system (CMS). Designing a website on SharePoint can be difficult because of the great leaps made by the competition. WordPress, Drupal and others have taken the benchmark for design of a CMS to a whole different level. There are ready made themes which are beautiful and then a wide variety of off-the-shelf themes is even more inviting.
In a world of responsive design, with its many moving parts requiring a close eye, if you throw in a tentative and inexperienced team, with a large CMS like Microsoft SharePoint to the mix, things get interesting. And the thought of such a challenge can make many vendors shy away (obviously, many vendors take on this challenge, but some that I know of didn’t fancy it).
To get such a project to take off and complete on time can be tricky. Decisions on design are dictated by many organizational and often personal factors. Negotiating the back and forth and bringing the teams to a workable compromise requires lateral thinking, quick learning and hard work.
Some shortcomings of the existing mechanism
For a user interface (UI/UX) component, frequent changes would result in frequent deployments, which require a deployment each time resulting in a minor website down time. In an environment where each such iteration can result in outages, which in turn can harm the corporate brand, we needed to have a better solution.
UI/UX development is complex and considering the fact that most of the design elements are primarily visual elements (Examples like image sliders, navigation etc.) which display information (more on forms and elements which get and store information from the users later), and are updated frequently, we needed something which was truly agile, something which will be fast during development, accommodating to frequent changes, and can be updated without any disruption – all within the SharePoint ecosystem.
Content editor to the rescue
Problem with coding such design elements was that it took longer to update, compile, deploy and then test and it needed a server class machine and developers with enough knowledge. We always knew that we can manipulate elements via ‘content editor web-parts edit HTML feature’, but we didn’t think about using it for actual development.
We could change the file (which is referred in the content editor) as many times as we wanted without causing any disruption to normal business. These text files would have HTML tags, script and style blocks, which makes everything easy to manage on the development and user testing environments during the seemingly never ending ‘discovery and R&D’ phases.
The learned users could then orient themselves on where to make changes in these ‘text files’ and run with it. The days of outages for each and every design change go down drastically.
Published originally on LinkedIn on August 7, 2016