Tag: kranthi

“But The Client Wants IE 6 Support!�





 



 


Frequently, when I discuss CSS3 with other developers, the issue of stubborn clients comes up. They tell me that even though they personally don’t think a website should look the same in all browsers and they’re eager to try all of these new techniques, their clients insist that their website should look the same, so the developers are stuck with the same Web development techniques that we used five to ten years ago. Their clients just don’t “get� graceful degradation.

Is this really the issue? Are our clients incapable of understanding these things? Is the problem that our clients don’t “get� the Web and need to be educated? I don’t think so. We got ourselves into this. We are the ones who caused this problem for our industry. We are the ones giving ourselves this trouble and making our profession less creative and enjoyable than it could be. It’s entirely our fault and no one else’s.

Wait, What?

If we choose to make a website pixel-perfect in Internet Explorer 6 to 8, then we are doing up to 100% more work. No matter how many frameworks, polyfills and other scripts we use to ease our pain, we will always be doing at least 30% more work for those browsers. How many of us actually charge 30-100% extra for this work? I haven’t heard of many who do. Clients get this kind of extra work for free, so of course they will say that they want IE 6 support. If I was a client, maybe I’d say so, too, especially if I didn’t know how these technologies work. They won’t care about our extra time if we don’t care enough ourselves to charge for it accordingly.

Of course, faster download times and better SEO are compelling arguments, but let’s face it: one of the biggest advantages of the new CSS features and new JavaScript APIs is the huge chunk of development time they save us, including making maintenance easier and quicker. As long as that doesn’t translate to reduced costs, clients will not care. And that’s perfectly understandable and natural.

Money always wins.
Money always wins the argument. (Image: HikingArtist)

I don’t do much client work these days, but every time I’ve taken on a client project in my career, I’ve always presented options for browser support to my client. They want pixel perfection in IE 7? It will cost them more. They want IE 6 support? It will cost double. I explain to them that this is because I will have to do double as much work for this browser. I’ve never had a single client opt to pay more to fully support older browsers. If it doesn’t come free, you’d be surprised at how many don’t care about it as much as you think. But even if they do, at least I will have enough motivation to do it without hating them, my job, browser makers and the universe. It’s fairer for everyone, including me.

“They’ll Just Go To Another Professional Who Doesn’t Charge Extra�

Whatever you do, don’t let the client think that you are charging extra for doing the same work as another professional. Not only will that look bad, but it’s also inaccurate. Explain to them that you just want to give them options and not decide on your own which browsers to support and charge for accordingly, without ever involving them in the process and letting them have a say about it.

How Much More?

You might have noticed that I implied above that supporting old Internet Explorers requires 30 to 100% more time. That’s a huge range, isn’t it? Actually, it should be even wider. I remember a case of a client coming to me with a CSS challenge that his developers weren’t able to solve. Making something that worked in modern browsers took me half an hour, then an hour to make it work in IE 8, and then three(!) more hours to get it to work in IE 7. Who knows how much longer it would’ve taken if I had to support IE 6, too! And that wasn’t the only occasion when it took me very little time to build a prototype that works in modern browsers and then a grossly disproportionate amount of extra time to make it work the same way in old Internet Explorers. If you’ve been in the field for more than a year, I’m sure this has happened to you, too.

On the other hand, if you don’t use any modern technology and you stick to CSS 2.1, then I guess you would only have to face the old IE bugs, which would take some extra time but not double. Or, if you used a ton of frameworks and polyfills, you would still have to spend some time making them work together and debugging potential conflicts, but still not double the time. 30% was an estimate for cases like those.

As you can see, the range is huge and depends on a number of different factors, including but not limited to the following:

  • You
    How modern are your development techniques? The more cutting-edge they are, then the more effort you will need to put into making good fallbacks or coming up with alternative techniques for old Internet Explorers (but less effort to make the original prototype)
  • The project
    If it’s a brochure website, the main thing that will need extra effort in order to work in old IEs is the styling. If it’s a Web application, it gets way trickier (and more time-consuming).
  • Level of support
    Supporting a browser is not black and white, either no support or full support. How good your fallbacks need to be will greatly determine how much extra time you have to spend on them.

So, I’m sorry but I can’t tell you how much extra you will need to charge to support old Internet Explorers. You’ll have to decide yourself, case by case, taking all relevant factors into consideration.

“But What If They Just Want To Pay For Firefox?�

Of course, there is a baseline of browser support that I won’t go below, even if the client doesn’t want to pay for it. We have a responsibility to ourselves and to the Web to follow the principle of universality. Even if a client wants to pay only for Firefox support, for example, my responsibility is to ensure that the website is still functional in the other browsers. Even if they are not willing to pay for mobile support, my responsibility as a Web developer is to at least add some media queries and make it decent there. Even if they don’t care about accessibility, my responsibility is to make the website somewhat accessible. These things don’t take up much time anyway, and they should be factored into even your lowest price.

So, What To Do With Old IEs?

So, what do I do for those wise clients who don’t want to pay for support of old Internet Explorers? Usually, I try to keep graceful degradation in mind and provide decent fallbacks for old browsers, so that at least the content is accessible in them. But in cases of really naughty browsers, like IE 6 and 7, sometimes even graceful degradation doesn’t work very well. Then, what I usually do is split my CSS into three files:

  • base.css
    Fonts, basic colors, etc.
  • screen.css
    Everything specific to the screen. Most of the CSS goes here.
  • print.css
    Print-specific styles, such as for hiding contact forms, etc.

Then, I just don’t serve screen.css to IE 7 and below. They get something like a print style sheet, without the hidden elements. It’s not very pretty, and it’s not modern, but at least they get the content. The same could be done with JavaScript. Check whether an API is present before using it, or simply don’t serve those script files to old Internet Explorers. If you’ve coded your JavaScript properly and it’s unobtrusive and all, then old browsers won’t get that extra functionality, but they won’t get JavaScript errors and broken functionality either. All of those require minimal effort on your part.

“Does That Mean I Always Have To Charge Less For Using Modern Stuff?”

While discussing my point of view with another developer, he asked me, “So, you’re saying that I shouldn’t charge more if I use responsive design and add a bunch of media queries?� Absolutely not! I’m not saying we should feel sorry for being cutting-edge or punish ourselves for that with less income! What I’m barely advocating is the common-sense idea of charging more for more hours of work. If you code some JavaScript that does the same thing that media queries do, then of course you should charge more for the JavaScript, because it will take you more time. But if you weren’t going to do anything like that, and the media queries were icing on the cake, then of course you should charge them more than you would for a non-responsive version of the website.

