One question I get frequently is how to build real world forms with SharePoint. This involves in particular organizing the fields in logical blocks (e.g. Street/City/Zip Code/State) and tweaking the layout to have multiple columns or interactive zones (e.g. tabs).

Until last year, InfoPath was the official go-to application for form design. You can still use it today, however in January 2014 Microsoft announced that InfoPath was retired. Some InfoPath fans will tell you that with Microsoft’s deprecation policy you are still safe for 10 years… What they don’t mention is that this is only true if you decide never to upgrade to new SharePoint versions!

Considering the lack of visibility on the future of SharePoint forms, I have decided to explore what could be done with my SPELL library.

SPELL already includes several building blocks to help with forms, in SP 2007, SP 2010, SP 2013 and Office 365. It can parse a default SharePoint form page, identify field types (e.g. text, drop-down choice, multi-lookup), and add behaviors like cascading selects or pre-populated fields. Also, I already have a solution for form layouts, however just limited to tabs. The new solution will expand it, to allow for more custom layouts.

To accommodate the new features, SPELL is going to evolve:

• the existing Form module will be renamed Form Behaviors: cascading selects, item ID, pre-populated fields, read only fields, color coding, etc.
• the new module will be called Form Layout and will include Form Tabs.

To get started, I have built a proof of concept. Feel free to play with it, and let me know what you think! Eventually the plan is to release a gratis and a commercial version, just like I already did with Tabs and Cascading Selects.

A quick walk through:

1. Move the logo to confirm that your browser supports drag and drop
   
2. In the Form Editor, select the target form, the layout and the name of each zone. Then press “Retrieve Form and Render Layout”.
   
3. Drag and drop the fields to add them to the custom form layout. Double click on a field name to switch to a stacked display (example: Task Name in the screenshot below).
   

What if my browser doesn’t support drag and drop?

The proof of concept is not going to work. You’ll need to switch to a browser that supports the HTML5 standard (yes, HTML5 officially became a standard…today!), or add the feature via a polyfill.

Note that:

• a fix for older browsers will be included in the final solution
• only the designer – not the regular end user – needs the drag and drop feature.

Tentative release schedule:

• End of 2014: alpha version, available to existing SPELL users.
• Early 2015: the SPELL Form Layout will be offered for on premises environments (SP 2007, SP 2010, SP 2013).
• For new SPELL users on Office 365, I plan to make the solution available in the second half of 2015.

I am starting 2014 with a new channel to distribute my SharePoint solutions.

Since 2011, I have been working on my SPELL program to address some shortcomings of the solutions published in the SharePoint User Toolkit. I made a number of choices that shaped the future of SPELL:

• A single framework with interconnected modules, rather than independent code snippets.
• Dual presentation, inline code for developers vs. “no code” for end users (encouraging the use of the Page Viewer Web Part, more solid and reliable across SharePoint versions than other content/script Web Parts).
• Move away from the free model, to adopt a freemium approach with gratis (no cost) and full version.

Because the setup forms are now included in SPELL, the delivery method has switched from an online configuration tool to more standard file downloads. The natural move for me was to make the files available in a public SharePoint library, but several users got stuck because of the counterintuitive behavior. As an anonymous user, you have to use a right click, not a regular click, to access a file. The file extension might also change in the download process (for example from .aspx to .htm).

As a quick workaround, I started sending files by e-mail (!). Of course I got bitten by corporate filters that blocked e-mails because they contained code, or just delivered the e-mail without the attachment…

So I finally decided to use myself the solution I had been promoting among my SharePoint customers in the past 12 months. Ever since the new version of Office 365 came out, I have been praising its fantastic ability to go across company barriers and allow extended enterprise collaboration. I just worked on such a project last week! Office 365 ‘s sharing options make it an easy and cost effective solution. For some of my customers, this is actually the number 1 reason for migrating to Office 365.

If you are interested in the gratis version of the SPELL Tabs 1.1, go ahead and fill out the contact form with your company information (granted, at this point contact forms are not Office 365’s most powerful or user friendly feature). SharePoint will store this information in a list (restricted access), and notify me. I’ll then send you a “shared link” to access the package.

Distributing files is just the first step. I expect to move further later this year, and open other areas of the site to my customers and partners, for example for online support, discussions, or to vote on enhancement requests.

If you’d like to experiment with Office 365 ‘s external sharing abilities yourself,  you are welcome to contact me for a free 30 day trial. Even if your company is already using SharePoint internally, you might be interested in a separate instance of Office 365 for projects that involve external partners!

This week I sent out issue 8 of the SPELL Newsletter. The topic of the month is cascading selects.

The SPELL Newsletter now has 450 subscribers. Unfortunately, for some reason a dozen addresses are returning me a “delivery failed” message. If you have requested to receive the newsletter but didn’t get any message this week, please get in touch with me to confirm your e-mail address. In the meantime, I am attaching the documentation to this post (see link below).

SPELL is a freemium program (free entry level solutions, full solutions for a fee). Even if you are not willing to pay for SPELL, I think the document is a good read as it explains in detail the purpose of cascading selects, and how they are related to lookup columns. And for the sake of transparency it also lists some alternate tools that will help you achieve the same result (see “What are my other options” at the end of the document).

