Check for mobile, tablet and desktop computers in Dynamicweb Razor-templates

Dynamicweb detects which device is being used when a user visits a website built with Dynamicweb CMS. In Razor you can use this information in the following way:


This can be very useful in creating adaptive webdesign as it allows you to serve e.g. images scaled and compressed correctly and directed to a particular device. Note, though, that Dynamicweb CMS has had some problems keeping up with new devices. Meaning that you should always provide a fallback method.

Get content from paragraph – Dynamicweb and Razor

Dynamicweb CMS allows you to get content from a certain paragraph – by using the following template-snippet:


This works fine in a regular HTML-template. However, Dynamicweb CMS has a rather new feature that allows you to use Razor-templates instead, and in these the above mentioned method doesn’t work. Thankfully, a colleague of mine (Morten Bengtson as usual) showed me how to do it properly in Razor:

<div class="span9 contactInfo">
        var pageView = Dynamicweb.Frontend.PageView.Current();
        var item = Dynamicweb.Content.Items.ItemManager.Storage.GetById(Dynamicweb.Base.ChkString(pageView.Area.get_Value("AreaItemType")), Dynamicweb.Base.ChkString(pageView.Area.get_Value("AreaItemId")));
        var ContactInfoParagraphID = Dynamicweb.Base.ChkInteger(item["ContactInfoParagraphID"]);

So we went from a very simple approach that took only line to a much harder to remember approach. I guess you can’t always win. ūüôā

ScrollTo using AngularJS and jQuery

The following small snippet allows you to create a smooth scroll effect to a particular DOM-element. You just insert the function inside an AngularJS-controller.


$scope.scrollTo = function(element) {
  $( 'html, body').animate({
    scrollTop: $(element).offset().top
  }, 2000);


$scope.scrollTo( ".level2");

Design and develop for large screen resolutions

In the last couple of years we have witnessed an explosion in the amount of different screen sizes. In my company, this has resulted in a huge focus on designing websites that target Smartphone-devices as well as Tablet-devices. Almost every project today involves designing a responsive website that will be displayed well on small screens.

However, I believe that in this process we’re forgetting about the larger screens. We’re giving the mobile user a lot of attention in our web development.¬†But in this focus on the mobile user we forget that there is a huge amount of screen estate that we’re not using at all.

A lot of websites has been built using the popular Twitter Bootstrap CSS-framework. Twitter Bootstrap creates a grid that allows the web developer to create optimized layout for extra small devices (phones <768px), small devices (tablets >= 768px), medium devices (desktops >= 992px) and large devices (desktops >= 1200px). So a lot of websites built with the latest version of Twitter Bootstrap have a maximum width of 1200px.

In fact, most websites built on top of Twitter Bootstrap will probably have been built using the old version of Twitter Bootstrap which had a grid with a maximum width of 940px.

But as you can see from the following chart, most users have a screen resolution that is larger than that.

Development in screen resolution - data source: W3Schools Browser Display Statistics

Development in screen resolution – data source: W3Schools Browser Display Statistics

The chart above shows that in January 2014 93% of all users that visited the W3Schools had a screen resolution of 1280×800 or higher. And 99% of all users had a screen resolution of more than 940px.

In fact, if you look into the statistics from Statcounter, you can see the decline of the 1024×768 resolution and the rise of the larger screen resolutions. Desktop computers with a resolution of 1024×768 went from 18% in May 2013 to 10% in May 2014. This is in contrast to desktop computers with a resolution of 1366×768 which went from 25% to 29%, and desktop computers with a resolution of 1920×1080 which went from 7% to 10%. In fact, the most popular resolution right now is the 1366x768px resolution.

Top 10 Desktop Screen Resolutions from May 2013 to May 2014 - data source: Statcounter

Top 10 Desktop Screen Resolutions from May 2013 to May 2014 – data source: Statcounter

So what is the solution for this? Well, I have the following recommendations that I use when I speak to our customers:

  • You should absolutely still focus on smaller screens – more and more users are using¬†Smartphones and Tablets when they surf your website, so this is still very important. Therefore,¬†you should still optimize design and functionality for these devices.
  • You should realize that designing for a¬†maximum width of 1024px is a thing of the past. Most desktop users will have a screen resolution that is much larger than this. How can you utilize this extra space?
  • Consider that¬†it is almost impossible to predict the future screen resolutions, and users will have all sorts of different devices that will have different screen resolutions. There are different techniques to handle this – an example of this would be the fluid design that will adapt 100% to different screen sizes. This is in contrast to responsive webdesign that creates “fixed” layouts for different screen resolutions.
  • If you do not want to use fluid design then you should at least use a responsive grid that will adapt to larger screen sizes. The latest version of Twitter Bootstrap does this, but it is important that the webdesign process takes this larger screen size into consideration.

Why are all my Dynamicweb templates all of a sudden renamed to “.cshtml”?

Dynamicweb CMS has almost always been using it’s very own templating system. Almost always means that in the beginning there wasn’t any templates, and instead you had to use a central Stylesheet to insert logo, change colors, and so on.

This templating system has worked quite well for a very long time, and the reason for this is that it is pretty easy for most people – including customers – to change the content of these templates. The templates are just very simple HTML-snippets mixed with different Dynamicweb tags that contain the content coming from Dynamicweb CMS. However, there are a lot of different drawbacks with the old templates – especially in terms of developers trying to do more advanced stuff. This originally lead Dynamicweb to create the XSLT-template which allows the developers to do some manipulation to the template based on different content. In Bleau we also used this approach, and we were pretty happy with it – but I don’t think it really took off with other Dynamicweb CMS partners because it is also a bit more complicated, and it really requires a developer.

Now, Dynamicweb introduces Microsoft Razor to complement the existing old templates and the XSLT – and by the way, the old Stylesheet is still there. Confused? ūüôā

Razor is a relatively new technology from Microsoft, and it essentially allows you to execute C# or inside a normal HTML-template. This allows the developer to create really powerful templates containing rich functionality – which can be both good and bad. Let’s try summing up some of the good stuff:

Better performance
The old Dynamicweb templates need to be parsed through a central Dynamicweb “parsing” engine which matches the template tags inside the template with the content from Dynamicweb. The new Razor-templates do not need this, and therefore the new templates provides the end-user with a better performance.

Easier for existing Microsoft-developers to learn and reuse knowledge
New developers are sometimes having a hard time grasping Dynamicweb – mostly because that there a lot of different ways to display content and there a lot of different Dynamicweb-specific tags and methods that you can use. As an example, Dynamicweb has developed its very own if/then-construct and also its very own loops. Which pretty much sucks if you’re a developer trying to learn Dynamicweb CMS, and you would rather just reuse your existing knowledge instead of learning new concepts that are only applicable to this particular CMS. In my view, this is one of the most important reasons for introducing Razor – you suddenly get access to a vast pool of developers who would rather work with Microsoft-technologies than Dynamicweb-technologies.

One of the other benefits in relation to this is that developers gain Visual Studio Intellisense support.

Easier to create custom functionality
There are a lot of ways that a developer can inject custom functionality into Dynamicweb. You can do all sorts of stuff with Dynamicweb, and the CMS is in no way a closed CMS. However, you need a backend developer to do this.
Because of the ability of executing code inside Razor-templates it all of a sudden becomes easy to create custom functionality. You just add the code right there inside the template.

Razor is part of the future Dynamicweb CMS
The new Razor-engine is only the first part of a new future Dynamicweb CMS. The upcoming generations will see a tight integration between items, MVC, Web API and front end technologies like AngularJS. You will experience a completely different way of building websites with Dynamicweb CMS that will be much more powerful and flexible than currently.

So these are some of the positive aspects of adding Razor-templates to Dynamicweb. There must also be some drawbacks…

Easier to create custom functionality – part 2
Well, a good thing can also be a very bad thing. Unskilled developers can really create a mess for themselves. You can do EVERYTHING inside these templates – which could potentially create a lot of work for the Dynamicweb support.

More difficult for customers to quickly change a template
Customers used to work with templates will suddenly find it a bit more intimidating. Meaning that it will still be possible, but some customers might find it scary that all of a sudden there is code inside their templates. And so the risk of customers f….. up a template increases.

However, this could also be a good thing – customers quickly changing stuff inside a template can certainly also be a direct route to errors.

A mess of HTML and C#
In the ‘old’ days you would try to separate presentation from logic. And you should still do this as much as possible. Our advice is still to create backend modules for business logic, and then only use Razor for modifying the output from Dynamicweb. However, because you can do EVERYTHING inside Razor there will be developers (not Bleau-developers!) that will be tempted to do EVERYTHING. Which could create a mess of HTML and C#, and thereby making it even tougher to support, debug and administer.

A mess of different Dynamicweb-methodologies
The new Razor-templates open up a new way of doing front end development inside Dynamicweb – next to all the other existing possibilities ūüôā This can also really create a mess of template-archive consisting of normal Dynamicweb-/HTML-templates, XSLT-templates, Razor-templates, and then some settings inside the Management Center, and so on. Dynamicweb still needs to cater for existing solutions, and I certainly understand this fact. However, the result can potentially become a mess – especially if the implementation partner doesn’t understand this.

So what are the consequences of all this? Well, as a customer implementing a Dynamicweb-project, you shouldn’t try to understand Razor, but you should make some requirements to your implementation partner. In Bleau we try to strive to the following:

1. Use Razor as much as possible – it will increase performance. Also if you don’t have any advanced stuff going on, but just want to present ‘normal’ content
2. Drop methods that do the same thing. You can use XSLT to accomplish the same stuff as you can in Razor. So that’s why you should only use one of these methods (Razor).
3. Only use Razor to modify output from Dynamicweb in order to present content to the user – more advanced stuff still goes into backend modules

In Bleau, we will start adapting Razor-templates as much as possible. We look forward to all of the new improvements that will happen inside these templates, and we think that it will benefit the developer community as well as the solutions created for customers.

Developing your employees

In Bleau A/S (the company I work for) we now dedicate 1 day in each sprint to the development of the skills of each individual developer. Each sprint lasts 10 working days, and so this means that 1 day equals to 10 percent of the employees’ working hours. It might seem a lot, but we actually believe that we can become a much better agency by allocating this amount of time.

This is a relatively new decision and it has been a tough one. We are still a very small company – with 30 employees in total – and spending 10 % on the development of each individual is a major investment for us. And then there’s the issue of demanding projects and demanding customers. We’re always busy, and it is difficult to focus on personal development, when you know that there are tough deadlines to be met. We’re often focusing much more on the short-term future, than the long-term.

We made this decision because we realize that if we want to stay in business, we need motivated and skilled employees, and we also need to train them ourselves. We’re growing as a business, and we need employees who are able to make clever decisions on their own. And the fact that we’re a digital agency demands employees who are well educated and observant of the latest trends and technologies. The knowledge that our employees gain from this personal development will benefit our customers and their projects.

Of course, we already had motivated and skilled employees before this new program. And of course we also spent time on personal development. However, it was much more ad hoc and much more something that was done after hours. Now we feel that we can control it much more – both in terms of the content but also in terms of making sure that each employee actually spends the time.

The future must show whether or not this 10 % is the correct amount or not. It seems to be right, and our employees has grasped the opportunity. Our employees are now becoming certified in such different areas as QA, Scrum, Dynamicweb and Microsoft. However, we also encourage our employees to pursue smaller areas of interest – e.g. improving their skills in CSS or jQuery.

But how do you practice personal development? Does your company also dedicate a certain amount of time? And how much does it allocate? Or is it more ad hoc? I would really like to learn more about this, so if you have any experience on this subject, then please write a comment.

Keep web projects simple

Creating unnecessary complexity in webprojects is one guaranteed method to failure. And so it follows that if you want to create succesful projects, you have to remove unnecessary complexity.

The introduction of the iPhone ended a period that was pretty stable in terms of web technologies. Sure, there was some innovation going on, but nothing like we’ve seen since then.¬†Suddenly, it was not enough to consider the usual browsers on the desktop PC. You also had to consider the different browsers on the new devices. And you couldn’t rely on ever-increasing bandwidth and processing power to hide your mistakes.

What we’ve been witnessing is a period characterized by a lot of experimentation from especially Apple and Google – and from several other hardware¬†manufacturers. And in the wake of all this experimentation, we’ve also witnessed the rise of several open source projects trying to¬†accommodate for and exploit¬†all the different possibilities.

Operating a web agency in these conditions can be very exciting and prosperous – but it can also be very dangerous. The company that I work for – Bleau – quickly decided to rush into the development of websites optimized for mobile devices. Today, we almost never work on websites that shouldn’t be optimized for mobile. It has been a very giving process in terms of knowledge – but it has also been a very expensive process in terms of money and quality. We simply made a lot of mistakes – both because we didn’t know better, but also because we sometimes got so excited by all this new fancy technology.

The most important lesson we learned in this process is to keep projects simple, and to use the 80/20-rule. The 80/20-rule says that a minority of causes, inputs or effort usually lead to a majority of the results, outputs or rewards. Taken literally, this means that, for example, 80 per cent of what you achieve in your job comes from 20 per cent of the time spent. So, 4/5 of the effort – that is, most of the project – is largely irrelevant.

This is a very valuable lesson – translated into web projects it means that 20 % of our effort yields 80 % of all business value. Now the hard part is finding out which 20 % is most relevant.

In Bleau we have decided to take the initial process of requirements gathering very seriously. In fact, we’ve decided that if we cannot establish the requirements ourselves in cooperation with the customer, we do not engage in the project. That’s the reason why Bleau never engages in public tenders – where requirements are formulated by the customers themselves and then handed over to the web agency. We simply believe that our experience combined with the customers’ knowledge about their business is the best way to ensure that requirements are formulated in a way that ensures web projects are carried out efficiently and with high quality.

In the requirements gathering process, we urge the customer to think in terms of business value – instead of features. We focus on setting business goals – and we let the customer prioritize these business goals. We then translate these business goals into user stories, and finally we assign monetary value to each user story. On top of this, it is our responsibility to come up with a user interface and technologies that support the customers’ business goals.

We’ve found out that such a process ensures that people focus on what is important. When you align user stories with business goals, and you put a monetary value on each user story you make sure that nobody diverts from the path. The result of this is that everybody in the project understands what is most important in the project and that features not supporting the business goals are eliminated. This makes web projects much more simple.

An example of how this works is the issue of browser- and device compatibility. Often, the customer will have an initial requirement stating that the new project should work on every browser, every smartphone and every tablet. However, if you look at the usage statistics for the different browsers and devices, you will notice some interesting trends:

  • The usage of Microsoft Internet Explorer 8 is falling and in Denmark less than 5 % is using this browser per the 29th of December 2013
  • Microsoft Internet Explorer 9 has seen a very sharp decline and currently the usage of this browser is also below 5 % in Denmark
  • Browsing on tablets almost always happen on iPad-devices (86 %)

I’m not saying that you should ignore people using IE8 or IE9. After all, these browsers still have almost 10 % of the market share in Denmark. But I’m saying that you should consider prioritizing more modern browsers, and maybe putting your emphasis on tablet devices.
Instead of putting your money on optimizing for browsers that will be gone in a year, you should perhaps focus on browsers and devices that will be big when the project is done. So, the website is optimized and working perfectly on the majority of browsers and devices, and ‘just working’ on old browsers. People using these old browsers will still be able to view the website, but the more advanced features will not work in these browsers.
Making such a decision will absolutely reduce the complexity in web projects and will therefore reduce the cost of the project and increase the quality.

Another example is the battle for the frontpage. We always encounter this battle, and it is typically a battle between different departments in the customers’ organization. The different departments think that their content is the most important, and therefore should be present on the frontpage of the new website. However, if we include all this content, the frontpage will be heavy and it will surely compromise the customers’ business goals. Often, when this situation arises webdesigners try to minimize the burden of all the content by hiding it via sliders, scrollers, tabs and so on. However, adding this stuff will add to the complexity of the project – both because we now add all sorts of JavaScript-plugins and because we have to spend even more time on increasing performance of the website.

Instead, we try to force the customer to prioritize the content – and only the absolutely most important goes to the frontpage. By removing unnecessary content from the frontpage, we can reduce the complexity of the project – and thereby save money and increase quality.

What we’ve seen in my company is that by insisting on discussing requirements and by reducing complexity, we can increase quality, deliver on time and reduce cost. What we’ve witnessed is more satisfied customers. What we’ve also learned from this process is that introducing new technology should happen incrementally and not as a “big bang”. Surely, we learned a lot from introducing responsive webdesign, AngularJS and quality assurance of multiple devices and browsers, but we also became bruised and damaged along the way.

The new Dynamicweb Email Marketing module

It’s been a while since i last blogged about Dynamicweb. I’ve been busy working on other projects based on other products and technologies than Dynamicweb and Microsoft.

But it’s not because that there’s nothing to talk about. Dynamicweb CMS has seen a remarkable development in the last year or so and a lot of new exciting functionality has been added to the standard software.

Some of this functionality is wrapped inside the new Dynamicweb Email Marketing module, which is set to replace the old Dynamicweb Newsletter module. Which is a good thing, because the old newsletter-module was something that I introduced while I still worked there – five year ago!¬†The old newsletter-module had several quirks here and there – but most of them was actually solved in the end, and the result was a pretty stable module that could be used for most of the ordinary requirements most customers have. But in Bleau, we often experienced that our customers had requirements that were difficult to fulfill with the old module. For example, one of those requirements was the ability to automatically create a digest with content from the website based on recipients’ personal preferences.

This blogpost is the first in a series concerning the Dynamicweb Email Marketing module. I will try to cover all the details of the module. The first one concerns the administration of recipients.


The old newsletter-module started a trend in Dynamicweb CMS concerning the consolidation of users. Before this module, users were scattered around in different silos in the form of separate modules, but the old newsletter-module consolidated users into the Dynamicweb User Management module. The new Dynamicweb Email Marketing module continues this trend, and it integrates heavily with the User Management module. This means that management of users/recipients is something that is done inside the User Management module, and then you can apply the new Dynamicweb Smart Search to filter the different users into segments that you can send e-mails to.

The consolidation of users is a huge benefit, because that way you get a 360-degree view of all users in the system – which is very beneficial with the addition of the Dynamicweb Online Marketing module.

You can mark all extranet users in the user management module as e-mail recipients

You can mark all extranet users in the user management module as e-mail recipients

You can also create your own folders containing e-mail recipients inside User Management, and every user can become a recipient by just checking the green icon next to the e-mail address. Before, you had to assign each user to a “NewsLetter V3 Recipients” folder.

You can also do the same for a complete user group:

You can allow email communications for a complete user group

You can allow email communications for a complete user group

Much more information about each user – if you want

The old newsletter-module gave you the possibility of adding user-defined fields that could be used to require extra information from the user. But the implementation of this was crappy, and in Bleau we have no customers using it. You had to jump through hoops in order to implement this in the sign-up process, and you really couldn’t use the collected information for anything – other than export it to other systems.

Now that recipients are really consolidated into the User Management module, it suddenly becomes way more easy to collect extra information from users. The User Management-module already contains a lot of useful fields, that you could just let your users fill in when they subscribe to a newsletter, but you can also very easily create new user-defined fields in case you need some special information. We will get back to the benefits of this particular feature in a later blogpost.

It is very easy to add new user-defined fields in Dynamicweb Email Marketing center

It is very easy to add new user-defined fields in Dynamicweb Email Marketing center

Sign-up process

The old newsletter-module required you to create a new paragraph containing the old newsletter-module in order to let users sign-up. The procedure is almost the same in the Email Marketing module, but instead of using a special newsletter-module, you use Dynamicweb Extranet. This module has been modified, so that a much more simple user creation process is available. E.g. instead of requiring that the user provides a password, the module can be configured to automatically assign a new password to users, so that these only need to provide the most basic information.

A more simple user sign-up process has been created

A more simple user sign-up process has been created

The example above – which illustrates the paragraph module-settings – shows how you can create a very simple sign-up process by selecting “Create profile/Manage subscription” and selecting “email_subscribe.html” as a template. As you can see, it is also possible to decide whether or not the user should be automatically created, or if the user should be approved – either by an administrator or by the user himself.

This is also where it is possible to select a more elaborate sign-up form. If you need more information from the user, you can select another template that will contain these fields. And of course, you can also just create your own template – which you probably want in all cases, because the ones delivered in the standard package looks like s**t, and contains HTML, CSS and JavaScript that I would never want in my projects. In fact, I think that this demonstrates a major area of critique of the usual standard modules in Dynamicweb CMS. The primary purpose of creating new modules in Dynamicweb is to create new functionality to paying customers, and therefore developers are sometimes considered as an after-thought.

Adding e-mail consent into templates

Because of the consolidation of users/recipients into the User Management-module, it is very easy to let the user change his status, so that it is allowed to send out e-mails to that particular user. If a user is logged on to the website, you can add the following template tag, that will allow the user to change his status:


Example from the Dynamicweb User Manual:

Adding a template tag to change user e-mail consent

Adding a template tag to change user e-mail consent


Unsubscribe or modify profile
Adding an unsubscribe-feature is just as easy as creating a sign-up form. You just select another template. And each e-mail can also contain a link to unsubscribe the users


All in all, the above mentioned features demonstrate major improvements from the old module. I guess that most of the customers, that I work with, will be happy to make the switch from the old module to the new module. The only negative thing I can find right now is that the templates could be improved by cleaning them up – so this is probably one of the first things I need to do before starting using the module.

More on this subject later on – please leave your comments below.

Using permanent Scrum teams in a digital agency

Do you use fixed teams or do you employ a more flexible approach to your Scrum-teams?

In May 2013 we started implementing Scrum in my company – Bleau. We were at the time in the middle of building a new outsourced development-company, and we figured that Scrum would be able to help us ensure the necessary quality in our development projects. We were several people who had a great deal of experience using Scrum in a previous company, so we knew the benefits of using Scrum in an outsourcing environment.

We decided to reuse the knowledge we had from our previous effort – even though Bleau is a digital agency and our experience was from a software company. We have had to make several modifications to the Scrum-process in order to accommodate for this different setting, but we quickly decided to reuse the concept of permanent cross-functional teams consisting of front end developers, back end developers and Quality Assurance personel. Each team consists of up to five persons.

We haven’t been disappointed. The Scrum-process is working out greatly for us, and we’re able to deliver projects on time and with great quality.

However, there is still one issue that keeps on nagging me, and this is the issue of using permanent teams versus more flexible teams established from project to project. The permanent teams have ensured that it is very easy for us to plan our projects, we have team members who know each other very well and the different processes are running pretty smoothly.

However, it is a bit inflexible. One team is responsible for an entire project – meaning that we get into trouble if one project would potentially be solved better by another combination of developers.

So I’m still pondering about this issue – which approach is better? The permanent team or the flexible teams? As I can see it there are the following benefits of permanent teams:

  • The planning process becomes much more simple – you just establish one backlog per team, and then you can very easily see when the team will be ready to take on new projects
  • The team can become extremely efficient – especially if the team members enjoy working together
  • The team learns pretty quickly and can also adapt quickly to new insights
  • The team will quickly establish clear “roles”
  • Things quickly become more routine

However, there are also potential drawbacks:

  • It is difficult to employ the most relevant people on the projects
  • If one or more team members don’t like working on the team, the complete team will suffer
  • Exchanging new insights between different teams can become more difficult
  • Things can become too much routine

For now, I’m very satisfied with the results we have gained in a very short while, and this is not something that I’m going to change anytime soon. But Scrum is about learning to become better, and this is absolutely an area that has my interest. Does anyone have more experience with this matter?

Trigger HTML5 form validation onblur using jQuery and checkValidity

HTML5 form validation is in my view one of the nicest things in HTML5. It makes it very easy to implement form validation, and you avoid writing your own validator or implementing some custom jQuery-plugin – which improves load time and reduces complexity of the solution.

As you probably know, the HTML5 form validation works by adding different attributes to the input element. The code below will make sure that the user only inserts a number in the range of 1000 to 9999. The user will not be able to submit the form unless the correct number has been inserted.

<input type="text" name="zipcode" placeholder="Insert zip-code" class="zipcode" min="1000" max="9999" maxlength="4" size="4" required="required">

However, this validation is only triggered when the user tries to submit a form. Clicking submit will produce an error message, and nothing will be sent to the server. I had a certain case where I needed to validate each input-field onblur.

In this case, you can use the checkValidity-method in the constraint validation API. (You can read more about this API in the following blogpost: The checkValidity-method can be applied to each input-element and will return true if the value of the input-element is valid. Otherwise, it will return false.

I therefore ended up applying the following small jQuery-snippet in order to add form validation onblur:

$('#wizardvalidator input').blur(function(e) {
	var controlgroup = $(;
	if (! {
	} else {

The code above checks each and every input-element onblur and adds the necessary classes in order to display a validation-state to the user.