Conclusion

We may love what we do, but we certainly don’t love catering to the whims of old browsers. We do a lot of extra work to hide their incompetence, and that work needs to be compensated for properly. You don’t have to work for free, especially on something you don’t like doing. Explain the situation to your clients and they’ll understand how it goes, I promise. After all, “extra work = higher costs� is an established rule in every industry. The concept is not hard to grasp, and it makes the benefit of modern Web technologies much more tangible for technologically unsavvy clients.

What do you think?

How do you account for browser support in the pricing of your work? Do you charge extra for legacy browsers or do you provide a basic version of the design to legacy browsers? Let us know and leave a comment!

(al)


© Lea Verou for Smashing Magazine, 2011.


Introduction To URL Rewriting





 



 


Many Web companies spend hours and hours agonizing over the best domain names for their clients. They try to find a domain name that is relevant and appropriate, sounds professional yet is distinctive, is easy to spell and remember and read over the phone, looks good on business cards and is available as a dot-com.

Or else they spend thousands of dollars to purchase the one they really want, which just happened to be registered by a forward-thinking and hard-to-find squatter in 1998.

They go through all that trouble with the domain name but neglect the rest of the URL, the element after the domain name. It, too, should be relevant, appropriate, professional, memorable, easy to spell and readable. And for the same reasons: to attract customers and improve in search ranking.

Fortunately, there is a technique called URL rewriting that can turn unsightly URLs into nice ones — with a lot less agony and expense than picking a good domain name. It enables you to fill out your URLs with friendly, readable keywords without affecting the underlying structure of your pages.

This article covers the following:

  1. What is URL rewriting?
  2. How can URL rewriting help your search rankings?
  3. Examples of URL rewriting, including regular expressions, flags and conditionals;
  4. URL rewriting in the wild, such as on Wikipedia, WordPress and shopping websites;
  5. Creating friendly URLs;
  6. Changing pages names and URLs;
  7. Checklist and troubleshooting.

What Is URL Rewriting?

If you were writing a letter to your bank, you would probably open your word processor and create a file named something like lettertobank.doc. The file might sit in your Documents directory, with a full path like C:\Windows\users\julie\Documents\lettertobank.doc. One file path = one document.

Similarly, if you were creating a banking website, you might create a page named page1.html, upload it, and then point your browser to http://www.mybanksite.com/page1.html. One URL = one resource. In this case, the resource is a physical Web page, but it could be a page or product drawn from a CMS.

URL rewriting changes all that. It allows you to completely separate the URL from the resource. With URL rewriting, you could have http://www.mybanksite.com/aboutus.html taking the user to …/page1.html or to …/about-us/ or to …/about-this-website-and-me/ or to …/youll-never-find-out-about-me-hahaha-Xy2834/. Or to all of these. It’s a bit like shortcuts or symbolic links on your hard drive. One URL = one way to find a resource.

With URL rewriting, the URL and the resource that it leads to can be completely independent of each other. In practice, they’re usually not wholly independent: the URL usually contains some code or number or name that enables the CMS to look up the resource. But in theory, this is what URL rewriting provides: a complete separation.

How Does URL Rewriting Help?

Can you guess what this Web page sells?

http://www.diy.com/diy/jsp/bq/nav.jsp?action=detail&fh_secondid=11577676

B&Q went to all the trouble and expense of acquiring diy.com and implementing a stock controlled e-commerce website, but left its URLs indecipherable. If you guessed “brown guttering,� you might want to considering playing the lottery.

Even when you search directly for this “miniflow gutter brown� on Google UK, B&Q’s page comes up only seventh in the organic search results, below much smaller companies, such as a building supplier with a single outlet in Stirlingshire. B&Q has 300+ branches and so is probably much bigger in budget, size and exposure, so why is it not doing as well for this search term? Perhaps because the other search results have URLs like http://www.prof…co.uk/products/brown-miniflo-gutter-148/; that is, the URL itself contains the words in the search term.

screenshot

Almost all of these results on Google have the search term in their URLs (highlighted in green). The one at the bottom does not.

Looking at the URL from B&Q, you would (probably correctly) assume that a file named nav.jsp within the directory /diy/jsp/bq/ is used to display products when given their ID number, 11577676 in this case. That is the resource intimately tied to this URL.

So, how would B&Q go about turning this into something more recognizable, like http://www.diy.com/products/miniflow-gutter-brown/11577676, without restructuring its whole website? The answer is URL rewriting.

Another way to look at URL rewriting is like a thin layer that sits on top of a website, translating human- and search-engine-friendly URLs into actual URLs. Doing it is easy because it requires hardly any changes to the website’s underlying structure — no moving files around or renaming things.

URL rewriting basically tells the Web server that
/products/miniflow-gutter-brown/11577676 should show the Web page at: /diy/jsp/bq/nav.jsp?action=detail&fh_secondid=11577676,
without the customer or search engine knowing about it.

Many factors (or “signals�), of course, determine the search ranking for a particular term, over 200 of them according to Google. But friendly and readable URLs are consistently ranked as one of the most important of those factors. They also help humans to quickly figure out what a page is about.

The next section describes how this is done.

How To Rewrite URLs

Whether you can implement URL rewriting on a website depends on the Web server. Apache usually comes with the URL rewriting module, mod_rewrite, already installed. The set-up is very common and is the basis for all of the examples in this article. ISAPI Rewrite is a similar module for Windows IIS but requires payment (about $100 US) and installation.

The Simplest Case

The simplest case of URL rewriting is to rename a single static Web page, and this is far easier than the B&Q example above. To use Apache’s URL rewriting function, you will need to create or edit the .htaccess file in your website’s document root (or, less commonly, in a subdirectory).

For instance, if you have a Web page about horses named Xu8JuefAtua.htm, you could add these lines to .htaccess:

RewriteEngine On
RewriteRule   horses.htm   Xu8JuefAtua.htm

Now, if you visit http://www.mywebsite.com/horses.htm, you’ll actually be shown the Web page Xu8JuefAtua.htm. Furthermore, your browser will remain at horses.htm, so visitors and search engines will never know that you originally gave the page such a cryptic name.

Introducing Regular Expressions

In URL rewriting, you need only match the path of the URL, not including the domain name or the first slash. The rule above essentially tells Apache that if the path contains horses.htm, then show the Web page Xu8JuefAtua.htm. This is slightly problematic, because you could also visit http://www.mywebsite.com/reallyfasthorses.html, and it would still work. So, what we really need is this:

RewriteEngine On
RewriteRule   ^horses.htm$   Xu8JuefAtua.htm

The ^horses.htm$ is not just a search string, but a regular expression, in which special characters — such as ^ . + * ? ^ ( ) [ ] { } and $ — have extra significance. The ^ matches the beginning of the URL’s path, and the $ matches the end. This says that the path must begin and end with horses.htm. So, only horses.htm will work, and not reallyfasthorses.htm or horses.html. This is important for search engines like Google, which can penalize what it views as duplicate content — identical pages that can be reached via multiple URLs.

Without File Endings

You can make this even better by ditching the file ending altogether, so that you can visit either http://www.mywebsite.com/horses or http://www.mywebsite.com/horses/:

RewriteEngine On
RewriteRule   ^horses/?$   Xu8JuefAtua.html  [NC]

The ? indicates that the preceding character is optional. So, in this case, the URL would work with or without the slash at the end. These would not be considered duplicate URLs by a search engine, but would help prevent confusion if people (or link checkers) accidentally added a slash. The stuff in brackets at the end of the rule gives Apache some further pointers. [NC] is a flag that means that the rule is case insensitive, so http://www.mywebsite.com/HoRsEs would also work.

Wikipedia Example

We can now look at a real-world example. Wikipedia appears to use URL rewriting, passing the title of the page to a PHP file. For instance…

http://en.wikipedia.org/wiki/Barack_obama

… is rewritten to:

http://en.wikipedia.org/w/index.php?title=Barack_obama

This could well be implemented with an .htaccess file, like so:

RewriteEngine On
#Look for the word "wiki" followed by a slash, and then the article title
RewriteRule   ^wiki/(.+)$   w/index.php?title=$1   [L]

The previous rule had /?, which meant zero or one slashes. If it had said /+, it would have meant one or more slashes, so even http://www.mywebsite.com/horses//// would have worked. In this rule, the dot (.) matches any character, so .+ matches one or more of any character — that is, essentially anything. And the parentheses — ( ) — ask Apache to remember what the .+ is. The rule above, then, tells Apache to look for wiki/ followed by one or more of any character and to remember what it is. This is remembered and then rewritten as $1. So, when the rewriting is finished, wiki/Barack_obama becomes w/index.php?title=Barack_obama

Thus, the page w/index.php is called, passing Barack_obama as a parameter. The w/index.php is probably a PHP page that runs a database lookup — like SELECT * FROM articles WHERE title='Barack obama' — and then outputs the HTML.

screenshot

You can also view Wikipedia entries directly, without the URL rewriting.

Comments and Flags

The example above also introduced comments. Anything after a # is ignored by Apache, so it’s a good idea to explain your rewriting rules so that future generations can understand them. The [L] flag means that if this rule matches, Apache can stop now. Otherwise, Apache would continue applying subsequent rules, which is a powerful feature but unnecessary for all but the most complex rule sets.

Implementing the B&Q Example

The recommendation for B&Q above could be implemented with an .htaccess file, like so:

RewriteEngine On
#Look for the word "products" followed by slash, product title, slash, id number
RewriteRule  ^products/.*/([0-9]+)$   diy/jsp/bq/nav.jsp?action=detail&fh_secondid=$1 [NC,L]

Here, the .* matches zero or more of any character, so nothing or anything. And the [0-9] matches a single numerical digit, so [0-9]+ matches one or more numbers.

The next section covers a couple of more complex conditional examples. You can also read the Apache rewriting guide for much more information on all that URL rewriting has to offer.

Conditional Rewriting

URL rewriting can also include conditions and make use of environment variables. These two features make for an easy way to redirect requests from one domain alias to another. This is especially useful if a website changes its domain, from mywebsite.co.uk to mywebsite.com for example.

Domain Forwarding

Most domain registrars allow for domain forwarding, which redirects all requests from one domain to another domain, but which might send requests for www.mywebsite.co.uk/horses to the home page at www.mywebsite.com and not to www.mywebsite.com/horses. You can achieve this with URL rewriting instead:

RewriteEngine On
RewriteCond   %{HTTP_HOST}   !^www.mywebsite.com$         [NC]
RewriteRule   (.*)           http://www.mywebsite.com/$1  [L,R=301]

The second line in this example is a RewriteCond, rather than a RewriteRule. It is used to compare an Apache environment variable on the left (such as the host name in this case) with a regular expression on the right. Only if this condition is true will the rule on the next line be considered.

In this case, %{HTTP_HOST} represents www.mywebsite.co.uk, the host (i.e. domain) that the browser is trying to visit. The ! means “not.� This tells Apache, if the host does not begin and end with www.mywebsite.com, then remember and rewrite zero or more of any character to www.mywebsite.com/$1. This converts www.mywebsite.co.uk/anything-at-all to www.mywebsite.com/anything-at-all. And it will work for all other aliases as well, like www.mywebsite.biz/anything-at-all and mywebsite.com/anything-at-all.

The flag [R=301] is very important. It tells Apache to do a 301 (i.e. permanent) redirect. Apache will send the new URL back to the browser or search engine, and the browser or search engine will have to request it again. Unlike all of the examples above, the new URL will now appear in the browser’s location bar. And search engines will take note of the new URL and update their databases. [R] by itself is the same as [R=302] and signifies a temporary redirect.

File Existence and WordPress

Smashing Magazine runs on the popular blogging software WordPress. WordPress enables the author to choose their own URL, called a “slug.� Then, it automatically prepends the date, such as http://coding.smashingmagazine.com/2011/09/05/getting-started-with-the-paypal-api/. In your pre-URL rewriting days, you might have assumed that Smashing Magazine’s Web server was actually serving up a file located at …/2011/09/05/getting-started-with-the-paypal-api/index.html. In fact, WordPress uses URL rewriting extensively.

screenshot

WordPress enables the author to choose their own URL for an article.

WordPress’ .htaccess file looks like this:

RewriteEngine On
RewriteBase /  
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

