Introducing SPELL, a framework to speed up SharePoint customizations

Spell (paranormal), the claimed art of altering things either by supernatural means or through knowledge of occult natural laws unknown to science.

(Source: Wikipedia)

For 8 years, I have been writing solutions for SharePoint from the user’s side – I mean with only the SharePoint UI or tools like SharePoint Designer (originally FrontPage) as entry points, without direct access to the server.

When I started, in 2004, these were mainly patches to enhance the SharePoint interface, like menus or tabs. Then in the following years, the evolution of JavaScript and AJAX, and key enhancements in SharePoint 2007, like workflows, allowed me to build more and more sophisticated solutions, evolving from enhanced Web pages to the status of small applications.

In 2008, I started publishing some solutions on my blog. Others did the same, and today SharePoint users can find online a large choice of tools that allow them to quickly enhance a basic SharePoint team site.

However, this organic growth comes at a price. When users start relying heavily on these solutions, their pages become cluttered. Sites become much slower because of redundancies. Maintenance quickly becomes an issue, especially when these users start adding libraries like jQuery. Sometimes, there will be conflicts between the tools, because they were not built with modularity and scalability in mind.

I have been witnessing these issues in the past couple years, and also facing them myself, as I was duplicating the same snippets over and over across different modules. To address this, some time ago I started grouping all my scattered solutions under a single umbrella, called SPELL.

What can SPELL do?

The goal is to offer a consistent, easy-to-maintain-and-upgrade package that covers all the customizations that can be done from the user’s side: client side scripting, CSS, XSL views, SharePoint Designer workflows, calculated columns, etc.

For now, SPELL is mainly a JavaScript library (abbreviated $P) that allows to:

  • enhance the look of SharePoint pages, with tabs, slideshows, menus, etc.
  • build dashboards, including color coded indicators and charts
  • enhance the out of the box forms (New, Display, Edit)
  • connect with plugins offered by JavaScript libraries (jQuery or other) for additional functionalities
  • etc.

The free SharePoint User Toolkit gives you an idea of the kind of questions SPELL can address, although on a completely different scale.

SPELL includes utilities such as for example:

  • functions to facilitate the use of Web services, REST services, RSS, owssvr, etc.
  • functions to interact with the content of SharePoint pages
  • data format manipulations (xml, JSON, datatables)
  • a templating engine

Who could be interested in SPELL?

SPELL is for anybody who need to customize SharePoint, beyond out of the box list views and page layouts. It works with SharePoint 2007, SharePoint 2010 or SharePoint Online (Office 365), An important difference with traditional libraries is that SPELL is meant to be end user friendly, in the same spirit as the SharePoint User Toolkit. The idea is to offer a Lego-like set, so that even users with limited technical knowledge can safely assemble solutions.

Despite an ambitious scope, SPELL doesn’t aim at replacing server side solutions on large scale deployments. Its purpose is rather to fill the gaps, at the team level, or serve as an intermediary step while waiting for final solutions that have longer development cycles.

Timeline and availability

I have been working on this project, on and off, since 2010. The main component of the framework, the JavaScript library, just reached version 0.3, and is the first version to be put in production. In the weeks and months to come, it’ll be deployed for my current users, going from DJ30 companies to small businesses (and even one man shops). I also plan to build a special edition with tabs, slideshow and charting connectors as part of a hosting service. Later on, SPELL will be the core of a SharePoint coaching program that will start this Fall. The objective is to reach version 1.0 by October.

An important step this year will be to assess SPELL against the new version of SharePoint, and confirm if the upgrade process is as easy as advertised…

For more details…

I am currently building an interest list for the SPELL coaching program. Feel free to send me an e-mail, and I’ll include you in a distribution list to receive progress updates and code samples. You’re also welcome to provide specific information about your environment and your needs, to discuss how SPELL could help on your projects.

Bridging the gap between the users and IT

User Managed Solutions LogoHappy New Year 2012!

I discovered SharePoint 8 years ago, and I was immediately fascinated by the opportunities it offered. Being a functional consultant, I have always been on the user side, in “hosted” environments, where traditionally you have limited options to tweak applications. SharePoint was a game changer. The CEWP (Content Editor Web Part) and the DVWP (Data View Web Part) quickly became my best digital friends. It is at that time that I started using JavaScript, building my first user solutions like tabbed interfaces and list driven menus.

In 2008, I started this blog to share some of the techniques I had created. Overnight, they became popular and were relayed by bloggers around the world, including Mark Miller, the SharePoint End User Authority.

Then came 2010, and the release of a new SharePoint version, with a major innovation: sandboxed solutions. People now had a solid way to push packaged solutions from the SharePoint user interface.

