Introduction:
There are many competing requirements for web designers ranging from accessibility to legislative to personal preferences. Rather than trying to over-parameterise views, or trying to aim for some sort of line of best fit, or worse, sticking its head in the sand, “Joomla!” has added the potential for the designer to take over control of virtually all of the output that is generated.
“Joomla!” has been criticized by some for not giving due attention to accessibility or being archaic in their approach to web standards. However with 1.5, the responsibility, but more importantly the power is back in the designer’s hands.
In addition, except for files that are provided in the “Joomla!” distribution itself, these methods for customisation eliminate the need for designers and developers to “hack” core files that could change when the site is updated to a new version. Because they are contained within the template, they can be deployed to the Web site without having to worry about changes being accidentally overwritten when your System Administrator upgrades the site.
The aim of this tutorial is to introduce the how fours areas of the output of “Joomla!” are able to be customised by the template designer.
Not interested in all the theory? Jump straight to the cheat sheet.
MVC 101
MVC can be a scary acronym. It stands for Model-View-Controller and the concepts behind MVC are responsible for the extra flexibility that is now afforded to the designer. While parts of the theory can be rather involved and complicated, the only part that the designer need worry about is the V for View. This is the part that is concerned with output.
Different extensions display output in different ways.
Components, as you would already know, are fairly complex and have the ability to display different information in different ways. For example, the Articles Component (com_content) is able to display a single article, or articles in a category, or categories in a section. Each of the ways of representing the different types of data (an article, or a category, or a section) is called a “view” (this comes from our MVC terminology). Most components will have many views. However, the view doesn’t actually display the output. This is left up to what we call a “layout” and it is possible for a view to have a variety of layouts.
The main thing to remember here is that components can have multiple views, and each view can have one or more layouts. Each view assembles a fixed set of information, but each layout can display that information in different ways. For example, the Category view in the Articles component assembles a number of articles. These articles could be displayed in a list or in a table (and probably other ways as well). So this view may have a “list” layout and a “table” layout to choose from.
Modules, on the other hand, are very simple. They generally display one thing one way. Modules don’t really have views but they do support a layout. Some developers might even support a choice of layout through module parameters
Template versus Layout
It is very important to distinguish between the role of template and the role of layouts. The template sets up a structural framework for the page of the Web site. Within this framework are positions for modules and a component to display. What actually gets displayed is governed by the module layout, or the combination of view and layout in the case of the component.
The following image shows the structural layout of a typical “Joomla!” template (rhuk_milkyway, the default for 1.5). The module positions are displayed by adding tp=1 to the URL (eg, index.php?tp=1). You can clearly see where the module output is contained within the overall template, as well as the main component output starting in the lower-centre region. However, what is actually output in those regions, is controlled by the layouts.
Ancillary Customisation
While not strictly related to the MVC, there are two other important areas to consider when looking at customising the output of “Joomla!”.
In addition to layouts, modules have what we call “chrome”. Chrome is the style with which a module is to display. Most developers, designers and probably some end-users will be familiar with the different built-in styles for modules (raw, xhtml, etc). It is also possible to define your own chrome styles for modules depending on the designer result. For example, you could design a chrome to display all the modules in a particular position in a fancy Javascript collapsing blind arrangement.
In the screenshot above, you can just make out the names of some of the built-in module chrome used (rounded, none and xhtml).
The second area has to do with controlling the pagination controls when viewing lists of data. We will look at that in more detail later.
Component Output Types and Layout Overrides:
To understand layout overrides we must first understand the file structure of a component. While there are many parts to a component, all fulfilling different roles and responsibilities, we want to look just in the /views/ directory. Here is the partial structure for two of the com_content views:
/components
  /com_content
        /views
          /articles
                /tmpl
                  default.php (this is a layout)
                  form.php      (this is a layout)
                view.html.php (this is the view that outputs the HTML)
                view.pdf.php  (this is the view that outputs the PDF)
          /category
                /tmpl
                  blog.php         (layout)
                  blog_items.php (a sub-layout
                  default.php   (layout)
                view.html.php   (HTML view)
                view.feed.php   (RSS feed)
So what you see here is that under the /views/ directory, each view is placed in a directory of its own. The content component actually has three other views not shown: archive, frontpage and section.
Output Types
Under the /articles/ directory we have a number of files. There is almost always a file called view.html.php. This is what we call the view file, but there can be more than one depending on the type of output to produce. It has a specific naming convention, view.output_type.php, where the output type can be html, feed, pdf, raw or error (for more information see JDocument in the API reference and look in the directory /libraries/joomla/document/). What this means is when we want html output for this particular view, the view.html.php file is used. When we want the RSS output, the view.feed.php file is used.
The affect of these different output types is most apparent when the Global Configuration setting for Search Engine Friendly URLs is set to Yes, Use Apache mod_rewrite is set to Yes, and Add suffix to URLs is also set to Yes. When this is done, the site URLs will look something like this:
The exact URL will vary depending on how you set up your site but the point here is to show that sports.html will use the category view’s view.html.php file to, and that sports.feed will display the RSS feed for the category using view.feed.php. It should be noted that you cannot currently customise feed or PDF output types. However, you can customise the html output type and this is where layouts come into play.
To understand layout overrides we must first understand the file structure of a component. While there are many parts to a component, all fulfilling different roles and responsibilities, we want to look just in the /views/ directory. Here is the partial structure for two of the com_content views:

Introduction:

There are many competing requirements for web designers ranging from accessibility to legislative to personal preferences. Rather than trying to over-parameterise views, or trying to aim for some sort of line of best fit, or worse, sticking its head in the sand, “Joomla!” has added the potential for the designer to take over control of virtually all of the output that is generated.

“Joomla!” has been criticized by some for not giving due attention to accessibility or being archaic in their approach to web standards. However with 1.5, the responsibility, but more importantly the power is back in the designer’s hands.

In addition, except for files that are provided in the “Joomla!” distribution itself, these methods for customisation eliminate the need for designers and developers to “hack” core files that could change when the site is updated to a new version. Because they are contained within the template, they can be deployed to the Web site without having to worry about changes being accidentally overwritten when your System Administrator upgrades the site.

The aim of this tutorial is to introduce the how fours areas of the output of “Joomla!” are able to be customised by the template designer.

Not interested in all the theory? Jump straight to the cheat sheet.

MVC 101

MVC can be a scary acronym. It stands for Model-View-Controller and the concepts behind MVC are responsible for the extra flexibility that is now afforded to the designer. While parts of the theory can be rather involved and complicated, the only part that the designer need worry about is the V for View. This is the part that is concerned with output.

Different extensions display output in different ways.

Components, as you would already know, are fairly complex and have the ability to display different information in different ways. For example, the Articles Component (com_content) is able to display a single article, or articles in a category, or categories in a section. Each of the ways of representing the different types of data (an article, or a category, or a section) is called a “view” (this comes from our MVC terminology). Most components will have many views. However, the view doesn’t actually display the output. This is left up to what we call a “layout” and it is possible for a view to have a variety of layouts.

The main thing to remember here is that components can have multiple views, and each view can have one or more layouts. Each view assembles a fixed set of information, but each layout can display that information in different ways. For example, the Category view in the Articles component assembles a number of articles. These articles could be displayed in a list or in a table (and probably other ways as well). So this view may have a “list” layout and a “table” layout to choose from.

Modules, on the other hand, are very simple. They generally display one thing one way. Modules don’t really have views but they do support a layout. Some developers might even support a choice of layout through module parameters

Template versus Layout

It is very important to distinguish between the role of template and the role of layouts. The template sets up a structural framework for the page of the Web site. Within this framework are positions for modules and a component to display. What actually gets displayed is governed by the module layout, or the combination of view and layout in the case of the component.

The following image shows the structural layout of a typical “Joomla!” template (rhuk_milkyway, the default for 1.5). The module positions are displayed by adding tp=1 to the URL (eg, index.php?tp=1). You can clearly see where the module output is contained within the overall template, as well as the main component output starting in the lower-centre region. However, what is actually output in those regions, is controlled by the layouts.

Ancillary Customisation

While not strictly related to the MVC, there are two other important areas to consider when looking at customising the output of “Joomla!”.

In addition to layouts, modules have what we call “chrome”. Chrome is the style with which a module is to display. Most developers, designers and probably some end-users will be familiar with the different built-in styles for modules (raw, xhtml, etc). It is also possible to define your own chrome styles for modules depending on the designer result. For example, you could design a chrome to display all the modules in a particular position in a fancy Javascript collapsing blind arrangement.

In the screenshot above, you can just make out the names of some of the built-in module chrome used (rounded, none and xhtml).

The second area has to do with controlling the pagination controls when viewing lists of data. We will look at that in more detail later.

Component Output Types and Layout Overrides:

To understand layout overrides we must first understand the file structure of a component. While there are many parts to a component, all fulfilling different roles and responsibilities, we want to look just in the /views/ directory. Here is the partial structure for two of the com_content views:

/components

  /com_content

        /views

          /articles

                /tmpl

                  default.php (this is a layout)

                  form.php      (this is a layout)

                view.html.php (this is the view that outputs the HTML)

                view.pdf.php  (this is the view that outputs the PDF)

          /category

                /tmpl

                  blog.php         (layout)

                  blog_items.php (a sub-layout

                  default.php   (layout)

                view.html.php   (HTML view)

                view.feed.php   (RSS feed)

So what you see here is that under the /views/ directory, each view is placed in a directory of its own. The content component actually has three other views not shown: archive, frontpage and section.

Output Types

Under the /articles/ directory we have a number of files. There is almost always a file called view.html.php. This is what we call the view file, but there can be more than one depending on the type of output to produce. It has a specific naming convention, view.output_type.php, where the output type can be html, feed, pdf, raw or error (for more information see JDocument in the API reference and look in the directory /libraries/joomla/document/). What this means is when we want html output for this particular view, the view.html.php file is used. When we want the RSS output, the view.feed.php file is used.

The affect of these different output types is most apparent when the Global Configuration setting for Search Engine Friendly URLs is set to Yes, Use Apache mod_rewrite is set to Yes, and Add suffix to URLs is also set to Yes. When this is done, the site URLs will look something like this:

http://domain/sports.html

http://domain/sports.feed

http://domain/sports/rowing.html

http://domain/sports/rowing.pdf

The exact URL will vary depending on how you set up your site but the point here is to show that sports.html will use the category view’s view.html.php file to, and that sports.feed will display the RSS feed for the category using view.feed.php. It should be noted that you cannot currently customise feed or PDF output types. However, you can customise the html output type and this is where layouts come into play.

Layouts

Under the view directory there is a /tmpl/ directory in which the layout files reside. Each PHP file in this directory represents a layout. For example, article/tmpl/default.php is the default layout for an article whereas article/tmpl/form.php is the edit form for an article; category/tmpl/default.php is the default layout for a category whereas category/tmpl/blog.php displays the list of article differently.

The relationship between component views and layout is most plainly seen when adding a new menu item. The next screenshot represents the typical display of the New Menu Item page. Having clicked on Articles (which represents com_content), the tree expands to show the list of views and each layout within the view.

 

You will notice that while there are extra files in some of the /tmpl/ directories (like pagebreak.php in the article view), they are missing from the list. This is due to instructions in the XML file for the layout (for example, pagebreak.xml) to hide the layout (or even the view) from the menu item list. However, this is another broad topic which will be covered in another tutorial.

Armed with all that knowledge of how all the parts relate to each other, we are now ready to actually create our layout overrides.

 

Copying or Creating Layout Files

Layout overrides only work within the active template and are located under the /html/ directory in the template. For example, the overrides for rhuk_milkyway are located under /templates/rhuk_milkyway/html/, for the JA Purity template under /templates/ja_purity/html/ and for Beez under /templates/beez/html/.

It is important to understand that if you create overrides in one template, they will not be available in other templates. For example, rhuk_milkyway has no component layout overrides at all. When you use this template you are seeing the raw output from all components. When you use the Beez template, almost every piece of component output is being controlled by the layout overrides in the template. JA Purity is in between having overrides for some components and only some views of those components.

The layout overrides must be placed in particular way. Using Beez as an example you will see the following structure:

 

/templates

  /beez

        /html

          /com_content  (this directory matches the component directory name)

                /articles        (this directory matches the view directory name)

                  default.php (this file matches the layout file name)

                  form.php

 

The structure for component overrides is quite simple: /html/com_component_name/view_name/layout_file_name.php. Let’s look at a few examples.

The rhuk_milkyway template does not have any layout overrides for any components. If we want to override the default layout for an article, first we need to copy this file:

/components/com_content/views/article/tmpl/default.php

to this location, creating the appropriate directories in the event they don’t already exist:

/templates/rhuk_milkyway/html/com_content/article/default.php

If we wanted to override the blog layout in the category view, we would copy this file:

/components/com_content/views/category/tmpl/blog.php

to:

/templates/rhuk_milkyway/html/com_content/category/blog.php

Once the files are copied, you are free to customise these files as much or as little as required or desired. You do not have to honour parameter settings if you don’t want to.

 

Overriding Sub-Layouts

In some views you will see that some of the layouts have a group of files that start with the same name. The category view has an example of this. The blog layout actually has three parts: the main layout file blog.php and two sub-layout files, blog_item.php and blog_links.php. You can see where these sub-layouts are loaded in the blog.php file using the loadTemplate method, for example:

 

echo $this->loadTemplate(‘item’);

// or

echo $this->loadTemplate(‘links’);

 

When loading sub-layouts, the view already knows what layout you are in, so you don’t have to provide the prefix (that is, you load just ‘item’, not ‘blog_item‘).

What is important to note here is that it is possible to override just a sub-layout without copying the whole set of files. For example, if you were happy with the “Joomla!” default output for the blog layout, but just wanted to customise the item sub-layout, you could just copy:

/components/com_content/views/category/tmpl/blog_item.php

to:

/templates/rhuk_milkyway/html/com_content/category/blog_item.php

When “Joomla!” is parsing the view, it will automatically know to load blog.php from com_content natively and blog_item.php from your template overrides.

Module Layout Overrides
Modules, like components, are set up in a particular directory structure.

/templates

  /beez

        /html

          /mod_latest_news   (this directory matches the module directory name)

                default.php   (this file matches the layout file name)

The structure for module overrides is again quite simple: /html/mod_module_name/layout_file_name.php.

Copying or Creating Layout Files

The rhuk_milkyway template does not have any layout overrides for any modules. If we want to override the default layout for Latest News module, we need to copy this file:

/modules/mod_latest_news/tmpl/default.php

to this location, creating the approriate directories in the event they don’t already exist:

/templates/rhuk_milkyway/html/mod_latest_news/default.php

You need to take a little care with overriding module layout because there are a number of different ways that modules can or have been designed so you need to treat each one individually.

 

Module Chrome

“Joomla!” 1.0 had a number of fixed styles that could display a list of modules in a particular position. These where represented by numbers:

0 (the default) displayed modules in a vertical table

1 displayed them in a horizontal table

-1 displayed the raw module output

-2 displayed the modules in a XHTML compatible format with the title in a H3 tag.

-3 displayed modules in a set of nested DIVs that allowed for rounded-corner techniques

It was a great system except for two things:

Nobody could remember which number was which, and

You couldn’t expand on the styles.

Well, in 1.5, the numbers are still recognised, but more commonly the style is represented as a word. As well as that, the syntax for displaying a module position was changed. For example, this snippet displays each module in the left position in the xhtml style:

<jdoc:include type=”modules” name=”left” style=”xhtml” />

 

The built-in styles that are now available are:

table (was 0 and is the default)

horz (was 1)

none (was -1)

xhtml (was -2)

rounded (was -3)

outline (new – used to preview module positions – see screenshot above)

In the source code, these styles are actually referred to ask “chrome“. The default chrome can actually be found in the system template provided in the default “Joomla!” install:

/templates/system/html/modules.php

This file is maintained by the project so you should never modify it directly otherwise there is a risk that you will loose your changes if and when you upgrade your “Joomla!” installation.

To create your own chrome, or module styles, all you need to do is create or edit modules.php under the templates /html/ directory (this is the same directory we have been talking about for component and module layout overrides).

The rhuk_milkyway template actually does provide some extra chrome as an example (it provides and new example style called “slider”). This can be found in the following file:

/templates/rhuk_milkyway/html/modules.php

To create your own chrome is really easy. Let’s look at ficticious example that displays the module in a Definition List (a set of DL’s, DT’s and DD’s).

Just add the following function to the /html/modules.php file in your default template directory (create it if it does not exist):

 

/*

 * Module chrome that wraps the module in a definition list

 */

function modChrome_dlist($module, &$params, &$attribs)

{ ?>

        <dl class=”<?php echo $params->get(‘moduleclass_sfx’); ?>”>

        <?php if ($module->showtitle != 0) : ?>

                <dt>

                        <?php echo $module->title; ?>

                </dt>

        <?php endif; ?>

                <dd>

                        <?php echo $module->content; ?>

                </dd>

        </dl>

        <?php

}

We will be calling the style “dlist”, so the name of the function needs to be modChrome_dlist.

The function must take the three arguments as shown for the module object, the module parameters, and lastly the $attribs is an array of all the attributes in the jdoc XML tag.

There are three main properties in the module object to be concerned with:

showtitle tells you whether to show the title of the module of not

title is the title of the module

content is the output of the module (from its layout)

This is a very simple case and you can of course design more complex styles, possibly using custom atrributes in the XML tag.

 

Pagination Links Overrides

The final override we will look at is the pagination override. This override can control the display of items-per-page and the pagination links that are used with lists of information, as shown in the following screenshot.

The rhuk_milkyway template provides a well commented example for this override. The file is found here:

/templates/rhuk_milkyway/html/pagination.php

When the pagination list is required, “Joomla!” will look for this file in the default templates. If it is found it will be loaded and the display functions it contains will be used.

There are four functions that can be used:

pagination_list_footer

This function is responsible for showing the select list for the number of items to display per page.

pagination_list_render

This function is responsible for showing the list of page number links as well at the Start, End, Previous and Next links.

pagination_item_active

This function displays the links to other page numbers other than the “current” page.

pagination_item_inactive

This function displays the current page number, usually not hyperlinked.

Cheat Sheet

Using the rhuk_milkyway template as an example, here is a brief summary of the priniciples we’ve looked at.

Customise the Component Output

To override a component layout (for example the default layout in the article view), copy:

/components/com_content/views/article/tmpl/default.php

to:

/templates/rhuk_milkyway/html/com_content/article/default.php

Read more about component output.

Customise the Module Output

To override a module layout (for example the Latest News module using the rhuk_milkyway template), copy:

/modules/mod_latest_news/tmpl/default.php

to:

/templates/rhuk_milkyway/html/mod_latest_news/default.php

Add New Module Styles

To add new module styles (chrome), add them to the following file:

/templates/rhuk_milkyway/html/modules.php

Customise the Pagination Links

To customise the way the items-per-page selector and pagination links display, edit the following file:

/templates/rhuk_milkyway/html/pagination.php

Conclusion

“Joomla!” 1.5, through the use of an MVC paradigm has greatly improved the flexibility that is afforded to Web site designers. By way of a few simple principles, like copying certain files to certain places in your template, the designer is able to override almost all of the output generated by “Joomla!”.

 

 

Introduction:

MVC is an architectural pattern used in software engineering. In complex computer applications that present lots of data to the user, one often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface do not impact the data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.

The MVC paradigm is a way of breaking an application, or even just a piece of an application’s interface, into three parts: the model, the view, and the controller.

MVC was originally developed to map the traditional input, processing, output roles into the GUI realm:
mvc model controller view joomla15

Input –> Processing –> Output
Controller –> Model –> View

Model

The model is the part of the component that encapsulates the application’s data. It will often provide routines to manage and manipulate this data in a meaningful way in addition to routines that retrieve the data from the model. In our case, the model will contain methods to add, remove and update information about the books in the database. It will also contain methods to retrieve the list of books from the database. In general, the underlying data access technique should be encapsulated in the model. In this way, if an application is to be moved from a system that utilizes a flat file to store its information to a system that uses a database, the model is the only element that needs to be changed, not the view or the controller.

View

The view is the part of the component that is used to render the data from the model in a manner that is suitable for interaction. For a web-based application, the view would generally be an HTML page that is returned to the data. The view pulls data from the model (which is passed to it from the controller) and feeds the data into a template which is populated and presented to the user. The view does not cause the data to be modified in any way, it only displays data retrieved from the model.

Controller

The controller is responsible for responding to user actions. In the case of a web application, a user action is a page request. The controller will determine what request is being made by the user and respond appropriately by triggering the model to manipulate the data appropriately and passing the model into the view. The controller does not display the data in the model, it only triggers methods in the model which modify the data.

Joomla! MVC Implementation

In Joomla!, the MVC pattern is implemented using three classes:

1. JModel
2. JView
3. and JController

Hello world component

a) structure

¦   com_helloworld.xml (xml – installation source)
¦
+—admin                       – (administration folder)
¦   ¦  index.html – (blank file)
¦   ¦   admin.helloworld.php – (create controller and hand over the control)
¦   ¦   toolbar.helloworld.php  – (tool bar definition and a ‘help’ menu item)
¦   ¦   toolbar.helloworld.html.php   – (tool bar definition and a ‘help’ menu item)
¦   ¦
¦   +—images                  – (here are all picures used in the component)
¦   ¦       helloworld.png
¦   ¦       index.html          – (blank file)
¦   ¦
¦   +—controllers             – (controlers folder)
¦   ¦       default.php         – (default controler      – “default section”)
¦   ¦       helloagain.php      – (heloagain controler    – “helloagain section”)
¦   ¦       hellotestfoo.php    – (hellotestfoo controler – “helhellotestfooloagain sec.”)
¦   ¦       helloworld.php      – (helloworld controler   – “helloworld section”)
¦   ¦
¦   +—models                  – (models folder)
¦   ¦       helloworld.php      – (the only model defined here. Currently not in use)
¦   ¦
¦   +—views                   – (views folder)
¦   ¦   +—default
¦   ¦   ¦       view.php        – (default view      – “default section”)
¦   ¦   ¦
¦   ¦   +—helloagain
¦   ¦   ¦       view.php        – (helloagain view   – “helloagain section”)
¦   ¦   ¦
¦   ¦   +—hellotestfoo
¦   ¦   ¦       view.php        – (hellotestfoo view – “hellotestfoo section”)
¦   ¦   ¦
¦   ¦   +—helloworld
¦   ¦           view.php        – (helloworld view   – “helloworld section”)
¦   ¦
¦   +—sql – (SQL folder. Currently not in use. All sql files)
¦   ¦       uninstall.helloworld.sql      ( are commented out in the installation xml.)
¦   ¦       install.helloworld.sql        ( The reasson is very simple. Joomla! 1.5 has )
¦   ¦                                     ( a minor bug in installation.php. We will need )
¦   ¦                                     ( a “night build” for the next tutorial)
¦   ¦
¦   +—lang – (language folder)
¦           cs-CZ.com_helloworld.ini    – (czech text package)
¦           en-GB.com_helloworld.ini    – (english text package)
¦
+—component
¦   index.html                      – (blank file)
¦   helloworld.php                  – (core for the frontend application. )
¦                                     ( Prints “hello world”.)
+—lang
cs-CZ.com_helloworld.ini    – (czech text package)
en-GB.com_helloworld.ini    – (english text package)

b) concept
We need to rewrite the core of our previous component. It prints “hello world” by accessing methods of class helloScreens in admin.helloworld.html.php

