From Two 2 Twelve - general

HOW TO: CSS Sprites (Background Image Arrays) - Part 1

2009-02-10T04:44:00Z

A CSS Background Image Array (also known as a CSS Sprite) is a single image file that contains multiple graphics within it. Using this image file and the CSS background position property you can update all of your website graphics and page titles by editing one file and without changing any code. This technique can also significantly speed up your website’s loading time and help you automatically organize your website’s graphics.

In the first of this 3-part series we’ll cover the steps required to construct a CSS Sprite including the designing, preparing, and XHTML/CSS programming of a sprite, along with the multiple uses that CSS Sprites can be utilized for.

This Series

CSS Sprites have a countless number of possible implementations, I’ve chosen to cover three of what I’ve seen to be the most common uses.

These uses include:

An SEO-friendly page-title replacement sprite
A menu / navigation sprite
An icon / button sprite

Each of these sprite implementations have their own unique advantages and challenges that result in an ultimate benefit for your website.

In every part of this tutorial series we will cover the following process for each of the three sprite uses:

The slicing and preparing of graphics for use in a sprite
Programming the XHTML/CSS for a sprite
Extending and updating a sprite

In this first installment of the series we’ll be integrating sprites to create SEO-friendly page title image replacements. The end result will be pretty, image-based page headers for your website without giving up the SEO benefits of header tags and text.

Step 1: Slicing and Preparing Graphics

First, we’ll design and prepare the graphic for our page headers.

Next, we want to create additional page title graphics for our other website pages. Now, instead of creating a new file with the graphic for each page title, we’re going to implement the sprite technique into this single image by positioning our first graphic to touch the top and left edges of the canvas. Then, for each subsequent graphic (or page title) you require, duplicate that initial graphic and place it around 10px directly under the previous graphic (you can use the ruler tool and guides to measure the spaces). Here are some notes:

Next, we’ll crop the extraneous whitespace off the canvas using the crop tool. Finally, we should end up with a completed graphic that looks similar to this:

Step 2: Integrating A Sprite via XHTML/CSS

Now that we’ve constructed a sprite, we can move on to integrating it into our website.

Here is the XHTML code we’ll be using on each page to display it’s corresponding graphic from the sprite:

<div id="page_title">
    <h1 id="home_title">Home</h1>
</div>

As you may notice, this greatly resembles a normal looking page header without the use of a sprite, keeping our titles valid and SEO-friendly. Repeat this code on each page of your website that you have a title for and edit the h1’s id and text to correspond with the name of the page (Ex:

<h1 id="about_us_title">About Us</h1>

for your about us page).

The CSS for this sprite consists of three element styles:

div#page_title {
    display:block;
    height:40px;   <-- The height of each sprite + the whitespace below it
    margin:0 0 0px;
}
    div#page_title h1 {
      width: 215px;   <-- The width of your sprite image 
      height: 30px;   <-- The exact height of each sprite
      text-indent: -7777px;
      background-image: url('../images/sprite.jpg'); <-- The image file
      background-repeat: no-repeat;
    }
    h1#home_title { background-position: left top; }    
    h1#about_us_title { background-position: left -30px; }

The first element: div#page_title, defines the container that encompasses the page title. Here is where you can add padding and margins that will affect the overall style and positioning of the sprite.

The next element: div#page_title h1, defines the properties of each sprite, such as the height, width and the location of the sprite image. The “text-indent” property is used in this element to hide the text within the h1 tag, but still keeping it visible to search engines by not removing it completely.

The last elements h1#home_title and h1#about_us_title, define the position of the background image in relation to the sprite image. For the sprite used in this example, each page title graphic is 30px in height with 10px of whitespace below it. The first title graphic in our sprite is for our home page, this means, for our h1#home_title element we can simply set the background-position to left and top. Next, our about page graphic is placed under our homepage graphic making things a bit tricky. To position this title and subsequent titles, we’ll note the height of each graphic from our CSS (30px) then set the background position to left and -30px to move the background image up by 30px, as a result, displaying the portion of the graphic with our about title instead of the homepage title.

Now, if you have another graphic in the sprite under about us, for example, named contact us, simply duplicate the HTML above, fill in the h1’s details and create a new element with the name h1#contact_us_title and set it’s background position to left and -60px in your CSS file and repeat as necessary.

Tip: To get the exact dimensions for the sprites used in the CSS, use the ruler tool in Photoshop (command + i (mac) / ctrl + i (windows)).

Here’s an example of an implemented page title sprite.

View This Theme on ThemeForest

Step 3: Extending and Updating A Sprite

When it comes time to update your website’s look, sprites make is extremely painless. Simply, open your sprite image file, update each graphic title with your new styles and save this over your old sprite file. Congratulations! You’ve just updated all your websites page titles by editing one file and without changing any code.

Now that we’ve covered the basic concept of creating and implementing a sprite for our page titles, in the next tutorial, we’ll create a multiple-state menu / navigation system using the CSS Sprite technique.

Implementing Standards Into Your User-Driven Website

2009-01-16T00:25:00Z

While preforming some intense, in-depth changes for the upcoming release of 72photos I had a small, yet significant epiphany about the standards (or lack of standards) on social network websites and basically any user-content driven website. My epiphany being: These websites are generally ugly and lack a consistent, quality experience.

I became increasingly aware of this when the XMG team and I we’re brainstorming new ways to aggregate users data to create unique avenues for users to explore and browse through content on 72photos. Though, we came up with a myriad of great concepts, unforeseen problems arose late in development. We found the more user-uploaded content we featured, whether it be photos, galleries, or profiles; the more it began to affect the overall quality of the website, and not for the better. This was due mainly to the unpredictability of user content.

Then, I’ve begun to notice this trend throughout the larger, more prominent social websites…The more user content they displayed on their website, the more it affects the overall website quality. After some further research, I’ve reduced this down to 3 factors:

User-content is unpredictable, thus unforeseeable pitfalls and issues occur.
There is too large of a standards gap between the actual website’s content and user-generated content.
These websites just “give up” design-wise and end up aggregating user-content into tables or lists and seem to exclude these areas in the design process entirely.

I’ll forgo the listing of any of the websites who are guilty of the points above and instead, list a few that have risen above these factors.

3 examples of consistent standards in social websites:

72photos – Though I may be a little biased on this one (having designed and programmed it myself) I still believe there is a level of quality kept throughout the website, given it’s large amount of user-content.
PureVolume – With an unhealthy amount of user-based content displayed throughout the entire site, PureVolume has managed to keep the standards up by implementing a level of control and fine-tuning their user’s content.
Open Source Food – Not a large social network by any means, but good use of CSS and Javascript elements to style their user’s content makes for a smooth, flowing experience when browsing through their site.

So, how does one strive towards displaying all their aggregated user-data while keeping the high quality and standards of one’s website? Not easily…However, here are a few methods that 72photos employed and you can implement to overcome some of these drawbacks:

Don’t design “around” your user-content areas, instead, put forth more emphasis on laying out these content areas in interesting ways while designing your website’s pages before you begin implementing anything.
Implement CSS techniques / hacks on any featured user-content. For example, when displaying a featured photo from a users profile on your homepage use a PNG overlay or drop shadow on the photo. Perahps even dynamically size images so they don’t bleed over other areas of your page.
Truncate and format all user-generated text; removing all illegal characters, links, and anything else that may throw your content flow off.

With a little foresight and some CSS / Javascript trickery you can easily re-gain control of your social website’s design standards. The suggestions above are just a few of many ideas you can implement to keep the design of your site flowing with consistent quality by the end of the week—Win-win.

Anyone In The Market For A MacBook Pro?

2008-12-27T22:03:00Z

It’s been a good run with my ol’ MacBook Pro, however, I couldn’t resist the temptation of the new mercury-free, multi-touch, MacBook Pro goodness.

Anyone in the market for a gently used MacBook Pro? Oh, you are? Excellent! Check out the auction!

New Rails Plugin: OnLooker

2008-12-24T19:37:00Z

OnLooker is a simple rails plugin that lets a user check the status of his or her website or server. OnLooker uses Ping’s to check via TCP or HTTP whether the site, sites or servers that you specify are online and accessible. OnLooker also supports custom images to distinguish status.

Check out the demo or grab the source.

Have an issue / suggestion for the plugin? drop me a comment below.

HOW TO: Ruby on Rails + Passenger on (mt) MediaTemple's (dv)

2008-12-05T23:45:00Z

After spending 7 painstaking hours attempting to get Rails + Passenger (mod_rails) going on a (dv) VPS I have, I decided to post up my procedure for getting this going (sans the hours spent researching).

This setup wont change much of your current setup, whether it’s a new (dv) or one you’ve been using for a while. I personally preformed the following on my 1 month old, fairly untouched, v3.5 (dv).

Prerequisites
Developer Tools – Install Guide.

Steps

Step 1: Remove all current installations of ruby and ensure sure ruby -v reports nothing.

yum remove ruby

Step 2: Install Ruby v1.8.6 and RubyGems 1.3.1

cd /opt
wget ftp://ftp.ruby-lang.org:21/pub/ruby/1.8/ruby-1.8.6.tar.gz
tar -zxvf ruby-1.8.6.tar.gz
ln -s ruby-1.8.6 ruby
cd ruby
./configure && make && make install
cd ../
wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar -zxvf rubygems-1.3.1.tgz
cd rubygems-1.3.1
ruby setup.rb

Step 2: Install Rails & Passenger Gems and Install Passenger

gem install rails (unless already installed)
gem install passenger
passenger-install-apache2-module

Step 4: Follow the passenger install’s onscreen instructions.

Step 5: chown -R {your_domains_username} {your_rails_app}

Step 6:

service httpd restart

Your Done!

Tips: Ensure your app’s directory is owned by it’s domain’s respective owner, since passenger runs as the apps owner.

A Place For My Plugins

2008-10-24T00:57:00Z

In regards to my last blog post, I’m continuing my quest to release open-source snippets and tid-bits of code I’ve used in my various projects.

To better facilitate my newly founded altruistic views, I’ve put together little space to display my current list of plugins and perhaps even a demo or two.

Without further adieu…

plugins.two2twelve.com Is online!

There, you’ll notice my most recent (and currently only) plugin CleverValidation; Do away with the default (and unattractive) Rails validation methods and sexify your validations with CleverValidation. Try out the demo here or go straight to the source.

Any issues with the plugin? Think it could be sexier? Let me know in the comments section.

My Requital To The Intarwebs

2008-10-12T15:01:00Z

Following the development of several large-scale web productions for my own uses. To the open-source web 2.0 industry, I feel compelled to return some of that which I expend and capitalize on daily. Though I’ve always been a huge supporter of open source, my position has always been that of user rather then the contributor.

In the weeks to come I plan on releasing several excerpts (in rails plugin form or similar) of, what I’ve found to be, extremely useful code. I may even release a few javascript libraries I’ve dabbled with over the years.

To start off, here’s my somewhat recent plugin for mephisto that allows the retrieval and integration of a 72photos users photos into their mephisto blog.

Grab the source at Github.

More to come!

How A Sensible Navigation Flow Is Crucial to Application Design

2008-06-18T18:11:00Z

During my recent revocation of the 72photos photo hosting service, I came across multiple hurdles in the lines of navigation. I’ll spare some of the more gritty details, but I will add, if and when your site begins to employ multiple areas such as, a separate website and client backend for instance, it’s crucial to have a navigation flow thats easy to follow, somewhat static (i’ll elaborate on that shortly) and most definitely sensible.

Here was the progression of navigation used on 72photos which consists of 2 separate sections, the main website and a user’s control panel area:

Version 1:

Main website: Displaying a set of links pertaining to navigation for the main website’s pages. The active link (the page you’re currently on) is subtly underlined.