My initial though was that it was the beginning of the end for the CEWP. Well, obviously I had missed the point. Sure, people liked what my solutions accomplished, easily adding tabs to a page or color coding to a calendar. But what they liked even more was the hands-on experience. With a CEWP and code accessible in a document library, the user was in control. Even better, because my solutions were closely tied to out of the box features, they helped the user understand SharePoint itself – page layouts, calculated columns, or workflows. It was not just about using, it was also about building and learning. The solutions didn’t just improve the site. They helped the user improve his/her own skills.

So here I start 2012, with my solutions still very much alive, and so popular that I plan to expand them, and adopt a more sustainable and professional approach. There are in particular two directions I want to explore.

With SharePoint pros, I plan to adopt a more structured approach, providing them with both a methodology and modules to embed in their own solutions, in the spirit of a Lego set. I see this as a highly interactive process, where the modules I’ll push will be based on the needs and feedback I collect. Flexibility is key here.

With end users, I believe that a little guidance can go a long way. Of course it might be hard to picture users digging into client side code today… well, just like 20 years ago it was hard to imagine users editing Web pages or building automated workflows. One step at a time. For example this year I’ll push in my samples more JSON, a JavaScript notation that is considered almost humane. Could the user and the computer share the same interpretation of {flag:”red”} ? This is definitely something I’ll experiment with this year!

How does this look from the IT side? Honestly, I didn’t even ask, as I am certain IT pros are not too excited about these user driven initiatives. And to be fair I can understand why. I am not the only one to have witnessed the flood of undocumented Excel macros in corporate environments, isn’t history just repeating itself? So here is another important point: these user solutions have to be managed. Only by maintaining a clean and sustainable environment the users will gain long term benefits, and gain the trust of IT. Here too I plan to provide guidance, for example by introducing risk management to help the user understand the implications of his/her customizations.

Prediction is very difficult, especially about the future (*). I am starting 2012 with ambitious objectives, we’ll see where we stand in a couple months!

(*) Niels Bohr, Physicist

Easy Tabs and accessibility

Adaptive Web Design is my topic of the day, with my RSS reader bringing me two articles on this theme: Responsive Layouts Using CSS Media Queries, by Kyle Schaeffer, and Now You See Me by Aaron Gustafson.

I am sure the Easy Tabs have a role to play in responsive layout, but today I’ll focus on the second article.

In this excerpt from his book, Aaron compares various methods to show and hide content – a standard pattern nowadays with tabbed interfaces, accordions and other widgets.

This gives me an opportunity to point out one of the changes I made to the Easy Tabs last year. In version 5, the show/hide behavior is now included in a stylesheet, in a class called “et-offscreen”. And the method I use is the one recommended by Aaron Gustafson: instead of changing the display to “none”, move the content off-screen. This way, users don’t see it anymore, but assistive technologies can still access it.

As we’re talking Web design, I should also mention that the Easy Tabs follow the progressive enhancement approach.

If you are not familiar with CSS, this post may just be as clear as mud. But the bottom line is that by adhering to the principles of accessibility and progressive enhancement, the Easy Tabs v5 are currently a solid solution to build tabbed interfaces.

Client side scripts: packaged Web Part vs. Content Editor Web Part

A couple days ago, there was an awkward moment while I was working on a new project.

I was on a video conference with a customer who already had a SharePoint site set up – actually a whole application including CRM, project management, etc. And he was happy to show me that my Easy Tabs were part of his solution, and had been installed by his developer.

Naturally, I was interested to see if the script was implemented correctly, so I asked him to edit the Web Part. Surprise! Instead of an out of the box Content Editor Web Part (or Form Web Part, or PVWP, etc.), I discovered a custom Web Part, with no option whatsoever to edit or link to an external script.

The customer was not able to tell me what the developer had done, but apparently the guy had embedded the script in a custom Web Part. This is a standard practice, and you can for example see it explained in this recent post from the SharePoint Developer Team Blog  (one of my favorite SharePoint blogs of the moment btw). But for me, it was the first time to actually see it, and done to my very own script…

A glass of cognac and a couple nights of rest later, it is time for me to try and understand the respective benefits of the two techniques.

This is actually a topic I discussed six months ago with SharePoint MVP Sean Wallbridge (the discussion was already around the Easy Tabs). I submitted to him this idea of wrapping my Easy Tabs in a Web Part. At that time his advice was that I should not bother to do that, and that the CEWP approach was more convenient.

I’d be interested in hearing from others who have applied the technique described in the SharePoint Developer Team blog, to try and understand possible benefits. At this point, I don’t see any, but maybe I am missing some specific use cases. One interest of packaging the script is that if you update it on the server side the changes will apply to all the Web Parts. But AFAIK you can have the exact same effect by linking a CEWP to a central script.

Developer approach vs. User Managed Solution, what’s your take on this?

Don’t take my solutions at face value!

Last week, I stumbled upon this comment on Twitter:

“I have used and love easy tabs, but I do need pretty on my current engagement”