class helloScreens
{
function helloworld()
{ echo JText::_(‘helloworld’); }

function helloagain()
{ echo JText::_(‘helloagain’); }

function hellotestfoo()
{ echo JText::_(‘hellotestfoo’); }

function hellodefault()
{ echo JText::_(‘hellodefault’); }
}

All these methods will become stand-alone views. \views\helloworld\view.php

class HelloWorldComponentView extends JView
{

function display()
{
echo JText::_(‘helloworld’);
}
}

Are you a customer or partner of IT?

If you answered “customer,” guess again. IT only has one customer — and that is the customer who buys the company’s products and services. Serving this customer requires an effective IT-business partnership.

As a wise old client of mine articulately states, “IT should be of service, but not subservient.”

Of course, it’s much more enjoyable (and simpler) to be a customer than a partner. The thought of having to understand the long-term interests, workload, and challenges of my financial planner, gardener or babysitter is depressing. Why should I? The service is well defined and pretty commoditized. If my needs are not met, it’s easy to pick up the phone and move on. Although there are components of IT that are of a commodity nature (e.g., computer and network services), how a business applies technology to support their business processes and improve the performance of their people is not.

Partners take care of each other. Partners are committed to finding win-win solutions and making it work for the long term. They make sure that their plans, priorities, authorities, processes, and people dovetail. When problems arise, they fight the temptation to place blame and instead examine the context and system that allow great people to stumble and fall.

