Frameworks and libraries can speed up the development time and make code maintenance simpler, but it’s important you understand how they work.  It’s not just the framework itself but the entire footprint your application leaves when a user visits a specific page.  Ask yourself what’s involved from the database, to the code/framework, and then to the client through http requests.

After experiencing some issues with an application running the Zend Framework, I realized there were a lot of things I was not doing to optimize my application.  There are simple and more complex actions you can take to speed up your application.  Since time is precious, and developers with an expertise on optimization are not always available, I’ve split this post into two sections (simple and more advanced).  This post focuses on the simple part.

Simple tips and tools

1. Use Firebug with YSlow
   Firebug and YSlow are powerful tools to analyze the front end of your site.  Run the most common request on your site and see what YSlow says.  Expect a low grade, probably a D or lower.  If you can reach a level C or greater you’re doing really well as some of the requirements are not practical for most applications.

   How-to:
   Net: How many calls are there?  Try to minize these calls and definitely remove any 404 calls as they can eat up server resources.

   Console:  Do you have a lot of POST calls?  Some libraries, like dojo’s javascript framework, can make a lot of POST requests.  Reduce these if possible.

   YSlow: Rules I would pay attention to:
   1. Make fewer HTTP Requests
   3. Add an Expires Header
   4. Gzip components (server related)
   5. Put CSS at the top
   6. Put JS at the bottom (not always possible)
   7. Avoid CSS expressions
   10. Minify JS

   Resources:
   http://getfirebug.com/
   http://developer.yahoo.com/yslow/
   http://developer.yahoo.com/performance/rules.html

2. Minify Javascript and CSS
   Minification is the process of compacting your scripts by removing extraneous content such as white space.   In addition, minification can make attempts at refactoring the code to remove redunancies.  If you want to play it safe, only remove white space to ensure your code is still running. The Yahoo compressor is one of the best minifiers out there and reduces both Javascript and CSS by a significant percentage.

   How-to:
   java -jar yuicompressor-x.y.z.jar -o style_minified.css style.css

   add the “–nomunge” to only do whitespace compressions.

   Resources:
   http://developer.yahoo.com/yui/compressor/
   http://dojotoolkit.org/docs/shrinksafe
   http://dean.edwards.name/packer/

3. Merge css and js http requests- manually or automated
   Reduce the amount of calls you make to various CSS and JS files by merging them to one URL.  This is more work but will reduce the overhead.

   How-to – manually:
   This is really easy, take your css and copy and paste them together into one file.  Make sure your preserve the order of your css.  The same applies to your Javascript files.

   How-to – Automated – google or your own custom:
   Google has a php script which can take various sources and return them as one.

   Resources:
   http://code.google.com/p/minify/
   http://reinholdweber.com/?p=37

4. CSS Background Images are bad – usually
   Using a div for all of your images with a background image is not that great for performance as it requires more calls.  I’ll be the first to admit it’s my favourite way to design, but you should try to avoid them where possible.  In addition, for hover states try using one large image with background-position calls to show specific parts.

   How to:
   Use background-position to select which portion of the large image you want to show.  There isn’t much more to explain.

5. GZip
   Gzipping files on the server side will reduce the amount of overhead significantly.  It adds a bit more on the server side, but generally the pay off should be well worth it.

   How to:
   It depends on your server situation, but here’s a snippet:
   mod_gzip_on Yes
   mod_gzip_item_include mime ^application/x-javascript$

   Refer to http://snipplr.com/view/9017/gzip-your-components/ for details

   Resources:
   http://developer.yahoo.com/performance/rules.html#gzip
   http://snipplr.com/view/9017/gzip-your-components/

Conclusion
That wraps up the simple part of this tutorial… really, that’s it!  The focus of these posts is to keep them simple and easy to use.  You may be surprised at how much faster your application runs when you apply these techniques.  I hope you found these useful or at least agree that these are good practices to apply.  In the next part I will examine more advanced methods of optimizing your application.

Feedback
Your feedback is always appreciated.  In addition to commenting, if you have more resources, please add them to my growing list of links through this buncholink

It’s a simple way to organize a group of links together.

Without a doubt there are at least two faces to any open source publishing platform. There is the elegance of the code, and then elegance in the visual design. Sometimes it’s this difference between the ease of working with the source code vs. the ease of designing a visual interface that will account for why one boutique shop will roll out websites with online-community-type features in, say, Joomla, while another will roll out websites that do more or less the same things, but in another tool, say, Drupal.

Coming up with a sharp new design for a website is one thing, and implementing it into a working website is another – this is particularly true when it comes to taking a Photoshop mock-up and splicing it up to fit the markup and code generated by open source software. And unfortunately, there is no good way to get a good feel for this other than getting your hands dirty yourself, or talking to someone else who has (and whose skill level you know and trust).

When it comes to the design aspect of open source software, not all products were created equal – some open source products are easier to design for than others.

Drupal, for example, is infamous for offering incredibly powerful programming possibilities, but sometimes to the point where designing beautiful interfaces becomes a real challenge for even the best designers. Now that being said, there are some amazing sites out there that are driven by Drupal.

