Disqus

Properly resizing Disqus thread in an iframe

I had a use case where I needed to insert Disqus-threads into an iframe. Which should’ve been pretty easy.

The problem, however, is that the height of the Disqus-thread is dynamic which means that you cannot set the height beforehand. You need to set the height of the iframe when everything in the Disqus-thread is loaded. After a lot of searching I figured out the following solution for the problem.

Disqus pushes the events called “onReady” and “onNewComment” and you can use these events in the following way to get the height:

    <script type="text/javascript">
        /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
        var disqus_shortname = 'SHORTNAME'; // required: replace example with your forum shortname

        /* * * DON'T EDIT BELOW THIS LINE * * */
        (function () {
            var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
            dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
        })();

        function disqus_config() {
            this.callbacks.onReady = [function () {
                var newsId = getParameterByName('newsId');
                setTimeout(function() {
                    var frameHeight = $(document).height();
                    $('#disqus_iframe_' + newsId, top.document).attr("height", frameHeight);
                }, 2000);
            }];
            this.callbacks.onNewComment = [function () {
                var newsId = getParameterByName('newsId');
                var frameHeight = $(document).height();
                $('#disqus_iframe_' + newsId, top.document).attr("height", frameHeight);
            }];
        }

        function getParameterByName(name) {
            name = name.replace(/[\[]/, "\\[").replace(/[\]]/, "\\]");
            var regex = new RegExp("[\\?&]" + name + "=([^&#]*)"),
                results = regex.exec(location.search);
            return results == null ? "" : decodeURIComponent(results[1].replace(/\+/g, " "));
        }
    </script>

In the code above I execute code onReady and onNewComment. I grab the height of the document and then set the iframe height accordingly. Please notice, that it is not enough to just listen to the onReady-event as the complete list of comments is not loaded when this event is fired. Instead, you will have to set up a timer function and wait a couple of seconds in order to let all comments load properly – and then you can get the proper height. Not an elegant solution, but it works.

Remember to check “Include paragraph items” when upgrading from Dynamicweb 8.2 to 8.4

When updating a Dynamicweb solution, you need to keep an eye on all the important notes provided by Dynamicweb Software. However, I encountered this undocumented feature today when I was updating a Dynamicweb-solution from version 8.2.1 to 8.4.10. All of a sudden all items disappeared.

I investigated the release notes, and made sure to verify all item settings in management settings – to no avail. The solution was to check the “Include paragraph items” on each paragraph containing the itempublisher-module (sigh!).

Just like this:

Include_paragraph_items

Styling a group of checkboxes as a dropdown via CSS and JavaScript

The following demonstrates how to create a dropdown list based on a list of checkbox elements. You can view a complete example of how this works at the following fiddle: http://jsfiddle.net/Terkildsen/mTSLa/

In the following I will walk you through the code.

First, I start by creating the HTML:

    <div class="dropdown">
        Choose city
        <ul class="dropdown-list">
            <li>
                <label>
                    <input type="checkbox" value="Vejle" name="city" />Vejle</label></li>
            <li>
                <label>
                    <input type="checkbox" value="Horsens" name="city" />Horsens</label></li>
            <li>
                <label>
                    <input type="checkbox" value="Kolding" name="city" />Kolding</label></li>
            <li>
                <label>
                    <input type="checkbox" value="Fredericia" name="city" />Fredericia</label></li>
        </ul>
    </div>

There’s not much to say about the HTML above. I use a “dropdown” div to contain the entire dropdown – including the default text that is displayed when the checkbox list is hidden. I then assign a “dropdown-list” class to the list of checkboxes.

Then, I start styling the dropdown:

.dropdown {
    width: 200px;
    border: 1px solid silver;
    cursor: pointer; /* use correct mouse pointer when hovering over the dropdown */
    padding: 10px;
    position: relative;
    margin: 0 auto;
    -webkit-touch-callout: none;
    -webkit-user-select: none;
    -khtml-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    user-select: none;
}

In the CSS above I start by styling the entire dropdown. I provide the dropdown with a width of 200px, some padding and a border to make the dropdown resemble a normal select-list.

Notice that the usage of the “user-select: none;” prevents the user from accidentally highlighting the text in the dropdown.

