Zoals bij ieder commercieel bedrijf is de website van Oxxio een belangrijk verlengstuk van de marketing campagnes. Tam Tam zorgt daarbij voor de vertaling online. De lancering van de nieuwe wintercampagne was een uitgelezen kans om het gehele aanmeldproces onder handen te nemen.


Tam Tam werkt al sinds een aantal jaren nauw samen met Oxxio en fungeert daarbij als vaste partner voor haar website. Wat het werken met Oxxio zo prettig maakt is dat zij openstaat voor nieuwe mogelijkheden en dat zij graag als early adopter wil fungeren voor innovatieve technologiën.

Dit komt onder meer tot uitdrukking in de vergaande integratie van Google Analytics die Oxxio op haar website heeft doorgevoerd. Vooral de campagne pagina's worden op alle mogelijke manieren doorgemeten. Waar klikken mensen op, wat zien zij als waardevolle secties, waar lopen bezoekers tegen problemen aan? Maar nog belangrijker: hoeveel bezoekers gaan daadwerkelijk een interactie met Oxxio aan?

Naar aanleiding van de wintercampagne werd Tam Tam betrokken bij de doorontwikkeling van deze campagne pagina's. Op basis van de eerder verzamelde statistieken is er een vertaling gemaakt van de zwakke en sterke punten. De pakkettest speelde op de oude website een belangrijke rol en was de belangrijkste landingspagina in het gehele aanmeldproces.

Op basis van het MBTI model (dat bezoekers indeelt in vier verschillende typen) hebben we gekeken naar de pagina's. Kan ieder van deze vier typen vinden wat hij/zij zoekt op de website? En hoe kunnen we de pagina's verbeteren zodat elk type het beste wordt benaderd? Uit onze analyse bleek dat de oude pagina's vooral focusten op één type bezoeker. Op basis hiervan zijn we een redesign traject ingegaan, met de nieuwe campagne site als gevolg.

Sinds 17 januari staan de pagina's live en vanaf die datum zijn we ook weer druk bezig met het doormeten van de pagina's in Google Analytics. Zorgen de nieuwe pagina's voor een hogere conversie en meer klanttevredenheid? En wat moet er aangepast worden om deze pagina's nog verder te verbeteren? Een on-going, maar vooral erg leuk proces.

Ook dat is Tam Tam: samen meedenken met de klant en zorgen voor de beste oplossing. Met daarbij een duidelijke focus op het resultaat.

AJAX applications can have one pitfall: the browser can't handle the history state, so the usual features don't work (back, forward, refresh, etc.). To overcome this you need to explicitly add browser history support. With ASP.NET (since 3.5 SP1) it's pretty straightforward. To do that you have to enable history in the ScriptManager and make an event handler for navigation.

Let's take the example of a tabbed interface. Maybe you have an update panel and a navigational menu. Each time you click on a tab it loads the content using AJAX.

The first thing to do is set the EnableHistory property of your ScriptManager to true. As you can imagine this adds support to your application for adding browser history points.

Another property that I like to configure is EnableSecureHistoryState. This property encrypts the anchor string that will identify your application state. I usually set it to false, to have a nice human readable anchor in the browser instead of an ugly string (e.g. #&&tab=settings, which is actually readable and can be changed if you know the possible values).

Normally you would have a click event on your menu and, according to the tab that was clicked, different content would be loaded. You still do this, but now there is an extra step: you need to add a history point to the browser state.

          
            protected
            void menu_TabClick(string tab)
{     Navigate(tab); //
load the appropriate content from this tab     AddHistoryPoint(tab); //
save the current history state }
        

When adding a history state, you need to specify a key, a value (identifying the state of your application) and optionally a title (so you can have different titles depending on the state).

          
            protected
            void AddHistoryPoint(string tab)
{     ScriptManager manager = ScriptManager.GetCurrent(this.Page);
    if (manager
!=null)
    {         if (manager.IsInAsyncPostBack)
        {             string title ="Your
page title";             manager.AddHistoryPoint("tab",
tab, title);         }     }
}
        

Finally you need to create an event handler for the Navigate event of the ScriptManager. In this event you can read the state of your application (using the key of your designation) and then do the appropriate action.

          
            void manager_Navigate(object sender,
HistoryEventArgs e) {     string tab = e.State["tab"];
    Navigate(tab); //
load the appropriate content from this tab     this.updatePanel.Update();
}
        

As you can see it's not that much work, but increases the usability of your application substantially.

This error message can have different causes. I will talk about one of them, that I found reading the ASP.net forums (Bug : Setting ScriptPath). This is the type of error that can drive someone insane.

Background information

The ScriptManager control has a property called ScriptPath which lets you specify a path to the ASP.NET AJAX JavaScript files as well as other custom scripts.

Using this, the ASP.NET AJAX files will be loaded directly from the file system, in contrast to the default, where they are loaded through an HTTP handler.

This is not only useful for debugging, but may also be necessary in specific scenarios where the HTTP Handler might give you some problems.

With this in mind, Microsoft included the JavaScript files for ASP.NET AJAX so that you can copy them to your desired folder.

Depending on your setup, these files can be usually found at:

• C:\Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025\MicrosoftAjaxLibrary\System.Web.Extensions\1.0.61025.0\Globalization

You will find both debug and release (minified) versions for each JavaScript file.

The problem

It appears that using the release version of the MicrosoftAjaxTimer.js file can lead to trouble when also using a timer on a page.

In these cases, "h is not a constructor" JavaScript errors can appear and things start to fail.

The problem is in the MicrosoftAjaxTimer.js file where aparently the minification didn't go so well and a semicolon (;) was left out.

To fix this, open the file and search for the following string:

          Sys.UI._Timer.registerClass("Sys.UI._Timer",Sys.UI.Control)if(typeof(Sys)!=='undefined')Sys.Application.notifyScriptLoaded();


        

There should be a semicolon (;) before the "if". Just add it, save the file and be glad that someone else found this for you (not me, congratulate the original guy in the forums)!

Resources

• Bug : Setting ScriptPath
• Using the ScriptPath of the ASP.NET Ajax ScriptManager
• Tip/Trick: Using ScriptManager ScriptPath to load MicrosoftAjax.js from file system

Some developers are unaware that you can store custom properties in SPWeb objects. It's usually referred as the property bag and can be useful for storing configuration variables.

If you look at an SPWeb object you will notice a property called AllProperties. "Great", you say, but looking further down reveals another property: Properties. "Which one to use?", you ask. The answer is simple: both.

Properties is of type SPPropertyBag and was only left for backwards compatibility. AllProperties was implemented later as a replacement for Properties and is an Hashtable object. Properties only contains a subset of what is stored in AllProperties.

To avoid any inconsistencies, you should write an entry to both, as following:

          SPSecurity.RunWithElevatedPrivileges(delegate()
{     using (SPSite
site =new SPSite(SPContext.Current.Site.ID))
    {         using (SPWeb
web = site.OpenWeb(SPContext.Current.Web.ID))
        {             web.AllowUnsafeUpdates =true;
            web.Properties[key] = value;
            web.AllProperties[key] = value;
            web.Update();
            web.Properties.Update();
            web.AllowUnsafeUpdates =false;
        }     } });
        

What an ugly code for such a simple thing. Unfortunately, the RunWithElevatedPrivileges and the AllowUnsafeUpdates are necessary for this to work. For retrieving an entry you should use AllProperties.

You're better off creating an utility class to add, update, get and remove properties.

You will be restricted to strings, but obviously you can also parse booleans, integers or even serialize objects to JSON (for that you can use To and FromJson Extension Methods).

I haven't confirmed this myself, but it seems there haven't been made any changes in these properties in SharePoint 2010.

Resources

• SharePoint: The Wicked SPWeb.Properties PropertyBag
• The SPWeb PropertyBag
• How to: Write a value into the property bag

SharePoint search offers a lot of possibilities. In this article we'll discuss some of the shortcomings that you might come across when programmatically querying the SharePoint 2007 search service.

Welcome pages as "STS_Web"

The welcome page of a publishing site is the page a user first sees when visiting that sub site (usually default.aspx).

Here's the strange part: the SharePoint search service treats these results with the content class "STS_Web", differentiating them from the remaining pages.

What does this mean? It means, for example, that if you want to create a scope that includes all the pages of a site (e.g. by including only items with content class "STS_ListItem_850"), the welcome pages will not show up, unless you also include the content class "STS_Web".