The -f means “this is a file� and -d means “this is a directory.� This tells Apache, if the requested file name is not a file, and the requested file name is not a directory, then rewrite everything (i.e. any path containing any character) to the page index.php. If you are requesting an existing image or the log-in page wp-login.php, then the rule is not triggered. But if you request anything else, like /2011/09/05/getting-started-with-the-paypal-api/, then the file index.php jumps into action.

Internally, index.php (probably) looks at the environment variable $_SERVER['REQUEST_URI'] and extracts the information that it needs to find out what it is looking for. This gives it even more flexibility than Apache’s rewrite rules and enables WordPress to mimic some very sophisticated URL rewriting rules. In fact, when administering a WordPress blog, you can go to Settings → Permalink on the left side, and choose the type of URL rewriting that you would like to mimic.

screenshot

WordPress’ permalink settings, letting you choose the type of URL rewriting that you would like to mimic.

Rewriting Query Strings

If you are hired to recreate an existing website from scratch, you might use URL rewriting to redirect the 20 most popular URLs on the old website to the locations on the new website. This could involve redirecting things like prod.php?id=20 to products/great-product/2342, which itself gets redirected to the actual product page.

Apache’s RewriteRule applies only to the path in the URL, not to parameters like id=20. To do this type of rewriting, you will need to refer to the Apache environment variable %{QUERY_STRING}. This can be accomplished like so:

RewriteEngine On
RewriteCond   %{QUERY_STRING}           ^id=20$                   
RewriteRule   ^prod.php$             ^products/great-product/2342$      [L,R=301]
RewriteRule   ^products/(.*)/([0-9]+)$  ^productview.php?id=$1             [L]

In this example, the first RewriteRule triggers a permanent redirect from the old website’s URL to the new website’s URL. The second rule rewrites the new URL to the actual PHP page that displays the product.

Examples Of URL Rewriting On Shopping Websites

For complex content-managed websites, there is still the issue of how to map friendly URLs to underlying resources. The simple examples above did that mapping by hand, manually associating a URL like horses.htm with the file or resource Xu8JuefAtua.htm. Wikipedia looks up the resource based on the title, and WordPress applies some complex internal rule sets. But what if your data is more complex, with thousands of products in hundreds of categories? This section shows the approach that Amazon and many other shopping websites take.

If you’ve ever come across a URL like this on Amazon, http://www.amazon.co.uk/High-Voltage-AC-DC/dp/B00008AJL3, you might have assumed that Amazon’s website has a subdirectory named /High-Voltage-AC-DC/dp/ that contains a file named B00008AJL3.

This is very unlikely. You could try changing the name of the top-level “directory� and you would still arrive on the same page, http://www.amazon.co.uk/Test-Voltage-AC-DC/dp/B00008AJL3.

The bit at the end is what really matters. Looking down the page, you’ll see that B00008AJL3 is this AC/DC album’s ASIN (Amazon Standard Identification Number). If you change that, you’ll get a “Page not found� or an entirely different product: http://www.amazon.co.uk/High-Voltage-AC-DC/dp/B003BEZ7HI.

The /dp/ also matters. Changing this leads to a “Page not found.� So, the B00008AJL3 probably tells Amazon what to display, and the dp tells the website how to display it. This is URL rewriting in action, with the original URL possibly ending up getting rewritten to something like:
http://www.amazon.co.uk/displayproduct.php?asin=B00008AJL3.

Features of an Amazon URL

This introduces some important features of Amazon’s URLs that can be applied to any website with a complex set of resources. It shows that the URL can be automatically generated and can include up to three parts:

  1. The wordsIn this case, the words are based on the album and artist, and all non-alphanumeric characters are replaced. So, the slash in AC/DC becomes a hyphen. This is the bit that helps humans and search engines.
  2. An ID numberOr something that tells the website what to look up, such as B00008AJL3.
  3. An identifierOr something that tells the website where to look for it and how to display it. If dp tells Amazon to look for a product, then somewhere along the line, it probably triggers a database statement such as SELECT * FROM products WHERE id='B00008AJL3'.

Other Shopping Examples

Many other shopping websites have URLs like this. In the list below, the ID number and (suspected) identifier are in bold:

  • http://www.ebay.co.uk/itm/Ian-Rankin-Set-Darkness-Rebus-Novel-/140604842997
  • http://www.kelkoo.com/c-138201-lighting/brand/caravan
  • http://www.ciao.co.uk/Fridge_Freezers_5266430_3
  • http://www.gumtree.com/p/for-sale/boys-bmx-bronx-blaze/97669042
  • http://www.comet.co.uk/c/Televisions/LCD-Plasma-LED-TVs/1844

A significant benefit of this type of URL is that the actual words can be changed, as shown below. As long as the ID number stays the same, the URL will still work. So products can be renamed without breaking old links. More sophisticated websites (like Ciao above) will redirect the changed URL back to the real one and thus avoid creating the appearance of duplicate content (see below for more on this topic).

screenshot

Websites that use URL rewriting are more flexible with their URLs — the words can change but the page will still be found.

Friendly URLs

Now you know how to map nice friendly URLs to their underlying Web pages, but how should you create those friendly URLs in the first place?

If we followed the current advice, we would separate words with hyphens rather than underscores and capitalize consistently. Lowercase might be preferable because most people search in lowercase. Punctuation such as dots and commas should also be turned into hyphens, otherwise they would get turned into things like %2C, which look ugly and might break the URL when copied and pasted. You might want to remove apostrophes and parentheses entirely for the same reason.

Whether to replace accented characters is debatable. URLs with accents (or any non-Roman characters) might look bad or break when rendered in a different character format. But replacing them with their non-accented equivalents might make the URLs harder for search engines to find (and even harder if replaced with hyphens). If your website is for a predominately French audience, then perhaps leave the French accents in. But substitute them if the French words are few and far between on a mainly English website.

This PHP function succinctly handles all of the above suggestions:

function GenerateUrl ($s) {
  //Convert accented characters, and remove parentheses and apostrophes
  $from = explode (',', "ç,æ,œ,á,é,í,ó,ú,à,è,ì,ò,ù,ä,ë,ï,ö,ü,ÿ,â,ê,î,ô,û,å,e,i,ø,u,(,),[,],'");
  $to = explode (',', 'c,ae,oe,a,e,i,o,u,a,e,i,o,u,a,e,i,o,u,y,a,e,i,o,u,a,e,i,o,u,,,,,,');
  //Do the replacements, and convert all other non-alphanumeric characters to spaces
  $s = preg_replace ('~[^\w\d]+~', '-', str_replace ($from, $to, trim ($s)));
  //Remove a - at the beginning or end and make lowercase
  return strtolower (preg_replace ('/^-/', '', preg_replace ('/-$/', '', $s)));
}

