Mark Everard

Hello, I'm Mark – a PhD physicist turned technologist / architect.

Archive for May, 2012

Setting up sitewide replacement languages for EPiServer

without comments

Fallback languages allow editors to specify inheritance chains for content at the page property level, meaning that if content isn’t available in the user selected language, the fallback language is served. This can be useful when working with a large site that requires a translation effort – meaning that you can translate parts of pages at a time.

I recently dealt with a requirement from a client who wanted to start over with their translation effort which had occurred at different rates across large areas of their site. They wanted just the English language version to be served. There are many possible solutions to this – such as putting in top-level redirects for all language variants through IIS  – however the editors wanted to retain the control of when they could re-enable a language for a particular page.

This meant removing all of their existing fallback and replacement languages settings for each and every page and then ensure that English was served as a replacement language for every page on every language variant*

* Obviously there are SEO impacts of serving identical contents on different urls, our solution also included a technical piece that handled this – perhaps I’ll share that next time if anybody is interested.

Under the hood

EPiServer stores language replacement and fallback in the sql server table tblPageLanguageSetting

If no data is found for a page – then the EPiServer code assumes that the fallback/replacement language data is inherited from a parent page. This behaviour is chained all the way up the tree to the site’s start page.

If you add data through the UI then EPiServer will add an entry to the table for each enabled language branch (in the above image I have three site languages enabled). When it does this it adds a null entry for each enabled language that doesn’t have a fallback or replacement language defined.  The presence of this entry is enough for EPiServer to know that the language data isn’t inherited.

So achieving our requirement is actually pretty straightforward. Ensure that the language settings are correct on the homepage and then remove all entries in this table apart from entries with fkPageID equal to the start page ID. (Note this wasn’t an enterprise scenario – you may have to be a little more granular with what you delete in that instance)

Obviously running direct SQL against the EPiServer schema isn’t recommended (or supported by EPiServer) – so BE CAREFUL – with great power comes great responsibility. However this is a huge time-saver over using the UI to achieve the same result.

Written by mark

May 22nd, 2012 at 7:58 pm

Posted in EPiServer

Will HTML5 deliver the mobile app-ocalypse?

without comments

Despite the continued success of Apples’ App Store and similar online application stores, publishers are beginning to invest and deliver mobile applications using technologies that many believe may signal the demise of the traditional native app. Is it time to take shelter from an impending mobile app-ocalypse?

With the current popularity of the App Store (over 25 billion downloads) it might not seem like it. However the phenomenal success of the native app market presents a number of problems for both users and publishers alike.

Will HTML5 deliver the mobile app-ocalypse?

The App Store is noisy

There are now over 500,000 apps available on the App Store meaning that finding the latest and greatest is difficult. This can lead to a unhealthy reliance on curated lists and editorially featured content as a means to reliably discover new apps.

As a publisher, this increases the risk that your beautifully created app can sink without trace, no matter how great it really is. This increased competition in the market place also brings out the more nefarious means of grabbing attention. Those user reviews and 5-star ratings are worth real money!

Mobile home screens are overcrowded

Once you’ve found and downloaded the app you want, it has to compete with all of the other apps you’ve downloaded for prime real estate on your device’s home screen. The desktop paradigm that most devices have adopted just doesn’t scale to hundreds of apps. The cost of having to organise, rearrange, update and de-clutter your home screen becomes significant compared to the individual value offered by many of the apps.

Developing for multiple platforms is expensive

Which platforms should you launch your app on? How many versions built on different platforms can your development teams support? Should you try and develop features in parallel across platforms or should you let your feature set diverge and add new features to one platform first? All difficult decisions. It’s pretty clear why there is an imperative to develop with cross-platform mobile frameworks.

Is HTML5 the answer?

No, not in isolation. HTML5 is often misunderstood. It provides an open standards way of marking up data for display as  user interfaces, content and rich media. So the real question is will web apps using HTML5 become the dominant way of delivering mobile functionality? The answer as always lies in the context. If you need to interact with the device hardware then a native app is still the best way to achieve this. If you need to present content, text, images and media then HTML5 and a web app allows you to do this in a cost effective and time-tested way.

There is a third way. Many publishers are now pushing a hybrid approach and realising significant cost savings across mobile channels by building native apps which use HTML5 to deliver user interfaces that are imperceivably different to those offered by native code. Take for example, the latest LinkedIn IPad app which to many commentator’s surprise delivers 95% of it’s views using HTML5 (and of course a hefty dose of JavaScript and server-side data services).


Native apps won’t disappear but clearly there is convergence between the experiences native apps can deliver and those available via a browser.

Perhaps though it’s the app delivery mechanism that will change most of all. Rather than investing time up-front collecting apps from a store (with a vastly improved app discovery mechanism), perhaps apps will be downloaded only if and when you need them. This is the exact model suggested by ex-Apple and Google mobile UX guru Scott Jenson who suggests that future apps will be delivered ‘just-in-time’, installing only the features you need there and then. The underlying technology for such delivery is already available. It’s the web!

Here for the long run

Ultimately, reports on the death of native mobile apps have been greatly exaggerated, but HTML5 shows every sign of becoming the dominant cross-platform technology for serving rich interfaces, media and content.

Every future device of note will have a standards compliant browser, meaning that every device will be capable of consuming content and services delivered in HTML. As a publisher or developer it would be foolish to ignore this. As a user, hopefully you won’t even notice the difference…..

Written by mark

May 16th, 2012 at 4:02 pm

Posted in iOS,Mobile,Opinion