Tag Archives: JSLink

Top X Things Needed To Make PowerApps Awesome for SharePoint

While chatting about PowerApps recently, someone told me that I should always know my ‘top x’ things I want fixed, added, changed, etc. I can see where that might be handy to talk about with Microsoft, with other implementers, etc. It’s a quickly changing community and product and hey, they *are* listening. For PowerApps my current focus is on how it integrates with SharePoint. With that in mind, here’s my top 2. I’ll come up with more later. These are the ones I think are *really* important. 

  1. Embedded
  2. Embedded

PowerApps has great potential and already has a running start. But it has to nail the embedded story. If the integration of SharePoint and PowerApps is going to be *really* successful and gain the love of SharePoint users it needs to be easy and seamless. That means when a user selects a PowerApp in SharePoint it’s not going to jump to another application. It needs to run within the SharePoint interface.

So why do I list ‘embedded’ twice? Not because I really, really want it (I do) – but because there are (at least) two distinct embedded use cases:

Embedded Forms

EVERYONE has been talking about forms – which is well and good. They should be talking. They should (and have) been yelling. The gap is obvious and a solution is WAY overdue. With the scheduled end of InfoPath and the rudely unscheduled end of SharePoint Designer’s (SPD) visual designer, users have been left with one of the community’s longest and most obvious gaps. Thanks to third-party offerings (K2, Nintex, etc.) and community-efforts (Stratus Forms, etc.) certain needs have been met, but there are still gaps and it’s been far too long for a Microsoft-sponsored solution for business and power users.

Note: I don’t want this coming off as an anti-Microsoft rant. That is definitely not my intent. There were plenty of reasons for the delay. What they want to do and need to do is not trivial and the standards are extremely high. The integration we’re talking about also requires collaboration (see what I did there?) between two separate, complex, and rapidly changing products and teams. The PowerApps and SharePoint teams are also in different reporting structures within Microsoft. Fortunately both teams understand how important it is to get this particular integration done. The good thing is that there are many indications that this time around they’re going to make it – and maybe even exceed your expectations.

PowerApps needs to be able to replace existing SharePoint forms – the standard New, Edit, and Display forms – as well as add additional forms to a list or library. Form editing needs to be easy and intuitive in terms of which fields are displayed, how fields are laid out and formatted. Beyond that, there are plenty of other features we’d love to see, but the ones listed here are the core. Talk to anyone that’s used InfoPath or SPD and you’ll quickly get a list of wanted features.

We have every indication that Forms and the embedded experience will be addressed. Microsoft has gone as far as announcing that PowerApps IS the replacement for InfoPath. It is important to remember however that the features are coming iteratively, little by little, but continuously. So be patient.

Embedded Views

The embedded story that folks aren’t talking about as much is for Views. SharePoint views have historically been a powerful tool for business users. And while they are powerful out of the box, power users continue to find that they’d like to extend views beyond the out of box capabilities, and extend without involving developers when they are able.

Again, power users were once able to do some limited, yet still extremely useful, view customizations with SPD, but lost that power with the deprecation of the designer view. For the last few years, some customizations were again available using Client-Side Rendering (CSR) and the JS Link property of web parts. While extremely flexible, this approach was beyond most typical business users as it crept into a grey area between out of the box and ‘real’ customization and development. The approach never gained mainstream support or adoption. Now, as O365 continues to mature and lock down features that have the capability to jeopardize platform stability, CSR and JS Link are also going away from fringe power users and exclusively back into the hands of developers (good for the platform, unfortunate for those that were using it). 

Users need a way to get the benefit of SharePoint views, specifically choosing a list of fields, the order of the fields in a grid or spreadsheet format, the filter for the list of items, and how they are sorted. Once those core features are available they’re going to want the ability to customize that view using PowerApps’ ability to change field formats, apply conditional formatting, and other rules.

PowerApps today are surfaced in O365 SharePoint Online via the view dropdown.

image

Selecting one of them initiates the loading of a PowerApp, but only give the user a button to open the PowerApp – opening the client application.

image

Embedding the PowerApp would (hopefully) spin up a PowerApp right in the SharePoint window – just like any other view – rather than having to launch a client application – which is a fairly jarring experience for users.

I think there’s some interest in this use-case in the community, but it’s definitely less discussed than the forms example. I’m not sure what the interest level is, but I imagine anyone that was doing CSR and JS Link work would be interested in it. We’ll just have to wait and see.

#3 – A View Template

OK. So I did think of a third item on my list.

The current SharePoint template for PowerApps starts with a SharePoint list and creates a series of three forms in PowerApps. It would be great is there was a PowerApps template that took the selection a step further – into the current views for a list (or library) – and had a default layout that looks more like a traditional SharePoint view – a table/grid layout. This feature alone would allow SharePoint users to leverage their existing investment in views straight into extending them in the PowerApps interface. 