The bonus for strengthening the IT-business partnership is on line leaders. IT has practically tied their organizations into pretzels trying to crack the alignment code by trying to:

* Link IT and business strategies
* Shift authority for key IT decisions to business leaders (e.g., funding, priorities, functionality, service levels)
* Define IT services and processes to clarify respective roles and responsibilities and help ensure consistent, predictable delivery
* Decentralize application services to mirror the structure of the business
* Hire, develop, and reward business and relationship management skills (vs. technical skills)

In spite of their efforts over a long period of time, IT hasn’t figured out how to insert themselves in a real way in your real world. Every CIO and IT leader worth their weight understands that they should spend at least ½ of their time outside of the four walls of IT working with their business partners on planning, executing, and trouble-shooting. When challenged to do so, they sheepishly admit that they don’t know what to say and do. I have had many a CIO ask me, “What do I say?” They shy away from spearheading enterprise IT strategy, joint IT-business leadership development forums, IT-business job rotation, and believe it or not, co-location. To many, these efforts make them feel like they are inviting themselves to a party where they aren’t really welcome.

As a result, IT feels like a provider rather than a partner. They are dying for a “seat at the table” in decision-making so that they can advise you as to how to best achieve your goals and support enterprise interests, leverage current capabilities, and exploit new technologies.

