1. 10 Useful RSS-Tricks and Hacks for Wordpress - Smashingmagazine
   Great tips for any user of wordpress that relies on RSS for syndicating content.  Most of these tips show you how to gain more control over your RSS feeds.
2. 5 good programming habits in PHP
   General rules of thumbs for php programmers.   Some of the rules may make you think twice, like the rule of “Never copy and paste”.
3. What is More Important To Succeed Online:  Business or Technical Skills?
   A question for the ages, at least in the IT field, is it more important to be business or technical minded?  A very interesting article on how these skills have attributed to the success of several companies.
4. Firefox 3.1 beta news - web workers
   A CNET article on Firefox 3.1.  The interesting part is how “web workers” can process work in the background.  Background processing would push the RIA movement further and I’m sure would lead to some very novel ideas from early adopters.
5. How to Setup a Dedicated Web Server for free - with Ubuntu
   A practical and useful article on how to setup a web server.  This is a very well written article that shows how far Linux has come in terms of ease of use.
6. How to use Twitter as a tool
   An article by Guy Kawasaki on how to use Twitter for productivity.  It’s a very detailed post and for those new to Twitter, it explains the utility factor of Twitter beyond just being a gossip tool.
7. Online Advertising and Its Impact on Web Design
   An excellent article from Smashing Magazine on how online advertising affects web design.  It’s an interesting topic as web advertising is a primary means of revenue for the majority of blogs.
8. Top 10 Web Dev Blunders of 2008
   A list of some of the biggest “mistakes” we’ve seen on the web this year.
9. Who Protects The Internet?
   Who does protect the Internet?  This article should be of interest to anyone who uses the Internet, so that’s a lot of people.  Techcrunch takes a go at reviewing where we are with the Internet.
10. Referrer Detector Wordpress Plugin
    A great wordpress tool to greet your users coming from specific sites.

I hope you find these articles useful.  You can contribute your own links by visiting this buncholink which groups related links together in a useful manner.

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.

At work the other day, I was forwarded an email with a co-worker asking for my thoughts to a question. The question went along the lines of: “How many emails in a defined time period should we be sending to our customers? How many emails is too many?” My answer? One!

But really, how many emails is too many?

Here were my thoughts on the matter.

When people sign up for a mail-out, it’s likely because they are:

• curious as to what they’re going to receive
• interested in something they saw from a related communication
• enticed by some sort of incentive, or
• doing a competitive analysis to see what other organizations are doing with their mailouts, or trying to get their hands on an HTML email template they can use as a basis for designing one for themselves

As long as that person gets something valuable out of the mailing, they’ll stay subscribed.

When do they unsubscribe? Anyone read The Tipping Point by Malcolm Gladwell? I think people unsubscribe when a series of things happen that tips them over the edge:

1. They receive a message that doesn’t have any content that speaks directly to their interests, and
2. They receive similar messages from other sources (either from you or from completely different lists they’ve signed up for), and
3. They look in their inbox and suddenly see it’s getting full of emails that they don’t need or want or have any useful need for

Once those 3 things happen, they’ll be on the verge of unsubscribing and all it will take to push them over the edge is one more email from you on a day when their inbox is already really full. So to answer, “How many emails is too many?” in this case it really is just one!

The Key to Email is VALUE

Often a company will be sending out regularly scheduled emails - for example a monthly newsletter or a weekly update of recent discussions in their online forums. In general, these will be well-received provided the recipients signed up to receive the mailings.

In many other cases, though, people will still sign up to receive e-newsletters, not know for sure how often or when they’ll receive the email.

In general, when you send an email to someone and they aren’t expecting it (for example, they didn’t sign up to receive a regularly-scheduled mail-out or they didn’t first send you an email expecting a reply), it stands to reason that they’ll be surprised when they receive your message. People like surprises when they get something. People don’t like surprises when they are asked for something.

