Angular JS with its single page application was a perfect fit for us because it was light weight and worked like a charm within Microsoft SharePoint.
Using AJAX to pull information from SharePoint lists made everything very user-friendly, we were able to access information from SharePoint’s lists, which was a big improvement since our users didn’t need to update the ‘text files’ at the back, but they could make changes to the content in the lists and see the results immediately. In case we required two-way data binding between the UI and our application logic and more functionality and play within the visual component, we moved on to Angular JS.
How do we make applications faster? Better?
With a typical requirement of displaying a bunch of data on the screen, let the user search and filter through it dynamically.
Traditional approach would be
- Develop, Build solution, move the WSP & deploy web-part
- If the complete data set is too large, the page can take a lot of time to load initially, AJAX can speed up this time
- Upon a search/filter query, a server trip would return the filtered result
- Upon each press of the search button, a resulting server trips adds delays and results in more processing to be done at the back end
- Any change to the application would mean development – retract and deploy with downtime
The same example with a single page application (SPA) using Angular JS would mean:
- Develop on text file – plug into any content editor
- The page loads up while the AJAX call is busy in fetching the latest data, put up a loading gif while he waits for data
- The user can use a variety of filters, search queries and see their request updated in real-time on the client’s browser. No server trip, no wait time, no frustration.
- Any change to the application would mean changes to the text files meaning no downtime for updating the application.
Two-way data processing
Gathering information from users on a form works just as well as getting data from a SharePoint list and displaying it on the page. Angular JS with its powerful client-side validations and processing can mean improved UI/UX along with the incredible maintenance aspect which was the goal all along.
Published originally on LinkedIn on August 11, 2016
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
“It’s not what Zune knows, but how Zune thinks”
Like everything else in our life, our thinking pattern should evolve to keep up with the pace of this world.