Users backend: Displaying a completely different navigation from the main website with links pertaining to sections in the users backend.

Why this doesn’t work: Once a user was in their backend control panel, the only way to navigate back to the main website was to click the 72photos logo (not effective). Reversely, the only way to get to the users backend from the main website was one link entitled “dashboard” which replaced the “home” button on the navigation once a user was logged in. Since the main website and user backend designs changed dramatically from a dark design to light, a feeling of seperation would overcome to user when switching between the 2 interfaces with no elements constant to give the feeling of connectedness and flow throughout the system.

Solution (Current Version):

Main website: Redesigning the set of links to use the colors from the footer and highlighting the active link distinctly sets a tone for the main navigation which is now shown on every page/section of the application.

Users backend: A redesigned and re-aligned set of links as before, however, this time around the main websites navigation is still up top.

Why this works over the former: The constant, site-wide navigation up top gives users the ability to explore the entire website at any time and to always know where they are—where they came from. The new backend navigation cleans up the interface and keeps the header a reasonable size even though it now employs 2 separate navigation’s.

Final Thoughts:

I can’t say for certain my approach will work for you but as long as the most sensible items are in your main navigation and are always present you’re application’s usability will go up a few points.

Also, Throwing your entire applications site-map in an over sized footer bar is never an appropriate solution (speaking from experience).

It's 2am, Do You Know Where Your Log Files Are?

2008-05-15T06:21:00Z

So, I was having just another ordinary night, you know, where you’re converting some video files for your iPhone instead of doing something truly productive, when I received my first “low disk space” warning on my Macbook Pro. This came quite to my surprise as I had thoroughly inspected my disk space usage that very morning (yes, I’m a power-geek) and noted 60GB was available. Now, considering the video in question I was encoding was roughly 30MB, I concluded this sudden inflation of used space wasn’t a possible side-effect of my extra curricular encoding activities.

To investigate, I ran a quick WhatSize in hopes to find the culprit and found it was coming from my very own OS X Log files. Now, being in a full-blown panic state, not knowing if my logs would keep inflating—rendering my computer useless (It could happen?), it took a great deal of restraint to not just delete every log file I could find, but instead I googled it to get some insight on what exactly one should do in this situation. Sure enough, deleting every log file in sight was the preferred solution, so I did just that.

After this entire ordeal, I’ve concluded this is in fact, quite a unique problem, but considering this is my 6th time cycling my logs (since that first night) i’ll take my chances and bet you’ve had (or will have) the same problem at some point.

Now if you are however, currently experiencing this same issue, I have indeed conjured up a somewhat more elegant solution then the constant metal juggling of your log file sizes with a spare finger on the “delete” key. It’s a little, freeware application called OnyX and can be scheduled to run and clear your log files automatically. There are other applications that do this same function aswell (Cocktail to name one), so if you find something your more partial too, firstly, clue me in ;-P and secondly, make sure it’s set to cycle all log files.

Transmuting this blog...

2008-05-04T19:23:00Z

Up to now this blog has focused mainly on my personal web endeavors and various technical ramblings of that sort. However, lately i’ve been compelled by the possibilities of blogging and it’s ability to influence others based on ones personal experiences (yeah, I’m a bit late catching the blogging boat). As a result of this revelation, I have been inspired to transmute this blog into something that encompasses more aspects of my persona (which could be good or bad for the general public, we’ll see).

You can now explore my web portfilio, photographical hobbies, attempts at becoming a rockstar, and fascination with moving pictures.

Hopefully you’ll find something of mutual interest here, or perhaps be introduced to something new. Either way given the broadness of content to be contained, there’s certain to be a high level of ambiguity, which I’m hoping could make things a bit suspenseful, no?

Collective Consciousness Indeed

2008-03-19T18:41:00Z

It appears the folks over at Ajaxian.com are having parallels thoughts to my own and have recently reported on a new project called “ProtoSafe” enabling Prototype to be more 3rd party friendly.

