Wednesday 9:15, Keynote

First of all, Sitecore has been waving version 7 in our faces for a while. The last year’s conferences were full of promising new features – will this be the time when we hear something concrete?  I therefore hope (although not exactly expect) to hear a keynote with a working demo of Sitecore 7. Michael Seifert is growing into a fantastic speaker, so if he has the product, he will be able to deliver the wow factor.

Wednesday, 15:30: Developer Track, Multiple Ways to Multisite Solutions

One of the eye-catching sessions for me has got to be the multi-site session by Tim Ward. Over the years, we have pretty much delivered multi-site solutions to ALL our clients. I’ll be interesting to get the official Sitecore take on the problem. Furthermore I am very comforted by the fact that Sitecore actually has a take on it – given the problems we have faced historically with lack of multi-site support in some of the official modules.

Wednesday, 14:15: Sponsor Track, Preventing the Language Chaos
Thursday, 11:15: Sponsor Track, Sitecore Translation Strategies and Techniques: Which One Is Right for You?

During the conference, there are talks by two translation/localization vendors: Clay Tablet and Lionbridge. In the last years translation support is one of the key features our enterprise clients request, and it’ll be interesting to see if the vendors gives us some nice technical integration tips. Although I must say, I do expect sales pitches from both sessions.

Wednesday, 15:30: Sponsor Track, Best Practice for Performance Tests Within CMS Installations

The Sitecore Partner Apica has a session about performance testing and best practises. Seeing that this is a techie talk on the sponsor track (which in itself is a contradiction in terms) I’m hoping for a surprise wow experience.

Wednesday, 16:30, Product Track: Building, Connecting and Measuring Communities with Sitecore

Social media and social web features are seemingly always very important to our clients – and why?  “Well because everybody else has it”. In this light, I’m expecting John Field to give me some Sitecore recommendations on how to prove the value – or lack of same – to the clients. Secondly, Sitecore recently purchased a large share of the Danish Facebook integration company KOMFO – I’m hoping for the conference to shed some light on what this collaboration could mean.

Wednesday, 16:30, Sponsor Track: Sitecore and Salesforce – A Compelling Case for Unified Customer Engagement

During the last year, a number of our clients have shown a very keen interest in the CRM integration part of DMS – turning their website into a direct sales tool, integrated with their sales department’s weapon of choice. A nicely done Salesforce/Sitecore integration could give us an additional tool in our integration toolbox.

Thursday, 9:00, Developer Track: Breaking a Million with a Bucket of Items

Buckets are in my world, the next HUGE thing in Sitecore – and something which have been waved around our nose in years. I hope to see massive amounts of data, easily indexed and faceted AND extracted with a nice and neat API. And how does the bucket data tie in with the hierarchy that we know today? Furthermore I hope – well I might even venture an “expect” – to see the concrete implementation and a glimpse of Sitecore 7.

Thursday, 12:15, Product Track: Sitecore Roadmap – Where Are We Going with the Product

This I guess is always a conference must-see. This is where I expect more Azure integration, more social media stuff, more enterprise features, closer integration to ERP and CRM, more app center services from Sitecore etc. etc. Although I hope to see a glimpse of what’s beyond Sitecore 7 and, pretty please, some focus on integration and the development community – and not just new features.

Thursday, 14:00, Developer Track: Become the Marketer’s Best Friend ̶ Using the DMS API to Extremes

The DMS API has never really had any success with the developers within Pentia – and in my view for a good reason: It’s simply not good enough. It just doesn’t have the sleek interface and neatness that the core Sitecore API has. Therefore I’m hoping for an introduction to a clean DMS API in Sitecore 7, although I must admit that I’m expecting an attempt to woo us developers with some features in the current API.

What are your expectations? Hope to see you there!

www.brk.dk