IT has done pretty much everything they know how to do. Unless business leaders commit to forging a better partnership with IT, whatever IT is today, it will still be tomorrow.

As daunting as this may sound, the truth is that business leaders have always wanted more control over IT, as evidenced by their willingness to create “shadow” IT organizations, select technologies without involving IT, and contract directly with vendors.

IT-smart business leaders make sure that their organizations work seamlessly with IT. They invest in building strong relationships and teamword with IT because they understand that that IT is an organizational asset, not simply an organization structure, and that exploitation of this asset requires effective IT-business collaboration across, up and down the organization.

Taxonomy is the practice and science of classification. The word finds its roots in the Greek τάξις, taxis (meaning ‘order‘, ‘arrangement‘) and νόμος, nomos (‘law‘ or ‘science‘). Taxonomy uses taxonomic units, known as taxa (singular taxon).

In addition, the word is also used as a count noun: a taxonomy, or taxonomic scheme, is a particular classification (“the taxonomy of …”), arranged in a hierarchical structure. Typically this is organised by subtype-supertype relationships, also called parent-child relationships. In such a subtype-supertype relationship the subtype kind of thing has by definition the same constraints as the supertype kind of thing plus one or more additional constraints. For example, car is a subtype of vehicle. So any car is also a vehicle, but not every vehicle is a car. Therefore, a thing needs to satisfy more constraints to be a car than to be a vehicle.