Of course, that's not all. This comes with all sorts of shortcomings. Let's say you want to retrieve all results for the content type "Project". Now imagine, that you have several sub sites and some of those have a welcome page of the type "Project".

You'll just query the search service and say that you want all results of the content type "Project", right? Wrong. The thing is, because the welcome pages are treated differently, this simply won't work. As long as those pages are welcome pages they will be treated with content class "STS_Web", preventing you from filtering them by their managed properties, with no easy way around this.

Here's one solution that you can adopt: create a redirect page using the "RedirectPageLayout.aspx". Make this page redirect to the actual page that you want to be the homepage of the publishing site. Now set the welcome page to the redirect page.

The search service will now treat your redirect page as the welcome page (meaning with content class "STS_Web"), but all the other pages will be treated normally. Users won't notice the redirect, because it happens behind the scenes.

Beware that you might also want to adjust the navigation of your site to hide your actual homepage from the navigation.

Unable to get results for items with null values

By design, null values are not stored for an item's properties in the SharePoint database.

This means that if you use an "OR" condition for several properties, only items with values for all properties will be returned. For example, maybe you're trying to find all "Project" items which belong to a specific industry or have a specific status. If there are some projects which don't have a value for any one of those properties, your search will not return them.

Another implication of this situation, is that you cannot find items which have a property set to null. For example, you're trying to find all items that don't have a value for a given property - you can't. You can either retrieve all items and then manually remove those that don't have any value for the property you're searching for, or you can get all items that have some value.

Unfortunately, this is a serious limitation and I'm not aware of any workaround for this yet.

Retrieve an item's content type

There is a managed property named "ContentType" that you can use to filter the results by their content type. However, if you want to read their actual content type, you cannot use the same property.

That's because the managed property "ContentType" is mapped to two crawled properties: "Basic:5" and "ows_ContentType". Although it works for filtering (i.e. in the WHERE clause), if you try to read its value, the "ContentType" property will return the value of the "Basic:5" crawled property.

If you want to retrieve the content type for your results (e.g. for showing them in a filter), you will need to create a new managed property (e.g. "ItemContentType") and map it just to the crawled property "ows_ContentType".