Frisk initiativ, lad os dog håbe at de har fokus at løbende optimere og kvalitetssikre deres søgemaskine (for øvrigt en opgave de fleste overser – tendensen er at søgemaskiner er noget man køber og glemmer). Er der nogen der ved hvilken søgemaskine Bornholms Regionskommune bruger?

Sitet fik mig dog straks til at tænke andre tanker, for hvor utraditionelle Bornholm end er på søgemaskine-tilgangen, er de ikke ulig så mange andre i den primære navigation.

www.brk.dk (UX og implementering: Valtech)

Vi har hos Pentia igennem årene været temmelig involverede i kommunale websites og set en del iterationer og udviklinger i informationsarkitekturen, design og generel UX. Min konklusion efter at have kigget en række kommuner igennem, er at de (og deres designpartnere) enten låner lidt rigeligt fra hinanden eller også har de faktisk opnået den optimale informationsarkitektur for et kommunesite (IA-nirvana!)

www.gentofte.dk (UX og implementering: DIS/PLAY)

http://www.horsholm.dk (UX og implementering: DIS/PLAY)

http://www.egedalkommune.dk/ (UX og implementering: DIS/PLAY)

www.aarhus.dk (UX: Matter Design Studio, implementering: Pentia)

Hvis der er nogle derude der kender mere til de design og IA beslutninger der blev taget i processen så smid endelig en kommentar.

Værktøjet virker kort sagt ved at du som bruger i Sitecore peger værktøjet på en ekstern webside – eksempelvis en webside implementeret til et specifikt marketingsformål eller nyhedsbrev – som importere siden ind i Sitecore. Herved oprettes siden med indhold, det grafiske design, billeder mm. som en ny sidetype der kan anvendes på dit site. Herefter kan indholdsområder på den nye sidetype udpeges som dynamiske og peges hen på indholdselementer i Sitecore – derved kan redaktørerne i Sitecore oprette og vedligeholde indhold på sædvanlig vis til den nye sidetype.

Kontakt Pentia hvis du vil vide mere om hvordan værktøjet kan hjælpe dig.

Sitecore skriver:

Sitecore has announced the availability of Sitecore Design Importer

• The Design Importer is a tool that lets non-technical users such as marketers and content editors, to quickly import static web pages into Sitecore and enable content editing.
• This should not be thought of as a migration tool but rather to support one-off landing pages or campaign sites, PoC pages and to quickly test prototype designs, all without the need for Sitecore Developer resource.
• The Design Importer enables you or your clients to get better value from resources created externally and edit/re-use the content.
• It enables the import of HTML, then fields, images and placeholders to be set, resulting in first-class support for content editing and design in the Page Editor by default. The result can be stored as a layout or sublayout.
• The Design Importer is compatible with Sitecore CMS 6.5

For more information about the Design Importer, visit the Sitecore Developer Network and download the following resources:

• Design Importer 1.0 rev 120206
• Documentation

Sincerely,

The Sitecore Customer Service Team

Følgende er teksten fra websiden “Sitecore’s Recommended Version Policy“ på sdn.sitecore.net. Siden er beskyttet med password og derfor ikke tilgængelig for alle kunder. Men er gengives teksten:

As part of our commitment to continually improving our software and listening to our customer’s feedback, Sitecore regularly releases new versions of our CMS product. Each release undergoes careful quality assurance procedures to minimize the number of issues. Nonetheless, Sitecore only assigns the “Recommended Version” stamp to specific, carefully selected releases.

Some of our customers have found this confusing.

To understand our recommended version policy, it’s important to remember that people install Sitecore CMS for many different reasons. For example, a Sitecore CMS installation can be:

• A production installation that runs an important website for a customer.
• The development environment for an upcoming website. It may take several weeks or months before the website is deployed.
• A training website that helps developers learn about the product.

Our recommended version policy is aimed at production installations that run important websites for our customers.

Sitecore has a very agile approach to development. As a result, we release a steady stream of updates and feature releases for our product. This constant stream of improvements can place a burden on system administrators; who must decide whether or not to install the latest update.

Our recommended release policy helps administrators make these decisions, by reducing the risk for our customers and limiting the number of upgrades that we recommend.

When we release a new version of our CMS product, it does not immediately become the recommended version. This indicates that production installations that are working fine do not need to update to the new release.

Not every release is destined to become a recommended release. Sometimes we select a later version as the new recommended release. We work closely with the Sitecore development teams and with our partner/developer community when we decide which version should become a recommended release. Once again, our focus is on limiting the number of upgrades that our customers must perform.

However, it is important to remember that Sitecore fully supports every new release including those that aren’t recommended versions.
Before you decide which version of Sitecore you should use on a new production environment, you should investigate the later, non-recommended versions. If there is a later version that contains some new features that your website requires or resolves some known issues that might affect your website, it makes very good sense to install that version. If you subsequently decide to upgrade your website to a later release, you can investigate Sitecore’s Recommended Versions.

When in doubt, we recommend that you discuss this with your Sitecore partner before making a decision.

Sitecore’s Product Version Numbering

Every Sitecore product uses the following versioning system:
<Level 1>.<Level 2>.<Level 3> (rev. <Level 4>) — Sitecore.NET 6.2.0 (rev. 091012 Hotfix 330275-1)

For new releases, an increase in the version number at the various levels provides information about the release.

The following list describes what an increase in the version number at each level indicates:

• <Level 1> — indicates a major new version of the product. Developers, users, and partners should attend supplemental training to keep their certification status up-to-date. Internal sales training, documentation, and training materials will be updated. Major new versions require the greatest effort to upgrade. On average, upgrades for this level of release will take several weeks to implement.
• <Level 2> — indicates a release that introduces new features, these are typically UI changes and updates of, for example, XSLT files, ASPX files, or APIs. Documentation and training materials will be updated. Upgrades at this level require a moderate amount of effort to implement. On average, upgrades for this level of release will take 1-2 weeks to implement.
• <Level 3> — indicates a release that contains minor structural changes. Upgrades at this level require a minimal amount of effort. On average, upgrades for this level of release require less than a week to implement.
• (rev. <Level 4>) — indicates a release that contains bug fixes. Upgrades at this level require a minimal amount of effort. On average, upgrades for this level require a few hours to implement.
  The fourth level numbering is a date — yymmdd-n — and n is used if more than one build is made on the same day.

Bemærk at Pentia generelt set – på nye løsninger og ved opgraderinger – anbefaler vores kunder at anvende den seneste version fra Sitecore. Det er vores oplevelse at en løbende opgradering til nyeste version af Sitecore giver en bedre værdi end “the big bang” når Sitecore opdaterer deres anbefalede version – hvilket ikke sker så ofte som vi gerne så hos Pentia.

Desuden er Sitecore – som det kan læses i ovenstående – committet til den samme support på den nyeste som på den anbefalede, og alt andet lige er der lavet flere rettelser, optimeringer og nyskabelser i den nyeste end i den anbefalede.

Kontakt os for mere information om hvordan vi kan opgradere din løsning.

Bemærk at den nye opdatering ikke er den anbefalede version fra Sitecore, men kun anbefales hvis der opleves problemer med den nuværende version på jeres website.

Læs mere om opdateringen her

Pentia anbefaler generelt vores kunder at opgradere til eller på nye løsninger at anvende Sitecores seneste version. I skrivende stund version 6.5 Update 3.

Kontakt os for mere information om hvordan vi kan opgradere din løsning.

Template inheritance:

Template inheritance is an integral part of Sitecore which I hope that all of you Sitecore fans out there use extensively in your solutions. At Pentia, template inheritance is so vital that in practice, you will see no item.TemplateID == SomeID or item.TemplateKey = "sometemplate" in any of our code, just like you (hopefully) would never use MyObject.GetType().Name == "MyClass" in C#.
No, we always use the following extension method:

[sourcecode language="csharp"]
public static bool IsDerived(this Item item, ID templateId)
{
if (item == null || templateId.IsNull || item.Template == null)
return false;

TemplateItem templateItem = item.Database.Templates[templateId];
if (templateItem == null)
return false;

Template template = TemplateManager.GetTemplate(item);
return template != null &amp;&amp; (template.ID == templateItem.ID || template.DescendsFrom(templateItem.ID));
}
[/sourcecode]
The method is used as item.IsDerived(“MyTemplate”) just as you would always do MyObject is MyClass in c#. Sadly, Sitecore offers no obvious way to do the same out-of-the-box….wait… oh yeah, you could naturally do Sitecore.Xml.Xsl.XslHelper.IsItemOfType()

Hierarchical inheritance:

While template inheritance is used to give all content of different types the same properties, hierarchical inheritance in Sitecore is slightly different. This is primarily used to allow a piece of content, a setting or a configuration to propagate down a branch in the tree – i.e. propogate down a number of content types which can be totally unrelated, but grouped together solely because of their content position. For example, this could be used to apply a given design theme to an entire subsite within you site. Using hierarchical inheritance, extension methods and Linq, this could be accomplished as such (pardon the train-wreck):

[sourcecode language="csharp"]
protected void Page_Load(object sender, EventArgs e) {
var theme = this.GetDataSourceItem().GetAncestorOrSelf().First(i => i.IsDerived("HasTheme")).Fields["Theme"].Value;
//…
}
[/sourcecode]
In this example there are – besides the IsDerived extension method described above – two very useful extension methods:

GetDataSourceItem extends the ASP.NET UserControl to provide easy access to the DataSource set on a sublayout and is implemented as follows:

[sourcecode language="csharp"]
public static Item GetDataSourceItem(this UserControl control)
{
Sublayout sublayout = GetSublayout(control);
if (sublayout == null)
return null;
string dataSourcePath = sublayout.DataSource;
return !String.IsNullOrEmpty(dataSourcePath) ? Context.Database.GetItem(dataSourcePath) : null;
}
[/sourcecode]

GetAncestorOfSelf extends item to return a list with the item itself and all its parents – and this is naturally where the key to hierarchical inheritance lies:

[sourcecode language="csharp"]
public static IEnumerable<Item> GetAncestorOrSelf(this Item item)
{
do {
yield return item;
item = item.Parent;

} while (item != null);
}
[/sourcecode]

I hope this post shows you how some simple extension methods can give you a lot of power in your solutions.

Versioneringssystemer er et uundværligt værktøj for de fleste udviklere, og hos Pentia har Subversion en central rolle i vores udviklingsflow.

Der kan dog opstå problemer, hvis man ikke er opmærksom på de skjulte .svn foldere, som Subversion opretter i løsningen, og som rummer metadata for de registrerede filer.

Problemerne kan opstå, hvis man kopiere en mappe, som er tilføjet Subversion, fra projekt x til projekt y. Herved vil også de metadata, som Subversion bruger, blive kopieret, og der vil opstå problemer i dit SVN-projekt.

En løsning er at fjerne alle .svn-mapper, inden du flytter eller kopierer dine filer til en ny destination. Hertil er følgende script praktisk:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREClassesFoldershellDeleteSVN]
@="Delete SVN Folders"
[HKEY_LOCAL_MACHINESOFTWAREClassesFoldershellDeleteSVNcommand]
@="cmd.exe /c "TITLE Removing SVN Folders in %1 && FOR /r "%1" %%f IN (.svn) DO RD /s /q "%%f" ""

Kopíer, gem som .reg-fil og kør.

Eller download denne fil, unzip og kør: FjernSvnFolders.reg

So where do we draw the line in the holy name of bending functionality and giving the customer “what they want”? Remember:

• Convincing the client to choose standard functionality is also an option.
• Each change of standard Sitecore functionality is potentially expensive – for you and for the client.
• If possible, do not replace Sitecore functionality, extend it.
• Think about what you put into Sitecore: Content and functionality can be accessed through .NET code and does not necessarily need to be added to the Sitecore DB’s or in a pipeline.
• Keep track of your customizations – source control it and document it.
• Remember that your customizations will have to upgrade with Sitecore.
• Stay true to yourself: If it feels wrong, don’t do it.

In short, just because you can does not mean that you should:-)

The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.

Select your implementation partner carefully

Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the project’s success. Therefore your primary focus initially in your project should without doubt be to find the right implementation partner.

In my opinion, what you should focus on is:

Human chemistry: A website is not primarily a technological project, but a communication project. Therefore select a partner with whom you can communicate openly and freely. If you sense that they are listening, factors as for example domain knowledge is less important.

Experience: Sitecore is not a difficult tool to learn – but is takes time to master. Therefore, try to find a partner which has multiple large scale projects under its belt, and preferably with projects which has undergone a number of iterations.

Technology based: In my experience, companies which are technology based, i.e. which focuses primarily on the integration and platform parts of the solutions compared to the user experience driven companies, e.g. design agencies, makes more future proof Sitecore solutions. Therefore if you are looking for someone to build your future webplatform as opposed to just your next website, opt for a company with vast knowledge of Microsoft .NET and surrounding technologies.

References: Most implementation partners can most likely show an impressing list of references – but please do not stop there. Call their references and enquire about support, quality etc. Hearing whether their existing customers have gotten value for money is very useful.

Don’t be too specific in your requirement specifications

My suggestion is that you use your implementation partner as a sparring partner on requirements. Remember that these guys have built other solutions before yours and might bring experience, skills and functionality which will benefit you. Also, allowing multiple implementation partners to suggest different solutions to your website’s objective – as opposed to a RFP checklist – will allow you to better evaluate their creativity.

Therefore, in the specifications, try to explain the objectives you have for your company, users or editors, instead of the precise functionality. In Pentia we have had multiple requests for debate forum functionality in solutions – which in our experience is a prime example of a specific functionality which is often never used by users. By explaining which objective the clients wanted to achieve on the website, instead of the specific functionality, we could have advised better, earlier in the process and given more value to the client. By the way; in most cases we managed to dissuade the clients to actually implement the debate forum, and used the precious development time for something much more valuable.

In short: Requirements change. Therefore, being too specific and detailed about functionality already in the RFP process will most likely get you a whole lot of expensive, unused functionality.

Be open about your development budget

This is in my book a no-brainer. The only reasons for not being open about the budget are if you adopt the “they-are-all-thieves-and-robbers” attitude or if you hope to haggle your way to a cheaper website. In both cases, you are doing yourself and your website a whole lot of damage.

First of all, you have to trust your implementation partner, as they hold an immense power to make your project a success or failure. If you don’t, find another partner. Secondly, this is not a standard product you are buying. If you push your implementation partner on time or money, they have but one place to push back: quality. This basically means that your solution will be in a worse state, bringing lower reliability or higher support cost.

Therefore, a selection process is not about getting the lowest price or best solution description. It’s all about finding the implementation partner which you trust the most. And if you found that implementation partner, why not be open about mostly everything, including budget?

Bring your partners on board early

There is a lot of benefit in bringing in all your partners as early in the process as possible – this means both strategy and design partners and well as implementation and hosting partners. Each domain has something to bring to the process and can potentially save you a lot of money and hassle. Getting the implementation partner and hosting partner to talk together as early as possible can save a lot of time in the deployment process, and in my experience, by getting the implementation partner involved in the strategy and graphical design process a lot of hours can be saved in communication afterwards. Furthermore implementation partners often have prebuilt functionality which – if it fits the project – can save you a lot of time and money. The earlier this is brought forward, the easier it is to fit into any graphical design or information architecture.