Summary

PowerApps is a powerful addition to the suite of tools Microsoft is making available for power users – many of which are currently using SharePoint. The PowerApps team wants to see user adoption grow and has a large group of potential users in the existing SharePoint user base – and SharePoint folks are an eager bunch. We’re already intrigued by the potential PowerApps brings to the table. If Microsoft is able to smoothly embed PowerApps into SharePoint (and Teams!) pages, users will be chomping at the bit to use PowerApps (and Flow) even faster than they already are.

Display Links to SharePoint Item Attachments using CSR

I had an inquiry this week regarding whether or not CSR could be used within a SharePoint list view to display links directly to an item’s attachments. It took a bit of tweaking code around a bit, but Raymond Mitchell (@iwkid) and I were able to get it working.

Background: SharePoint lists may allow for attachments to list items. SharePoint also has a default column that can be used in a view for displaying whether or not an item *has* one or more attachments. (Is that Clippy in disguise?)

image

A user experience (UX) stumbling block however is that you have to open up an item view in order to see the list of items and links to them. If you’re familiar with SharePoint, not a huge UX issue, but still somewhat irritating compared to just seeing the list of items in the view directly. If you’re *not* SharePoint-savvy, then you might not know at all whether an attachment exists or how to see attachments.

We’re aiming for something like this:

image

The CSR JavaScript file can be found here: CSR_ViewAttach.js

Note: I’m sure the JavaScript gurus out there will find more code cleanup that can be done and methods that can be used to improve it – this should get you started. We’ll add new versions as improvements are made.

Instructions for use:

  1. If you don’t already have one, create a ‘scripts’ document library on the Office365 / SharePoint site you’ll be using the CSR file on.
  2. Download the JavaScript file from here
  3. Edit the JavaScript file to work with your column, list and site URLs (see more in the sample file or below)
  4. Upload the edited JavaScript file to your ‘scripts’ library.
  5. jQuery is required for this CSR to work. If you don’t have jQuery already, upload it to the same scripts library. (See this post for more information on using jQuery with CSR)
  6. Add the Script Editor web part to your page or use the ‘Embed Code’ option to add a reference to jQuery.
    Ex. “<script language=”javascript” type=”text/javascript” src=”../Scripts/jquery-2.1.3.min.js”></script>”
  7. Your list: If you don’t have a ‘spare’ text column you can use to override in a view, create a new text column (ex. ‘ViewAttach’).
  8. Create a view for your list that includes your new column. You can still use all the same sorting, filtering, and other other view configuration settings for this view.
  9. When using your list view, edit the web part and add the link to your JavaScript file to the JS Link property of the web part. It will look something like: ~site/Scripts/CSR_ViewAttach.js

If everything is in place, attachments in your list should now be listed in the column you identified. (If not, check the common troubleshooting items for CSR… hmm, that sounds like another post…)

Items to configure in the JavaScript/CSR file before it will work in your environment (these are also noted in the file itself):

  • The (internal) name of field being overridden. In the example code below we’re using the ‘Body’ column (which is the internal name for the ‘Description’ field) of a task list. You can override any text field and/or create your own.
  • The siteURL variable.  — See example in the CSR file itself
  • The listName variable.  — The list that includes the attachments you’re displaying links to (example in file)
  • The attachPath variable.  — Link to where attachments are stored (example in file)

Thanks, Notes, and References:

Please let me know how this works for you!

Using jQuery for CSR

There are a few useful CSR utility solutions that require jQuery to be available to the CSR script. If you are an IW / Power User you don’t necessarily need to know how to use jQuery explicitly, but there are some easy templates that only work by using it.

If jQuery isn’t already enabled for your site, you need to add the jQuery file and a link to it on the page you’re using it on.

  1. Download the latest version of the file from HERE. Get the ‘…compressed, production…’ version.
  2. Copy the file to your Scripts library (just to be consistent with where your other CSR files are).
  3. On the page you are using jQuery dependent CSR, add a Script Editor web part.
  4. In the Editor web part, add the following line – or similar based on where your file is located. This worked for me by having the file in my Scripts library:
    <script language=”javascript” type=”text/javascript” src=”../Scripts/jquery-2.1.3.min.js”></script>”

Note: Take a peek at Marc’s post on jQuery to make sure your file is working properly.

CSR that uses the jQuery library should now function properly.

SharePoint Fest DC – PWR104 – Customizing SharePoint 2013 Sites and Pages

The following is a link to the slides from today’s session on (mostly) CSR and JSLink within SharePoint 2013.

Much of the CSR / JSLink content and instruction can also be found in the blog post found here:
http://www.idubbs.com/blog/2012/js-link-for-sharepoint-2013-web-partsa-quick-functional-primer/

Other recent posts worth checking out: