From the category archives:

General

The Case Against Flash.

by Jeff on January 11, 2006

I don’t know if you’ve noticed, but people have quite a bad reaction to Flash, in general. Sure, it can be used well, but the reaction of most visitors to something starting to load will be “oh no, Flash!”, followed by a hasty dash for the back button. Why is this? Well, there are a number of reasons that come together to cause it each one, on its own, seems relatively minor, but together they make up a pretty comprehensive case against Flash.

Flash is a Plugin.

Flash isn’t integrated with any web browser instead, it’s available as an installable plugin. This has a lot of downsides. The first time someone views something that users Flash, they’re asked to install the Flash plugin this takes time and is annoying, especially considering that Flash plugin isn’t available for all browsers. After that, every time some Flash content appears, the Flash plugin has to be loaded into the browser before the content can even begin to be loaded, losing a vital few seconds.

Flash is Slow to Load.

Once the plugin itself has loaded, the next step is for it to load the Flash movie in question. Because Flash movies are typically so heavy in images and animation (that is, after all, the point of them), visitors will often end up spending a considerable amount of time being forced to stare at a ‘loading’ graphic. This is supposed to be the web, not a PlayStation no-one wants to watch your site load.

Flash Makes Sound.

Flash upsets users because they generally have no way of knowing that it’s going to make sound many users disable all their browser’s sound functions, not wanting random websites to be able to make sounds at them, but Flash sound still gets through, since it’s a plugin and doesn’t obey these settings. Flash is part of the reason why users end up browsing the web with their speakers turned off altogether people just hate having unexpected sound forced on them, and they have no way of knowing whether your Flash website might suddenly start making some.

Flash is Often Unnecessary.

Because Flash lets you make little animations, many websites use it for things that are completely unnecessary and un-interactive, but that they think look ‘cool’. The classic example of this is the web crime of the Flash intro: a useless piece of Flash that visitors have to sit through before they get to a website, usually saying and doing nothing useful whatsoever. Using Flash for unnecessary things is actively user-hostile, and many users have come to associate its use with that mentality.

Flash Breaks URLs.

If you let visitors navigate around within a Flash movie, that navigation isn’t saved at all. If they go to another site and come back, or even just press the ‘Refresh’ button, they’ll lose their place entirely, and have to start from the beginning again. This isn’t good if they found a particular piece of information or picture they’ll be annoyed at having lost it.

Flash Breaks Right-Click.

Users like to be able to right-click, to print what they’re looking at, or save it, or copy it to the clipboard not to mention all the extra functions that they might have installed on that menu. Right-clicking on a Flash-based website, though, gives a right-click menu of things related to Flash, like whether the movie should display in high or low quality. Users just aren’t interested in this menu, and are upset that they can’t get their normal one back. This is an especially large problem for users that like to have more than one window open at once by using right-click followed by the ‘Open in New Window’ function.

Search Engines Can’t Read Flash.

Finally, perhaps the most convincing argument against Flash: it’s entirely invisible to search engines. Text you put in a Flash movie doesn’t exist, as far as search engines are concerned. It’s closed off from the rest of the web and unfindable by most of your potential visitors. That surely can’t be good.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 4 comments }

The Basics of Web Servers.

by Jeff on January 10, 2006

There are a lot of web servers out there. Whenever you go to a website, you’re downloading it from a web server. When you pay money to a web host, what you’re really doing is renting a space on their web server. The Internet consists of millions of computers networked together, but it’s the servers that are providing all the information that makes up the web you can’t have a website unless it’s on a server.

What is a Web Server?

A web server is really just a powerful computer they use the same kinds of processors and memory that normal computers use, but they have more of it. Servers usually run a Unix or Unix-like operating system like Linux or BSD, but they can just as easily run Windows.

What makes these computers servers isn’t their hardware it’s the software they run. Web server software includes the HTTP server itself, as well as databases and other things that are needed to make a web server work however it needs to. This is why different hosts offer different features: they have different programs installed on their servers.

Web Servers Serve Files.

The role of the web server, at its most basic level, is to send people your files over HTTP. It has a hard disk (often more than one) and stores your files like any other computer if you don’t upload a file called ‘index.html’, many servers will list all your files for you instead of providing a web page. It’s the replacement of the index.html (named because it is supposed to be an index of files) that creates the illusion of everything on the server being one ‘web site’, instead of a set of files linked together.