Applications

Originally the term taxonomy referred only to the classifying of organisms (now sometimes known as alpha taxonomy) or a particular classification of organisms. However, it has become fashionable in certain circles to apply the term in a wider, more general sense, where it may refer to a classification of things or concepts, as well as to the principles underlying such a classification.

Almost anything — animate objects, inanimate objects, places, concepts, events, properties, and relationships — may be then classified according to some taxonomic scheme

In an even wider sense, the term taxonomy could also be applied to relationship schemes other than parent-child hierarchies, such as network structures with other types of relationships. Taxonomies may then include single children with multi-parents, for example, “Car” might appear with both parents “Vehicle” and “Steel Mechanisms”; to some however, this merely means that ‘car’ is a part of several different taxonomies. A taxonomy might also be a simple organization of kinds of things into groups, or even an alphabetical list. However, the term vocabulary is more appropriate for such a list. In current usage within “Knowledge Management”, taxonomies are seen as less broad than ontologies as ontologies apply a larger variety of relation types.

Mathematically, a hierarchical taxonomy is a tree structure of classifications for a given set of objects. It is also named Containment hierarchy. At the top of this structure is a single classification, the root node, that applies to all objects. Nodes below this root are more specific classifications that apply to subsets of the total set of classified objects. The progress of reasoning proceeds from the general to the more specific. In scientific taxonomies, a conflative term is always a polyseme.