It’s not the most elegant solution, however it surely beats methods I’ve used in the past for using multiple javascript libraries (refer to my last article for details).

Head over to Protolific and check it out for yourself.

Why Not To Exclusively Use One Javascript Framework

2008-03-14T05:10:00Z

Since I began using Ruby on Rails I’ve never really thought of using any other javascript framework except the standard Prototype/Scriptaculous pair regarded as the rails standard. I mean, who could blame me, with all those JavaScriptHelpers and fancy RJS templates to entice you. But, don’t get suckered it by these mere facades, as a result, your application may suffer. I’ll explain…

While programming some additions to my photo hosting application, 72photos, I found the need to add functionality that was particularity difficult to do in Prototype. I’ll spare you the actual details, but as a result of this conundrum, I turned to another Javascript framework, which was, what I believed was the enemy, until now…Mootools. Sure, I heard the hype surrounding mootools of late, however, my loyalty to Prototype/Scriptaculous clouded my judgment to explore it more throughly. When I decided to give a decent look through mootools documentation, I noticed it’s very elegant syntax and it surely made more sense in areas such as event handling.

Where am I going with this exactly? Well, If you’re currently loyal to one Javascript framework and it works for you, I’m not suggesting to break out of your current comfort zone. However, I wouldn’t suggest putting aside features or avoiding them because your framework doesn’t support what your trying to do or would take more time then desired to implement. There are other options and I advise you have a look around regardless. Theres no problem using 2 or even 3 separate frameworks in 1 application, surely you’ll have to watch out for incompatibilities, but theres always a workaround.

Personally, I love Ajax/Javascript, it gives life to what would otherwise be a stationary application. A word of advice…If you’re one who relies on RJS and JavascriptHelpers in rails, I highly recommend learning exactly what those helpers do and how to reproduce that particular code in pure javascript unobtrusively. You will benefit with such knowledge in future endeavors.

Oh the possiblities of Slingshot...

2007-11-04T16:57:00Z

I’ve been working lately with a new framework called Slingshot by Joyent. It may have gotten some initial hype when it was released a few months back, but since has died down quite a bit.

Basically Slingshot allows Ruby on Rails applications to run offline as a normal desktop application, plain and simple. Joyent have built wrappers for Windows and Mac OS’s in which wrap a Rails application and port it into an offline runnable form. Sounds amazing, I know, however, there are several drawbacks, none crippling, but drawbacks none the less. It’s a bit rough to forsee all these pitfalls and bugs just by reading their wiki, So, i’ve felt compelled to document my experiences with the framework and how I’ve so far, managed to get past some hurdles. Also note, my testings up to this point have solely been on Mac OSX Tiger.

Just by reading their introductory write-up you can see the potential and with a quick browse of the wiki you can get a full idea how everything works (compared to the more complicated and incomplete Adobe AIR).

Here are a few issues i’ve faced in building my first Slingshot application:

Size: The size of Slingshot is insane. The base framework is roughly 130mb, which basically is unable for a production app.Why is it so big you may ask? Well, I did some digging into the source and Slingshot actually contains a full version of the Ruby language. So, my quick solution was deleting all the .svn files, deleting all the RDocs, tests and examples for each gem that was installed. After that, We’re down to about 27m, much better, still a bit high, but, we’ll deal with that more in depth later.
Open Code: Another drawback of Slingshot is the fact your Rails application code is completely open to viewing being that it resides in a sub-directory that is accessible by simply right-clicking the app and viewing the contents. Now, I haven’t come across any viable mac encryption methods (not sure if Windows has a solution for this either) and giving users full exposure to your source code is not an option (unless of course you’re taking the open-source route). Im my case, I’ve built an API for my main application (a web application), wrote a ruby library for the API, and am now using that API for my Slingshot app, which I have no problem with users being able to view.

So far those we’re my main concerns, now for some positives:

Performace: After opening Slingshot with a newly created rails app, the performance is superb. CPU is at 0.00 and memory is just over 13mb. We’ll see how this continues after adding some more ajax libraries and graphics.