Web Servers Run Scripts.

Of course, web servers don’t always just serve the same files over and over again. Sometimes they need to insert other information into pages, especially information that comes from databases. This is done with scripting languages like PHP and Perl the server is told that it should give files that end in .pl or .php to the appropriate script interpreters, and these interpreters then tell the server what to send to the browser. This means that dynamic websites can often be slow, as the server is having to produce a different page for each visitor.

Virtual Servers and Dedicated Servers.

When you buy web hosting, though, you’re not necessarily getting a whole server to yourself in fact, the chances are that you’re not, unless you’re paying lots of money. Instead, you’ll be sharing a server with the hosts’ other customers. You might not realise this, since the server doesn’t appear to have anything on it that isn’t yours, but the other customers are simply being hidden from you you’re using what is known as a ‘virtual server’.

For small websites, there isn’t really any option other than virtual servers: they’re a great idea for letting resources be shared among lots of websites that don’t use much of the server’s power or space. If one of the sites does start growing, though, you might find your website slowing down. Oddly enough, this fact means that it’s often better to find a host that offers price plans with limits instead of one that offers ‘unlimited’ disk space and bandwidth to each customer your website will be much faster at the ‘limited’ host.

More Than You’d Think.

One thing that people don’t often think about is that there’s more than one web server program out there. It’s not really visible to visitors, since they all do basically the same thing, but there are lots of servers available, and they’re all quite different in the way they work. There are three main groups:

Apache. The open source Apache software is the most popular server software out there, with around 70% of the market share.

Microsoft servers. Microsoft are responsible for the various versions of IIS (Internet Information Server) and PWS (Personal Web Server), which altogether have around 20% of the market.

Sun servers. Sun produce lots of servers, most notably the Netscape-branded ones. The market share of these servers depends on whether you count all sites (making it 3%) or just the actively maintained ones (in which case it drops to less than 1%).

Source for statistics: netcraft.com.

Other servers available are mostly ’simple’ servers that don’t have all the somewhat unnecessary features of these servers, such as thttpd (the ‘t’ is for tiny or turbo). There are literally hundreds of them, but they have mostly negligible market share.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

The Basics of Web Forms.

by Jeff on January 9, 2006

Whenever you want people to enter data and send it to you, you need a web form. Whether the data is as simple as a username and password or as complicated as a full address form, the basic principles remain the same.

The Tags.

Form tags have always been a troublesome part of HTML, simply because they’re not often used and require you to memorise a lot of words, depending on what kind of input boxes you want on your form.

To set up a form, you need to have a form tag with a method and an action, like this:

These properties aren’t very well-named, but they basically tell the browser where and how you want things that are entered on the form to be sent. The file named in action should be a script that is prepared to do something with the data from your form, such as entering it into a database. It’s worth knowing that you can make use odd things like “mailto:youremail@address.com” as the action (that one submits by email), although it’s not recommended.

Once you’ve got that, the next step is to put input tags between the form tags. There are lots of different kinds of input tags, and you say which kinds you want using the ‘type’ property. For example:

one

This is a checkbox (the boxes you can tick). The name property lets you give the checkbox a name so you can refer to it your scripts later on. The text between the tags (’one’) is what appears next to the tick box.

Other input types include:

text - a text box.
radio - a set of options where only one can be chosen.
button - a clickable button.
file - a box that allows someone to upload a file to your site.
submit - a special kind of button that sends the result of the form to the server.
reset - a button that clears everything a user has entered in the form, so they can start over.

Web Forms and CSS.

Those forms you just made, however, aren’t going to be pretty: they’ll be displayed in only the most basic style, one after the other and surrounded by ugly boxes. Luckily, it’s simple to add some styling using CSS in exactly the same way as you would add it to normal text. You can change the boxes’ background-color, font (font-family), remove the borders, and so on.

You might also like to make use of the various CSS ‘events’, such as the hover event. Take a look at this example CSS:

input:hover {
background-color: yellow;
}

It makes the input box go yellow when the user hovers over it combine that with a bit of Javascript that automatically moves the typing cursor into input boxes that the user hovers over, and you’ve got an easier to use form right away. Try as much as you can to make your input boxes look and behave like ones you like in software you find easy to use, and you won’t go far wrong.