The other alternative that will be available to you is to turn back to the “source” and make use of some community-created templates (for example: Drupal Themes, or WordPress Themes). This is an excellent alternative, especially if you’re really under the gun to churn out a hot-looking site pronto. This can also be an incredibly helpful way to learn more about what’s involved in customizing the designs for the open source tool.

Key Design Skills for Customizing Themes and Templates

There are a few key skills that you’ll absolutely need to have “in-house” if you’re going to tackle any design work that touches the source code:

1. Expert Knowledge of CSS

Any open source software you download worth its lick will have templates that rely heavily on CSS for its overall look and feel. Knowing how to edit someone else’s CSS can sometimes be trickier than starting from a blank slate and creating a completely fresh stylesheet. Either way, you’ll need to have someone on your team who knows their CSS.

2. Familiarity with Templating engines

By “templating engines” I’m referring to things like Smarty or the overall framework for how Drupal or WordPress pieces together what becomes the template of your site. While it would be ideal to have the in-house knowledge of the exact platform you’re using, the reality is that different platforms have their own methods for creating the overall look and feel of their sites, so you’ll be just as well off with a generalist who is able to figure out how a particular platform pieces together the programming logic, markup, and styles. Just because you know one, doesn’t mean you’ll automatically know them all. But if you get the gist of how a template engine/system works, you should be able to adapt to figure out the others.

3. Past Experience Customizing a Design

Ok, this one’s admittedly a vicious circle – how do you leverage past experience if you don’t have any? Well this is where it comes back to how the only way you’ll REALLY learn what’s involved in customizing the design of an open source platform is to get your hands dirty and start trying it.

The point here, though, is that if, for example, you already have one or two people with past experience modifying a WordPress template whereas no one has yet tackled a Drupal theme, this should really weigh in on your overall decision-making process of what tool to use. It’s nice if you have the time to learn the new tools, but if you’re pressed for time and need to roll out what you can by the deadline, go with what you know.

4. Past Experience Implementing & Modifying Extended Themes/Templates/Plugins

There are a lot of really good – and freely available – templates that others in the community have created and shared. And what you may quickly find out is that your time will be better spent taking one of these extensions of the core templates, and then making the customizations on these rather than the original default templates.

This, again, is an area where past experience will do you well – you really won’t know (and can’t appreciate) how hard or easy it will be to implement and then modify an extended theme or template until you’ve gone ahead and tried it.

Similar to how you should be selective of which plugins and modules to use, you can apply the same measures to help you be selective of the themes and templates you set up for your site – how active is the template designer? What sorts of questions are being asked by others who are using the template? Is the original template creator still using the template themselves?

These are just some thoughts, tips, suggestions. What do you think? What else would you be looking for in a designer? What would you want to know before diving into redesigning an open source template?

“I think the page is too narrow. I hate it when I have to scroll through pages and pages of content,” says one person.

“Hmm. Yeah, but, I don’t know…I don’t like it when the page is too wide….makes it too hard for me to scan the text,” says the other.

“Well, yeah, sure, but well. I just think it looks better when it’s a little wider.”

“Well how wide do you think it should be? It’s actually filling my whole browser window right now.”

“Oh really? I’m looking at it on my laptop and it’s not.”

“Well it’s filling it on mine.”

And on it goes…

It can catch you off guard, and it can be delicate to tip-toe around what you really want to say: “What you yourself personally think doesn’t really matter! (unless you have something more to base that opinion on).”

So what can you do to better prepare yourself for the design presentation? How can you arm yourself with the right tools to walk into a meeting confident that you can politely, and yet assertively, re-affirm the decisions you made with coming up with your design?
One of the best ways to confront – and also pro-actively deal with – the rise of personal opinions in a design discussion is to arm yourself with some good solid data, and web statistics are one of the best ways to do this.

Opinion vs. The Informed Web Design Decision

Web statistics are helpful for making informed decisions about the design, development, and on-going maintenance of your website.

Rather than relying on personal preferences or anecdotal observations, statistics provide a broader and more objective context for helping you make decisions that will best accommodate the needs of your online audience.

Web statistics can help you decide:

• how wide (or narrow) to make your web template
• when to separate content into separate pages or when to use anchor links in a single page to make sure content isn’t lost “below the fold”
• when to change your page layout or add new design elements to aid with navigation
• what tools and technologies you can reliably expect your audience to be able to use (e.g. Flash)
• what time of year/month/week/day to complete major site-wide changes

Statistics will not make decisions for you – but what they do is provide you with information that you can then make a judgment on.

For example, if you find out that only 3% of your web visitors are using browsers with a resolution of 800×600 pixels or less, you could now consider the impact of creating a fixed-width template at 1024 pixels wide (giving you a controlled and relatively large page to work with) vs. a fluid-width template (giving you a less-controlled but more flexible and adaptable page).

For any design decision, there are always pros and cons. But with web statistics, you will at least be able to make informed decisions on what the benefits and trade-offs are rather than relying one person’s opinion.