Interface: The great thing about Slingshot is it has the look and feel of any mac application and with Interface Builder you can tweak and edit the menu bar, etc… for even more customization. Changing the application name and icons are very simple, so branding is very simple.

I’ll keep you updated as my application progresses, but so far it looks extremely promising if your in an abiding position.

Let me know if you’ve done any experimenting with Slingshot yourself, i’d love to compare notes!

To Beta or not to Beta

2007-05-11T16:56:00Z

It’s been often talked about whether new web 2.0 services or new internet services in general should enter that proverbial public beta stage rather than holding off and releasing a polished, final product. I’ve been increasing noticing the beta phase being something more accepted and implemented in the web 2.0 community as new services emerge. With XMG Image v2’s release on the horizon, this particular topic has come up quite often in my thoughts when getting ready for deployment. On one side with the beta option, is the idea of getting feedback from users, as there are no better improvements to be made on your application then user-suggested ones. But on another note, this beta stage could be rather irritating to a user who’s constantly dealing with bugs and unexpected events while using your system and at worse, could result in lost clientele. So, before we can make a calculated decision, we need to look at all sides of the story…

Now, before even considering a public beta phase, you need to first have a clear definition of what this so called “beta” phase will actually consist of and the obvious aspects must be taken into account such as; the market/industry your service is in, what your service is trying to accomplish, and the overall magnitude of your application. With that said, for XMG Image, the service is; targeting a fairly unsaturated market, trying to accomplish things in a smoother more user-enjoyable way, and is fairly robust as an application. So, with much emphasis put on usability and the lack of much notable competition in our market, a public beta seems like the most reasonable choice to carry on with.

Now that we’ve established our service is going to head for a public beta, there are some things you should consider before diving into beta and throwing you’re unfinished, possibly buggy system out there for the public to beat the hell out of and send loads of bug reports to you for. For starters, be sure to have a clear definition of what your beta release will actual consist of and what you expect to get out of it. For XMG, entering a beta stage doesn’t mean releasing an incomplete, buggy product, that’s not even going to accomplish its primary functions without encountering bugs. It still means getting 100% of the application finished and all its functions tested from a developer’s standpoint. Leaving the “beta” part more for users feedback and suggestions that, when implemented, will further evolve your application, not to get things working as you initially planned (that’s just being lazy :-P).

Entering a beta stage can be extremely beneficial to new services, but could also be a miscalculated move. Be sure to figure out exactly what you expect to get from your beta stage and take in as much user feedback as you can get from it. It will definitely come in handy when getting ready to revamp your service.

Transforming XMG Image to v2 on Rails

2007-03-20T16:55:00Z

From the inception of XMG Image, it’s goal has been to provide a simple, effective and easy-to-use way to upload and manage your images online. Trying to offer a more intuitive system than others like ImageShack and something a little less social and more robust like Flickr.

Unfortunately, XMG Image v1 was designed and coded in a time before Ruby on Rails and inevitably declared an end-of-life system almost as soon as it was released. But, with my newly acquired knowledge of RoR, I decided there was no better time than the present to shift development towards v2. In doing so, Rails has not failed to deliver as an immensely powerful development framework which completely streamlines the development, testing, and deployment aspects of building a robust web application.

But even as v2 reaches it’s proverbial beta testing phase, the general public, even XMG Users, have no tangible evidence that development for v2 is even taking place (except for this flashy splash page). So here, I present a quick screen shot of the new customer dashboard, and I must admit, it’s dead sexy…

The initial release date is still hard to predict since private beta testing is currently going on. Also worth mentioning, v2 makes heavy use of Ajax/Javascript, so testing has been a challenge.

As for the service itself, there will be 2 plans offered, a completely free plan, and a yearly subscription plan (roughly around $14/year), which will give you access to tons more features and our built-in support ticketing system.

More info on the release will be available here and on the XMG forums as it gets closer.

Feel free to leave a comment/opinion on the new interface!