Archive

Author Archive

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.

Categories: Dynamicweb CMS Tags: ,

Developing your employees

February 19, 2014 Leave a comment

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.

Categories: Management Tags:

Keep web projects simple

December 29, 2013 Leave a comment

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

November 30, 2013 Leave a comment

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.

Consolidation

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:

<!–@UserManagement:User.EmailAllowed.Input–>

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

Conclusion

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.

Categories: Dynamicweb CMS Tags:

Using permanent Scrum teams in a digital agency

November 23, 2013 Leave a comment

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?

Categories: Scrum Tags: ,

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: http://www.html5rocks.com/en/tutorials/forms/constraintvalidation/). 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 = $(e.target.parentNode);
	if (!e.target.checkValidity()) {
		controlgroup.removeClass('success').addClass('error');
	} else {
		controlgroup.removeClass('error').addClass('success');
	}
});

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.

Categories: Code Tags: , ,

Create a HTML5 canvas element with clickable elements

Canvas with clickable circles
A client asked me to implement a website with different images having clickable circles on top of them. The circles would be placed randomly – and would be used to display additional information about what was going on in that particular place in the image.

Fortunately, the client did not require that users with older browser should be able to view the website. So I was able to use some modern technology in order to make my life a bit easier.

I have never worked with the HTML5 canvas-element before. So I needed to get some hands-on experience with it. I therefore decided to create a proof-of-concept first. You can see this proof-of-concept in the following fiddle: http://jsfiddle.net/Terkildsen/9pgWf/

The following is a quick walk-through of the elements in the code. First, I start off with a canvas element:

  <body>
    <canvas id="myCanvas" width="1420" height="702"></canvas>
  </body>

After that, I create a reference to the canvas-element in my JavaScript – and initialize a circles-array that will hold information about each circle:

var canvas = document.getElementById('myCanvas');
var context = canvas.getContext('2d');
var circles = [];

Then I implement a function to handle the drawing of each circle. The function will accept a reference to the canvas-element (context), the x- and y-position of the circle, the fillcolor, radius, and different other parameters necessary to draw the circle. The circle is drawn by using the context.arc-method – which is documented right here: http://www.html5canvastutorials.com/tutorials/html5-canvas-arcs/

var draw = function (context, x, y, fillcolor, radius, linewidth, strokestyle, fontcolor, textalign, fonttype, filltext) {
    context.beginPath();
    context.arc(x, y, radius, 0, 2 * Math.PI, false);
    context.fillStyle = fillcolor;
    context.fill();
    context.lineWidth = linewidth;
    context.strokeStyle = strokestyle;
    context.stroke();
    
    context.fillStyle = fontcolor;
    context.textAlign = textalign;
    context.font = fonttype;
    
    context.fillText(filltext, x, y);    
};

Now I create an object that will hold the position of each circle – this information is used later on for deciding whether or not the user clicked on the circle

var Circle = function(x, y, radius) {
    this.left = x - radius;
    this.top = y - radius;
    this.right = x + radius;
    this.bottom = y + radius;
};

I then create a drawCircle-method that will call the draw-method – in order to draw the circle – and that will store the position of each new circle.

var drawCircle = function (context, x, y, fillcolor, radius, linewidth, strokestyle, fontcolor, textalign, fonttype, filltext, circles) {
    draw(context, x, y, fillcolor, radius, linewidth, strokestyle, fontcolor, textalign, fonttype, filltext);
    var circle = new Circle(x, y, radius);
    circles.push(circle);  
};

Now I can add my circles – naturally, this would come from a database containing the texts as well as the coordinates of each circle.

drawCircle(context, 300, canvas.height / 2, "green", 40, 5, "#003300", "white", "center", "bold 32px Arial", "1", circles);
drawCircle(context, 600, canvas.height / 3, "blue", 50, 5, "#003300", "white", "center", "bold 32px Arial", "2", circles);

And then, finally, I add a jQuery-method that will bind to the click-event, and decide which circle – if any – the user clicked. Here, I use the previously stored information about each circles’ position to calculate whether or not the user clicked a certain circle. Right now, I just alert some dummy text – but I will add a method to display additional information.

$('#myCanvas').click(function (e) {
    var clickedX = e.pageX - this.offsetLeft;
    var clickedY = e.pageY - this.offsetTop;
    
    for (var i = 0; i < circles.length; i++) {
        if (clickedX < circles[i].right && clickedX > circles[i].left && clickedY > circles[i].top && clickedY < circles[i].bottom) {
            alert ('clicked number ' + (i + 1));
        }
    }
});