This would generate URLs like this:

echo GenerateUrl ("Pâtisserie (Always FRESH!)"); //returns "patisserie-always-fresh"

Or, if you wanted a link to a $product variable to be pulled from a database:

$product = array ('title'=>'Great product', 'id'=>100);
echo '<a href="' . GenerateUrl ($product['title']) . '/' . $product['id'] . '">';
echo $product['title'] . '</a>';

Changing Page Names

Search engines generally ignore duplicate content (i.e. multiple pages with the same information). But if they think they are being manipulated, search engines will actively penalize the website, so avoid this where possible. Google recommends using 301 redirects to send users from old pages to new ones.

When a URL-rewritten page is renamed, the old URL and new URL should both still work. Furthermore, to avoid any risk of duplication, the old URL should automatically redirect to the new one, as WordPress does.

Doing this in PHP is relatively easy. The following function looks at the current URL, and if it’s not the same as the desired URL, it redirects the user:

function CheckUrl ($s) {
  // Get the current URL without the query string, with the initial slash
  $myurl = preg_replace ('/\?.*$/', '', $_SERVER['REQUEST_URI']);
  //If it is not the same as the desired URL, then redirect
  if ($myurl != "/$s") {Header ("Location: /$s", true, 301); exit;}
}

This would be used like so:

$producturl = GenerateUrl ($product['title']) . '/' . $product['id'];
CheckUrl ($producturl); //redirects the user if they are at the wrong place

If you would like to use this function, be sure to test it in your environment first and with your rewrite rules, to make sure that it does not cause any infinite redirects. This is what that would look like:

screenshot

This is what happens when Google Chrome visits a page that redirects to itself.

Checklist And Troubleshooting

Use the following checklist to implement URL rewriting.

1. Check That It’s Supported

Not all Web servers support URL rewriting. If you put up your .htaccess file on one that doesn’t, it will be ignored or will throw up a “500 Internal Server Error.�

2. Plan Your Approach

Figure out what will get mapped to what, and how the correct information will still get found. Perhaps you want to introduce new URLs, like my-great-product/p/123, to replace your current product URLs, like product.php?id=123, and to substitute new-category/c/12 for category.php?id=12.

3. Create Your Rewrite Rules

Create an .htaccess file for your new rules. You can initially do this in a /testing/ subdirectory and using the [R] flag, so that you can see where things go:

RewriteEngine On
RewriteRule   ^.+/p/([0-9]+)   product.php?id=$1    [NC,L,R]
RewriteRule   ^.+/c/([0-9]+)   category.php?id=$1    [NC,L,R]

Now, if you visit www.mywebsite.com/testing/my-great-product/p/123, you should be sent to www.mywebsite.com/testing/product.php?id=123. You’ll get a “Page not found� because product.php is not in your /testing/ subdirectory, but at least you’ll know that your rules work. Once you’re satisfied, move the .htaccess file to your document root and remove the [R] flag. Now www.mywebsite.com/my-great-product/p/123 should work.

4. Check Your Pages

Test that your new URLs bring in all the correct images, CSS and JavaScript files. For example, the Web browser now believes that your Web page is named 123 in a directory named my-great-product/p/. If the HTML refers to a file named images/logo.jpg, then the Web browser would request the image from www.mywebsite.com/my-great-product/p/images/logo.jpg and would come up with a “File not found.�

You would need to also rewrite the image locations or make the references absolute (like <img src="/images/logo.jpg"/>) or put a base href at the top of the <head> of the page (<base href="/product.php"/>). But if you do that, you would need to fully specify any internal links that begin with # or ? because they would now go to something like product.php#details.

5. Change Your URLs

Now find all references to your old URLs, and replace them with your new URLs, using a function such as GenerateUrl to consistently create the new URLs. This is the only step that might require looking deep into the underlying code of your website.

6. Automatically Redirect Your Old URLs

Now that the URL rewriting is in place, you probably want Google to forget about your old URLs and start using the new ones. That is, when a search result brings up product.php?id=20, you’d want the user to be visibly redirected to my-great-product/p/123, which would then be internally redirected back to product.php?id=20.

This is the reverse of what your URL rewriting already does. In fact, you could add another rule to .htaccess to achieve this, but if you get the rules in the wrong order, then the browser would go into a redirect loop.

Another approach is to do the first redirect in PHP, using something like the CheckUrl function above. This has the added advantage that if you rename the product, the old URL will immediately become invalid and redirect to the newest one.

7. Update and Resubmit Your Site Map

Make sure to carry through your new URLs to your site map, your product feeds and everywhere else they appear.

Conclusion

URL rewriting is a relatively quick and easy way to improve your website’s appeal to customers and search engines. We’ve tried to explain some real examples of URL rewriting and to provide the technical details for implementing it on your own website. Please leave any comments or suggestions below.

(al)


© Paul Tero for Smashing Magazine, 2011.


Building WordPress Themes You Can Sell





 



 


When I took my first steps into the WordPress theme arena, I didn’t know much about it. I wandered blindly into the business, not knowing whether I was doing things correctly. Over time, through trial and error and making rookie mistakes, I learned some valuable lessons and gained important insights. To save you from going down the same winding path, I’ll share some of the important takeaways that I’ve learned so far, like how to gain a solid user base, what to include in your themes and, most importantly, what to leave out.

sawyer_teaser

Gaining a Solid User Base

You could build the best WordPress theme in the world, but it won’t matter unless people know about it and use it. One of the smartest things I did when starting my theme business was to release a free theme. It took a while for it to gain traction, but things took off once it got some attention from being featured on other websites. Consumers are willing to download a free theme from the new kid on the block and try it out because hardly any financial risk is involved.

The free theme was unique and easy to use, and people liked it so much that they began requesting a premium (i.e. commercial) version, with more features (the free version had the bare essentials). To this day, the premium version is still one of my best sellers. Consumers like to download the free version to try it out, and then they typically purchase the commercial version. Value is added to the commercial version with support, updates, easier customization and a bundle of exclusive features. Releasing a free theme enabled me to gain momentum and build on a solid user base as I began creating commercial themes, and I’ll return to that strategy in the future to increase sales.

