Perishable Press

I am getting so old that I need to make recipes of my design stunts so I don’t have to relearn them from scratch every time. Sad, but so are a lot of things..

In any case, here is the basic procedure for creating the transparent panels used in my current (Quintessential) design:

1. Open main design template
2. Verify proper widths via existing images
3. Create guides according to desired width(s)
4. Create a rounded-corner vector shape of 10-pixel radius
5. Rasterize vector shape
6. Set outer-glow layer style (normal, 33, 3, 7)
7. Create new empty layer and merge with panel layer
8. Magic-wand select panel area at 1%, no anti-aliasing
9. Add layer mask to reveal all
10. Ctrl+Gradient tool from panel top to desired fade
11. Duplicate layer as new document
12. Crop and match desired size

From there, it should be self-explanatory. If not, perhaps it’s time to pursue an alternate line of employment..

Recently overheard on conservative talk radio (instructing listeners how to obtain a free promotional video from their new website):

“This website has tons and tons of firewalls, so you have to use your real email address to download the video..”

Just a thought.. As awesome as Google is these days, it would suck if they ended up owning the entire search-engine business. When they get to the point where all competition is impossible (due to their sheer size, financial resources, media influence, etc.), how many alternate search engines will have the resources for continuous improvement and top-quality search results? When this happens, we will have no choice but to do exactly what Google tells us to do.

As deeply ingrained as it is for everyone to instinctively and unthinkingly turn to Google for their search activity, it is time to leave a few alternate search tabs open for as much use as possible. Instead of using Google just because that’s what you always do, try your search on MSN, Yahoo, Ask, or any of the other independent search engines instead. Sharing traffic with other search engines is a nice, quiet way to keep the competitive spirit alive and well in the search-engine business.

Today I experienced difficulties while trying to publish or even save new posts in WordPress. I would compose the post as usual, add all of the keywords, tags, meta tags, and so on, but as soon as I clicked the “Publish” or “Save” button, the post would just disappear from existence.

The weird thing is that during the drafting process, WordPress’ default auto-save feature showed that the post had been saved at expected intervals. Unfortunately, after trying to publish several different posts, WordPress showed absolutely no record of the posts ever being created. They simply vanished into thin air.

Fortunately, a little investigation revealed the culprit. If you should find yourself dealing with this same issue, here are some different things that you should try. First, re-upload fresh copies of your entire WordPress installation. I don’t know why exactly, but apparently various files can either go stale or completely disappear from the server. Overwriting or writing fresh files may do the trick.

If that doesn’t work, check your WordPress database for errors. In my case, a little investigation revealed that something had caused a couple of fatal errors in the wp_posts table. Fortunately, checking and repairing the table solved the issue.

Please excuse the duplicate Tumbr posts.. seems there is no way to ping Tumblr to refresh/rebuild the RSS feed according to changes in post content. So, to resolve the issue I have discussed now like two or three times regarding paragraph elements and proper feed formatting, I have no choice but to repost a majority of my text posts.

This is necessary for the proper import and display of my Tumblr feed into WordPress. Currently, there are five items displayed at once, each styled according to proper inclusion of paragraph tags. Thus, whenever the Tumblr feed “forgets” to enclose single-paragraph posts with the proper tags, the result is an unstyled post entry displayed on my site.

Assuming that makes sense, you will please excuse my dust while I repost a few older entries in an attempt to reconstruct (the hard way) a properly formatted Tumblr feed.

Another important step in improving the performance of my recent redesign involves the optimization of both CSS and JavaScript content. During development there were around 15 server requests for these two types of files, 10 JavaScript files and 5 CSS files. This was okay for my own use, but would not work for production purposes.

Optimizing these file types involves consolidation, compression, and caching. Consolidation of 10 JavaScript files into three is huge improvement. Now I deliver one JS file for the functionality of the site, one for Mint, and another for Analytics. Likewise for the stylesheets; after consolidation, a single stylesheet is delivered to all modern browsers. There are two additional stylesheets as well, but they are targeted at IE6 and mobile browsers and will not load elsewhere.

Once the files were consolidated as much as possible, it was time to optimize or “crunch” them. Using the sexy Flumpcakes CSS optimizer, I was able to reduce my stylesheets by around 25%. Likewise for JavaScript, I used xtreeme.com’s optimizer to shave an additional 20% off the size of my JS content.