SPELL Cascading Selects 1 1 0 – Evaluation Version

Three years ago, I published a post to clarify how scripts (and Web content in general) could be added to a page via a Web Part. It was SP 2010 at that time, and the main contenders were the Content Editor Web Part (CEWP) and the HTML Form Web Part.

I concluded the post with a small note about the Page Viewer Web Part (PVWP). It’s about time I explain what I meant…

Note: this article focuses on Web Parts. There are of course other ways to include html, stylesheets or scripts in a SharePoint page!

What is a Page Viewer Web Part?

A PVWP allows you to embed in your page another Web Page. Technically, a PVWP doesn’t do much, it is just a wrapper for a html iframe element.

iframes have a bad reputation. One of the main reason is that people often confuse them with frames. An excerpt from the MDN page:

Using the <frame> element is not encouraged because of certain disadvantages such as performance problems and lack of accessibility for users with screen readers. Instead of the <frame> element, <iframe> may be preferred.

As a matter of fact, iframes are enjoying a surge in popularity in modern Web design. They serve as building blocks in modular pages (several SharePoint Web Parts rely on iframes), and are a key component of application pages (for example on Twitter, Facebook or with Disqus). I would expect them to become even more popular once the new iframe html5 attributes become widely available.

Note: besides linking to Web pages, the PVWP also has options to display folders or file content.

How is this similar to the CEWP?

As explained in my old post, a CEWP allows you to embed, via its content link property, Web content (html, stylesheets or scripts) in your page. A PVWP acts in a similar way, except that the linked file is a whole Web page, instead of a fragment stored in a text file.

But this means two different pages?

Right. With a CEWP, the code fragment becomes part of the host page. With a PVWP, the code remains in its own page. That said, it doesn’t mean that the two pages cannot communicate, within the boundaries allowed by the same origin policy. In particular, an iframe can access and modify its host page. In the basic example shown below, the code in the iframe accesses the parent body to change its background color.

Any real life example to share?

Sure! In the past few months, I published in this blog several demos from my SPELL library. SPELL is built to work in dual mode: either “inline” for direct insertion within a page (CEWP, Master Page, etc.), or “app” for inclusion in an iframe. For example, the process navigation showcased in this blog post is inserted via a PVWP. Same for its sibling featuring a button navigation. Other solutions like the SPELL Tabs or mini-BI work exactly the same way.

Why use a PVWP rather than a CEWP?

That’s a good question. While other environments have a good case for iframed scripts, we SharePoint users can already rely on the CEWP to link to html, css and JavaScript. Still, I see a couple benefits when using a PVWP.

1/ Sandbox

Because the iframe loads another page, this provides a clear separation between the host page and the iframe content. The sandboxed environment avoids code conflicts. This can be for example useful:

• for charting apps, to make sure that the styles of the main page don’t interfere with the styles of the chart itself.
• for scripting: if your app requires a specific jQuery version, you can run it within the iframe, without having to worry about the main page running a different version.

2/ Standalone

One constraint with Web Parts is that they have to live in a page. Picture a SharePoint dashboard: you view it as a whole, with no easy option to isolate a specific chart. With a PVWP, the chart can be viewed either embedded in the dashboard or directly in its underlying page. This scenario is showcased in this post: with read only permissions on my site, you cannot build a SharePoint dashboard page, but you can still interact with the individual chart page.

Even better, standalone pages work great with SharePoint dialogs. Iframing is actually the technique SharePoint relies on with forms: when you open a new, display or edit form in a dialog, you are simply opening newform.aspx, dispform.aspx or editform.aspx in an iframe! Do I have a dialog example with SPELL? Thanks for asking 🙂 You’ll find it here. Working with standalone pages allows to pile up dialogs and create the drill-down effect.

3/ Asynchronous load

Because the host page and the iframe are two different pages, the browser can load them in parallel, so this “should” result in better performance. With a CEWP, the content becomes part of the host page and execution will follow the page flow.

4/ Links across site collections

The CEWP allows you to link to an external file, but only within a same site collection. An iframe doesn’t have such restrictions, so a single application page stored in SharePoint can be reused across site collections.

5/ Storage of parameters

This is a technique I use with the SPELL library – not really standard but let me explain it anyway.

Because the script running in the iframe can access its own url, this url becomes a place where you can store parameters. For example the URL for the SPELL Tabs will look like this:

Tabs.aspx#css.activeBackground=orange;css.inactiveBackground=blue;css.hoverBackground=lightblue

For cascading dropdowns, the url would be for example:

CascadingSelect.aspx#form.parentLabel=State;form.childLabel=City;source.listName=Locations;source.parentField.DisplayName=State

You might find the above urls intimidating, but if you look at SharePoint urls they actually work in a similar fashion. The point is: if you used a CEWP, you’d need to store one snippet of code for each cascading dropdown you implement. With the above method, one single page called CascadingSelect.aspx can be reused across all site collections!

Note:  In practice the SPELL library includes editors, the above paths are not built manually.

Of course, iframes also have some drawbacks. The asynchronous load complicates the relationship between the iframed content and the parent’s content. The sandbox means that if the same code is needed in both the host page and the iframe, locally you have to load it twice (or find a trick…). Both the CEWP and the PVWP have their place in SharePoint design!