For a long time, I was proud of the fact that I was using Blogger as a blogging platform. I thought it was challenging and fun to invent ways to hack and get around many of the challenges associated with hosting my own Blogger blog and using the non-xml old style version. I associated it with driving a vintage car. There was something cool about not moving to the latest and greatest, but instead sticking with retro for retro's sake. Blogger is the ratty old Chevy that, with some love can be made into something that will turn heads and function pretty well, but not without a lot of work.
Additionally, I was able to convince myself that WordPress or another CMS was too robust for what I needed and had doubts about integrating the rest of my site into a CMS.
That's all changed. Shortly (how dare I commit to a specific date), I will be making the move to WordPress. There is too much support, too many features (for both you ans I) and too many good things going for it to not make the move. To boot, everyone else is using it. True, it's terrible to be a follower, but there is strength in numbers, and strength in knowledge. Nine of ten design firms I speak with prefer WordPress. While you need to know XHTML and CSS to do web work...its seeming like knowing WordPress doesn't hurt either.
Blogger, so long. WordPress, here I come.
*Sorry for using "I" ten times above. This blog isn't just for me. It's for others as well. "I" promise to not let that become a habit. :)
Labels: Blogging, Web Development
There is a lot of talk about creating cool funky calendar style dates for blog posts like the one one this site. Most of them are centered around WordPress, as it's built in PHP, and is easier to manipulate.
Fortunately, the original Blogger allows users to publish files in php as well as html. As such, creating the calendar date thing is pretty straight forward in Blogger, when publishing in php.
Initially, Blogger outputs the date as a string like this:
Mar 9, 2009
After a bit of planning, we decide we want the month at the top, the day in the center, then the year offset at the bottom. We should be able to do this with four divs (or any block level elements, for that matter); one container div and one for the day, month and year. The container div will house a background image and the inner divs will have margins placing the data exactly where we want them.
Going to Photoshop, we design something like this:
You can see that the divs are laid out for each of the bits of data. From this, we can measure exactly how much margin we need and where.
Now lets lay out what we want the HTML to look like:
<div class="date-block">
<div class="date-m">jan</div>
<div class="date-d">21</div>
<div class="date-y">09</div>
</div>
Next, let's create the css to style our HTML above:
.date-block {
background: transparent url('../images/calendar.gif')
no-repeat scroll top right;
display: block;
float: left;
font: normal 900 10px Verdana, Arial, Helvetica, sans-serif;
height: 59px;
margin: 25px 0 5px 0;
text-align: center;
width: 54px;
}
.date-block .date-m {
color: #FFF;
display: block;
line-height: 10px;
margin: 6px auto 2px auto;
padding: 0;
text-align: center;
text-transform: uppercase;
}
.date-block .date-d {
display: block;
font-size: 26px;
font-family: Arial, Verdana, Helvetica, sans-serif;
line-height: 18px;
margin: 7px auto 0 auto;
padding: 0;
text-align: center;
}
.date-block .date-y {
color: #FFF;
display: block;
font-size: 9px;
font-family: Arial, Verdana, Helvetica, sans-serif;
line-height: 9px;
margin: 4px auto 0 32px;
padding: 0;
text-align: center;
}
Lastly, we need to create a function that we can call in the Blogger template to turn the standard date into our new fancy calendar date. The function will look like the following, which you can place in an included file, or directly in the Blogger template:
function prettyDate($date) {
list($month, $day, $year) = explode(" ", $date);
$day = str_replace(",", "", $day);
$year = substr($year, 2, 4);
echo "<div class=\"date-block\">";
echo "<div class=\"date-m\">" . $month . "</div>";
echo "<div class=\"date-d\">" . $day . "</div>";
echo "<div class=\"date-y\">'" . $year . "</div>";
echo "</div>";
}
Breaking it down, we are going to split up the original date by exploding them by the space character, which will give us:
$month = "Mar";
$day = "9,";
$year = "2009";
Notice that there is still a comma after the day, so we replace ',' with nothing. Additionally, we turn the four digit year into a two digit year by grabbing the substring of the year, starting at the second digit and grabbing the following two digits, which will return '09'. At this point, we simply print out the HTML containing the variables $month, $day and $year.
Lastly, in our Blogger template, call the function and pass the original date to it:
<?php prettyDate("Mar 9, 2009"); ?>
The function will run when the page loads. This example assumes a couple of things. You have included a functions file with the above function in it. You have placed the CSS in an included CSS file, or directly in the Blogger template. You are running on a server that has PHP installed. Enjoy!
Labels: (X)HTML, PHP, Web Development
With libraries out there like
jQuery and
MooTools, the need for a front end developer to
know Javascript is lessening. jQuery's selector and simple method based context makes it easy for those who have no coding experience to jump right in and hang with those who do. There are, however, some instances, in my opinion, that knowing Javascript can be very handy.
Adobe Extendedscript Toolkit
This IDE allows an Adobe user to write all sizes of scripts to automate tasks in all of its programs. Automate image resizing and directory creation. Employ conditional logic to an action. Target multiple Adobe applications with one script. Do all of this and more with the Adobe Extendedscript Toolkit. What language are these scripts written in? You guessed it. The primary language is Javascript. Optionally, use VBScript or AppleScript. Of what value is this to a front end web developer? A user could write a script to open a site mockup, chop into slices, save them all and close the document, all in the blink of an eye.
Photoshop 7.xx users can
download the extension. (This tool comes with any CS editions)
UltraEdit
UltraEdit is my favorite text editor. It's lightweight, easy to use and very customizable. The latest version incorporates scripts that can be written and called with hotkeys, or by referencing the menu. Much like the Extendedscript Toolkit above, these scripts are written in Javascript and can make automation or repetitive tasks very simple. Need to print an HTML snippet? Use a script. Need to tag all of the files in a directory with your 'copyright comment'? Use a script. Write a script to find all special characters in some text and replace them with their respective hex codes.
These were just a few instances where I use Javascript in applications other than web development.
Labels: Javascript, Programs, Web Development
Like many other site owners out there, I've got created a
smart 404 error page that emails me when a user arrives on said page. This enables me to identify common problems that I can fix. (For example, I've moved my blog from cmoist.com/ to cmoist.com/blog/, so I still get a lot of visitors to these now defunct URLs) Anyhow, after sorting out some of the more common problems, I started seeing pages come through that looked nothing like any URL I've ever hosted. All of them looked something like "SlurpConfirm404/PhD7Cameron/melanson.htm".
After a bit of research, it appears that this is the Yahoo! slurp crawler. The purpose of this crawler is to ensure sites have a proper 404 error page in place. Yahoo creates a URL consisting of random words that it appends to the end of your domain, then crawls.
Read Yahoo!'s
explanation for what exactly the purpose of this crawler is.
Labels: SEO, Traffic, Web Development
Over the past year or so, we've taken large strides at MCM to optimize our site for search engine optimization. I'd like to share some of the steps we've gone through to get to where we are today. Obviously, optimizing for an ecommerce site is a bit different than optimizing for a blog, but there are a lot of similarities. Each week, I'll cover a different portion of this process.
Most of the work we did focused on our product detail pages, as our primary goal was to get better coverage of our site and increase our indexed page count. We have something like 250 thousand product pages and a fraction of that number make up the rest of the site. Because our product detail page is technically only one page of code and affects hundreds of thousands of pages, it's the best "bang for the buck", so to speak.
I think its important to point out that there are several elements that comprise a search result, and that they all come from different places on your page. There is the title, the body and the destination url. These are all important in their own ways.
The first item on our product page that we addressed was probably the most important item; the title tag. This populates the title of a search result. We originally had something like this:
<title>MCM Electronics | 58-10665 - 12 Ft DVI-D
Home Theater Cable</title>
So there are a few problems with this. Initially, when browsing search results, your store brand is pretty much irrelevant. Sure, brand will play a small part in whether or not a searcher clicks on your result, but a relevant page title will go a lot farther towards getting a click. If you do your job and actually show relevant data in the title, people will notice your result, then see your brand in the url line below, or once they click through and visit your site.
Thinking like a potential customer who is searching, lets define what terms they are likely to search. Using the example from above, which is a Monster Cable cable, by the way, the searcher may search for "Monster Cable". They may search for "DVI400-4M", Monster's part number. They may search for "DVI-D cable". Out of all of this, the only bit in our original title was "DVI-D cable"; no manufacturer info at all. The truth is, when dealing with branded products, there are only a few bits that are universal; the manufacturer part number, upc and a few other identifiers. Therefore, it's more relevant to put these important bits in the title. MCM's sku is pretty much worthless unless someone knows they want a 58-10665 from MCM Electronics, but chances are, if they know that much, they will be visiting our site directly and not through a search engine. Hence, there is no real point in including MCM's proprietary sku in the title.
Putting all of the above together, we reach the conclusion that we want to include the manufacturer part number and the best title or description of the product we can come up with. Additionally, many people will search for the manufacturer name in conjunction with the manufacturer part number. Combining these two fields in a search query is a sure-fire way to get relevant data, and will rule out the possiblity to get results for a "DVI400-4M" from some other company, should they have the same term in their title. Now we have something like this:
<title>12 Ft DVI-D Home Theater Cable |
Monster Cable | DVI400-4M</title>
This is far more relevant than what we first started with. It combines three model specific attributes that searches will be searching for, if they are searching for this product.
It's important to remember that search engines have limits to number of characters they display. Google limits their titles to 66 characters, including spaces. If your title is longer than that, it will get cut off and Google will display a '...' at the end of the line. You can do some coding behind the scenes to cut your long title down to size, or simply let Google do the work for you.
Next week we'll discuss META tags.
Labels: SEO, Web Development
Being a self taught front-end web guy, there are occasions when I come across an HTML tag that, well, I hadn't heard of. Some of these are more useful than others; there are tags that I could probably go without knowing for the rest of my career and there are a few that I can't imagine doing without.
<pre> (text, inline)
Before I started to blog with the need to show highlighted pre, I had no clue that this tag existed. Use it to specify any type of pre. By default, most browsers will print this in the ugliest font they can find.
<ins> & <del> (text, inline)
Surely the insert and delete tags go back to the beginning of our beloved markup language, as they seem to be best used when using HTML as a word processing language, not necessarily the rich interfaces that are so common today. Obviously, they signify inserted and deleted text. The ins and del tags have two optional attributes; cite and datetime. Cite should specify the location (as a URI) of an explanation of why the insertion was made, while datetime should state the date and time of the change. By default <ins> underlines the text within it and <del> strikes through the text within it.
<caption> (table, block)
Used inside table tags, the caption tag is to be used only once and must appear right after the opening table tag. It's meant to describe the contents of the table and by default displays above the table. Style this element to get the most out of it.
<base> (link, inline)
Defines a base location for links on a page. This can come in handy if every link on your page will have a base link of something different that your base domain.
If you are just getting into HTML, or even if you have been doing it for a while, it may be worth taking a look at the W3C to see if there is anything you just haven't had a use for yet. Chances are, something may come in handy that you were not previously aware of. Additionally, getting to know all of the HTML elements will greatly improve (and simplify) the pre you write.
Labels: (X)HTML, Web Development
Up until six months ago or so, I was responsible for MCM's email marketing effort. We sent HTML and text emails to our opted-in users about once a week.
Before I took this task on, I thought designing web pages for all the different browsers out there was difficult. It turned out that designing HTML emails was worse. There are a lot more email clients than browsers, and all of them seem to have their own rules and quirks. Of course, there are guidelines out there to work around all of these. (I'd recommend giving MailChimp a visit for lots of good info)
After I had moved on from creating our email promotions, I came across the "Email Standards Project". This website movement aims to "work with email client developers and the design community to improve web standards support and accessibility in email". Sweet.
In addition to bringing fed-up designers together, the site uses it's version of an acid test to rate the state of all major email clients, from excellent to poor and gives full reports to boot. I'd recommend stopping by this site, saying hey, bloging or linking to it and spreading the word.
Here's to better web standards support in email clients!
Labels: Email, Marketing, Web Development
Up until about six months ago, I always preferred to make all of my buttons in Photoshop. (You'll notice this on mcmelectronics.com)I was able to get them to look exactly how I wanted them to; no variations in size or of the font.
Recently, with a little inspiration, I decided to go ahead and take a stab at recreating the buttons that we use on our main site. Once complete, this will mean that I don't have to create 50+ buttons for each site we do, and our front end guys don't have to wait for me to build new buttons when needed, they will have the styles needed at hand. Sure, it wont be identical to the PS version, but it will be close.
Here is a sample button from a step in the checkout process.
So, the first thing I did was to go to my original .psd and created images to use for the left and right sides of my button, similarly to the tutorials over at dynamicdrive.com.
Tips: Make sure to make the right side of your image long enough to cover any phrase that will be used (and then some). Save them as gifs with transparent backgrounds, or pngs so that they can be used on any background.
Now that we have the images ready and saved, lets start in on the CSS.
/***********************************************************
Author: Christian Moist, May 21, 2008
Bits For Regular Buttons
***********************************************************/
a.grnbutton{
background: transparent url('roundedge-grn-left.gif')
no-repeat top left;
display: block;
float: left;
font: 900 11px Arial;
line-height: 14px;
height: 20px;
padding-left: 6px;
text-decoration: none;
color: #FFFFFF;
text-transform: uppercase;
}
a.grnbutton span{
background: transparent url('roundedge-grn-right.gif')
no-repeat top right;
display: block;
padding: 3px 8px 3px 3px;
color: #FFFFFF;
}
Now to create the HTML. Essentially we are going to create a regular link and give it a class of 'grnbutton', but by looking at the code above, this will only give you the left half of the image we created earlier. To bring in the right half, we need to add <span> tags around the content of the word.
In all the HTML should look something like this.
<a href="#" class="grnbutton"><span>Continue</span></a>
Notice it doesn't matter if the word 'continue' is uppercase, lowercase, or a combination of the two because we have 'text-transform: uppercase;' in the CSS above.
If we try this out in a browser, we will get:
Continue.
There you have it. This has been tested in IE7 and FF, and should work in other major browsers without a problem. Next, I'll talk about creating input buttons to match.
Labels: CSS, Web Development