My First Mistake

The first mistake I made when getting started, and one that I still kick myself over, is that I didn’t implement a newsletter opt-in method for users who downloaded my themes. This would have given me a long list of consumers to whom I could market my premium themes, and it would have been extremely valuable when I launched the commercial version of my theme a year later. I’ve now gotten my act together and have a booming mailing list that I email every time I release a new theme, thus generating sales that would otherwise have been lost.

You’ve Got ’Em, Now Keep ’Em

Once I had a solid user base, I found that in order to keep them as returning customers, I had to add value not only to my themes but to my services. When you start a theme business, you’re not just selling themes; you’re also providing support and updates. Some of the top brands make great products and provide excellent support. Think of Apple, MediaTemple and Zappos. Say what you want about these companies, but there’s no denying that their user base is loyal because of both their products and their support and services.

One way to provide great support is simply to be timely with your responses. A customer loves nothing more than being responded to the same day. If you don’t know the answer to their question, at least let them know that you received it and are looking into it. You would think this is common practice, but you’d be amazed at how long some companies take to respond. If you can provide killer support, you’re already one step ahead of a lot of the competition.

Another way to add value is to provide educational resources that teach customers how to get the most out of your products. Some users will be more advanced than others, and they are usually the ones who purchase themes regularly. If you can provide a resource that enables those users to derive extra value from your products, then they will be more likely to stay with you and purchase more of your themes.

Streamline Your Process

Streamline and standardize your development process as much as possible. One way to do this is to use a theme framework, whether your own or a third party’s. Using a framework to quickly develop a theme is important when an eager audience is waiting on you. Most importantly, when you use the same framework, updating all of your themes after they’ve been released is easier. For example, all of my themes display a notification in the administration panel when an update becomes available.

The code that enables this notification is in a file named framework-init.php. In this file is a bunch of other important blocks of code that add features, such as the theme options panel and custom post fields, as well as common functions used throughout all of my themes. When I need to update that code, I simply make the change to my framework’s file and then that file gets replaced in all of my themes. By knowing that the file is the same throughout all of my themes, I don’t have to bother going through each theme to find that block of code to update. You can see how this becomes valuable when your inventory starts to accumulate.

The Hybrid theme framework
Hybrid is one of the more popular theme frameworks, thanks to its extensive list of features, including translations into 20+ languages and theme hooks.

Custom vs. Third-Party Frameworks

From the beginning, I decided to build my own framework, mainly because I would know it back to front, making it easier to maintain and build on (being a control freak might have contributed to the decision as well). A custom framework also meant that I wouldn’t have to rely on someone else, and the framework would have exactly what I needed and nothing else.

This is, of course, just personal preference, and many people prefer to use a third-party framework. By using a third party’s, you save the time it takes to develop a solid framework. It also means that you’re not solely responsible for maintaining the framework, and you will usually have a support system to turn to if you run into development issues. A lot of impressive frameworks offer useful functionality, such as theme hooks, extensible layout options, styling for popular plugins and much more. Lastly, there is a growing market for child themes of such frameworks as Genesis, StartBox and Hybrid.

Other popular frameworks are:

What To Include In Your Theme

Depending on the type of theme you’re creating, the expectations of consumers will vary. But you should consider certain features and functionality for the majority of your themes. You needn’t implement all of these, but at least consider whether they would add value to your theme.

Internationalize the Theme for Other Languages

Internationalizing your theme enables users to translate the text displayed by your theme, and implementing it is fairly straightforward. This one is a must-have. I was amazed at how many non-English-speaking users downloaded my themes. Looking back, I should have internationalized my themes from the beginning, knowing that millions of people all over the world use WordPress. You would be silly not to internationalize your theme. Look at the “Translating WordPress� section of the Codex and this helpful tutorial by AppThemes for more information.

Support WordPress’ Coding Standards and Practices

Develop your themes in a way that supports WordPress’ latest coding standards and practices. In doing so, you ensure that the theme is compatible with future versions of WordPress, and you’ll avoid a flood of emails from customers who have run into conflicts. Also, avoid deprecated functions, which are functions that are “no longer supported and may be removed in future versions of WordPress.�

An easy way to check all of this is to install the Theme-Check plugin. This great little plugin runs the same tests as those that WordPress.org runs on submitted themes.

Theme-Check plugin
The Theme-Check plugin has saved me many times from leaving out important details and using deprecated functions.

Documentation and Readable Code

Write thorough and helpful documentation for your themes. This will not only help users, but also cut down on the number of support requests you get from aggravated users. And trust me: the less support requests you get, the happier you will be. Document everything that’s unique about your theme that WordPress users might be unfamiliar with, as well as any built-in features such as custom backgrounds and headers, menus, and post formats. Also provide instructions on how to update the theme and on the proper way to customize the code (in case a user wants to create a child theme).

A well-documented block of code in Twenty Eleven
The Twenty Eleven theme is a good example of a theme with well-documented code.

Another important aspect of documentation is to make the code easy to read and understand. Some advanced users will want to customize the code, so it should be commented in a way that helps them understand what you’ve done under the hood. For a good example of well-documented code, check out the functions.php file in the default Twenty Eleven theme.

Child Themeable

As noted, many users will want to customize the code. The trick is that, when you release an update, the developer has to avoid overwriting the files that they’ve customized. The solution is for them to make their customizations in a child theme. So, make sure to support this functionality by allowing child themes to be easily created.

If you don’t want users to have to worry about including a particular script when creating a child theme, then use the get_template_directory_uri(); function to reference the parent theme’s folder. To allow the developer to overwrite this file, use get_stylesheet_directory_uri(); instead, which references the folder in the child theme, if one is being used.

Page Templates

Your theme should support the various page templates that a WordPress website can have. Because you don’t know how each developer will use the theme, you have to prepare for all possibilities. This is where testing comes in. For a typical WordPress theme, you should at the very least support these templates: page.php, archive.php, 404.php, search.php, single.php, attachment.php and, of course, index.php, which is the ultimate fallback. For a full list of templates, check out the “Template Hierarchy� section of the WordPress Codex.

WordPress Template Hierarchy
WordPress’ “Template Hierarchy“ is a great reference to have on hand.

