Webparts vs Widgets vs Static HTML

Jay McCormack asked on January 28, 2015 04:31

Screen Shot

I need some advice. After going through a few different projects using different approaches I'm interested to see how you might approach something like the item in the snippet above.

The green element with the word 'Policy' would appear on the home page of a website we're building and would also be a link to some subsection of the site.

The challenge we've faced is getting a good balance between developing this quickly and making it easy for people to manage/edit it.

I can think of potentially 3 different ways to achieve this:

  1. A custom web part where the text and the link are properties on the part.
  2. A custom widget where the text and the link are properties on the widget.
  3. A repeater web part that points to a single content record as the source.
  4. A static HTML part that just hard codes in the HTML to make it work
  5. A HTML text part that has the content added into the page view

There's no doubt other ways to achieve this. Here's the challenges though:

  • Widgets are a good solution but render badly in the editor as just a cog.
  • Repeaters are easy to implement but require changes to the page template and are difficult for the CMS users to manage/update
  • Anything that touches the template or page type means that those changes need to be staged from dev to testing to production

How would you typically approach this so that it's easy to implement and yet can be maintained by CMS users AND will easily move through staging from a to b to c.

Hope that all makes sense.


Correct Answer

Brenden Kehren answered on January 28, 2015 06:37

Awesome question!

Personally I ALWAYS think about my client's experience. You know the old saying, "A happy wife is a happy life!" That's very true with clients as well. Here are my thoughts on your list of 5 approaches.

1. This is an OK solution but the second to last option I'd use (if at all). Reason being is you have to write custom code. You have to worry about the code being "upgradable" with new versions. You still have to register this webpart and stage the files and object from dev to live. Don't get me wrong, I'm not afraid to write custom code but if you don't need to, why muddy the waters. I've implemented Kentico sites with other CMSs, CRMs, AS400, web services, etc. so it's not that I don't want to write code, I'm thinking why should I when Kentico has already done an awesome job at it!

2. This is an OK solution as well but the last option I'd use (if at all) because a widget is based on a webpart, so in all actuality, you need to create #1 for #2 to work, so if you're not going to do #1, you will never do #2. Right there is enough for me to say no.

3. This is my most favorite approach and most recommended by Kentico and any developer/partner who knows what they are doing with Kentico. Kentico is built around document/page types. If you look at how the content tree and navigation are setup you'll see this approach is not much different than using a static or editable text webpart on a page. Reason I say this is because a "page" (cms.menuitem) is a page type and has essentially the same query as would a custom page type.

The views used in the repeaters select from node, document and page type information, it doesn't matter if the page type is custom or not or if there are static or editable text webparts on a page template. The static and editable text values are stored at the document level but the query still joins the page type, because it has to.

Custom page types allow you to customize your clients experience by giving them one form to enter data on (or multiple different views if you want) and using transformations, display the same data differently all over the site. You (designers and developers) also have control over the rendered HTML and don't need to leave your client try to decide what the site will look like. If that was the case, all sites would look just like the CKEditor styles show...nice brand huh?

By using a custom page type you can also use built-in form controls to gently persuade editors to select or enter data in the format you need or desire. For example, giving the user an image field. You could give them a simple textbox to enter an image url OR you could give them a URL selector OR even better yet, a direct file uploader. This gives them the immediate satisfaction to see the image is uploaded and "it works"!

Creating custom page types to work with templates and shared layouts is the most powerful approach you can use to make your Kentico site. Especially if you know how to use Content Inheritance within your templates. Always start with your wireframes, those are your page layouts. Next incorporate your layouts into templates. The templates use a layout and tell the page where to put the content (webparts and zones). Then if you want to use personalization use widgets on a template. Next add a new page and use your predefined template and start adding content in the content tree. Page sliders, content blocks, news articles, etc. Use the repeater or whatever webpart you need/want to display them.

Using custom page types, you get specific a lot more SEO abilities like page metadata, tagging, categories, friendly URLs, aliases, etc. You don't get this with static or editable text.

4. Assuming static and editable text here for 4 and 5. I perform maintenance on a lot of Kentico sites and many of the early ones are setup with editable and static text webparts on say 3 or 5 templates. This does work and you can get a site out very quick with this but think of the client now when they go to post a new news article or a blog post. Maybe the original developer used the blog template and the blog page type but on the other 35 pages that have latest articles or blog posts, they are all static text. Now not only does the blog editor enter their new post, they have to update 35 other pages with static text.

Don't get me wrong, the above is a pretty extreme example (but it exists, I've fixed many) and it does work BUT in the end your client will be very unhappy with you after they make the first few edits and you lose their business. OR you gain more business (yes!) to fix what you implemented wrong in the first place, in which, you should feel horrible that you cheated your client but if you have no morals or values, no big deal...right?

5. See answer #4

#4 and 5 are useful and every now and then I use them simply for fillers if the client is unsure of what the data structure might be.

Now on to your other points:

Cost vs. time:
You get what you pay for. If the client has a lopsided project management triangle and has no budget then so be it, you need to find a way to work with that. If that means not taking the job (no matter how big the name is), you have to remember your name (personal and business) and reputation is on the line. If you deliver an inferior product and your client is unhappy, others will find out, just give it time...

Now on the flip side, if you are honest up front and state "hey here is what you get for this time, but if we had a bit more time to use all the features of Kentico, and you'd get THIS! WOW!", I can guarantee the majority of the clients will take a deep look into their budget for that extra time because it makes their life easier and that's why they spent the money on a Kentico license.