HTML is stripped from properties (or why PublishingPageImage doesn't work in search)

Let's say you have news items on your site. As part of a news' content, you use the default "Page Image" field (internally named "PublishingPageImage") for storing a news' main image.

In your search results, you want to be able to display the news images right next to the text summary. You create a new managed property and you map it to the "ows_PublishingPageImage" crawled property. Now you try to use that property in your search results, but you notice that the property is always empty. How can this be?

That's because by design SharePoint cannot crawl compound controls. That's a beautiful way of saying that SharePoint hates you and will strip all HTML markup from the values of the properties when crawling them. Because the "PublishingPageImage" is entirely stored as HTML markup (i.e. "<img ..."), nothing comes up in the search.

There is a "simple" workaround for this. If you want to make use of the "PublishingPageImage" property for your search results, first you'll need to create a new property. This property will store just the image's path. Secondly, you'll need to create an event handler. In the handler you will need to define the "ItemUpdated" event, so that each time an item is updated you will populate the new property you created with the URL to the image of the "PublishingPageImage" field. After that, just create a new managed property mapped to your new site column and then use that property in your search results.

Conclusion

In this article we covered some trivial and simple things that become a nuissance when working with the SharePoint search that, although being powerful, also has many shortcomings in itself.

Resources

• Including Welcome Pages in the search scope in SharePoint Web Content Management solutions
• The contentclass and isDocument properties along with the Welcome Page caveat
• Custom Cross-List Search Development Pitfalls (Part Two)
• FullText SQL Query issues with NULL MetaData Properties
• FullTextSQLQuery tips
• Publishing Image does not get indexed
• No HTML Markup in MOSS 2007 Managed Properties
• SharePoint Search and HTML Meta tags

A strange problem started occuring with the RichHtmlField. When using IE8 in a SharePoint site, after editing a RichHtmlField the second time, a JavaScript error is thrown in form.js and the user is redirected to the welcome page of the site.

I'm still not sure what triggered this strange behaviour, if it is something specific to this site or a general problem. What I found out is that this occurs in IE8.

Here is how to duplicate this issue:

• You edit a RichHtmlField (clicking where it says "Edit Content").
• Then you click somewhere else on the page.
• Now go and edit the same field again.

If you have the same issue, after doing this, a JavaScript error will be thrown:

Message: 'null' is null or not an object
Line: 2325
Char: 2
Code: 0
URI: (...)/form.js?rev=df60y6YolDjUVbi91%2BZw%2Fg%3D%3D

Unfortunately this is not all that happens. After the error, the user will be redirected to the welcome page of the site where he's at.

It's something that occurs in the form.js file, so I'm not sure if this is something that can be fixed by configuration.

The workaround I implemented is not entirely pleasant, but it also solves other issues with default SharePoint installations. Basically what I did was make IE8 render the site as if it were IE7.

You can do this in several ways. For example, you can put a meta tag in your masterpage:

<meta content="IE=EmulateIE7" http-equiv="X-UA-Compatible" />

Another alternative is to add an HTTP header to the site in IIS with:

X-UA-Compatible: IE=EmulateIE7

You can read more about emulating IE7 for IE8 here.

Sometimes in complex tables with lots of columns you will run into the problem of the headers being too wide and causing the table to stretch beyond the available width. One solution is to use vertical text to render the headers.

It is easy to achieve this using images, but by doing so you lose the benefits of text: selectable, resizable, easier to style and update and easier to dynamically generate.

With the future CSS transform attribute it is possible to rotate text to become vertical. Current browsers already provide support for this:

div.vertical
{
    /* Safari/Chrome */
    -webkit-transform: rotate(-90deg);

    /* Firefox */
    -moz-transform: rotate(-90deg);
 
    /* Opera */
    -o-transform: rotate(-90deg);
}

For Internet Explorer it is done in a different way:

div.vertical
{
    /* Internet Explorer */
    writing-mode: tb-rl;
    filter: flipv fliph;
}

There are some caveats though. Browsers usually apply the transform at the end, so we have to take this into account and adjust the width/height accordingly. If you don't adjust the size, the width/height of the container will be the same as if the text wasn't rotated.

In the case of a table we will use a div inside each table cell so we have more control to style the outcome.

<table>
    <thead>
        <tr>
            <th class="vertical"><div class="vertical">Really long and complex title 1</div></th>
            <th class="vertical"><div class="vertical">Really long and complex title 2</div></th>
            <th class="vertical"><div class="vertical">Really long and complex title 3</div></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Example</td>
            <td>a, b, c</td>
            <td>1, 2, 3</td>
        </tr>
        (...)
    </tbody>
</table>

Due to the differences in rendering between IE and the others browsers we will use two different stylesheets.

For IE:

div.vertical
{
    position: relative;
    height: 210px;
    width: 45px;
    margin-left: 0;
    padding-right: 10px;
    writing-mode: tb-rl;
    filter: flipv fliph;
}

th.vertical
{
    padding-bottom: 10px;
    vertical-align: bottom;
}

For the other browsers:

div.vertical
{
    margin-left: -85px;
    position: absolute;
    width: 210px;
 
    /* Safari/Chrome */
    -webkit-transform: rotate(-90deg);

    /* Firefox */
    -moz-transform: rotate(-90deg);
 
    /* Opera */
    -o-transform: rotate(-90deg);
}

th.vertical
{
    height: 220px;
    line-height: 14px;
    padding-bottom: 20px;
    text-align: left;
}

Here is a screenshot of the final result:

You can download the final code here: vertical-text.zip (1,07 KB).

Tegenwoordig zijn nog weinig websites volledig opgemaakt in Flash. Toch zien je nog regelmatig bepaalde elementen in Flash terugkomen. Bijvoorbeeld een banner, button of video. Hierbij wil je graag weten hoe je bezoekers omgaan met deze elementen. Hoe vaak wordt er op geklikt of een andere actie ondernomen? Google Analytics kan je hier vergaande inzichten in verschaffen.

Er zijn verschillende manieren om je Flash elementen door te meten met behulp van Google Analytics. Eén en ander hangt ook een beetje af van de Flash versie waarin het element ontwikkeld is. En de actionscript code die is gebruikt.

Actionscript 2.0

Binnen Actionscript 2.0 is het mogelijk om de _trackPageview functie aan te roepen indien je een actie wilt registreren. Door middel van het aanroepen van de getURL functie binnen actionscript kan je ervoor zorgen dat Google Analytics een bepaalde actie in het Flash element trackt. Hieronder een voorbeeld van het doormeten van een button die naar een bepaalde pagina verwijst.

Stel je hebt een button die naar een volgende pagina binnen je website verwijst. Normaal gezien zorg je er met de getURL functie voor dat zodra er op de button geklikt wordt door de bezoeker hij naar de pagina wordt doorverwezen:

on (release) {
getURL(" http://www.google.nl ", "_blank");
}

Maar stel nu dat je met Google Analytics het aantal kliks op deze button wilt bijhouden. Normaal gezien zou je dit binnen de HTML inrichten met een onClick event, maar dat is binnen Flash niet mogelijk. Met de volgende functie wordt het mogelijk om de _trackPageview functie van Google Analytics te gebruiken én ervoor te zorgen dat de bezoeker ook doorgeleidt wordt naar de juiste pagina:

on (release) {
getURL("javascript:pageTracker._trackPageview('/clickthrough/flash-button-google'); window.location = 'http://www.google.nl';", "_blank");
}

Door de url te vervangen door een javascript code kunnen we zowel de _trackPageview functie als de redirect functie gebruiken. En dat allemaal binnen Flash. Om te checken of de functie correct werkt is het nog wel aan te raden om een alert te plaatsen binnen het javascript.

Voorwaarde voor bovenstaande is wel dat de Google Analytics code binnen de HTML aan de bovenkant van de pagina wordt geplaatst, of in ieder geval boven het Flash element. Anders zal Flash de trackPageview functie niet herkennen en het ‘bezoek’ niet registreren.

Hieronder nog een aantal voorbeelden van andere codes die gebruikt kunnen worden. Naast de _trackPageview functie is het uiteraard ook mogelijk om een _trackEvent in het Flash bestand te plaatsen.

Actionscript 3.0

Door een recente samenwerking tussen Google Analytics en Adobe Flash is het sinds kort een stuk eenvoudiger geworden om Flash elementen door te meten. Het Google Analytics for Adobe Flash component zorgt ervoor dat je de Analytics code gemakkelijk in je Flash bestand kunt gebruiken. Voorbeelden van toepassingen zijn onder andere:

• Het meten van een Flash widget op een HTML pagina;
• Een volledige Flash website die wordt gehost op een HTML-pagina;
• Een gedistribueerde Flex/Flash applicatie waar je geen controle hebt over de plaatsing van de widget.

Het Google Analytics component is zowel beschikbaar voor Adobe Flash en Adobe Flex. Google heeft een uitgebreid overzicht beschikbaar voor het implementeren van het Google Analytics component.

Belangrijke randvoorwaarde voor het gebruik van het component is wel dat de Flash bestanden zijn ontwikkeld met Actionscript 3.0. Anders zal het component niet werken.

Update

The GetSiteData method allows querying list items across multiple lists and webs. It is extremely useful because it allows for recursion and searching across the entire Site Collection. It uses CAML syntax and returns a DataTable.

Unfortunately it also contains a known bug in some SharePoint versions, preventing it from returning all existing results for a given query.

The problem is only visible in some situations, for example, when searching in more than 10 document libraries, so it might not affect everyone.

The GetSiteData method is also used by SharePoint, for example, in the Content Query Web Part (CQWP). If you're not seeing all expected results from your CQWP, then it might be because of this.

Microsoft has a KB article with more detailed information about this issue: Search results are incomplete when you use a CAML query that uses the SPSiteDataQuery class to search content on a SharePoint Server site or on a Windows SharePoint Services 3.0 site.

Microsoft offers a fix for this in the SharePoint Infrastructure Update of July 15, 2008 (KB951695 for WSS3 and KB951297 for MOSS). This upgrade brings your SharePoint version to 12.0.0.6318, so if you have an higher version, you already have it.

However, there have been reports by some people that this doesn't completely fix the issue. You should install it if you're having this problem, though. If it doesn't work you can try dividing your results in multiple queries.

Related information

• site.GetSiteData() query on multiple sharepoint lists does not return all list items of one list
• SPSiteDataQuery used with GetSiteData method not returning expected results
• SPSiteDataQuery limited to 10 document libraries or lists