In contrast, in a context of legal terminology, an open-ended contextual taxonomy — a taxonomy holding only with respect to a specific context. In scenarios taken from the legal domain, a formal account of the open-texture of legal terms is modeled, which suggests varying notions of the “core” and “penumbra” of the meanings of a concept. The progress of reasoning proceeds form the specific to the more general.

Go ahead just leave, can’t hold you, you’re free
You take all these things, if they mean so much to you
I gave you your dreams, ’cause you meant the world
So did I deserve to be left here hurt?

You think I don’t know you’re out of control
I ended up finding all of this from my boys
Girl, you’re stone cold, you say it ain’t so
You already know I’m not attached to material

I’d give it all up but I’m takin’ back my love
I’m takin’ back my love, I’m takin’ back my love
I’ve given you too much but I’m takin’ back my love
I’m takin’ back my love, my love, my love, my love
My love

Yeah, what did I do but give love to you?
I’m just confused as I stand here and look at you
From head to feet, all that’s not me
Go ‘head, keep the keys, that’s not what I need from you

You think that you know
(I do)
You’ve made yourself cold
(Oh yeah)
How could you believe them over me, I’m your girl

You’re out of control
(So what?)
How could you let go?
(Oh yeah)
Don’t you know I’m not attached to material?

I’d give it all up but I’m takin’ back my love
I’m takin’ back my love, I’m takin’ back my love
I’ve given you too much but I’m takin’ back my love
I’m takin’ back my love, my love, my love, my love