If a client wants me to deliver an inferior product, I won't take the business. Not because I don't agree with them or won't do the work or couldn't use the money to feed my 4 kids. It's about my morals and beliefs as a person and a business professional. It's not about a quick buck and a client, its about earning my client's trust and repeat business.

Promoting changes:
If a client has an environment where they can afford a dev or staging environment then, there is no question, do it right the first time. Kentico offers content staging, which allows you to bidirectionally sync changes between environments. Yes this is only available with Ultimate and EMS licenses but its a feature and if the client is looking for this, then it's worth it. You can also export and import changes manually. Another option would be to manually recreate the content or object.

Typically when a client has 2 or more environments, I always do server coding or major template changes on dev just to be safe. Any content related items, adding/removing pages, updating pages, new forms, etc. I'll do those on the live site and implement workflow. This allows for the "simple" changes to be done immediately while the other more complex items (new templates or layouts and doc types) can be tested on the dev site without breaking anything. Then when you are finished creating those objects, export them and import them into live. You can then start adding your content and it displays on your page.

I base my answer off of the majority of the sites I build. I ALWAYS use Portal development mode with custom webparts and modules (if needed). I never use straight ASPX or MVC simply because they do not allow my clients to utilize the features of the Kentico. Yes they are powerful and you can develop quickly them, but if you took a day or two and learned about how to develop in Portal mode, you'd see the same thing I do, no need for ASPX or MVC (IMHO, they're only there for developers who don't want to learn).

Hopefully my lengthy answer helps out a bit. I hope others chime in as well because this is a very valid topic and discus it all the time with other developers.

Best of luck!

3 votesVote for this answer Unmark Correct answer

Recent Answers

Virgil Carroll answered on January 28, 2015 05:33


This is actually. Really good question that we face all the times. My opinion is always to go raw HTML when you can...with caveats. You will always get the best page performance.

The caveats would be: - how often does the content con the dropdown change? If a lot then I would use a more dynamic component. If occasionally, then it kind of goes to how much your editors can do.

  • if its going to change a lot, I would go the repeater route and turn it into a widget so your editors have to manage the least amount of properties...tie it to a custom table or roll up links below.

I realize there are probably many devs here that would go code, code, code but I have been doing web over 16 years and nothing performs better than good old HTML, so when I can I default back to it.

Hope this helps.

1 votesVote for this answer Mark as a Correct answer

Roman Hutnyk answered on January 28, 2015 16:10

A lot of useful information is here. I have nothing to add which approach is good and what is bad - to my mind it always depends on particular situation.

I'd like to mention Link web part here as another alternative in this particular case.

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on January 28, 2015 16:35

Good discussion point Virgil. You are correct in the speed aspect but since the html is being stored in the database is it really going to be that much faster? We're talking about an asp.net database driven website, not a static HTML website. Even if the kentico website was using straight aspx development mode, there are still queries to get the webpart content out of the database. The only way it could help improve speed would be if the physical aspx template had the html hard coded on it and that would only be a minor improvement. If we remove the speed factor (we'll assume everyone wants a lighting fast website), look at what's left, most likely an upset client because they have to update code that is possibly located in the file system somewhere and is not dynamic.

Speed is something every site needs to have and Kentico offers some great features to improve speed out of the box by configuring some settings. IMHO, static HTML on an aspx page or page templates full of static or editable html webparts is not where you are going to gain speed or return business.

1 votesVote for this answer Mark as a Correct answer

Virgil Carroll answered on January 28, 2015 22:29


Don't really disagree with you except when the content actually renders on the page raw HTML has no additional processing, no transformation code, no resolving of dynamic fields, macros, etc... so yes I would say it renders faster because of that. I agree Kentico has some great features for performance enhancemen, but HTML will always perform better, hence all my caveats above. If its something that does not change often, it can still be a smart move.

On the other side, in high availability, high performance systems (say such as needing to run in locations all throughout the world with varying bandwidth) I have written systems that just render the raw HTML and get it from the local file system. Using dynamic processes in more of a windows service format to dynamically create static content.

Obviously if the info changes regularly I would not recommend the above method at all.

Tx, Virgil

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on January 29, 2015 00:22

Virgil, where are you talking about placing the static HTML? In a static or editable text webpart? Webpart layout? Page layout? Page template? ASPX template? Where you place it will make a difference and will do as you mention (speed things up). I take that approach from time to time although making a practice of it simply for performance reasons has many more drawbacks than it does benefits.

Take for instance having some static footer text that is not navigation related but has 2-3 sentences in it that didn't change when you upgraded the site last time and hasn't updated again on this site 7 years later. When I first started using Kentico I would have placed that in a page template or layout within the the Kentico UI. Now, I simply put an editable text webpart on the page template and set the caching level as needed so ultimately has the same if not better effect than if it were to be placed in the template or layout.

We can talk technical details all day long and I'm all about speed, I'm trying to state we can't always look at speed especially when a client spent money on Kentico to have a website that can be easily updated. So we develop in Kentico differently, no big deal and I'm not stating my way is the best, most efficient or makes my sites run the fastest, I'm saying my clients are very happy with what they are delivered so that must mean something. :)

0 votesVote for this answer Mark as a Correct answer

Jay McCormack answered on January 29, 2015 00:37

@Roman - had forgotten about the link web part. This seems a little more elegant in this case I think.

1 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.