Akumina views – making SharePoint UI design easy and consistent

When you think about SharePoint development the first thing that probably doesn’t come to mind is, “Wow! Building our custom-branded experience on this platform could NOT be easier!”

The reality is that SharePoint IS a great platform. Combine it with Office 365 and you have arguably the best digital workplace cloud platform on the planet. However, in a lot of cases companies stand up the out-of-box version of SharePoint with some minor color palette changes. Ultimately this doesn’t deliver on the organization’s brand guidelines—all it does deliver is a lackluster user experience for employees. The reason? Frankly, it’s just a lot of work using traditional SharePoint development means.

You have an alternative to traditional SharePoint development.

Another approach? Use Akumina! Akumina is a lightweight development and user experience framework that fits within your existing SharePoint on-premise or SharePoint online architecture. With Akumina’s widget technology you can quickly deploy page components with tight control over the page output. As a result you can build beautiful user experiences in a fraction of the time. This is done through Akumina’s concept of a “view” which is an HTML file that includes Handlebars JS syntax to build semantic templates.

In a moment, I’ll provide some clarity on what exactly I’m talking about. But first, a little background on Akumina widgets…

What is an Akumina Widget?

An Akumina widget is a client-side component that provides a building block of functionality that can be deployed within the SharePoint runtime. The scope of what a widget could be is quite vast—anything from a widget that pulls SharePoint list data onto a page to a widget that pulls in tasks from a variety of sub-applications like Workday or ServiceNow. The anatomy of a widget is as follows:

• • Widget Definition. The widget definition is essentially JavaScript code that outlines what the widget does, where the data is coming from, what properties are going to be surfaced and, in some cases, data manipulation before final display.
  • Widget Instance. An instance is a single configuration of a given widget definition. The instance will typically utilize and set the properties that were made available. Let’s use a basic Twitter feed widget as an example. The API calls to Twitter would be contained in the widget definition. The definition would also have properties created such as hashtag value, default height of feed, and a choice between a light and dark theme. The surfaced properties would be set in the widget instance [hashtag: #Akumina, height: 400px and theme: dark]. Once the properties have been configured, Akumina will automatically generate a HTML snippet (which represents the widget instance) that gets deployed to the SharePoint page.

• • Widget View. Alright, back to the topic of this blog post: Akumina views. View files are .html snippets which the widgets bind their data to. The markup in a view file contains raw HTML and dynamic placeholders for where data (returned by the widget definition) will fall. Why is this a good thing? Well, for one it allows you to follow a consistent design pattern to build front-end UI regardless of where the data is coming from. This is because the view is separated from the data. So whether I’m returning data from a SharePoint list or an enterprise search index, the view file is built the same way.

Furthermore, since the view file’s anatomy is raw HTML, you can leverage standard front-end development frameworks like Bootstrap to roll out a fully responsive set of components with ease. Each widget instance can have multiple views, allowing the site manager to quickly switch between several renditions of the same data set. New to handlebars? No problem, let’s look at a sample:

Notes from above view file

1. 1. 1. Here you see standard Handlebar syntax (expression). In this case {{#Items}} implies that the widget definition is going to return more than one item. This allows the designer to create repeatable markup for every element returned. Handlebars provides several default tokens that can be utilized such as if / else statements, for each, Boolean checks, and much more. Essentially these expressions allow for some built-in logic to be applied to the views to support situations in which the developer may want to alter the output based upon a certain situation (i.e., no results returned).
      2. Data token: In this case we are passing in the Title of the content item. In some cases, you’ll notice views that simply use the column names of a SharePoint list as the data token, but this doesn’t need to be the case. The widget definition is in charge of building the data structure that gets returned to the view file—so the actual value of these tokens is 100% configurable.
      3. The rest of the file is standard Bootstrap syntax. In some cases, the view file might also include a snippet of JavaScript such as a jQuery plugin to further manipulate the end markup of the widget.

One more way Widgets are easier

Global organizations will especially benefit from the resource files in Akumina’s view technology. Akumina stores a set of values in a JSON file that can be referenced within a view. Each language the site supports would have its own resource file.

When would you use these? Well let’s say you have a label or button in your view. You don’t want to hard-code the value of those elements because you’d then have to create the same view for every language you are supporting—THAT would be a major headache. Instead, you can reference a token value that refers to the resource file mentioned. Here’s an example:

Hopefully this helps outline how much control you have over the end markup that shows up on your page with Akumina. With the Akumina platform organizations bring their creative designs to life, crafting compelling user experiences that employees can consume and take advantage of.