Validating Input.

Once the user has typed something in, you need to validate it that is, check it makes sense. If they’re supposed to be filling in an email address, there needs to be an @ in there somewhere. If they’ve chosen a username, you need to make sure it’s not already been taken by someone else. That kind of thing.

There are two ways of validating input: client-side and server-side. To put it simply, client-side validation is done by Javascript, and is purely there for the user’s convenience, so they don’t have to submit a form only to find out it was wrong. Server-side validation will be done with a language like PHP, and is the final check before the data gets written to a database if it’s wrong at that point, you have to throw the user an error page and ask them to re-enter the relevant piece of information.

It’s very important that you don’t leave vital checking purely up to the Javascript, as some of your visitors may have Javascript turned off, or may even turn it off deliberately to get around your checks. The last thing you want is people being able to fill your database with bad information.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

The Art of the Logo.

by Jeff on January 4, 2006

Logos are difficult to design. Every website needs a logo, and you should spend some time designing them or yours if you haven’t already

Your Logo is Your Face.

When visitors come across a website that they haven’t seen before, one of the first places they look is at your logo and that’s when they start to form impressions of you. A good logo can make or break trust in your site, and be a big factor in whether anyone takes you seriously. Branding experts know this: logos can produce positive reactions (like recognition), and negative ones (like revulsion), but both are equally strong. Having a bad logo is, effectively, like having an untrustworthy-looking face.

Keep Pictures Simple.

If you do include an image in your logo, keep it to one, and keep it to simple shapes. You don’t want your logo to become ‘busy’: just suggest what you’re getting at, instead of pasting in a full-colour photograph of it. In fact, you should keep your logo to as few colours as possible, if you want it to make an impact.

Typography is Important.

Don’t let anyone deceive you into thinking that the most important thing about a logo is how many little shapes and pictures it has in it. What draws visitors’ eyes about logos is the typography: the font, spacing and whitespace.

Unfortunately for logo design, there are a hundred or so fonts that come with Windows and Office, and they’ve become overwhelmingly common in amateur logos. You’re never going to be taken seriously if your logo appears in Times New Roman, or Verdana, because everyone else’s is too.

So where can you find a less-common font. Well, take a look around sites like fonts.com and typography.com for a start. Personally, I often like to use fonts that I’ve seen in advertisements and found appealing: you can identify any fonts you can scan using a service like WhatTheFont (www.myfonts.com/whatthefont) it will take a look at the letters and tell you which font you’ve found.

Of course, commercial fonts can be expensive. Don’t pay ridiculous amounts, but don’t be afraid to pay a little: the chances are that you’ll be getting a much better font than you would be otherwise.

You can find great fonts at places like t26, Chank or check Typophile’s site for some free fonts.

Avoid Cliche’s.

Finally, whatever you do, please avoid the painful cliche logos that are so common on the web. To help you out, here’s a quick list of logo types to stay away from:

Decade-linked logos. Please don’t make your logo look like something from the ’60s, ’70s or ’80s, unless one of those decades is directly relevant to your site. If you just do it for no reason, it’s a cliche.

Spirals. Putting spirals in logos has been done to death no matter what variations you might be able to think of on it, they’ve been done. Spirals are nice, appealing shapes, but simply too common in logo design to consider.

Animals. Putting an animal (or a silhouette on an animal) into your logo might look nice, but the chances are that there are already plenty of people out there using your animal. Especially if you’ve had the ‘original’ idea of combining a rabbit and a hat to imply that your product is ‘magic’.

Letters making faces. Painful in every case, and yet getting more common all the time. Please resist the urge to draw a little curve under two O’s to make a smiley face. Please.

Letters making punctuation. Like the faces, but worse. How many more I’s turning into exclamation marks do we have to endure? Just don’t do it.

Swooshes. The king of the clich’s, the swoosh is at the point where using it in your logo will get you mocked. A swoosh is a curved line running across your logo some say it’s now the most common logo device in the world. I’m sure you can think of something better.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

Text Ads: Unobtrusive Advertising.

by Jeff on January 2, 2006