You can also provide users with custom page templates. The two most common that I include with my themes is one with a widgetized sidebar (the default page.php) and one with a full-width page. You’ll likely be able to come up with other templates that users would benefit from once you’ve designed the theme.

Some theme developers use custom fields for this functionality, instead of page templates. This seems counterintuitive because the functionality is built into WordPress and is so simple to use. Creating your own page template is as easy as creating a new PHP file in the theme’s folder and adding the following PHP comment at the top (replacing “Full Width� with the template name of your choice):

<?php
/*
Template Name: Full Width
*/
?>

Of course, the code that follows the line above is up to you and will determine what the template does.

A Note on Theme Options

There seems to be a misunderstanding about what users of premium themes expect. The common belief is that they expect an options panel that looks like the control panel of a Boeing 747, where they can tweak the smallest detail of the theme. Sure, users want to be able to control certain aspects of their website, but simplicity and ease of use trump bloat and complexity.

Airplane Control Panel
Your options panel shouldn’t be this complicated. (Image: Fly For Fun)

When deciding whether to include an option in your theme, consider whether it’s really necessary and whether that functionality is already built into WordPress. The more options you add, the more complicated the code becomes and the steeper the learning curve for users. I keep the options for my themes to the bare essentials, and a goal of mine is to create a theme for which an options panel isn’t even necessary. I challenge you to do the same.

You can build your theme’s options on top of any one of the several great options frameworks. These are the ones I’ve come across:

Appearance Options

One reason to include an options panel is to enable the user to tweak the appearance of the theme without having to mess with the code. The option demanded by most users is surely to be able to upload a logo. Adding a logo is the easiest way for a user to personalize their theme. I enable it in all of my themes.

Preview of a simple theme options page
A snapshot of the options page in my latest commercial theme (based on the Options Framework).

Most theme buyers aren’t designers. They might not have an eye for color or be able to make informed design decisions. So, in addition to providing options to customize the theme’s main elements (like the color of text, the color of the call-to-action button, etc.), I include a selection of “skins,� which are basically just pre-defined palettes that a user can select from. This way, if the user doesn’t have an eye for color, they at least have options and aren’t restricted to one scheme. I usually provide several styles that cater to a variety of audiences.

Social Network Options

Most individuals and businesses have some type of presence on social networks, whether on Twitter, Facebook, YouTube or whatever the next big thing is. Because the design and placement of these social-network links vary from theme to theme, you can provide an option that allows users to customize the links.

Aside (and a little plug): I used to recommend including social-network options in the theme’s panel, but having given it more thought, I now feel it’s better suited to a plugin. New social networks pop up every day, and anticipating which ones your theme’s users will be on is hard. You will never be able to cover all bases, which is why I recently built a plugin that I’ll soon be supporting in all of my themes, and I suggest you do the same if you plan on including this feature. The plugin adds a new settings page where the user can create a list of social-network links. Users can select from the range of icons built into the plugin or built into the theme (if present) or upload their own. If this interests you, the plugin is called Social Bartender and is in the WordPress repository.

Advertising Options

You could also enable users to add advertisements, either through a widget or through an option that positions the ads in certain spots (like following the top blog post). Many people want to monetize their website and so advertising options would be important to them. Being able to select the locations of ads to suit the design is a selling point.

What To Leave Out

Almost as important as what to include in the theme is what to leave out. Many themes have options and functionality that are better done as plugins or that are already built into WordPress. Use the functionality that WordPress already supports, such as custom backgrounds, headers, post thumbnails and post formats. This is easier to implement because WordPress does all of the heavy lifting, and many users are already familiar with it. That being said, if your theme doesn’t need this functionality, then don’t include it in the first place!

Example of bad shortcode usage
Shortcodes should not replace standard HTML tags. Many of the shortcodes shown above are unnecessary.

Shortcodes

Shortcodes are great for executing a set of functions, but they’re unnecessary simply to embed a link or add a class to an element. Use standard HTML tags for this. For example, don’t create a [quote] shortcode when the HTML <blockquote> tag does a perfectly good job. I’ve seen themes that have shortcodes for quotes, citations and headers but no support for the same styling with HTML tags. This is a big no-no. Many users will switch from theme to theme and will already have content on their website when they activate yours. HTML tags will stay the same, but shortcodes vary from theme to theme. Don’t force the user to go back through all of their content just to add your custom shortcodes. Use shortcodes only to execute functions, not to apply styling. There may be a few exceptions, such as to wrap a message in complicated HTML, but if you’re simply adding a class, then adding it to the “Format� menu in the post editor’s kitchen sink makes more sense.

A great tutorial was recently published by Luke McDonald that details how to add your own styles to the drop-down menu in the visual editor, giving you one more reason not to use shortcodes to style elements.

Plugin Territory

Don’t include options for things that should really be added with existing plugins; for example, Google Analytics and favicons. I hear someone in the back asking, “Why not include such things?� Well, person in the back, what if the user decides to switch themes, even to another of yours? They would lose all of that information and have to figure out how to get it back. The option is unnecessary, would make the code overly complicated, and would cause trouble when the user switches themes. Include only options that alter functionality that is unique to your theme; otherwise it’s better suited to a plugin.

Further Resources

(al)


© Sawyer Hollenshead for Smashing Magazine, 2011.


Idiots, Drama Queens and Scammers: Improving Customer Service with UX





 



 


User experience design isn’t just about building wireframes and Photoshop mock-ups. It extends to areas that you wouldn’t necessarily think are part of the discipline.

For example, your customer service department can have a huge impact on your website’s overall user experience. Similarly, the design of your user experience could have an awfully big effect on your customer service department. Of course, not all of your users will interact with the customer service department, but for those who do, their experience can improve or destroy the customer relationship.

Improving Customer Behavior

Consider the difference in customer perception between Zappos and Comcast. Customers routinely rave about one, while the other was attacked with a hammer. Clearly, there’s a difference in the way they deal with their users.

Zappos
An excellent customer experience is a core value for Zappos

One of the biggest differences between the two is that Zappos appears to go out of its way to deliver great customer service long before a user ever has to deal with a representative. The differences aren’t just in the way they treat unhappy customers. Zappos makes a concerted effort to prevent customers from ever being unhappy in the first place. And that’s a good policy, because unhappy customers are expensive.