Tooltips are nice small additions that can improve the user experience. They are so common that Dojo and other javascript frameworks provide precanned ways of creating them. In dojo, they provide dijits (their widgets) that can do some amazing things on the user interaction side. That being said, when you want to customize them in any way, you can run into many walls.

Dojo tooltip

Problem & Goal of this Article

The main goal of this article is to show you how to stylize the tooltips so that you can create your own type of tooltip. This article will go through the css required and how to structure your code so that you can create more than one tooltip.

To extend the style of dojo’s dijit, it’s best to copy one of the existing themes and create your own custom theme. In this tutorial, I’ve copied the “tundra” theme so all the following css code will use the “tundra” selector. You could replace the tundra selectors with your own custom name, but it may be more work than it’s worth.

Prerequisites – tools you’ll need setup:

• Firefox
  You should have this
• IE 6 or IETester
  You’ll want to make it IE6 compliant right? Or maybe not…
• Firebug
  Every developer and especially UI developer should have this.
• Dojo framework setup
  Follow their documentation on setting up the includes

The Steps

1. Setup a new theme
-Open up the dojo dijit theme folder
-dojo-release-1.1.1dijitthemes
2. Create a copy of the “tundra” folder.
3. Rename it to the name of your theme. (e.g. – “tundraextended”)
4. Include the dojo style and your extended theme in your header code:

<style type=”text/css”>
@import “pathtodojo/dojo-release-1.1.1/dijit/themes/tundraextended/tundra.css”;
@import “pathtodojo/dojo-release-1.1.1/dojo/resources/dojo.css”
</style>

5. Include the tool tip dijit:

<script type=”text/javascript”>
dojo.require(”dojo.parser”);
dojo.require(”dijit.Tooltip”);
</script>

6. Add the tool tip code

<body class=”tundra”> <!– you need to set the body to load the dijit styles –>

<a id=”theId” href=”#”>Hover over this</a>

<div dojoType=”dijit.Tooltip” style=”display:none” position=”left” connectId=”theId”>
<div class=”custom_tooltip”>tool tip content</div>
</div>

Note the attribute “position=left”. This should remain the same for all tooltips that are defined by the inner class “custom_tooltip”. I don’t really use the position attribute and rely on css position.

At this point you should have a simple tool tip hover when the mouse goes over the link. If you don’t, then open up firebug and see if you have any errors. If you do, then you most likely didn’t setup dojo properly.

If all is good now, then you have a nice basic tooltip. Now, the hard part is how to extend the look:
7. Create a new css file – dojoextended.css
This style sheet should be included last. As its name suggests, it extends (overrides and resets) the dojo stylesheet.

<style type=”text/css”>
@import “pathtodojo/dojo-release-1.1.1/dijit/themes/tundraextended/tundra.css”;
@import “pathtodojo/dojo-release-1.1.1/dojo/resources/dojo.css”
@import “pathtocss/dojoextended.css”
</style>

8. Add the following css to the extended css file

/*Reset the generic tooltip container */
.tundra .dijitTooltipContainer
{
background:none;
padding:0;
margin:0;
border:none;
height:auto;
width:auto;
}

/*defines the div inside the tooltip – your custom tooltip*/
.custom_tooltip
{
/*this defines your tooltip*/
position:relative;
left:5px; /*use left and top to position it */
top:15px;
width:125px;
height:100px;
background-image:url(”yourimage.png”);
}

/*if your tooltip uses transparency, define a ie6 specific one below */
.dj_ie6 .tundra .custom_tooltip
{
background-image:url(”yourimage_ie6.png”); /*an 8-bit png*/
}

/*hide the connector – an arrow that connects the tooltip to the hovered item */

.tundra .dijitTooltipAbove .dijitTooltipConnector { background:none; }
.tundra .dijitTooltipLeft .dijitTooltipConnector { background:none; }
.tundra .dijitTooltipBelow .dijitTooltipConnector { background:none; }
.tundra .dijitTooltipRight .dijitTooltipConnector { background:none; }

You’re done!

You can now create as many styles for your tooltips as you need by defining a specific div and a new style (e.g. – custom_tooltip2). You will likely have to do a lot of tweaking on the positioning image, but it’s pretty straightforward when you look at it. The longest part is determining which css selectors you need to use, if you look at the tundra.css class you’ll notice there are more selectors I didn’t look at.

Pros

-Quick to code.
-Easy to understand, there’s only one div to deal with.
-IE6 compliant. It’s always a bonus .
-Extendability. You can now create as many tooltips as you want for one project. With the standard tooltip, you would be stuck with one tooltip for an entire project.

Cons

-Inefficient: Resetting styles is cumbersome and requires more data to be loaded.
-Upgrading dojo could break the custom tooltips if they change the way the tooltip are rendered.
-Tooltipconnector: I didn’t use the tooltipconnector which allows you to position the tooltip in various positions easily.

Conclusion
That wraps up the first tutorial on dojo. I hope you found it useful, and I appreciate all feedback. If you have a better way, I would like to know about it. My next article will look at how to combine dojo’s ajax with the zend framework.