Advertising on the web is big business again, but idea behind the revival is quite strange. Back in the dot-com boom days, all ads were graphical, as it was assumed that this was the best way to get people to click through. However, modern ad companies, led by Google’s AdSense division, have found that text advertising works just as well as (if not better than) graphical banners. It’s this discovery that got advertising on the web moving again. But why does it work so well?

What Does a Text Ad Look Like?

The answer to this question is that they look pretty much like any other link. A typical text ad might look like this:

Buy My Stuff
I have stuff to sell to you. Come buy it.
http://www.example.com/stuff

It’s as simple as that: headline, text, URL. The ads usually appear in a ‘block’ of three or four, followed by an ‘Ads by’ message, but it’s just as possible for them to appear on their own. Clicking anywhere in the ad follows the link some text ads even exclude the text and URL parts, making them nothing but a link. One of the good things about the text ad approach is that it solves the ‘banner blindness’ problem, where users gradually learn to ignore banner-shaped areas of websites and so don’t actually see the ads at all.

Text Ads Annoy No-one.

Text ads are very subtle: they don’t jump out at you, animate, open in a new window or make noises. The great thing about them is that their lack of annoyingness is also part of their power: people actually pay more attention to an ad that looks like a useful link than they do to one that looks and sounds like an ad. You get to annoy your users less while making more money from click-throughs, and you get to reduce the amount of space ads take up on your site while increasing their effectiveness. It’s win-win.

Lower Ad Costs.

Text advertising also works out well for the advertisers themselves. Previously, to advertise on the web, you had to get a bunch of banners made in different sizes. Each time you wanted to change the message, you needed a new banner. Uploading these banners to the various ad sites was a pain, and the cost of the bandwidth used to serve the ads made the ad rates more expensive to advertisers. There was also a need for ads to be reviewed to ensure that they were suitable for the intended audience.

Text advertising changes this situation, removing a huge number of the costs associated with the whole process of putting ads on a site. Text takes effectively no bandwidth. You can’t really produce anything unsuitable in text or, at least, things that are unsuitable can be easily flagged by automatic filters. The whole process of creating an ad and taking it live becomes much easier for the advertisers: lower cost, and with more flexibility to create campaigns at short notice.

What this means for the marketplace is that there has been a shift in who buys advertising: instead of sites having three or four big advertisers, they can now have hundreds of small ones. This lets small businesses advertise when they wouldn’t have been able to before, not to mention removing websites’ dependency on their advertisers and giving them greater freedom to say what they want to. Again (and this is a pattern with text ads), it’s win-win.

Text Ads and Context.

Finally, it’s worth noting that the power of text ads doesn’t just come from the fact that they’re not graphical. It’s also important to note that the systems serving the ads pay more attention to context than the old graphical systems did: they can compare the text of the ads to the text of the websites that are being advertised on, to find the best match for the ads in question. This raises click-through rates by making ads highly targeted.

In short, we’re moving away from the web full of flashing graphical ads that are mostly irrelevant to what we’re reading, towards one with sober text ads that offer us just what we wanted.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

Happy New Years!

by Jeff on December 31, 2005

Thanks everyone for a wonderful year and hope that 2006 is totally super. I have big faith that 2006 will be a great year and hope everyone can keep their new year’s resolutions. Mine is to stop smoking which is of course a big deal to a smoker, or I should say ex smoker. Here’s to a happier and healthier 2006!

Hope you all have a happy and safe New Year’s Eve and New Year!

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

Taking Your Website Mobile.

by Jeff on December 29, 2005

You might have tested your website on every computer browser you can find, but nowadays thats just not enough. Nowadays the web is getting more and more mobile its being used on mobile phones, PDAs, and all sorts of other small devices that can be used on-the-go. You need to allow for these visitors as well, but thats easier said than done.

So Whats the Problem?

Well, unfortunately, there are dozens of manufacturers of mobile devices, and each one produces hundreds of different models. There has been little standardisation among mobile web browsers: basically, the only real way to check whether your website will work on one or not is to test it. As you can imagine, with all the devices out there, thats something that you could never really do especially considering that new devices come out every few months or so.

All you can do, then, is make your site generally suitable for as many mobile browsers as possible, instead of trying to alter it to work perfectly with specific makes and models. When you do this, there are a few basic rules to remember.

Make Things Work Without Images.