Finally, once I had consolidated and compressed my JS and CSS files as much as possible, I wanted to further my optimization efforts by ensuring that these files were cached by the browser. By setting far-future Expires headers for everything but the statistical files, my site gains an additional performance boost by eliminating the need to reload preexisting content.

With image-rich designs, it is important to optimize as much as possible to maintain an enjoyable user experience. During development, the current (Quintessential) design at Perishable Press called over 50 different images, 10 JavaScript files, and around 5 stylesheets. This was fine during development because I was the only person involved with the design. Plus, with a fiber-optic Internet connection, I wouldn’t have noticed it if there were 200 image requests.

Once the design finally began coming together and looked consistent in as many browsers as I could find, it was time to begin optimizing the site for performance — not just to decrease loading time, but also to conserve as much bandwidth as possible. For the images, I began by consolidating the collection into four or five sprites, each containing graphics of similar dimensions. By reducing the number of server requests for images from 50 to 5, I was able to speed up loading times dramatically.

Then, to reduce the overall size of each of the sprites, I further optimized them with the incredible OptiPNG. Crunching the images with OptiPNG, I reduced overall graphics size by over 25%, thereby saving bandwidth and further decreasing load times. Further, PNG image optization via OptiPNG is lossless, meaning there is no loss of image quality.

For the new Perishable Press design, I am incorporating CODA-like slider functionality. At first I was wrestling with the Coda Slider Effect over at jQuery for Designers, but was having problems getting consistent horizontal sliding to work within a narrow parent division. Also found it difficult to add multiple sliders with that technique.

Eventually, after about a day of wrangling, I decided to move on to Niall Doherty’s popular script provided at ndoherty.com. Four hours later, I modified the script, CSS, and markup to suit my needs and feel very satisfied with the results: proper scrolling and multiple sliders working perfectly within a highly elaborate page design.

Tested on Safari, Camino, Opera, and Firefox on the Mac, as well as Internet Explorer 7, Opera, and Firefox on the PC.

After much debate and years of wasted link juice, I have decided to redirect my Perishable Press subdirectory to my root directory. That is, the directory perishablepress.com/press/ will now be directed (via 301) to perishablepress.com.

Hopefully this strategy will improve the usability of the site by preventing an essentially duplicate page from confusing visitors. That is, because the site is generated from within a subdirectory, the root subdirectory content is also served as the root page.

Hopefully, this will also funnel the subdomain’s link equity to the site root. That would be a good thing!

When it comes to listing favorite posts, recent posts, and random posts in your sidebar, which is better from a search-engine optimization perspective? Hard-coding a few sets of favorite posts will obviously increase the link equity flowing to those pages, but what about links that change over time, either short-term (random posts) or long-term (recent posts)?

Short-term links may get a temporary rank boost, but only until the next spider crawl. Likewise for long-term links, with the residual love juice persisting for a bit longer. So, in comparing these two strategies against linking more permanently to favorite-type posts, we see that the real question asks how link duration and associated link equity affect the overall success (rank, traffic, etc.) of both individual pages and the entire domain.

Tumblr needs to improve its feed formatting. Lots of problems with paragraph elements on single-paragraph posts. Also seeing issues with paragraph formatting around code elements.

This makes it difficult to stay consistent when importing Tumblr into a site. You either design (markup and CSS) for paragraphs or design for no paragraphs. With both scenarios, producing a clean result is challenging.

Some philosophical SEO questions.. Where does PageRank originate? How much is there? Who or what determines how much PageRank is supplied to the Internet? Is there a limited supply? Is it inflationary? Will there ever be a PageRank bailout?

It seems to me that the entire concept of PageRank is based upon some arbitrary quantity of page equity that flows around the Internet. For example, if the current amount of equity were doubled, would we all see a doubling of PR across all sites evenly? Is it all relative? Is it all pointless? Hmmm.. would love to hear some ideas on this.

I get obsessive about source-code formatting. When viewing the source code of my pages, I like everything to nest properly, with the correct number of tabs preceding each line of code. With WordPress, this generally requires some tweaking of the core files.

Specifically, in wp-includes/formatting.php, the function wpautop needs a few extra \t’s before the <p>$1</p> on around the sixth or seventh line of the function.

The number of added tabs will vary depending on the specific nesting requirements of your theme. Also note that this formatting edit will affect both post text and comment text output.