I’d give it all up but I’m takin’ back my love
I’m takin’ back my love, I’m takin’ back my love
I’ve given you too much but I’m takin’ back my love
I’m takin’ back my love, my love, my love, my love

So all this love I give you, take it away
(Uh, uh huh)
You think material’s the reason I came
(Uh, uh huh)

If I had nothing would you want me to stay
(Uh, uh huh)
You keep your money, take it all away

I’d give it all up but I’m takin’ back my love
I’m takin’ back my love, I’m takin’ back my love
I’ve given you too much but I’m takin’ back my love
I’m takin’ back my love, my love, my love

I’d give it all up but I’m takin’ back my love
I’m takin’ back my love, I’m takin’ back my love
I’ve given you too much but I’m takin’ back my love
I’m takin’ back my love, my love, my love

I’d give it all up but I’m takin’ back my love
I’m takin’ back my love, I’m takin’ back my love
I’ve given you too much but I’m takin’ back my love
I’m takin’ back my love, my love, my love, my love

Ooh, my love
(I’m taking back my love)
Ooh, my love

PS: Thanks Tien.

Dick Harrington was most recently the CEO and President of the world’s largest information media company Thomson Reuters and is largely recognized for his transformation of the company from a diversified holding company to the information services juggernaut it is today. He currently serves as my Partner and Chairman at our early-stage investment firm, Cue Ball. He and I recently had a conversation about the wisdom of applying big company lessons to small ones. Here are some highlights from that conversation:

After spending about a decade running a Fortune 500 – the world’s largest information media company – what motivates you to now work with early stage and small businesses?

Small businesses employ over half of all American private-sector employees and are responsible for most of the growth within the United States. Over the past decade, they have generated about 75 percent of new jobs annually. Most important, it is where our most creative thinking comes from. Still, most small companies fail because they have poor basic business practices. So I get excited about having the opportunity to mentor them and hopefully share some lessons. Think about it: it’s a lot more exciting to get a company from 0 to $100M than getting a billion dollar company its next $100M.

What is the biggest misconception people have between small and big businesses?

Most small businesses think that big companies have limitless resources and tons of money, and accordingly can do whatever they want. At the same time, most large companies think that all small ones are entrepreneurial, acting quickly, and bursting with creativity. Neither of these common beliefs is true. Most big companies do not throw a lot of resources at every project, and most small companies tend to become stagnant when they are through with their initial, entrepreneurial stage.

Give some examples of how you are applying big company lessons to the small firms you are investing in today.

The questions we asked ourselves while I was at Thomson are the same ones that every small business has to ask itself. At the end of the day, business is business. The size of the organization doesn’t matter. We all must understand our customers and the markets we serve, put the right people in the right places, and be sure the organization is aligned to deliver on our goals and objectives.

What strengths shold entrepreneurs focus on?

Small businesses have important competitive advantages. When founders are leading the company, they do so with an authentic passion to deliver on a vision. It’s their life. They know their business and customers better than anyone else, and this knowledge can be hugely leveraged with the right operational practices. A large company may have more money for research, but the leader of a small company almost always has more direct interaction with their customers. I am a huge believer that customer-driven strategies win over the long run.

What is the most significant challenge facing small businesses?

The biggest issue is how well the entrepreneur can scale. It’s important for entrepreneurs to realize that one person can’t control everything, that they can’t be VP of marketing, sales, operations, etc. That kind of mindset just won’t work in the long run.

How can an entrepreneur meet that challenge?

It’s important to let go – to trust people you hire – and to be okay with them making mistakes along the way. Even if a manager makes a decision 180 degrees in the wrong direction, it’ll probably be okay. Let them learn from their own mistakes.

What other lessons have you learned that would be helpful for small businesses and emerging leaders reading this?

Years ago I started a plumbing supply company with some partners. We did not have a lot of capital so we sometimes had to get creative on how we filled orders. We went out of our way to ensure that every order was filled, always. Sometimes, this meant getting the parts from competitors or buying at retail to complete the order. But that was okay. What mattered was never disappointing a customer. We had “Yes, we can” years before Obama did.

In addition to the customer-comes-first principle, I always had the motto that the higher you get in an organization, the harder you have to work. Success rarely happens on a nine-to five schedule. Also- dive into the important issues and from time to time “work the line” with other employees. The best way to shape people’s behavior is to inspire them by doing it yourself.

Finally, focus. Don’t sweat the small stuff. Save the intensity and for the most important company priorities and always make sure those are done first. To help make that happen, deal at most with five things at a time, and don’t put #6 on until #1 gets knocked off. You’ll definitely increase your chances for success.