What? Not pretty, my Easy Tabs? Let me set the record straight.

First, let’s make sure we are on the same page. The current version of the Easy Tabs is v5, compatible with both SharePoint 2007 and SharePoint 2010. You can build your own here:
http://sp2010.pathtosharepoint.com/SharePoint-User-Toolkit/Pages/Easy-Tabs-v5.aspx

By default, the form offers two styles: one taken from SP 2007, and the other taken from SP 2010. Note that both options work on both SharePoint versions (for example, you can pick the SP 2007 style for your SP 2010 site).

You don’t like the colors? Well, talk to Microsoft! I did not invent the styles, I am reusing the default ones you get when you create a team site. The significant advantage here is that you don’t have any external dependency, just add the Web Part to a page and it ‘ll work.

If you want other colors, feel free to pick your own. Click on the “Modify colors” option, and you’ll be presented with a color picker, allowing you to choose your own background and font colors.

Not satisfied yet? Well, you can take it one step further. Look at the Easy Tabs code, and you’ll see that it is made of two independent parts: the stylesheet (style tag) and the tab builder (script tag). Modify the stylesheet as you please to get the final look. As an example, I have built this demo that has it all (rounded corners, hover effects, gradient):
http://sp2010.pathtosharepoint.com/Portfolio/Pages/Styled-Easy-Tabs.aspx

The purpose of the SharePoint User Toolkit is to open the door to advanced designs. Don’t see these tools as final products, but rather as a startpoint to build your own solutions. The beauty of such “User Managed Solutions” is that you have full control on them, and can tweak them to fit your specific needs. I took the Easy Tabs as example, but I could have chosen the image rotator, or other solutions from the toolkit.

If you are interested, I’ll start offering in a couple weeks a new series of online workshops, where I’ll show how to make the most of these tools. Feel free to contact me now if you have specific needs.

If you are a Web designer, or a SharePoint pro, looking for solutions for your customers, I have many other tools in my drawers. Come talk to me about your requirements, and let’s start a collaboration! We can also discuss this on LinkedIn, in the SharePoint User Managed Solutions group. And if you are in San Diego, or the Bay Area, I’ll be there in a couple weeks and we can meet in person.

About Scripts, Web Parts and Urban Myths

Today, I came across conversations, initiated by Marc Anderson (@sympmarc on Twitter), about the Content Editor Web Part.

Reported by Marc on his blog:

One of the things I heard at SPTechCon several times was that in SharePoint 2010, it is no longer possible to put script into Content Editor Web Parts (CEWPs). Instead, I was told, you have to use the new HTML Form Web Part.

And on twitter:

sympmarc Just verified that you *can* put script in a #CEWP in #SP2010, contrary to what several people said at #SPTechCon . Urban myths can kill…

EUSP RT @sympmarc: Just verified that you *can* put script in a #CEWP in #SP2010 <- Problems with <form> tags in CEWP 2010.

sympmarc @eusp: Problems with <form> tags in CEWP 2010. -> Different issue. Some HTML tags may not work, but it looks like script does.

sympmarc @eusp Remember that basically the whole page is a form already. That may be the issue rather than SP2010.

 

Let me try and clarify how this works.

The Content Editor Web Part

It was August 2008, I had just started my blog, and I was already writing about the CEWP. At that time, I did not even mention the ability to link to external content. I only talked about this several months later, when I started promoting an architecture where scripts are stored in a central library.

In SharePoint 2007, the most advertised way to add scripts to a SharePoint page is via the “Source Editor” option of the CEWP. So no wonder people are lost when they start using SP 2010: no “Source Editor” button anymore!

It doesn’t mean that the feature has been removed though. As with many others, the option – renamed “Edit HTML source” – is now located in the ribbon, and becomes visible when you click on the content section of the CEWP (in edit mode), or select the “Edit Web Part” option:

In addition, SharePoint tries to help: it will screen the code you enter, and you’ll receive this notification:
“the HTML source you entered might have been modified”

The cool part is that SharePoint will never tell you whether anything was modified, you’re on your own to figure it out. Feel free to take a look at some examples I collected when I posted the question on SharePoint Overflow two months ago.

Another issue with the CEWP is that you cannot include form elements. This is not new to 2010, it has always been the case even with previous versions. As Marc explains in the above tweet, the reason is that the whole page is already a form. So here comes…

The HTML Form Web Part

Yes, you can use the HTML Form Web Part to include scripts in a page. Yes, it will also accept form tags, it’s its primary purpose. Yes, it has this “Source Editor” button everybody is looking for. And no, it is not a new Web Part, it was already present in SP 2007. It is actually one of the building blocks of my SharePoint User Toolkit, in both SP 2007 and SP 2010.

So why is everybody promoting the CEWP, if the HTML Form Web Part offers more?