Many mobile browsers cant display images, which means that youre in trouble if your site uses images to display vital information or to make a form work. You need to test your site with images turned off to make sure everything still works. If youre using images on a form, you might consider replacing them with Javascript to insert images as most mobile devices dont support Javascript, this approach wont cause any problems for them.

Be Light on Bandwidth.

Most mobile devices are still accessing the web at sub-dialup speeds that makes your pages loading time very important to them. Sure, theyre not spending time downloading images, but they still have to download all of your pages source code before you can display it. You should make sure that your source code is as compact as possible, not repeating itself or using long-winded methods of doing simple things.

This is one of those times when its good to know HTML and have written your code yourself, but if youve used a WYSIWYG editor then you should at least try running the code through HTML Tidy, to see if you can reduce its size at all that way.

Watch Out for Screen Width.

Youve got to realise that mobile devices have a much smaller screen width than even the tiniest computer monitor. This makes it very important to make sure that your website (without images) will work on very small screens the biggest problem here is tables, which never work well. Better compatibility with mobile devices is yet another reason to switch your site over to valid XHTML and CSS, instead of relying on old table hacks for layout.

The Rewards.

If you can take your website mobile successfully, then therell be all sorts of rewards. Mobile shopping is still quite new, and there are lots of people trying it out for the first time and starting to build loyalty you can get a lot of long-term customers if you get into it now. People are also far more likely to pay for small pieces of information or downloads, since they can pay quickly and easily using their phone instead of a credit card.

Of course, even if youre not selling anything, a mobile website can still be good promotion. Mobile users are especially likely to use your website to try to get your phone number, or directions to where you are do you really want to let these people down? Anyone whos taking the time, trouble and expense to look up your site on their phone is likely a loyal (or potentially loyal) customer, and you want to make things easy for them.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

Taking HTML Further.

by Jeff on December 28, 2005

HTML might seem like a simple language for web documents, and to an extent, it is that’s what it was intended to be. If you know what you’re doing, though, you can do a lot more with HTML than you might think. This article should give you a few ideas on how to take HMTL further.

Inserting Multimedia Content.

Plain text and graphics are all well and good, but sooner or later you’re going to want to insert some multimedia content, such as a Flash movie, or an audio or video file. Unfortunately, browsers don’t handle these things themselves they use plugins, and you have to know the code to activate these plugins. While this should be simple, it isnt, for various historical reasons.

To begin with, there are two ways entirely different ways of calling a plugin. Newer browsers use the object tag, like this:

That one’s for Flash. To insert things like Quicktime or Windows Media players, you just need to find out their classid and codebase URL, as well as which parameters (param tags) they require. Most browsers now support the object tag, but some still use the embed tag instead:

For most cases, you should include both it’s best to place the embed tag inside the object tag, as this will cause browsers that understand object to ignore your embed. As an extra fallback, you might want to insert a plugin not found message, with a link to allow users to download the plugin, but in most cases browsers should now do this for you automatically.

For Internet Explorer only, you can extend object tags to call plugins that are on your server instead of on your computer this is known as ActiveX. Its most common use is to let users install web-based programs such as instant messengers without having to download and run a standalone install program.

However, you have to realise that many users will see ActiveX as dodgy, because it is an often-used way of installing undesirable software, and people who arent using Internet Explorer just wont see anything at all. If youre designing a site for a limited set of users, however (such as an intranet), ActiveX can be a very powerful capability.

Tables.

Even though tables are rarely used for layout any more, they’re still used for what they were originally intended for actual tables of information! You’ll probably need one at some point, but they’re still as complicated as ever, so it’s good to take a while to learn about how they work.

Basically, to create a table, you have to create the rows and columns individually: each table tag contains row (tr) tags, and each tr tag contains column (td) tags. A typical table looks like this:

month sales
January 200
February 300

This can be a difficult way to work, especially if your data is organised in columns, not rows. You just need to remember that the data you put in the tds will line up depending on their order in the tr: so, for example, ’sales’, ‘200′ and ‘300′ will line up in a column, because they are all in the second td tag of each tr. You might find it easier to use tabs instead of spaces to separate the tds, so the table appears lined up in the HTML the same way it will on the page.

Once you see how that works, you pretty much understand tables wasn’t so hard, was it? The only thing left to realise is that you can make one td fill more than one column using the ‘colspan’ tag. In the example table, for example, you could add text that fills two columns by adding this row:

text

Experiment a little, and you should be alright. Good luck.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

Taking HTML Further with Javascript.

by Jeff on December 26, 2005

Once you’ve built your HTML pages, you might need them to do something a little more interactive on the client-side (that is, in the visitor’s web browser). How can you do that? Javascript is the answer.

How Does Javascript Work?

To add Javascript to your HTML, you simply insert it between tags (or refer to the .js file that contains it, also using script tags). Overall, Javascript is quite a C-like language, but manages to be relatively simple in spite of it.

The Javascript you write should have functions that are tied to events on the page, meaning that when the visitor does something with your page, the Javascript executes.

Here are some events that you can use to trigger Javascript functions:

onload. Runs the code when the page loads.

onclick. Runs when the mouse is clicked. You can also use ondblclick for a double-click.

onmouseover. Runs when the mouse pointer is over a certain part of the page.

onkeypress. Runs when you press a specific key on the keyboard.

onchange. Runs when the contents of part of a form changes.

onblur. Runs when you press the tab key to switch between part of a form.

onsubmit. Runs when the form’s submit button is pressed.

What are these events useful for? All sorts of things. The onmouseover function, for example, can be used to rewrite parts of the page’s code when the user hovers over something useful for providing pop-up help ‘tooltips’. Onkeypress lets you give the user keyboard shortcuts to do things on your web page. Onblur and onsubmit can be used very effectively to spot errors in a user’s form input, and let the user know how to correct them before they’re ever even sent back to the server.

Once you know which event you want to tie some Javascript to, you have to say so in your code. You can do this in one of two ways. The first way is to directly attach it to the HTML element in question, like this:

This works well, but has the disadvantage of polluting your HTML with Javascript function names. The second, better, way, is to do it like this in the Javascript itself:

onload = function() { }

This creates a function directly from an event (in this case, the onload event), without ever touching the HTML itself.

Javascript Commands.

Here’s a quick reference to the most useful commands in Javascript.

alert. Pops up a dialog box giving the user a message. Useful, but sometimes considered annoying it might be better to put the message on the page instead.

confirm. Gives the user an alert box, but with buttons for Yes and No. Useful for asking ‘are you sure?’

document.write. Writes things into the current HTML document. Often-used, but not the best way of doing things.

getElementByID. Allows you to get an HTML element (that is, a tag) using its ID and manipulate it. Very useful for changing the text contained within tags, or their background colours, but can be used to do just about anything.

Math.random. Produces a random numb

navigator.userAg. Returns the name of the web browser. Useful to check if a certain browser is being used, although it’s often better to check for functions instead of browsers and decide which code to run that way.

parseInt. Looks through some text and gives you only the numbers from it.

window.location. Allows you to change the current URL that the web browser is at, as if the user had clicked a link.

var. Defines variables.

For more on Javascript, take a look at www.javascriptkit.com.

Javascript’s Problems.

The biggest problem Javascript has is that it just doesn’t work on all browsers: if you thought HTML support was erratic between them, wait until you start using Javascript. This will often put you in the position of having to check whether a function is available on the browser the code is running in (using an if statement), and then running some alternative code as a workaround if it doesn’t. In most cases, this isn’t as big a problem as it might seem, but it still requires you to have some knowledge of each browser’s limits, and do more testing than you would otherwise need to do.

Javascript is also, unfortunately, a pain to test and debug, as most browsers don’t give you any sort of reason why your code didn’t run if it’s wrong, they just ignore it.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }

Rare Books

by Jeff on December 23, 2005

My uncle is a rare book collector and has some amazing books. I totally dig anything that is before my time and rare books are totally fascinating. For one they are usually filled with great illustrations and two they usually have great typography. They are a windows into the past and the craftsmenship put into some of them is great. Sometimes they include autographs or personal messages inside the front cover which gives some insight into who owned them before you. Anyway, my uncle blogs about rare books he is selling and I couldn’t help but to notice this book “Lito and The Clown , which looks awesome. I’m a huge fan of the 60’s and this book just happens to be published in 1964 which btw was one of the best years for lincoln continentals.

If you enjoyed this post, make sure you subscribe to my RSS feed!

{ 0 comments }