Basic: The community version

A little while ago, I created a theme called “Basic” for corporate-ish websites and I’ve been getting requests for a community version; basically a version that would accomodate a blog/forum. I decided to reuse 90% – 95% of the original backend JavaScript to the discussion forum mockup (which I’ve renamed “Road”) including a lot of similar functionality. Except this time, I’m going for a more “component” oriented layout that I can easily turn into tabs. I created a simple tab plugin in jQuery to turn page elements into tabs with minimal overhead and I’m reusing a slightly modified version of the code formatting plugin in the topic page example .

Community index


Community tag browsing


Most of the changes really went to the topic view page. I made some changes to the code format snippet and moved the user info and avatar away to the side for clarity. The darker colors were partly inspired by the Sublime text editor (thanks to Shannon for mentioning it) as I found it easier to read large blocks of code on a darker background although I’m still not doing any syntax highlighting.

Forum topic view


Haven’t change much of the backend code of the add topic form, but I have changed the styling and streamlined things a bit.

Reworded instructions


Autocomplete with jQuery and MVC

This is just a prelude to a complete spellcheck addon to the discussion forum. I figured I’d start with basic autocomplete first that ties into the wordlist.

All spellcheckers essentially refer to a global wordlist in the specified language and any words that don’t belong, get flagged.

The hardest part of this turned out to be finding a decent wordlist. I was actually surprised at the delicate balance between finding a “good enough” list and one that’s “too good”. Too good? Yes, apparently a list that has too many words will mean you will get a lot of misses where an apparent misspelling turned out to be an obscure word… and you didn’t mean to use obscure words.

The final list I settled on has a word count of 125,346 and was from the Ispell project which also has common acronyms. Note: This is not the same as Iespell (written ieSpell), although if you Google, “Ispell”, you’ll get “ieSpell as the first result. Ispell lists are available for download at the Kevin’s Wordlist page. I have also combined the 4 main english lists into one file (MS Word). WordPress, strangely, won’t allow plain text files to be uploaded, but allows richtext documents. Email me if you want the plaintext version.

I started with a simple DB table to store all the entries. Since I may also be adding more languages, I also have a WordLang field which can be something small like “en”, “de”, “fr” etc…

Wordentries table


I then created an MVC app and loaded each of the wordlist files into the db using a simple function (this can take a while depending on filesize):