For one, it seems that few people actually know about the capabilities of this Web Part (it is better known for its role in Web Part connections). But another reason is that it doesn’t have the “Content Link” option that I recommend as a good practice.

Other Web Parts

Can’t use the CEWP or the Form Web Part on your site? There are still other Web Parts available (not to mention the option to add scripts outside Web Parts). Although they are not as convenient as the CEWP and the HTML Form Web Part, they can help in specific cases.

For example, back in SP 2003, forms (new, display, edit) were not as easy to edit as today. I used to rely on a Page Viewer Web Part, which allowed me to modify scripts without editing the form page itself. Come talk to me if you need more details!

Easy Tabs: Even Better with Print Friendly!

Author: Kerri Abraham, Revenue Cycle Sharepoint Coordinator, Mercy Medical Center.

Several months back I was tasked with a training build for our highest turnover position.   The main function of the job was a 7 screen registration process, and because of government regulation and business requirements, every field on these 7 screens needed thorough instructions.  The information I was to work from was half a paper ream thick as hard copy!  First step was a severe edit of the information and then solid structuring to make it useable to staff.  My thoughts went right to the Easy Tabs!

I started with organizing according to the 7 screen requirements, and soon realized that wouldn’t be enough, staff might still be overwhelmed with content.  Taking advantage of the natural breaks in the process it broke out a bit further, until finally that half ream of hard copy was just 17 wiki pages of instructions.  Using the Blog to Wiki publishing technique, I utilized a color coding strategy to keep the look consistent across all the pages and links at the bottom of each page moved staff through the steps.  Initially the trainer can walk new hires through the process using these handy links, but shuffling through the links to find the spot they are caught on (while the customer stands waiting) is unrealistic.  That problem was resolved with the Easy Tabs

By modifying the view of the wiki content and filtering it on ID, then adding them one after the other on the page, changing each of the web part’s titles to reflect the contents, and then implementing Christophe’s Easy Tab solution I was able to get all 17 pages of information neatly tucked up under each other on the page.  Keep in mind that the native content of the wiki does not roll up under the tabs, that gives the display as below.

This worked out perfectly, staff could keep this page up as they worked, if they were stuck on a step in the process, they could click the tab and immediately find their information.   When I sent a picture of my use of Easy Tabs to Christophe, he suggested that I add the Expand All tab, but call it ‘Printer Friendly’, as a way to appeal to  the trainer’s needs who was really impressed with the wiki, but still  attached to hard copy.  Up to this point she was printing each page separately because without page breaks the information was confusing the way it ran together.  Easy Tabs v5 completely solves that issue with ‘Printer Friendly’ plus page breaks.  Now this documentation prints just like a procedure manual.  The trainer is thrilled with the results!

I can offer a few tips for creating this kind of procedure manual with the wiki:  use the Advanced Web Parts gallery to quickly add multiple web parts.

The default display under native wiki content is ‘no Title’, so ‘Appearance’ on each addition will need to be adjusted to display as tab.  Note the only columns checked to display are Wiki Content and Edit.  Filter wiki content on ID.   Consider adding the column of ID to the Wiki Pages/All Pages view of the library to make it easier to identify ID.  The rest is simply a matter of perseverance in repeating the steps and setting the toolbar displays to none for a nice clean look.

I have a feeling this is only the beginning…  A comment Dux Raymond Sy recently made in a video recording about “printing a project plan” got me thinking.  I am a fan of Dux, so I’ve been using Sharepoint for project management for quite some time, but “printing a project plan” suddenly struck a new cord!  So I went to work rebuilding my project site template to include Christophe’s Easy Tabs, and while I was at it, I incorporated some color coding into the task list as well.  I restructured all the lists and libraries on a Web Part page.  In addition to the standard lists, again I utilize a wiki library, exposing just the content field, which is part of the site template and includes several project related forms that provide the project managers with an easy to edit alternative to Word documents (and now even more printer friendly under the tabs.)  The results were dramatic especially since I used the new color options with Easy Tabs v5!  

Now the project managers can quickly print off just the Web Parts they need, or the entire project documentation with just a few clicks.  Maybe regular hard copy reports are needed to communicate at Shareholder meetings?  Create a web part page just for report out, adding the desired web parts with list views and dashboards that can be tucked under Easy Tabs and printed in a moment’s notice.

I have number of other ideas in the works for these tabs as well, meeting minutes and agendas with easy printability, printable lists displayed in “Preview Pane” style, a telephone directory based off a contact list built with Easy Tabs v5, why, I’m just getting warmed up!

I think the new options make an already great solution into an awesome feature. What do you think? Someone recently told me “Printing web parts kind of goes against the purpose of electronic data capture doesn’t it?” Help me prove them wrong. There are countless uses for print friendly! I’ve listed out my ideas, now it is your turn, how are you using the Easy Tabs?