/* Display CSS arrow to the right of the dropdown text */
.dropdown:after {
    content:'';
    height: 0;
    position: absolute;
    width: 0;
    border: 6px solid transparent;
    border-top-color: #000;
    top: 50%;
    right: 10px;
    margin-top: -3px;
}

Instead of inserting an image to display an arrow in order to indicate that this dropdown can be clicked on, I use a small CSS-trick that will display an arrow using a border-property. You can read more about how this is done in the following blogpost: http://pterkildsen.com/2012/09/16/creating-arrows-using-css/

/* Reverse the CSS arrow when the dropdown is active */
.dropdown.is-active:after {
    border-bottom-color: #000;
    border-top-color: #fff;
    margin-top: -9px;
}

When the user activates the dropdown, the CSS above reverses the direction of the CSS-arrow. It does this by applying the white background-color to the “border-top-color”-property so that this part of the border is hidden, and then displays the bottom part of the border by assigning a black color to the “border-bottom-color”-property.

.dropdown-list {
    list-style: none;
    margin: 0;
    padding: 0;
    position: absolute;
    top: 100%; /* align the dropdown right below the dropdown text */
    border: inherit;
    border-top: none;
    left: -1px; /* align the dropdown to the left */
    right: -1px; /* align the dropdown to the right */
    opacity: 0; /* hide the dropdown */
    -webkit-transition: opacity 0.4s ease-in-out;
    -moz-transition: opacity 0.4s ease-in-out;
    -o-transition: opacity 0.4s ease-in-out;
    -ms-transition: opacity 0.4s ease-in-out;
    transition: opacity 0.4s ease-in-out;
    pointer-events: none; /* avoid mouse click events inside the dropdown */
}

I then style the list of checkboxes. There are a couple of important issues here. First of all, I use the “opacity”-property to hide and display the checkbox-list. And secondly, I use the “pointer-events: none” to prevent click events from happening in the checkbox-list – which would accidentally hide it.

.is-active .dropdown-list {
    opacity: 1; /* display the dropdown */
    pointer-events: auto; /* make sure that the user still can select checkboxes */
}

The is-active class is applied to the checkbox-list whenever the user clicks on the “dropdown-selector”. This class displays the checkbox-list by setting the “opacity”-property to 1 and it also makes sure that the user still can select the checkboxes by setting “pointer-events: auto;”

.dropdown-list li label {
    display: block;
    border-bottom: 1px solid silver;
    padding: 10px;
    -webkit-transition: all 0.2s ease-out;
    -moz-transition: all 0.2s ease-out;
    -o-transition: all 0.2s ease-out;
    -ms-transition: all 0.2s ease-out;
    transition: all 0.2s ease-out;
}

.dropdown-list li label:hover {
    background-color: #c41230;
    color: white;
}

And then finally, I just add some finishing touches to the labels inside the checkbox-list.

In order for this to work, I add a couple of lines of jQuery:

         $(function () {
            $(".dropdown").click(function () {
                $(this).toggleClass("is-active");
            });

            $(".dropdown ul").click(function (e) {
                e.stopPropagation();
            });
        });

The code above detects the click event on the “dropdown”-div – which will toggle the “is-active” class. It also captures the click-event on the list of checkboxes in order to make sure that this doesn’t accidentally close the dropdown.

This code has been tested in Internet Explorer 9+, the latest version of Mozilla Firefox and Google Chrome. I have also tested it on iPhone and iPad. Seems to be working just fine. However, please notice that I’ve had some issues with jsfiddle and Internet Explorer. The code works fine without jsfiddle, though.

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:

Base.ChkBoolean(GetGlobalValue("Global:Device.IsTablet"))
Base.ChkBoolean(GetGlobalValue("Global:Device.IsMobile"))
Base.ChkBoolean(GetGlobalValue("Global:Device.IsDesktop"))

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:

Global:Paragraph.Content([ID])

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"]);
    }
    @RenderParagraphContent(ContactInfoParagraphID)
</div>

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.

Snippet

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

Usage

$scope.scrollTo( ".level2");
responsive-web-design

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 VB.net 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, ASP.net 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.