public List GetWords(string p) {
	var query = from line in File.ReadAllLines(p)
			select new Wordentry
				WordText = NormalizeString(line),
				WordLowercase = NormalizeString(line).ToLower(),
				WordLang = "en"
	return query.ToList();


After feeding it a HostingEnvironment.MapPath to the filename, I can use this to load all entries into the list and call a db.Wordentries.InsertAllOnSubmition the result. NormalizeString is another helper function which I will list below.

I’m using a Spellword model instead of directly using the Wordentry object since I may want to extend the returned result in the future and changing the columns in the DB wouldn’t be practical.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Spellcheck.Models
	public class Spellword
		public int Id { get; set; }
		public string Spelling { get; set; }
		public string Lowercase { get; set; }
		public string Lang { get; set; }


And we’re using a SpellRepository class so we’ll keep the controllers free of too much data access stuff.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.IO;
using System.Text;
using System.Globalization;

namespace Spellcheck.Models
	public class SpellRepository
		// DataContext global
		private readonly CMDataContext db;

		public SpellRepository(CMDataContext _db)
			db = _db;

		/// <summary>
		/// Counts the total number of word entries
		/// </summary>
		/// <returns>Wordcount int</returns>
		public int GetCount()
			return (from w in db.Wordentries
			 select w.WordText).Count();

		/// <summary>
		/// Searches a given word or word fragment
		/// </summary>
		/// <param name="word">Search word/fragment</param>
		/// <param name="word">Number of returned results</param>
		/// <param name="word">Language to search. Defaults to 10</param>
		/// <param name="word">Search lowercase field only</param>
		/// <returns>List of spellwords</returns>
		public List<Spellword> GetWords(string word, int limit = 10,
			string lang = "en", bool lower = true)
			word = (lower) ?
				NormalizeString(word.ToLower()) :

			var query = from w in db.Wordentries
						select w;

			// Get only unique entries in case we have
			// duplicates in the db (Edited from an earlier "GroupBy")
			query = query.Distinct().OrderBy(w => w.WordLowercase);

			// If a language code was specified
			if (!string.IsNullOrEmpty(lang))
				query = query.Where(w=>w.WordLang == lang);

			// Lowercase?
			query = (lower) ?
				query.Where(w => w.WordLowercase.StartsWith(word)) :
				query.Where(w => w.WordText.StartsWith(word));

			// Order alphabetically
			query = query.OrderBy(w => w.WordLowercase);

			return (from w in query
					select new Spellword
						Id = w.WordId,
						Spelling = w.WordText,
						Lowercase = w.WordLowercase,
						Lang = w.WordLang
		/// <summary> 
		/// Inserts a new list of words into the spellcheck library
		/// </summary>
		public void SaveWords(List Words)
			var query = Words.GroupBy(w => w.Spelling)
				.Select(w => w.First())
				.OrderBy(w => w.Spelling).ToList();

			List Entries = (from w in query
									   orderby w.Spelling ascending
									   select new Wordentry
										   WordText = w.Spelling,
										   WordLowercase = w.Lowercase,
										   WordLang = w.Lang


		/// <summary> 
		/// Helper function normalizes a given word to the Unicode equivalent
		/// </summary>
		/// <param name="txt">Raw word</param>
		/// <returns>Normalized word</returns>
		private static string NormalizeString(string txt)
			if (!String.IsNullOrEmpty(txt))
				txt = txt.Normalize(NormalizationForm.FormD);

			StringBuilder sb = new StringBuilder();

					c => CharUnicodeInfo.GetUnicodeCategory(c)
					!= UnicodeCategory.NonSpacingMark).ToArray()

			return sb.ToString().Normalize(NormalizationForm.FormD);

To use this, we’ll just add a JsonResult action to our controller. I just created a Suggestions action in the default Home controller since this is just an example.

public JsonResult Suggestions(string word, int limit = 10, string lang="en")
	List Words = new List();
	if (!string.IsNullOrEmpty(word))
		using (CMDataContext db = new CMDataContext())
			SpellRepository repository = new SpellRepository(db);
			// 10 results is usually enough
			Words = repository.GetWords(word, limit, lang);
	// Need to use AllowGet or else, we'll need use POST
	return Json(Words, JsonRequestBehavior.AllowGet);


… And that pretty much covers the backend for now.

To test out to see if the word suggestion works, we’ll do one autocomplete textbox. Just add the jQuery and jQuery UI script files and include the jQuery UI CSS to your layout first and add this to the default view :

<script type="text/javascript">
	$(function () {
		var searchtext = $("#search");
			source: function (request, response) {
					url: "/Home/Suggestions", // Or your controller
					dataType: "json",
					data: { word: request.term },
					success: function (data) {
						// Returned data follows the Spellword model
						response($.map(data, function (item) {
							return {
								id: item.Id,
								label: item.Spelling,
								value: item.Lowercase
			minlength: 3
<form action="/" method="post">
<input id="search" type="text" name="search" />


Fun fact : Total misspellings as I was writing this (excluding Ispell/ieSpell names and code) before running spellcheck = 12.

Yeah, I really can’t spell.

Building a jQuery UI Dashboard

Sometimes you have an existing website or template that needs to function as a dashboard. The only solution then is to create drop-in widget functionality without necessarily modifying the HTML. This is a bit of an update to a much older post

The good news is that if the layout is by and large uncluttered and follows a predictable set of elements (key issue), it’s fairly straightforward to give a layout dashboard functionality without actually touching the HTML structure. jQuery and jQuery UI are perfect for this.

The tricky bit is adding any additional elements for control while handling each segment of content as a widget. In this case, every “widget” can be any element that has the CSS class column applied to it which means we can use the existing <h5> title element as the header for it.

Take as an example, my Simply theme which has no “widget-like” functionality whatsoever and the only JavaScript is Modernizr for backwards compatibility since it was recently rewritten in HTML5. But because all the content elements are predictable (there are sections and one level of nested sections that act as columns), it can be turned into a dashboard without touching the rest of the HTML.

You can take a look at a running demo of it and see below for an explanation of what’s going on.

A running demo of "Simply" turned into a dashboard

For this example, I needed the dashboard widgets to be able to be moved around on each row, have the title, content and the article icon changed and of course be able to close them. Naturally, this is only a client-side example. The final version would need to post these changes server-side for saving.

The Procedure

We can first start by adding the jQuery UI theme CSS file right above the original stylesheet. I’m using a customized version of the Smoothness theme. Just a few tweaks to make it match mine.

<link rel="stylesheet" type="text/css" href="themes/jQueryUI/ui-style.css" id="ui-theme" />
<link rel="stylesheet" type="text/css" href="themes/Simply/style.css" id="theme" />

After that we can add the jQuery and jQuery UI libraries to the template. In my project, there was also a need to add a wysiwyg and I had to use their propietary one, but for this example, I can simply use TinyMCE.

For this example, I’m going to put all the scripts into a folder called /lib. This is also where I’ll extract TinyMCE (the jQuery plugin version).

Modernizr, very usefully, can load other scripts by URL, so we can simply do the following right after adding its JS own file :

<script type="text/javascript" src="lib/modernizr.custom.js"></script>
<script type="text/javascript">
		load: ""
	}, {
		load: ""
	}, {
		load: "lib/tiny_mce/jquery.tinymce.js"
	}, {
		load: "lib/dash.js"

And that’s all we need to do on the template itself. That last file being called, “dash.js” in the /lib folder is where we’ll put everything else.


I’m going to start by adding some custom CSS to this file rather than cluttering up the head section of the template. These are just a few added classes to make the content more presentable.

All this will be added inside the jQuery $(fuction() { }); section.

$('head').append('<style type="text/css">' +
	'.icon { width:75px; height:75px; }' +
	'.ticon { float:left; margin: .3em .5em; width:25px; height:25px; box-shadow:1px 1px 1px #aaa; }' +
	'.ui-dialog { text-align:left; }'+
	'.ui-dialog input[type="text"], .ui-dialog textarea { display:block; width:90%; }' +

Next, since we’re working with TinyMCE, we’ll store those settings in a variable.

var tinySettings = {
	script_url : 'lib/tiny_mce/tiny_mce.js',
	plugins: "inlinepopups",
	theme: "advanced",
	theme_advanced_buttons1 : "bold,italic,underline,strikethrough," +
		"separator,cut,copy,paste,separator,bullist,numlist," +
	theme_advanced_buttons2 : "",
	theme_advanced_buttons3 : "",
	theme_advanced_toolbar_location : "top",
	theme_advanced_toolbar_align : "left",
	theme_advanced_statusbar_location : "bottom",
	width: "100%",
	height: 250,
	content_css : "content.css",

You’ll notice the last line refers to a “content.css” file. This basically styles the wysiwyg content as it’s being edited. In my case, this is all it contained…

body {
	font: normal 90% Sans-serif,tahoma,verdana;
	color: #575757;

p {


Dashboards frequently use dialogs when making changes, presenting confirmations etc… In this case, I just created two dialogs for editing content and to confirm when removing the widget…

function initDialogs() {
	// Close widget dialog
	$('article').append('<div id="dialog-confirm-close-widget" title="Close widget" style="display:none;">' +
		'<span class="ui-icon ui-icon-alert" style="float:left;"></span>' +
		'You are about to delete this widget. Are you sure?</div>');

	// Config widget dialog
	$('article').append('<div id="dialog-config-widget" title="Modify" style="display:none;">' +
		'<form><fieldset><legend>Change widget content</legend>' +
		'<p><label>Title <input type="text" id="widget-title-text" /></label></p>'+
		'<p><label>Content <textarea rows="5" cols="50" id="widget-content-text">Some test content</textarea></label></p>'+
		'<p id="icon-field"><label>Icon URL <span>Will be resized to 75x75 pixels</span><input type="text" id="widget-icon-text" /></label></p>'+

	// Create and destroy these dialogs to hide them

That textarea will be replaced with TinyMCE later.

3 Little Helpers

Often overlooked, helpers can save a lot of time and help unclutter your JS quite a bit.

The following three check for null or empty strings, initializes and applies TinyMCE to an element with the given settings and removes the wysiwyg after sending the changes back to the textarea… in that order.

function notEmpty(t) {
	if(t) {
		if($.trim(t) != "")
			return true;
	return false

function initTiny(t, s) {

function closeTiny(t) {
	var e = t.attr('id');
	tinyMCE.execCommand('mceRemoveControl', false, e);

Widget controls

In jQuery UI, there are ui-icons that we can use here without having to invest extra time to create our own. This also means we can apply our controls to these icons by using something like the “title” or “alt” attribute as the command string. In this case, I opted to use the “title” attribute since I’ll be using these icons in <span> tags.

function setControls(ui) {
	ui = (ui)? ui : $('.ui-icon'); {
		var b = $(this);
		var p = b.parentsUntil('.column').parent();
		var i = p.children('img[alt="icon"]:first').eq(0);

		var h = p.children('.ui-widget-header h5:first').eq(0);

		// Control functionality
		switch(b.attr('title').toLowerCase()) {
			case 'config':
				widgetConfig(b, p);

			case 'toggle':
				widgetToggle(b, p, i);

			case 'close':
				widgetClose(b, p);

Note, the three widget functions that will “config” (as in edit the content), “toggle” (collapse/expand) and “close” the widgets.

The toggle function is pretty simple. I wanted to minimize the .widget-content class (which we’ll add later), change the minus into a plus on the side of the widget after collapsing and turn the big image icon seen on most of those segments into a smaller one that fits on the header. The .ticon class is what we added to the head earlier.

// Toggle widget
function widgetToggle(b, p, i) {
	// Change the + into - and visa versa

	// Turn the big icon into a small one or visa versa
		i.switchClass('icon', 'ticon', '300');
		i.switchClass('ticon', 'icon', '300');

	// Show/Hide widget content

Closing a widget is also pretty straightforward. We’ll be using the closing dialog we added earlier.

// Close widget with dialog
function widgetClose(w, p) {
		resizable: false,
		modal: true,
		buttons: {
			"Close widget": function() {
				p.toggle('slide', {}, 500, function() {
			Cancel: function() {

The last of the widgets is the config. This is the trickiest part, since we’ll need to create and destroy TinyMCE instances and get input from the dialog and push to the content.

// Modify widget
function widgetConfig(w, p) {

	// Input elements in the dialog
	var dt = $('#widget-title-text');
	var dc = $('#widget-content-text');
	var du = $('#widget-icon-text');

	// Widget elements to change
	var wt = p.children('h5:first').eq(0);
	var wc = p.children('.widget-content').eq(0);

	// If there is no icon on the widget, there's nothing to change
	var wi = p.children('img[alt="icon"]:first');
	if(wi.length > 0) {
		wi = p.children('img[alt="icon"]:first').eq(0);
	else {

		resizable: false,
		modal: true,
		width: 500,
		open: function() {
			if(wi != null)


			// Initialize TinyMCE
			initTiny(dc, tinySettings);
		buttons: {
			"Save changes": function(e, ui) {

				// Some widgets don't have an icon
				if(wi.length > 0) {
						wi.attr('src', du.val());

				// Remove editor (also gets content from TinyMCE back to textarea)

				// Update

				// Careful here, don't wanna lose the control icons
				if(notEmpty(dt.val())) {
					var ci = wt.children('span.ui-icon');

					// Reset controls

			Cancel: function() {

				// Destroy TinyMCE


Basically, the above function grabs the text fields from the dialog and puts the existing content on page into them. The user makes some edits and clicks on “Save changes” which causes the script to take the changed content and apply it back to the page. In a real-world example, this content will actually be posted back to the server.

Note: Since the control icons are also located in the title, when we change the title text, we have to make sure that the control icons are spared from any edits.

The Initialization.

This basically takes every section with a “column” class that has a <h5> element inside into a sortable widget. It adds the control icons as <span> tags and wraps the content in a widget-content <div> (which we can minimize) and adds the ui-widget classes from jQuery UI to aid with sorting.

function Init() {

	// Initialize dialogs

	// Portlet and sort related CSS classes
	var sortClasses = "ui-widget ui-widget-content ui-helper-clearfix";

	// Set every column segment with h5 element as a sortable widget
	$('.column:has(h5)').each(function() {

		var s = $(this);
		var p = s.parentsUntil('section').parent();
		var h = s.children('h5:first').eq(0);


		// Function icons
			.prepend('<span class="ui-icon ui-icon-gear" title="Config"></span>')
			.prepend('<span class="ui-icon ui-icon-minus" title="Toggle"></span>')
			.prepend('<span class="ui-icon ui-icon-close" title="Close"></span>');

		// Need this to drag not highlight

		// Interaction cues
		h.css('cursor', 'move');
		$('.ui-icon').css('cursor', 'pointer');

		// Wrap control stuff (like icons and headers) in a widget-header div
		// and the rest in a widget-content div
		s.children().not('img[alt="icon"], .ui-widget-header, .ui-icon')
			.wrapAll('<div class="widget-content" />');

		s.children().not('widget-content').wrapAll('<div class="widget-header" />');

	// Group sortable widgets in each section to one sort-area
	$('section').has('.column').each(function() {
			.wrapAll('<div class="sort-area" />');

	// Trigger control initialization

And lastly, if we don’t have sorting ability, we can’t really call this a dashboard. Ironically the most defining characteristic in dashboards is the most simple to implement once all the wrapper divs are in place.

	connectWith: ".sort-area",
	opacity: 0.6,
	helper: 'clone',
	dropOnEmpty: true

This post was prompted by yet another example of why I have a dim view of project managers.

Can you put together a dashboard for us?

OK, no problem.

We already have the backend completed and a template in place although it doesn’t have any widget markup. Except for the head tag, we need you to not touch the rest of it because we do have other stuff on the page. BTW… We need it in an hour.

@$#& me!

I wish the above was an exaggeration, but sadly, it happens more often than I care to tolerate.

The problem is easy enough to come by. Someone first builds a backend thinking they’ll have all sorts of widget like functionality in the future, but doesn’t develop the front end for any of it. Time goes by… The next developer comes along and decides that since the template is already in place, they’ll finagle the output to be more “widget-like” and create a separate handler to manage user changes. This also explains why so many “legacy” dashboards are notoriously slow.

So now they bring in someone else to drop in a dashboard where there previously existed no frontend for it… And they want it yesterday.

Oh, right New Year resolution…
Less grumpy. Less grumpy. Less grumpy.


Changed the notEmpty(t) function line if(t != “”) into if($.trim(t) != “”).

Switchable stylesheets

The amount of time and effort that can be saved by using a single layout and moulding the CSS around it is immeasurable in most cases.

I wrote in detail about my motivations for doing this, but that post only contained a few small examples.

This time, I’ve updated my styles index to include a style switcher to futher demonstrate the importance of using a consistent layout. As long as your HTML scaffolding is not fiddled with, you can completely change the look and feel of a site using CSS alone.

The stylesheets were written in a very specific manner in order to accomodate ASP.NET App_Themes. It is far simpler to create one stylesheet and theme that will incorporate other devices than creating seperate stylesheets for each device and selectively loading them.

This is the most straightforward approach to reducing complexity.

To get your WebParts to accomodate this layout, read my previous post on tableless WebParts and WebPartZones.

These examples make heavy use of the jQuery library.

There are a few minor issues.
The drag n’ drop functionality is a bit shaky, but minimizing the webpart before moving it will solve this.
The minimize icon (plus/minus) will not change after the stylesheets are switched. But they will change once you click on them. This is a very minor issue and I didn’t spend any time trying to fix it. I thought getting the examples up there was more important. Feel free to use and improve.

Once again, these are only rough examples to get the ball rolling. Use them to create your own solutions.

Building (clean) dashboards for your web app

Update January 2nd 2012: This example was created in 2008. There’s now an updated version using jQuery UI Portlets.

This post was partly inspired by Francesco Sullo’s comment on the difficulties on finding a balance between functionality and accessibility, but the content is for whoever may find it useful.

I know its easy to whine and complain about a problem and not do anything about it, so I thought about being part of the solution. This can be applied to pretty much whatever you have in mind. I’m going to be as generic as possible so you can place whatever you want inside each of the content segments. From tables to lists to forms to images.

There are probably going to be a whole lot of bugs and such, but that’s because this whole thing was put together within the span of a couple of hours. With more time, I’m sure the bugs can be worked out. And since everyone’s going nuts for “widget” functionality, I’ll see what I can do.

Once again, this is only an example. Your situation will demand you take it apart piece-by-piece and put it back together. This is not meant to be a drop-in replacement for someone else’s project! I didn’t do any bug-testing at all on this. In fact, my coffee was still hot when I finished… So use it at your own risk!!


Believe it or not, the presentation of your content will be easy depending on how logical its arrangment is. That is to say, make the content logically partitioned ahead of time so you won’t need to work extra hard to present it later.

  • Title

  • Navigation

  • Content section

    • Segment1
    • Segment2
    • Segment3
    • Segment4
    • Segment5
  • Content footer

While you are building the page content, it’s ok to think about how you want it arranged. But don’t arrange it yet! Which means, don’t flood your page full of style elements and JavaScript. Leave that for the end, when your content is complete and you are ready to style the whole page.

In the content area, you can think of how you want to arrange your segments. In my case, I’m picturing a tab based page where each tab will have three columns. The content segments will go into blocks inside these columns. But I want to make the whole page accessible for people who may not have JavaScript enabled. The content should still be usable for anyone who browses the page.

The basic scaffolding I’m going to use.  As Phillip J. Fry would say, it looks like whale barf. But that’s because it hasn’t been styled yet.

The Styles

Tabs styles are are dime a dozen these days, but I’m going to use a technique similar to A List Apart Sliding Doors in that I will only use two images for the tabs and a couple more for the content background. I didn’t bother making them fancy or anything and it’s just a few minutes spent in Photoshop.

To apply the tabs, we need to give a few class names to the navigation list:

  <ul class="nav">
  <li class="active"><a href="">Home</a></li>
   <li><a href="">Articles</a></li>
   <li><a href="">Forums</a></li>
   <li class="na">
     <a href="">
     <img src="img/add_tab.png" alt="Add a tab" />

…And I’m reminded, once again, how much I dispise the WordPress text editor for typing code.

Notice that I changed the last “Add a tab” link into an image. If you do the same, just remember to give the image an “alt” value. Or else, people who have images disabled or are viewing in a browser that doesn’t have image capability will be left out.

Now let’s see what it looks like after we add the tabs.

Slightly better looking whale barf, I’d say. But there still aren’t any columns yet.

The Framework

One of the hard parts of building a dashboard is selecting your code libraries for rich UI functionality. There are literally thousands of code libraries that deal with this one way or another. But only a few that have gone into creating a complete set that you can use.

The two most popular are Prototype and jQuery. The least cumbersome and, as far as I can see, least intrusive of these is jQuery. Of course not everyone will agree, so flame away.

Instead of writing all of the widget functionality from scratch, I’ll be using the jQuery UI framework to build virtually all of it. When I’m done, I will only have two JS code files that I’ve written myself and only one of them will have true functionality in it. The other will just be a loader similar to the loader in principle, but a hundred times simpler.

Specifically, I’ll be using the sortable plugin. Unfortunately, to use this plugin, we need to call 5 seperate code files including the jQuery main code file (this is one of the big reasons why I have an issue with JavaScript heavy sites).

To lessen the load a bit, I’m going to use a loader and a seperate JS file for the dashboard “stuff”. You’re probably thinking, “why would you add another JS file to this? Doesn’t that make the load size bigger?” Hold on, there’s a method to the madness.

Keep your head clean

I’m serious!

Even if you look at the source of this page, you’ll see a ton of junk in the <head> tag. That’s WordPress for ya! Granted, this is for all their dashboard stuff, but I think they could really use more streamlining.

For this example, I’m only putting one stylesheet and two JS files in the header. That’s all that you need and that’s all that’s acceptible. If your <head> tag is longer than 10 lines, then you’ve got more planning to do!

First, we include the jQuery base library and include a “Setup” JS file. This is what will call all subsequent JS files into the page. There’s no sense in downloading all those files if your browser cannot support it. If it does support jQuery, then it will download the rest. If not, the script ends there and you’re not downloading any more files.

function loadJS(p) {
     '<script type="text/javascript" src="'+p+'"></script>'


This code uses jQuery’s own “append” function to load the rest of the code files into the header. Notice the last line contains the “Dashboard” file.

The Code

The Dashboard JavaScript file contains everything we need to create our columns, convert all the “segments” into widget blocks and sort them into the columns.

Believe it or not, it’s actually much simpler to do it this way than to hard-code anything into your HTML file.

The first step is creating our columns…

$('.main').append('<div id="container1"></div>');
$('.main').append('<div id="container2"></div>');
$('.main').append('<div id="container3"></div>');
$('.main').append('<div style="clear:both;width:100%;"> </div>');

Again, we’re using the “append” function to load the columns to our page. The last <div> is there to clear our content. This is another reason why I prefer to keep this stuff in the code file and not clutter the HTML.

In our plain content page, you may notice a “title” and “description” class given to each of the titles and descriptions in each of the content segments. This is so jQuery has something to grab onto as we create our content blocks…

$('.main').find("div").each(function(i) {
  if(this.className == 'segment') {
    var t = '';
    var d = '';
    var c = '';

    $(this).find("*").each(function(j) {
      if(this.className == "title") {
        t += $(this).html();
    $(this).find("*").each(function(j) {
      if(this.className == "description") {
        d = $(this).html();
     c = $(this).html();
     var rcol = $(this).attr('rel');
     $('#container'+rcol).append(segBlock(t, d, c));

This code selects each and every “segment” in our content and loads the title, description and the content inside and then sends it over to the “segBlock” function. Once that’s done, there’s no reason to keep the segments on the page any more, so we use the jQuery “remove” function to get rid of them.

The “segBlock” function is basically a formatter. It can be anything you want. In my case, I wanted to create a block like arrangement. You can give it “widget” like functionality too by giving it a collapsible panel, an editable title and description and other stuff. I won’t go into the details of how to get all of that done. You can see how it’s done via the code file. All of these extra features can be added using jQuery.

Putting it all together

Finally, we can see what two codefiles, a stylesheet and a plain HTML file can do when you select the right tools for the job. There’s no need to jump through hoops to get any of this done. No reason why you can’t do this in a single evening or even a few hours.

The “Add a tab” link can be used to redirect the user to a control panel where new sections can be added. For this example, I haven’t used such a page, and instead used the “append” function again to add a new tab each time. In a real-life example, this should be done via a server-side personalization mechanism.

I’d recommend avoiding cookies for this purpose, since some people don’t enable them. Plus cookies are vulnerable to being hijacked. In fact, they are fare more susceptible than session hijacking. So that’s something to keep in mind while enabling personalization.

Also, the drag-n-drop functionality is completely optional. But as per my original description, I tried introducing some “widget” like behavior here and there.

Here’s a more realistic example. The images for the news widget were courtesy of the Tango Desktop Project.

Well, that’s all I have for you today…
Hopefully you carried something away that will help you put together a dashboard for your own app.