So following this line of thought, if you’re sending mail-outs that people aren’t expecting, you’ll want to make sure you are giving people something that is of value to them (i.e. something that’s meaningful, relevant, generally interesting to them, or has actual monetary value).

But what about the “should” from a marketer’s standpoint?

On the flip side of all this is the perspective of what you “should” do to help build your business and your brand. And on this side of the communications, you “should” be sending out as many emails as it takes to keep your existence in people’s minds.

You’re competing for their attention and need to do what you can to keep it when you get it. But that doesn’t necessarily mean you need to send a lot of emails - it could just mean you have to send them one or two a month that will grab enough of their attention to get them to visit the website.

Provided you then have something of value on the website, that will be enough to keep them coming back or it will at least be enough to stop them from going away the next time you send them another message.

What about email marketing usability?

As far as usability goes, Jakob Nielsen is talked about a lot in circles of usability. The guy drives me nuts sometimes, but he also often has useful (or at least thought provoking) info on emails, for example check out these links:

What do you think?

There’s no place for unsolicited email, but what about semi-unsolicited email? What kind of emails do you like to receive? What do you value when it comes to email offers or promotions? What drives you up the wall and prompts you to unsubscribe?

First, It Was the iPhone

A handful of things have changed in the handheld landscape in the last few years. For one, Apple introduced the iPhone that rolled out with Safari installed on the phone. To the average consumer, having a web browser on their mobile phone gave it a nice “oooo ahhh” touch (pun intended). Suddenly you could browse around websites and it would actually look similar to what you would see on your computer. For web designers and developers, this is a much more monumental change than we, as a community, have given it credit for.

With a full-fledged web browser now installed on something like an iPhone, the barrier of entry has just been significantly lowered to offer web-based services for small-screen, portable devices. While the iPhone still has relatively small market penetration, it’s the first push towards truly leveraging the community of web developers and entrepreneurs into the handheld world.

And Then Came the GPhone (Android and Chrome)

The next big step is coming from Google - and it’s actually two or three smaller steps. The first step started with the work happening around Android - Google’s open source operating system for handheld devices. Starting with their acquisition of the Android team back in 2005, Google has clearly been planning a move into the wireless/handheld device world for at least a few years. Rumours surrounded this move, with many suggesting that Google would be unveiling a “GPhone”. It may have taken a few years, but sure enough, Google will be unveiling a phone, running off of Android, in the coming weeks.

The other big step is one that has garnered a lot of attention - the release of Chrome, Google’s web browser. While the attention around Chrome was largely surrounding the new features that would make Chrome stick out from today’s standard of web browsers like FireFox, IE, Safari, and Opera, little attention has been given to the potential impact and perhaps the real value of all this for Google.

By first rolling out an open source OS for mobile devices, and then also rolling out an open source browser, and now packaging it all into their own phones, Google will be making a strong push to establish itself in the world of mobile devices.

iPhone, Android, Chrome - What Does This Mean For Web Professionals?

Here are some thoughts and suggestions:

Learn How to Design for Small Screen Interfaces

A good place to start would be to do some Googling on “designing for handheld devices” or “designing for small screen interfaces”. There has been a lot of talk in this space for a number of years now, and even though earlier discussions would tend to revolve around the challenge of designing for 100 different versions of handheld web browsers, the underlying principles of design will hold true now as much as they did then.

For example, you might want to check out this buncholinks on designing for small screen interfaces:

Make Sure Your Current Websites Render Properly in Chrome and Safari (as well as FireFox, Opera and…well, ok…IE too)

Even though both Safari and Chrome are developed using WebKit - an open source web browser engine - sites are reportedly being rendered differently in each. As web designers, we aren’t in the clear yet - you’ll still need to do cross-browser testing. But at least now when you do it for Chrome or Safari, you’ll know what your website will look like in a handheld device as well.

Look for New Business Opportunities in Mobile Devices

Think about what opportunities are out there to merge the types of things you’re building on the web, with the types of things you already personally do on your own mobile device. Think about the things you could start doing now with near ubiquitous access to the web. For example, have you heard of Tagga?