I spend a lot of time talking to customers, customer support reps and community managers. I’ve learned that there are three types of users who take up an inordinate amount of time and energy for customer service departments and cost far more money than they should. The great thing is that the behavior of many of these users can be improved or corrected with the right set of features and a proactive interaction design.

Let’s look at some of the folks who are costing you money and time. I’ll call them idiots, drama queens and scammers.

The Idiots

Customer service representatives spend a lot of time explaining obvious things to users.

Recently, I spoke with a community manager for a web-based marketplace where users can sell things to other users. The community manager was annoyed because he routinely had to explain to the sellers, “If you ship something to an overseas army base, it will take longer than it does to ship within the country.� He couldn’t believe that people didn’t know this. He thought they were idiots.

Idiots Button
(Image: JD Hancock)

But are these sellers really idiots? Of course not! They might be geniuses who just don’t ship things on a regular basis, so they don’t know that an APO address indicates an army base that might be overseas. As far as the seller is concerned, they’re shipping to a regular domestic address and now have to wait almost a month to get paid.

In fact, a huge proportion of the time, the “stupid questions� that customer service representatives get over and over aren’t stupid at all. They’re opportunities to improve the user experience design.

If you’re getting the same question, it probably means you’ve made an incorrect assumption about information that a typical user is likely to have. In our example, the company was mistakenly assuming that everyone knows what an APO address is and that delivering a product to one could take up to a month.

How to Turn Idiots Into Geniuses

Spend some time with your customer service people, and find out what questions are being asked repeatedly. Figure out a way to answer those questions within the interface so that someone doesn’t get to the point of having to contact support.

In our example, the company could add a small note to all APO addresses, pointing out to sellers before they ship that the address is for an army base and warning that delivery could be significantly delayed. It probably won’t stop every inquiry they get about this problem, but it should help just by letting people know what to expect.

The Drama Queens

Too often, interactions with certain customers blow up far more quickly than service reps expect. As soon as their special requests are denied, some users will rant and rave and threaten legal action, while others calmly accept the fact that rules apply to everyone equally.

Drama Queen
(Image: F. C. Photography)

If you talk to customer service reps or community managers, they could probably name a dozen drama queens off the top of their heads. And they won’t look happy doing it either. You’ll see eye rolling and head shaking.

One client complained that every time they released a new feature or a significant change, their power users would blow up and start screaming and yelling about how the company was trying to ruin their lives. It got to the point that the product manager was terrified of releasing anything new for fear of angering customers.

The saddest part of all of this is that the people who cared the most about the product were the ones who were complaining the loudest when things didn’t go their way.

How to Turn Drama Queens Into Advocates

You might think that you couldn’t do much as a user experience designer to calm drama queens, but you’d be wrong.

One of the main reasons why people escalate to that point is that they feel they’re being ignored. In fact, one of the most common reasons that customers leave is that they believe the company doesn’t care about them. Your job is to make them feel that their opinions are important and that they’re being heard.

One way to do this is to provide a good venue for them to express their opinions. Unmoderated or lightly moderated forums where they will talk to other people who are also unhappy are not good venues. One-on-one conversations with staff are the best, but talking to every unhappy customer is obviously not always possible.

A client of mine had a great way to deal with this problem. The company needed to recruit people for user research. Meanwhile, a number of people were writing in with complaints. So, the company frequently asked those people to participate in user research sessions. Two birds!

You’d think that the users’ responses would be skewed because they were already unhappy, but this could be easily controlled in the sessions. The complainers were much easier to book as research participants because they had initiated the contact, and they always ended the sessions much happier for having been asked their opinions.

Another important way to minimize drama is to involve important customers early on in design changes. Sure, power users often push back when you make a major design change, but that push is significantly softer when the change is an obvious improvement and people know what to expect and feel that their opinions have been taken into account.

You can keep the community on your side by getting their feedback during the design process and keeping them in the loop on the progress of changes. Allowing them to opt into changes and to give early feedback can really improve your relationship.

Even more importantly, involving your most important users early on will significantly improve the design of the feature, since you’ll be able to anticipate any complaints and edge cases.

The Scammers

Scammers are both the hardest and the easiest group for customer service reps to deal with.

They’re tough, because determining whether someone is a scammer or just an idiot or drama queen is not always easy. They’re easy, because once you know for sure that someone is a scammer, the correct thing to do is ban them immediately and never let them come back.

The biggest problem is that misidentifying legitimate users as scammers can have an incredibly negative impact on your business. No one likes being accused of something they didn’t do.

Also, in a social environment, the behavior of scammers can have a negative effect on other users. Think of fraudulent buyers and sellers on eBay or the highly publicized assaults by people who advertise on Craigslist.

How to Turn Scammers Into Good Citizens

Sorry, you can’t! What you can do is quickly identify the bad actors and get them off your website as quickly as possible before they negatively affect your good customers.

Enlisting the help of the community in policing can make this process much faster and more effective. Give users tools, such as flagging and comments, to report and protect themselves from scammers. Enlist community moderators to interact regularly with other members and alert you early on when someone seems to be doing something sketchy.

Also, give customer service reps tools to track the behavior of individual users so that they can resolve disputes quickly and appropriately, without a lot of “He said/She said.�

Other Problem Customers

Obviously, these three aren’t the only types of users that your customer service people will deal with. There will be the normal folks who have a genuine problem with your service or who find bugs. There will be people who want to cancel a subscription or ask a question about a policy.

But idiots, drama queens and scammers are the ones who will take up a disproportionate amount of your time and energy. They are the ones who can sap the spirit from your customer service reps and make them less able to deal with other problems.

Luckily, they also have the kinds of problems that you can address in your user interface. By providing the right information at the right time and enabling customers to report bad behavior, you can dramatically lower the amount of time you spend dealing with problem users.

And that means you’ll have a lot more time to deliver fabulous service to your best customers!

(al)(fi)


© Laura Klein for Smashing Magazine, 2011.


Expanding Text Areas Made Elegant

An expanding text area is a multi-line text input field that expands in height to fit its contents. Commonly found in both desktop and mobile applications, such as the SMS composition field on the iPhone, it’s a good choice when you don’t know how much text the user will write and you want to keep the layout compact; as such, it’s especially useful on interfaces targeted at smartphones. Yet despite the ubiquity of this control, there’s no way to create it using only HTML and CSS, and most JavaScript solutions have suffered from guesswork, inaccuracy, or a lack of elegance … until now.

  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress