My slides from the March 2011 San Diego SharePoint User Group meeting

No, there’s no typo in the title, I am posting today the slides I presented 18 months ago in San Diego. My main purpose is to use them as reference in future articles, as it turns out that their content is very consistent with what I’ve been doing since then, and also with the way SharePoint has been evolving from the 2007 version to the 2013 version.

The slides feature in particular the Matrix View, a simplified form of pivot table. I’ll talk about it in future posts, but you can already visit this page for a live demo (click on a state).

Some of the other tools can be downloaded from the SharePoint User Toolkit.

For some reason the embedded slides below are distorted. They are better rendered in the original location on Slideshare.

Security concerns with the HTML Calculated Column

The HTML Calculated Column is certainly my most popular technique. It is mainly used to color code calendars, but its scope is much larger than that. The technique is especially useful when you… actually do calculations, for example in these progress bars with color gradients. You can see some other examples in this live demo, and in many other live demos and posts in this blog. Any html tag could be added using this technique.

For the record, the original post is outdated (and so are the hundreds of articles that copied it). You’ll need to read the more recent ones for updates on SP 2007 and SP 2010.

Did I just say any html tag? mmm… so how about script tags? Does it mean that a user could push a malicious script to your computer? Well, the short answer is yes. This is something I have already discussed in the past, in private or in forums, but I never posted a detailed explanation on this blog – until today.

The question was actually raised in a recent project I worked on. I accidentally stumbled upon an experiment that the IT team ran behind my back (well, to be fair, maybe they just didn’t know I was the author of the code). Let me tell you the story.

For the sake of simplicity, I’ll use these short snippets instead of the actual code:

  • our malicious script: alert(“Boo!”)
    The script simply opens a pop-up that says Boo!, be prepared to be scared…
  • our calculated column: =”<div style=’font-weight:bold;’>”&Title&”</div>”
    This will render the Title in bold. It is actually the example used in the original post from September 2008.

For example if Title is Chandler, the value of the calculated column will be
“<div style=’font-weight:bold;’>Chandler</div>”
and the page will render it as Chandler.

Now, here is what the IT team tested: in the Title column, they entered:
<script>alert(“Boo!”);</script>

In this case, the calculated column returns:
“<div style=’font-weight:bold;’><script>alert(“Boo!”);</script></div>”

What happens when you use my technique? You might expect to get a “Boo!” alert, but in practice… nothing! The code simply doesn’t execute. This is due to the technique I use in the HTML Calculated Column: script tags are added (just like other tags), but do not run.

I guess IT was satisfied with the test, as they agreed to leave my code on the page.

What they overlooked is that there are actually other ways than script tags to add code to the page. Imagine for example that you enter the following string in the Title field:
<img src=”/_layouts/images/blank.gif” onload=”alert(‘Boo!’)” />

This time, when you use my technique the above code loads the image (blank.gif), and once it’s loaded it triggers the code in the onload event. Wicked!

As I said, there’s nothing new here. I even have a blog post from 2009 that explains it:
http://blog.pathtosharepoint.com/2009/02/26/using-calculated-columns-to-write-scripts/

So is there really a security risk here? In theory, yes. In practice, only people who have contributor access will be able to inject code, so in collaborative environments the risk should be very low. Also, you’ll be very limited in the amount of code you can put (a text column like Title only accepts up to 255 characters). However, I would advise against using the HTML Calculated Column in open environments, for example if anonymous users have write access or if your list is mail enabled (and by the way in such cases you’ll have other concerns, not just with the HTML Calculated Column).

In the next few weeks, I’ll publish two techniques that avoid the security risk described in this post.

A dynamic website built on Office 365

I mentioned it on twitter a couple weeks ago, Bradshaw & Weil has launched its new public website based on Office 365: http://www.bradshawweil.com

In an article last year, I expressed my frustration with the current Office 365 public sites, for which building dynamic pages requires more effort than it should. Well, it doesn’t mean that it cannot be done, and Bradshaw & Weil is one of these sites that take advantage of both the traditional list management capabilities of SharePoint and the features specific to Office 365.

The site content is managed by the site admins in SharePoint lists. For example, when you open Topics.aspx?Menu=For%20Individuals SharePoint will filter the Topics list to only display the topics tagged “For Individuals”. Topics.aspx?Menu=For%20Individuals&Topic=Motorcycle%20Insurance will only display the information related to motorcycle insurance, and will pull from the Insurance Carriers library only the logos of the carriers that offer this specific service. Thanks to the dynamic behavior and the use of querystrings in the URL (“Menu” and “Topic”), a single page handles all the topics, where with a static site 20 pages would be needed. And if a new topic gets added to the Topics library, this will automatically create a new entry in the menu.

Besides content management, the site gets all the benefits from working with Office 365. The business users have a convenient interface, the Site Design tool, to customize the header, footer and layout of the pages, without having to call a SharePoint consultant for every minor change. And the gadgets allow them to include convenient features like contact forms that would be hard to implement on a regular SharePoint site.

The site also gets help from jQuery. Note in particular:

All these plugins pull content from SharePoint lists and libraries (menu items, images, logos, phone numbers, website links). Here again, no need to call the designer every time a logo gets added or a phone number changes!

For this project, I worked directly with Jared Morgan, vice president. This was a great experience, as the company has been using SharePoint for several years, and Jared knew exactly what to aim for.

As you explore the site, feel free to post your comments or questions below, and Jared and I will be happy to post additional details.

And if your company is interested in a test drive of Office 365, drop me a line and I’ll be happy to send you an invitation for a free trial.

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.

Pie and Bar Charts (Google connector)

Pie

I already mentioned it briefly in an earlier post: the SharePoint User Toolkit now includes a tool that allows you to add simple pie or bar charts to your SharePoint pages.

The code is actually a connector that points to the powerful Google Visualization interface. For this reason, Internet access is required.

A common concern with online tools is data security. In this case, we are safe, Google’s privacy policy explicitly states that no data is sent to the server. The charts are directly rendered in your browser. This is a major difference with the Google Image Chart API, where data is sent in clear to the server, which uses it to build and return an image.

Under the hood, the code works the same way as the Image Rotator: it retrieves data from a specific view of your SharePoint list.

No Easy Tabs v6 in 2012

This is not the most exciting post ever, but I had to write it for the sake of transparency.

In the past 6 months, I have been working on a new version of the Easy Tabs. I have also tried my best to answer the many requests I received in this blog or by e-mail.

In parallel, I have been working on the SharePoint User Toolkit, to clarify its purpose.

My conclusion is that the new version of the Tabs is becoming too complicated for the Toolkit.

I am not keeping the new version of the Tabs secret. It has actually been running on my site in the past few months, under various forms. I also shared an alpha version on LinkedIn some time ago. But the new features introduce several edge cases that I cannot afford to support for free, and that I believe cannot be left in the hands of users without detailed instructions.

Instead of publishing more complicated versions, my choice this year is to expand the scope of the Toolkit to provide more discovery options. This is the sense of the recent addition, Pie and Bar charts (Google connector). Expect a couple more in the coming months, like a RSS reader and a simple poll.

At the same time, I hope to open my services to a larger audience. I am currently working on a subscription service, an ambitious project that should offer better value than the current workshops and one-on-one sessions.

There will be a next version of the Easy Tabs, just not this year. The plan is now to release v6 for SharePoint vnext – just like v5 was released for SharePoint 2010. For now, the current version is robust and works well on both SP 2007 and SP 2010.

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

Follow

Get every new post delivered to your Inbox.

Join 261 other followers