Rethink How Your Website Is Going to be Used

As the Google phone and the iPhone gain more market share, there will inevitably be more people browsing the web through small screens. Take a look at your website right now (through an actual iPhone if you can), and do a quick assessment of how your website is going to perform for your visitors. If you’re about to embark on a new site redesign, you may even want to consider factoring in design for small screen interfaces as one of the requirements (even if it’s a secondary or “nice to have” requirement).

Keep A Close Eye on Your Web Stats

We’ve already started to see the first hints of web visitors peering at our websites through the eyes of tiny interfaces. In the stats, these show up as screen resolutions somewhere in the neighbourhood of 320×240. Keep an eye on the relative percentage of visitors you have that are checking out your site through these small eyes. Most right now are probably just curious what your website looks like on their shiny new phone, but soon enough these people will be legitimately trying to use your website through that small screen, they’ll also soon be expecting to see the same standards on that small screen as what they see on their 15.4″ monitor, and eventually the bigger players in the web will be catering to this - so you don’t want to get left behind!

The Bottom Line

The world wide web is about to get an awful lot wider - and it’ll be in large part thanks to the true arrival of the web onto smaller and smaller interfaces. With web2.0 apps that bring software-like functionality in byte-size packages, all processed through the power of cloud computing, it won’t be long before the power we now see on traditional computers gets leveraged through mobile devices. The change is coming - the question is what are you going to do about it?…And are you ready?

Reason 1 - Planning for Usability Testing Helps Keep Your Project On Track

Even if it only gets one row in the GANTT chart, having usability testing as a step in your overall project plan will give you a tangible goal to work towards that will help you move forward on your overall project.

In order to run any form of usability test, you will need to come up with mockups or prototypes of some form - be it crude Photoshop mockups or paper prototypes, or functional wireframes with a bare bones design - you need to have something to run the test on.

In this respect, having usability testing as part of your project plan helps break your big project down into smaller, more manageable chunks, which in turn helps you keep on top of your progress.

Reason 2 - Usability Testing Will Teach You Things You Didn’t Know Before

If you get a chance to do usability testing with a good variety of your targeted end-users, you may be surprised at what you find. Quite often, new insights come from watching someone use your website. What was natural and intuitive to you and your team suddenly doesn’t seem so logical when 4 out 5 of your testers can’t complete the task you originally set out for them to do.

Usability testing also gives your site a fresh set of eyes to help uncover new ideas and even possibly new features to add to your site. Sometimes it’s just a passing comment from one of your testers that might spawn the idea for a new core feature that you would never have thought of on your own.

You and your team probably also have some hunches on what will work with your target audience - maybe it’s something like a colour scheme to something more complex like the steps required to recover your username and password. Usability testing gives you that feedback to confirm your hunches.

Reason 3 - Usability Testing Gives You Data to Back Your Decisions

Unless you’re working on a personal project without any real accountability to another stakeholder or client, odds are the website or application you are working on will have to go through some levels of approval and sign off. In this process, you will be questioned about a design decision or asked to squeeze something else in. For example:

• Why is the font so small?
• Is there a reason why we can’t use the full width of the page?
• We have another 12 links that need to get into the sub navigation. Where can we put them in?
• That link down there needs to go into the top row of links on the homepage. Why isn’t it there?
• The photo on the homepage needs to be bigger. Like, way bigger. Like, ten times bigger than it is right now.

Usability testing has the potential to give you instant data to help back your design decisions. Armed with information gleaned from watching real people actually use your site (or working prototype), you will have greater credibility and more to stand on than just your opinion. Usability testing will give you real metrics you can use to support your position.

Reason 4 - Usability Testing Gives You Documentation that You Can Re-use for Future Projects

If you do a good job of documenting the findings from your usability testing, that whole process itself will serve as a valuable start the next go-around. Depending on the type of project and work being done, you may even be able to use the findings from previous tests to help get you and your team off on the right foot moving forward on your next project.

Similar to how usability testing gives you data to help defend your decisions to clients and stakeholders, that same data arms you with some information that you can use yourself. This is particularly useful when you’re confronted with making a seemingly arbitrary decision during your design phase.

Having a completely blank slate with endless possibilities and no constraints can actually be a very challenging and even frustrating space to design in - this is when arbitrary decisions are at their worst. It’s much easier to make a design decision when you have some form of constraint or guideline, really anything that can set you in one direction. And this is exactly what previous usability testing results can sometimes provide. With some baseline information on what worked and what didn’t work in the last design, you now have a starting point for this next design.

Reason 5 - Usability Testing Gives You an Opportunity to Field Test New Ideas

Usability testing doesn’t have to always be about testing something you’ve created. In fact, quite often, you could use the same exercise to test something that is, at this stage, nothing more than an idea.

In sales they would call this something like the foot in the door technique where you get someone to agree to a large request by first having them agree to a smaller one. What you’d want to do here is a little less sinister and more along the lines of trying to make the most of this valuable time you have with and end-user of your site.

Run your usability test and get your data, but then also try running some of your as-of-yet-unproven ideas and see what sort of feedback you get.

Face it, there’s definitely some administrative overhead that comes with running usability tests. If nothing else, there’s the simple task of scheduling and taking the time from people’s days to get them into the sessions. You might as well make the best use of this time and use it as a real opportunity to uncover some of the most valuable information you’ll get.

But Wait, There’s More!

This is all fine and dandy, but let’s bring this back full circle - what if you’re under a tight timeline, or don’t have the budget to get a robust usability test into your project cycle? All this is a lot of fluff if you can’t actually run the tests.

Well, usability testing doesn’t have to be that hard, and it can be done at any time in your development lifecycle - even after you’ve launched. You probably already engage in some form of usability testing yourself when you’re building your websites or applications, probably without even realizing it. We’ll go into these and other topics in the coming weeks.

In the meantime, let me know what you think! Why else would you do usability testing? Or why shouldn’t you do usability testing? If you’ve wanted to do usability testing before, why haven’t you? What’s holding you back?

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?

In this post, I will discuss 5 tips and tools that the php community has provided to speed up development time and improve code quality.  These should help you out if you don’t already know them, but if you do I would like to hear what you use to speed up your development time.

1. Framework with the Model View Controller (MVC):
   This is old news, the MVC pattern is an industry accepted pattern to improve the organization and overall quality of your code.  Put your database code in the model layer, visual UI code in the view, and business application logic in the controller.  If you don’t know the MVC layer, you really should.

   My choice: Zend Framework
   Why?  Easy to pick and choose what you want to use; strong momentum behind it; good documentation.

   Resources:
   http://framework.zend.com/manual/en/zend.controller.html
   http://www.cakephp.org
   http://www.symfony-project.org
   http://codeigniter.com/

2. AJAX Frameworks:
   Also old news, you should become familiar with a common AJAX framework.  Scriptaculous, mootools, jquery, and dojo to name a few… these frameworks can all do similar things and will make your clients go ooh and ahh.  Actually, these days AJAX interaction is become standard.  Being a Zend developer, I would suggest acquainting yourself with the Dojo framework.  It’s probably the largest and most complex of them all but is very powerful.

   My choice: Dojo
   Why?  Zend has adopted it into the zend framework; easy to extend; large resource of reusable widgets to use.

   Resources:
   http://en.wikipedia.org/wiki/Ajax_framework
   http://www.phpframeworks.com/
   http://mootools.net/
   http://jquery.com/
   http://script.aculo.us/
   http://www.prototypejs.org/
   http://dojotoolkit.org/

3. Integrated Development Environment (IDE):
   I won’t go into much detail here, if you’re developing objected oriented code or using a lot of libraries you should get a good IDE.  Eclipse PDT is my favourite because it’s free and has some very useful plugins to extend it.  My basic requiremnts are resource/file management of libraries, auto completion, basic syntax validation, and basic debugging tools.

   My choice:  Eclipse PDT
   Why?  It’s free and provides all the basic features an IDE should have.

   Resources:
   http://www.eclipse.org/pdt/
   http://www.zend.com/en/products/studio/
   http://www.ibm.com/developerworks/opensource/library/os-php-ide/index.html

4. Database Creation/Management Software:
   Managing a database schema can become tedious error prone thing to do.  If you don’t have a dedicated database team, and in many cases are the web and database developer, then you should be doing more than handling your schema in mysql (or your database of choice).  MySql has recently released workbench, a database management software that is really powerful.  I prefer DBDesigner 4 right now because it’s simple to use and feeds into propel db well.  But I plan on moving over to workbench in the near future as it’s really the continuation of DBDesigner.

   My choice:  DBDesigner, but not for long.
   Why?  It’s simple to manage your database schema visually and exports well.

   Resources:
   http://dev.mysql.com/workbench/
   http://fabforce.net/dbdesigner4/

5. Object Relational Mapping (ORM):
   If you don’t know what this is, it’s basically a way of mapping your database tables to objects.  It’s so you don’t have to think about how to connect your logic/business code to the database.  Also, if you use tools like Propel DB you don’t have to code this as it generates it all for you.  While your application may not perform as well as with straight SQL, you will code faster and you can find ways to tweak bottle neck cases.

   My choice:  Propel DB
   Why?  It’s easy to use and integrate into the zend framework; There aren’t many other options.

   Resources:
   http://en.wikipedia.org/wiki/Object-relational_mapping
   http://propel.tigris.org/

Wrap Up / Further thoughts

I hope this was useful for you.  Everyone has their own combination that works for them, and in a lot of cases the company forces you to use one.  Where I work, we can use whatever combination we want and I know there are many.  I would like to hear what your setup is like, what IDE, framework, and OS works for you and why?

Comment/Get the links for this post here:

“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.

Part of the point of open source is that you don’t have to be a Compu-Global-Hyper-Mega-Net nor a super programming ninja to get up and running with pretty powerful software. Open source increases access to the technology which in turn helps it grow. But “open source” doesn’t mean “free”. It’s free in the sense that you don’t have to pay a license fee to use the software, but there are still costs associated with running open source software. Other than basic infrastructural costs you’ll have for hosting any website, there is the added cost of the time it will take you or your developer to learn the tool.

What’s Your Time Worth?

It’s cliche because it’s true, but time really is money. The time you or your developer spends in learning the intricacies of an open source tool may pay dividends down the road - at least if you end up going with the tool that you spent all that time to learn. But the time you or your developer spends in learning the tool may also turn out to be a sunken loss if it turns out that you can’t use the software in the end. Sure, it’ll have been a good learning experience, but there’s only so much learning you can afford to do before you’ll need some bottom-line results.

Time becomes an even larger factor when it comes time to selecting and implementing plugins or modules. With each plugin or module you add, you start branching yourself off into a smaller sub-set of the larger community. If you customize the software yourself without contributing your modifications back to the community, you’ll be branching off even further. What you want to avoid is deviating so far from the core community that you end up on an open source island all to yourself.

Don’t Be Scared, Be Selective

The point here isn’t to avoid plugins, modules, or customization. In fact, it’s this extending of the core software that often delivers the kind of features that really draw in the growing masses of users. The key, though, is to be selective with what you implement.

The best time to pick-and-choose plugins and modules is early in the game when you’re taking the first steps in planning your site. And in fact, there are a few ways you can go about doing this.

Method 1: Draft up your list of all the features you’re looking for, then go hunting for a plugin/module that does it.

Method 2: Search-hunt-browse through the available plugins, modules, demo sites etc. and see what’s available. You may even get some new ideas for what you want to do with your site based on what you find.

Method 3: Do both of the above, and if you can’t find a plugin/module that does it, consider building it yourself! (Or contracting out someone to build it for you.)

You’ll likely end up doing a little of 1 and 2 (if you’re considering Method 3, you probably stopped reading this article a long time ago). No matter what, it never hurts to give a plugin or module a quick dry-run or pilot it on your development environment or sandbox - you can learn a lot very quickly just by trying to get it all set up, working (and looking) the way you want it to.

Do Your Homework, Do Your Due Diligence

When you evaluate these extensions, be sure to visit the sites from the plugin/module authors. When did they last update the plugin/module? What sorts of bugs have been reported? What kinds of comments are others submitting? Is the author actively using the plugin/module on their own website?

Depending on your technical knowledge, you may also want to take a look through the source code itself. If this plugin or module is going to become a core piece to your overall website, do you understand what’s happening well enough so that if you ever had to, you could be the one who maintains the source code as newer versions of the larger open source tool are rolled out?

Some Popular WordPress Plugins

• WordPress.com Stats - the same stats plugin running on WordPress.com
  
• cFormsII - a form-builder plugin
• podPress - to add podcasts to your blog

Ok, the Gears are Turning, but What About Making it Look Hot!?

While you assess the core functionality, the plugins or modules, along with your ability to support and customize these, you’ll also want to consider how far you can take the visual design - i.e. Step 3: Determine Your Capacity for Internal Design Work (coming up next in this series of posts).

If you have been following the Zend Framework at all, you’ll know that Dojo has been selected as the UI library to be adopted into the Zend Framework. The question is what does this exactly mean? I’m still trying to figure out how they are going to use dojo, but right now with release 1.6 you can create dojo widgets (e.g. - date pickers, currency boxes, specialized buttons etc…) in code with the Zend_Dojo object. That being said, you still need to learn a few more things to create a useful and reusable AjAX framework with Zend.

The Goal

This tutorial will explain how to create a reusable UI AJAX layer with dojo that communicates to the Zend controller class. I’ll provide some basic code that will show you one way of creating a reusable framework that makes it easier to organize your javascript/ajax and controller layer.

Prerequisites

Before you proceed, you’ll need to read up on how to setup the Zend MVC framework.

• Zend Framework with a MVC structure
• Dojo framework

The Steps

1. Setup the Zend Framework and a MVC structure

2. Create the controller class file (e.g. - MidstrideController.php)

3. Create the view folder “midstride” in the view/scripts directory.

4. Create the file “index.phtml” in the midstride views/scripts folder.

5. Create an empty javascript file called ajaxmethods.js and place it in your javascript folder.

-check up-
Your file structure should look something like this now:

-/application/controller/MidstrideController.php
-/application/views/scripts/midstride/index.phtml
-/www/javascript/ajaxmethods.js
-/www/scriptslib/dojo-release-1.1.1

Where application is your MVC folder and www is the directory for your assets and index.php bootstrap file.

5. Add the javascript code to the header of index.phtml

 

<script type="text/javascript" src="<?php echo $this->baseUrl; ?>/javascript/ajaxmethods.js"></script>

<script type="text/javascript" src="<?php echo $this->baseUrl;?>/scriptslib/dojo-release-1.1.1/dojo/dojo.js"         djConfig="parseOnLoad: true"></script>
<script type="text/javascript">

dojo.require("dojo.parser");

</script>

In this case, the baseUrl is a short cut variable defined in your controller class
e.g. - $this->view->baseUrl = $this->_request->getBaseUrl(); //gets the root of your application

6. Add some sample form information to index.phml

 

<div id="status_message"><!-- ajax messages go here--></div>

<form id="ajax_form">

<input type="text" name="test_input" value="12345" />

<input id="submit_button" type="submit"

value="submit"

onclick="formPost('<?php echo $this->baseUrl ?>/midstride/ajaxcall',"ajax_form","ajax_loader","submit_button") />

<div id="ajax_loader" class="ajax_loader" style="display:none;"  />

</form>

This form will call the javascript function “formPost” with the id of the ajax loader which is currently hidden. The next step is to define the javascript function which will do the ajax call.

7. Code a reusable javascript ajax function

 

function formPost(destinationUrl, formId, loaderId, submitId)

{

var useAjaxLoader= true;

var hideSubmitAction = true;

if (loaderId===undefined) {     useAjaxLoader = false; }

if (submitId===undefined) {     hideSubmitAction  = false; }

var postParams = { url: destinationUrl,

load: function(data) {

dojo.eval(data);

//hide ajax loader

if (useAjaxLoader)    { dojo.byId(loaderId).style.display = "none";}

if (hideSubmitAction) { dojo.byId(submitId).style.display = "";} },

error: function(data) { console.debug("An error occurred: ", data); },

form: formId,

timeout: 4000,

headers: { "X-Requested-With": "XMLHttpRequest" }

};

//show ajax loader

if (hideSubmitAction) {dojo.byId(submitId).style.display = "none";}

if (useAjaxLoader)    {dojo.byId(loaderId).style.display = "";} //block

dojo.xhrPost(postParams);

}

There’s a lot going on in this code but it’s not that complex. In short:

• destinationUrl = the HTTP address you want to call (a controller action method).
• formId = the id of the form that is making the call.
• loaderId = the id of the ajax loader (optional)
• submitId = the id of the submit button (optional)

The loaderId and submitId are used to show a loading icon and hide the submit button. This provides the nice ajax feedback and makes sure the user doesn’t click twice.

The destinationUrl is the same address as in the GET or POST URL. We need to pass the formId so that the parameters can be passed. I’ll explain at the end other ways of passing parameters.

8. Create some sample php code in the controller class “MidstrideController.php”

 

[in MidstrideController.php]

public function ajaxcallAction()

//only handle ajax calls

if ($this->_request->isXmlHttpRequest())

{

//don't render the page - no view script is needed{

$this->_helper->viewRenderer->setNoRender();

//json is the intermediate language to pass messages between the server and client

$jsonData = "";  //initialize to nothing
//get the parameter as normal

$testValue = $this->_request->getParam("test_value");

//prepare a fancy highlight response back

$jsonData =  "var highlight = dojo.animateProperty(

{

node: 'status_message',duration: 500,

properties: {

color:         { start: 'white', end: 'black' },

backgroundColor:{ start: '#fffecc', end: '#ffffff' }

}

});highlight.play();"

$this->_response->appendBody($jsonData);

}

}

This action method listens for the ajax called made by the javascript function. It only deals with XmlHttpRequests (AJAX) and then sets the controller to not render anything. The no rendering option means you don’t need to create a view (phtml) script. Next, you just handle the form data as you would normally and prepare a JSON response to send back. In this case, I’ve prepared a dojo animation to make a nice highlight on a status box. In practice, you may not want to include any javascript in your controller class, as this is technically UI logic that could be in the ajax (JS) layer. I prefer including dojo javascript because I don’t like writing javascript :).

The last call $this->_response->appendBody($jsonData) returns a javascript string which is evaluated in your javascript function by dojo.eval(data).

You’re done

That’s it! You now have a simple way of making ajax calls and keeping your main logic in the controller layer, where it should be. If you wanted to pass more parameters to the controller class, you would have to modify the formPost() function to have this:

contentParams = { “paramOne”:”1″,”paramTwo”:”2 };

and then pass this to the var post params like:

var postParams { content:contentParams, …other parameters}

This can be useful when you have hidden values or other non traditional form inputs to pass in.

Pros

-8 steps to a reusable ajax layer.
-You can easily customize the ajax post effects with dojo’s large animation library.
-A very customizable and flexible framework for any project.

Cons

-Technical level: It can take a while to learn the MVC and Dojo library.

Conclusion

That wraps up my first article on AJAX and the Zend Framework. Future upcoming AJAX articles will discuss how to integrate Zend in scenarios where you want a real progress bar, modal popups, and captcha services. Please let me know if you have any comments or questions.