Sunday, 25 October 2009

Silkmoth Launch New Kentico Site

One of the hardest jobs for a web development company is building your own website! Well we've finally got around to completing the new Silkmoth site and no surprises it's a Kentico build.

As you would expect we've incorporated blogging and a host of other Kentico features and because of that I'm going to end this blog here. Please come and see what's going on at Silkmoth and how we're using Kentico.

Carl

Friday, 3 July 2009

Quite a Fiddly Design But Doable in Kentico

We've recently launched a Kentico based site for Axon Garside. Content is a bit sparse but it will grow over the next few weeks.

It's a nice design, a bit fiddly in places and caused us to build more templates than we'd have liked to.

The biggest problem was the different colour schemes for each section of the site. Ideally we'd have added a class to the <body> tag via the template and controlled the colours through the stylesheet. Kentico doesn't seem to allow this (unless you know different, if so please reply) and we had to build a complete template for each colour scheme with very little difference between them. Just one class on a <div>. This obviously has an impact on support - a minor tweak means changing lots of templates.

Ho-hum, we're happy with the outcome and so is the customer.

Wednesday, 17 June 2009

Video Interview Now On Kentico Devnet

My interview with Wayne from Kentico at Internet World is now available for everyone to see. It looks like the hours in make-up paid off!!!

A quick update while I'm on. We're still learning about Kentico and restricting ourselves to small brochure type sites.

We've recently launched www.tyrz.co.uk which is a site for a local mobile tyre specialist. The gang at Tyrz have been through a training programme and seem quite comfortable adding and managing content.

We've got another three similar, if slightly larger sites, that are due to launch in the next week or so but we've already started work on our first Kentico social network (talk about from one extreme to another!). More details when it's closer to launch but it will be targetted at the car-modding community.

Thursday, 30 April 2009

Meeting with Kentico at Internet World London

Yesterday, we made the trip south to London to visit Internet World at Earl's Court. There we met Petr, Petr and Wayne. We had time to chat about what Silkmoth plan to do with Kentico and what Kentico are planning to do with the CMS.

The guys persuaded me to be interviewed on video with Wayne! So look out for that on the Kentico site - hopefully it's not too much of a video nasty!

I was asked about the choice of name for this blog, Kentico Geeko. I think everyone agreed it was a rubbish name!

More details on what I thought of the show can be found on my mainstream blog www.floatingdivs.com.

Thursday, 23 April 2009

How and Why We Chose Kentico

When we decided to replace our ageing CMS, Wirenet, we had three options:

  1. Build our own from scratch using what we've learnt from the building of and building with Wirenet for the last seven years
  2. Adopt an OpenSource solution such as DotNetNuke
  3. Buy in a third party commercial solution such as Kentico

We'd narrowed down the possible third party solutions to DotNetNuke and Kentico quite quickly. Everything we build is based on Microsoft technologies; Windows Server, SQL Server, C# and ASP.Net. Kentico and DotNetNuke were the outstanding candidates that fitted our technical profile, so they were the products we spent most time getting to grips with.

End-user Ease of Use

We've got around 50 customers using our old content management system. This system evolved between 2002 and 2005 but has remained fairly static since. The evolutionary process has meant that Wirenet was exactly what our customers wanted it to be - easy to use.

When we looked at our options we scored them as follows:

Ease of UseScore
Wirenet V290%
Kentico60%
DotNetNuke40%

We gave Wirenet V2 a very high score because it would be built specifically for our customers, whose behaviour we understand very well.

Functionality

In developing our own CMS, we have made conscious decisions to exclude functions where we thought customers would struggle to understand the concept or where we thought developing a new module wouldn't give us a return on our development effort.

A good example is event booking. In seven years only one customer has asked for event booking but wasn't prepared to pay for the full development cost of the module. We didn't build it because didn't think many of our other customers would use it.

Of course, the flip-side of this is that we may have lost business because our CMS didn't include event booking!

Functionality was scored as follows:

FunctionalityScore
Wirenet V240%
Kentico70%
DotNetNuke90%

DotNetNuke scored very well on this. The OpenSource nature of the product has meant that a very large group of users are creating modules and bolt-ons all of the time.

Kentico still scores well because it is feature rich. However, one team of developers can only achieve so much.

Of course there is an issue of quality here. All of the Kentico functions/modules are built in the same way and have the same look and feel and robustness. DotNetNuke on the other hand is a bit hit and miss. Some modules fit in well and others don't. We felt that there is an absence of quality control in the process.

Development

As much as it has to be easy for the end-user to manage their content it also has to be easy for the web developer to put sites together.

When a CMS is easy to develop with, it deskills the process. You don't need a software engineer to build the site, you simply need somebody with HTML and CSS skills. This makes the development process cheaper and more profitable.

One of the core differences between Kentico and DNN is that with Kentico, there is a separation of the front-end website templates from the administration function. With DNN they are tied together.

I appreciate that it's nice to skin the admin area of a website the way you want it, but if like me, you simply forget to add the menu to your templates, then DNN just stops working. I had to do a complete reinstall and try again when I did that!

Development was scored like this:

DevelopmentScore
Wirenet V2N/A
Kentico80%
DotNetNuke40%

So Kentico stands out on this front. I can now recruit HTML/CSS staff to build sites and let my C#/ASP.NET developers get on with something more exciting.

Support

Assuming that we don't need support on our own software, it's a straight fight between DNN and Kentico.

DNN has forums, books and blogs to support the product. There's even paid for support (which we thought was a bit expensive).

Kentico on the other hand has no Dummy's Guide and very few external websites talking about it.

What Kentico do have though, is a commitment to providing email and telephone support. We made a point of trying it out and Wayne, who we spoke to on several occassions, was great. Despite being based in the Czech Republic his English is better than mine. He understood the product and helped us with a number of issues during our evaluation.

Scores for Support

SupportScore
Wirenet V2N/A
Kentico100%
DotNetNuke50%

Cost

The last factor was cost. On the face of it DNN is free (actually I think there is a paid-for version now!) but if you're a commercial organisation building lots of websites for customers then you're going to need support.

The cost of a year's professional support for DNN was surprisingly high and we did wonder if we would need it because the DNN community is so large. Surely we wouldn't come across any problems that haven't already solved?

Kentico cost around US$4,000 when we bought our Social Networking version license. The price is considerably higher now and I can see why. A huge effort has gone into producing version 4.0. I just hope that the price isn't too high as I would like to see the customer base increasing so that stability of the product and indeed Kentico as a business is assured.

The cost of producing version 2 of our own CMS is a great imponderable. Just planning it and costing it all up would cost a big chunk of money.

The Decision

Initially our decision was to build our own. If we did that we could tick all of the boxes that were really important to us and we could limit functionality so that customer support wouldn't become too onerous.

We made that decision and then two months later, after absolutely no progress, we made the decision we should have made in the first place; Kentico

We're still coming to terms with it but as each day goes by the possibilities of what we can achieve and indeed sell to our customers is growing.

Support has continued to be fantastic in both quality of response and timeliness.

We're working on our second site now with the next one likely to be an eCommerce site. We're getting quicker as we understand more but it is a steep learning curve. This I think, is made worse, from the experience of building a CMS for ourselves and us having lots of bad habits.



If you're at Internet World in London next week, Kentico will be there, as will I!

Tuesday, 24 March 2009

Using <p> instead of <br/> in FCK

Out of the box, Kentico is configured to use line-breaks instead of paragraphs in the FCKeditor. It's a simple thing to change. Find the fckconfig.js file and change this:

FCKConfig.EnterMode = 'br' ;  // p | div | br
FCKConfig.ShiftEnterMode = 'p' ; // p | div | br

to this:

FCKConfig.EnterMode = 'p' ;  // p | div | br
FCKConfig.ShiftEnterMode = 'br' ; // p | div | br

Tuesday, 17 March 2009

Secure Document Access for Axis

One of our customers, Axis Corporate Solutions, provide an innovative (well innovative for an accountancy firm) function on their website. They allow their customers to login to the site and access all of the documents that have been created for them.

So each customer has their own login and their own private area within the website where they can view these documents.

This presented us with our first Kentico challenge. Here's what we did:

  1. Add a login form to the Master page. This was set to redirect to Login.aspx when a customer successfully logs in.
  2. In the Page_Load event for the login page we firstly check the ViewMode. We only want the redirection to happen on the live site otherwise we wouldn't be able to administer the login page.
  3. Then we get the current user context and find out if they are an editor. If they're an editor we send them off to the customer index page where they can choose who they want to have a look at.
  4. If they're not an editor then they're a customer. What we do for them is to check all of the documents in the Customer branch of the sitemap and see if they have read access. If we find one that has read access then we redirect them to it.

We like this approach because we don't need to add anything to the database to tie customers to their sections of the website. The code is below

  protected void Page_Load(object sender, EventArgs e)
  {
    if (!IsPostBack)
    {
      // Send the user off in the right direction if we're
      // in LiveSite mode.  Don't want to do this in edit mode.
      //
      if (CMSContext.ViewMode == CMS.PortalEngine.ViewModeEnum.LiveSite)
      {
        CurrentUserInfo user = CMSContext.CurrentUser;

        if (user.IsEditor)
          Response.Redirect("~/Customers.aspx");
        else
        {
          // It's a customer, check permissions on all sub-pages of "/Customer"
          //
          DataSet ds = TreeHelper.SelectNodes("/Customers/%", false, "Axis.Customer");

          foreach (DataRow dr in ds.Tables[0].Rows)
          {
            int docId = (int) dr["DocumentID"];
            CMS.TreeEngine.TreeNode node = TreeHelper.SelectSingleDocument(docId);

            if (CMS.TreeEngine.AuthorizationResultEnum.Allowed ==
                  user.IsAuthorizedPerDocument(node, NodePermissionsEnum.Read))
            {
              // User has access to this page - send them there...
              //
              Response.Redirect(CMSContext.GetUrl(node.NodeAliasPath));
            }
          }
        }
      }
    }

Monday, 16 March 2009

Why a CMS?

Just about every professional website is built on top of a Content Management System. Certainly when we go to see prospective customers it is their expectation that they will have full control over the content of their websites once it has been delivered. In reality only a fraction of them actually update their content, but they do expect to be able to do it!

For six years now we've been building websites on our own content management system Wirenet. Wirenet is built using classic ASP and uses a Microsoft SQL Server database. It's done us proud and has delivered billions of web pages since its launch with the Linder Myers website back in 2002.

However, all good things must come to an end and Wirenet is no exception. In the last couple of years we've been seeing a significant increase our clients' expectations of the web. Many want advanced functionality and more and more are moving to ecommerce. We found that building this functionality was a lot easier with a more up to date platform, ASP.NET. However, making the two technologies, Wirenet and .NET work together was a bit yukky (technical term that!).

So our plan was to rewrite Wirenet with ASP.NET. The problem was finding the time! After a year of not doing it we decided to have a look for other web platforms we could use instead. We had a go with many CMSs but narrowed down our shortlist to DotNetNuke and Kentico.

More details on how we chose Kentico next time

About This Blog

This blog is all about my/our experiences with the Kentico CMS. When I say "our" I mean Silkmoth. If you don't know what I mean when I say CMS then you're in the wrong place.

About Me

My photo
I'm most often described as a Grumpy Old Bugger.

Followers