That’s it – for a complete working sample please go to http://jsfiddle.net/Terkildsen/9pgWf/

Categories: Code Tags: , ,

CSS performance

Do you ever wonder about the performance of using CSS-reset? Well, until today I didn’t either.

I’m currently in the middle of implementing a new webapp based on AngularJS. We’re implementing extremely complicated swipe-functionality in this webapp, and this presents us with huge performance difficulties – especially on older tablets and smartphones. My old iPad 1 is having a very hard time trying to keep up with the demands.

That’s why I was investigating and debugging performance bottlenecks today.

I used Google Developer Profiler tool to investigate both the JavaScript and the CSS performance on the site. And to my surprise one of the most important performance issues was the usage of a universal CSS-reset matching all elements in the DOM. As you can see in the picture below, the reset uses a lot of processing power. (click on the image in order to view it properly)

CSS_reset_performance

The picture displays the result of a profiling being made of a single swipe. The consequence is that each time a user swipes, the tablet has to do all this rendering over and over again – which makes the screen flicker and gives the end-user a very poor experience. In fact, a single swipe would result in the desktop browser spending as much as 79 ms to render.

The solution to this – of course – is to make the reset more specific. Instead of matching the * selector – match tags. The result of this was that I went from a render time of 79 ms to 20 ms. I know that this is not much – but these measurements were done on my desktop PC with all its processing power. The effect was noticeable when I loaded the site on my iPad 1 – and the end-user will appreciate this simple fix.

Categories: Dynamicweb CMS Tags:

Executing code when all templates have been included – AngularJS

February 21, 2013 Leave a comment

Sometimes, you want to be able to execute code when all the templates have been included in AngularJS using the ng-include attribute. Perhaps, you want to manipulate the inserted HTML…

AngularJS doesn’t provide a method to handle this out of the box, so instead you have to implement it yourself. This is done by utilizing the $includeContentLoaded event, which is fired each time one template has been loaded. Just like the following codesnippet:

scope.$on('$includeContentLoaded', function(event) {
    renderedcount++;
    if (renderedcount == itemmax) {
        // Crappy hack!
        $('.removeparent').unwrap();
        $('.removeparent').removeClass('removeparent');
    }
    console.log('another include was loaded', event.targetScope);
});

Don’t mind the “Crappy hack”-comment…This is just me telling myself, that I should probably refactor this code at some point…*ahem*….

But anyway, you subscribe to the $includeContentLoaded-event, and keep track of all the templates by using a simple counter. When all templates are loaded, you execute the code – which in this instance is jQuery to manipulate the inserted HTML.

It would be nice to have this feature in AngularJS itself – but unfortunately it isn’t. But this way, you can still get what you want…

Categories: Code Tags: , ,

Avoid the empty span-tag when using ng-include in AngularJS

February 21, 2013 1 comment

Inserting HTML-templates via ng-include in AngularJS is a smart way to reuse code in your webapps. That way, you can have code in a separate file or in a separate block of code in the same file, and then insert the block of code whenever you need it.

Normally, you would have a block of code – just like the following:

<script type="text/ng-template" id="tpl1">
    <img src="img/pizza-pic1.jpg" alt="">
    <a href="#" class="title food-and-drink-cat h-50">
        <h3>Pizzasten</h3>
    </a>
</script>

You then insert the block of code in the following way:

<div ng-include="'tpl1'" ng-class="article.class">
</div>

This code will insert the template into the div-element. However, there is one small problem. If you inspect the result in Chrome Developer Tools, you will notice that AngularJS automatically inserts empty spans. Something like the following:

<span class="ng-scope">
</span>

AngularJS inserts this code in order to keep track of the current scope. However, I think it’s a mistake, and sometimes the empty span-tag messes with the layout of the page. Therefore, I investigated why this happens.

First of all, you can safely remove the empty span-tag. AngularJS doesn’t barf at you. Second, removing the empty span-tag is very easy. You just have to remove all spacing between the script-tag and the HTML. Just like so:

<script type="text/ng-template" id="tpl1"><img src="img/pizza-pic1.jpg" alt=""><a href="#" class="title food-and-drink-cat h-50"><h3>Pizzasten</h3></a></script>

This removes the empty span-tag – without consequences for AngularJS. I know that this solution isn’t pretty – I like to have my code formatted nice and pretty – but it works, and this is the important part.

Categories: Code Tags: ,
Follow

Get every new post delivered to your Inbox.

Join 489 other followers