With that in mind I started looking for alternate hosting solutions but I couldn't find any that matched MediaTemple's feature set or phenomenal customer service (availability issues aside). Ultimately, I ended up finding Google apps mail service. The "Premier" version is essentially an third-party-hosted MS Exchange replacement that seems extremely robust. On digging a bit deeper, though, I found that they offer the Google Apps Standard Edition - a feature-lite version offering up mail, calendaring and chat all through your personal domain.

For those unfamiliar with DNS records, set up might not be as easy as signing up for a Gmail account, but other than that mail was flowing only a few minutes after making the switch.

And now I'm happy to report that a week in things are great. Being able to take advantage of all of gmail's advanced features from my own domains is pretty amazing. If you're looking for an alternative to you hosting providers email solution or interested in a cheaper alternative to Exchange, Google apps is a great choice.

If you're familiar at all with the basic JavaScript slice() method it's application here is nearly identical. Slice() takes two arguments: a start value and an option end value. Just like in slicing in an array, performing a slice() on a jQuery set returns the elements starting at the start position and ending just before the end position. If no end is given (remember, that one's optional), the returned set starts at 'start' and ends at the end of set.

Now, that might not sound quite so straight forward but let's step back and remember one fundamental aspect of jQuery: a jQuery set is really just an array and the array is ordered in the same order each element is found in the DOM. Take this list for instance:

<ul class="colors">
    <li>Red</li>
    <li>Orange</li>
    <li>Yellow</li>
    <li>Green</li>
    <li>Blue</li>
    <li>Indigo</li>
    <li>Violet</li>
</ul>

We can create a set of those list items using:

$('ul.colors');

Now, that by itself doesn't do anything at all, but we can visualize the set as an array with "Red" at position zero, "Orange" at position one, "Yellow" at position two and so on. This makes figuring out slice a piece of cake. Let's see how it might work in practice:

$('ul.colors').slice(2,4).hide();

Will hide "Yellow" and "Green" (We start at position 2 and end just before position 4).

Another fun trick is using a negative number for the start position. When a negative number is passed in the slice starts from the end of the array instead of the beginning. This would mean that

$('ul.colors').slice(-3).hide();

will hide "Blue", "Indigo" and "Violet". Now obviously these examples aren't exactly real world practice but they help illustrate the point. Good places to use this is in dealing with paging for circular carousels (a discussion for another day), in page pagination (hiding everything but the first three paragraphs of a post with a "read more" link) and more.

There is even another nice pro-tips about jQuery's slice: it's non-destructive on existing variables:

var colors = $('ul.colors');
colors.slice(1,4).hide();

If we run console.log(colors), the entire set is still there, "Red" through "Violet".

So there you have it - the jQuery slice() method; another invaluable tool in the front-end developers toolkit.

Unfortunately, that's not as semantic as it could be (even less so if we're not already using a label). On top of that when the form is submitted we have to check every form element we've handled this way and clear it out if it hasn't been set; if we don't, the default values will end up getting submitted.

Using an alternate method we can get around this altogether:

Start with a basic, completely semantic text-input with a label

<p class="input_group">
    <label for="find_a_location">Find a Location</label>
    <input type="text" name="find_a_location" 
        value="" id="find_a_location"></input>
</p>

The input is as plain as it gets, with a name and an id. The label's nothing too special either, just make absolutely sure the 'for' attribute matches the inputs id. The last piece is that I've gone ahead and wrapped the two in another tag and classed it "input_group". This doesn't have to a paragraph tag (a span or li would work just as well), but know that whatever you use will end up having to act a block level element for the positioning of the label.

Next, a dash of CSS to pretty things up a bit. Start by styling the input itself; not terribly necessary, but certainly makes everything more attractive:

input {
    width: 350px;
    border: 10px solid #e2e1d4;
    font-size: 14px;
    padding: 7px;
    outline: none;
    border-radius: 7px;
    -webkit-border-radius: 7px;
    -moz-border-radius: 7px;
}

input:focus {
    border: 10px solid #9c836e;
}

Adding the :focus pseudo-class helps to draw a users attention to the active field.

Next we need to set up the input_group so that we can position the label correctly:

p.input_group {
    width: 350px;
    margin: 1em auto;
    position: relative;
}

And finally, drop the label over the input, giving the appearance that it's actually inside the input:

label {
    font-size: 14px;
    font-family: verdana;
    position: absolute;
    top: 19px;
    left: 19px;
}

We can even give the label a focus class (that will be triggered by javascript later) to push the illusion even further:

label.focus {
    opacity: 0.2;
    -moz-opacity: 0.2;
    filter:alpha(opacity=20);
}

The last piece of the puzzle: the experience layer thanks to JavaScript.

Get started by looping through all the fields we want to set up:

$('p.input_group input').each(function() {

Set up some variables we'll need for later (mainly storing the label that points to this input):

    var id = $(this).attr('id'),
            $label = $('label[for='+id+']');

On page load, if there's already a value in the input, hide the label (this fixes an issue if the user hits the back button and the field is already filled):

    if($(this).val() != '') {
        $label.hide();
    }

When the input is focussed, add a 'focus' class to the label:

    $(this).focus(function() {
        $label.addClass('focus');
    });

When the input is blurred, remove that 'focus' class

    $(this).blur(function() {
        $label.removeClass('focus');
    });

When a key that adds to the input's value value (any letter, number or other ascii character) is pressed, hide the label because the user is actively typing in the field.

    $(this).bind('keydown', function(e) {
        if(e.keyCode >= 48 ) {
            $label.hide();
        }   
    });

When any key is release, check the value; if it's blank, show the label again. This means when a user delete or backspaces through the field, cut's all the text or does anything to blank it out the label comes back

    $(this).bind('keyup', function() {
        if($(this).val() == '') {
            $label.show();
        }
    });

And close out the loop

});

That's all there is to it. One thing to note, this isn't meant to be a replacement for the original method, merely an alternative. There are situations where one will definitely be more viable than the other. Just use whatever works best.

Check out the demo here

It's no secret I seriously admire Dan Cederholm and his work. Needless to say, getting to see him speak at An Event Apart was a huge moment for me. To honor this oh so special of occasions I whipped up a TextMate theme based around the color combinations from Dan's presentation. Enjoy:

Download Handcrafted.tmTheme

For two days in Chicago, I had the privilege to attend An Event Apart - "an intensely educational two-day conference for passionate practitioners of standards-based web design" (from http://aneventapart.com). Divided amongst 12 hour-long sessions, we had the privilege of learning about everything from design to content strategy to in-depth javascript and css techniques from some of the top figures in the industry.

While there's way too much information to go over each bit in detail here, what follows is a notable sound byte from each presenter and an overview of how it fit into their overall presentation:

"One of the biggest tragedies in design is having a beautiful site that fails with real content"

A Site Redesign - Jeffery Zeldman, author, Designing With Web Standards, 3rd Ed.

A common problem in our business, having a beautiful design filled with Lorem Ipsum text. We're all capable of generating content; even if it isn't production ready we can make it realistic. We shouldn't be designing specifically for a specific number of lines of text or a fixed amount of characters. Designing from realistic content out instead of from visual design in (with content coming later) will allow our sites to be more flexible, easier to maintain and in the end more sustainable.

"Design systems, not pages."

Thinking Small - Jason Santa Maria, web designer

To maximize flexibility, we should be designing visual systems instead of specific pages. Using modular design speeds up the design process, allowing design pieces to be mixed and matched without the need for designing every aspect of every page. Again, using this approach makes sites more flexible, easier to develop, easier to maintain and even simpler to refresh layouts with little overhead.

"Content is not a feature"

Content First - Kristina Halvorson, author, Content Strategy for the Web

Content shouldn't be an afterthought. The backbone of information driven sites is the content itself and should be as integral a part of website creation as development or design. In fact, content can help dictate design patterns, look and feel for specific pages or even the tone of how a page is meant to be presented. All content has to be planned for - headers, body copy, footer text, error messages, titles, descriptions, alt text, metadata, everything.

"Everyone is a UX designer whether it's in your title or not"

DIY UX: Give Your Users an Upgrade (Without Calling in a Pro) - Whitney Hess, Strategic Partner, Happy Cog

Everyone involved in web design and development, whether they are UX people or not, are UX designers. We all have an influence over how users perceive and use a site from the feelings the visual design conveys to the responsiveness of the front-end implementation. The best way to find break downs in any of these aspects is to get the site in front of users, to do user testing. Testing doesn't have to be expensive or complicated, it can be as simple as asking people you know, people you work with (but not on the same project) or people that just happen to be around at any given time to use something and give feedback. The trick is to make sure they don't feel compelled to say "oh it's good" because being "good" won't make your site any better. Get users to tear it apart and grow from there

"Static designs fail by definition"

Walls Come Tumbling Down - Andy Clarke, author, Transcending CSS

Websites aren't just carbon copies of photoshop comps. They're living breathing things that act and react to user input. Why, then, do we continue to get client signoff based on static comps? Designing in the browser itself with CSS can potentially take the same amount of (if not less) time that putting together a comp in photoshop but in the end you have a living document that's clickable, scrollable and easily adapted to be used in production. How long would it take to change every single font-face in a comp? With CSS it takes minutes.

"Over time, plugins like the Flash player will give way to <script>"

Javascript Will Save Us All - Eric Meyer, author, CSS: The Definitive Guide, 3rd Ed.

The improvement of Javascript engines in just the past few years is astonishing. Just think of how far we've come from MapQuest to Google and the interface improvements it affords. At the core of all of these great applications - Facebook, Mint, Google Docs and Maps and More - is just HTML, CSS, and Javascript. We're currently in a pattern of using JS to bring legacy browser into the present - patching in support for basic features today that just didn't exist when browsers like Internet Explorer 6 debuted. If we flip our thinking a bit, however, there's no reason that we can't use javascript to push current browsers even further into the future.

"It's cheaper to build something than to have the meeting to discuss the thing you might build"

Building Stuff Fast-And Getting It Approved - Simon Willison, Developer, Guardian News and Media

1 hour kick off meeting, 6 people = 6 man hours

4 hours prototyping, 1 developer = 4 man hours

Developing web applications isn't difficult. No really, it isn't. What's difficult is coming up with an idea, getting everyone on the same page, getting client sign-off, coming up with a core visual identity, going through rounds and rounds of approvals and so on. Thanks to web development frameworks like dJango, Rails and Symfony all of the repetitiveness of building the core functionality of a web app has been boiled down to a few lines of code and maybe a terminal command or two. The sooner you get your stuff in front of users, the more apparent it becomes what they actually want and what is actually wrong with what you've done. Plus, banging out great prototypes is more fun than sitting in meetings anyway.

"Forms suck"

Web Form Design in Action - Luke Wroblewski, author, Web Form Design

No one likes filling out forms. Unfortunately the web runs on them. We can't have user generated content, content management systems, web applications or any of it without forms. While they may be the doldrums of user experience, they don't have to be bare and confusing and inelegant. There are a few ways we can go about making form submission as painless as possible and, in turn, reduce fall-off before people click submit:

• Have a clear path to completion
• Align labels consistently (top aligned labels can increase form entry speed by 10x)
• Add help and tips to anything unfamiliar or with constraints
• Use inline validation to avoid pogo-sticking back and forth between submission and feed back
• Separate out visual cues for primary form actions
• Organize your forms logically
• Gradually engage users - only get the information you actually need to continue up front

"We are product designers"

Designing Virtual Realism - Dan Rubin, co-author, Web Standards Creativity

The unfortunate part of designing for the web is that you can't touch it except through extensions to ourselves (mice, keyboards, etc.) but most principles product design apply to the web. If you design for intuition, your sites will feel better. It may not be quantitative, but a site that feels better and looks better will actually have better response from users, even if it isn't any more function than it's competitors (case in point, the original Apple iPod, beautifully simple and simply beautiful).

"Do websites need to be experienced exactly the same in every browser? Nope"

Progressive Enrichment With CSS3 - Dan Cederholm, author, Bulletproof Web Design

CSS3 is a wonderful tool that can't necessarily be used for mission critical implementation but can be used to enrich experiences in browsers that support them. Experience is the layer that lives on top of good markup and style and css3 is the icing on top of that.

All in all it was a fantastic conference and I'll leave it with my favorite thing that was said by Jeffery Zeldman himself:

"Real web designers write code. Always have, always will."

With minimal effort, these changes have been rolled into a fork of Crispin Porter + Bogusky's open source project Newd.

Taking the Hijax approach to web application development, Newd was engineered specifically to be entirely browsable without javascript. Each state in the app was built based on a rendered static page and then rolled into the main application using jQuery and a custom framework written around the modular approach to Newd's data feeds. For instance:

http://newd-example-domain/#topic

is simply a deep link, wired up with javascript, that allows the application to render the content at

http://newd-example-domain/topics/topic

without refreshing or redirecting the user to a new location. This allows all of your AJAX states to have static, crawlable equivalents.

The downfall here is that when Google indexes "/topics/topic", that's the link it serves back to users in it's search results. To subvert this, Newd has a simple javascript detection on pages rendered through "/topics/topic" - if JS is enabled, the user is redirected back to the AJAX app front-end at "/#topic".

Now, however, that redirection is unnecessary thanks to Google's proposed method. Updating the fragment identifiers is simple, all we need to do is at that extra bang to what is already being rendered ("#!topic" instead of "#topic"), making sure that anything parsing this new hash understands and appropriately ignores the exclamation point.

Up next, our static href's in the main navigation links can finally point to the AJAX state instead of having to be set to the static page.

<a href="/topics/topic">Topic</a>

becomes

<a href="#!topic">topic</a>

Originally, when clicked these links would be parsed by javascript, the hash updated programatically and the default behavior of following the link was prevented.

Finally, Newd needed a way to render the correct topic when presented with the escaped state in the query string (represented by Google's proposed "http://example.com/page?query&escapedfragment_=state"). Being built on CakePHP using the Hijax approach, all static paths were set during the initial implementation which means Newd doesn't require a headless GUI for rendering HTML snapshots of all of its states. Instead, a render time it only needs to be made aware of any escaped states being passed through the url:

if(isset($_GET['_escaped_fragment_'])) {
    $this->params['topic'] = $_GET['_escaped_fragment_'];
}

If the escaped state is passed in the query string, Newd's front_crontoller index method renders the data for the accompanying state for indexing. This rendered page contains our original AJAX state fragments as links, which in turn will get served back through search engine results once crawled.

And that's it. Bringing Newd up to meet this proposed standard took only a few hours thanks primarily it being based on the Hijax approach for AJAX applications. If this new proposal does indeed get adopted it means users will finally have direct access to AJAX content via search results, which is a very exciting prospect.

Browse or download the Newd source updated to this proposed standard at it's page on GitHub

Extremely helpful if you've got password changes in config files that you don't want committed

For the first post, we'll take a look at a basic CSS technique that I can't seem to go a day without using: text-image replacement.

The basic idea here is to take a block of web-safe text (be it a span, a paragraph, a header, a link or really anything) and replace it with an image representing that same text. Now there are a number of reasons we might do this but most likely it's because we'd like to utilize a font that isn't web-safe.

Let's start with a pretty much standard use - a header:

<h1>Markupboy</h1>

with a custom font or graphic:

We'll start with a basic css selector just to get things rolling:

h1 { }

Next, we'll give the header the appropriate background image as well as a height and width to match:

h1 {
    background: url(/images/bkg.h1.png) left top no-repeat;
    height: 80px;
    width: 240px;
}

Markupboy

As you can see, the image is there with the appropriate dimensions, but our text is still visible. Here's where the real trick is, first set the 'overflow' property to hidden

h1 {
    background: url(/images/bkg.h1.png) left top no-repeat;
    height: 80px;
    width: 240px;
    overflow: hidden;
}

and then set 'text-indent' to '-9999px' (or any suitably large negative or positive number)

h1 {
    background: url(/images/bkg.h1.png) left top no-repeat;
    height: 80px;
    width: 240px;
    overflow: hidden;
    text-indent: -9999px;
}

Markupboy

Setting the 'overflow' property to hidden on a block level element makes any child element (including text nodes) that falls outside of the rendering bounds of that parent element to be hidden. Then, with 'text-indent', we're forcing the child text node to render as far outside the parent element as possible and there you have it. We don't need any extra markup in this case and we don't have to resort to 'display: none' as that would cause accessibility issue with screen readers not even being able to access that text.

To take it one step further and make our header a clickable link, we just need to modify the markup a bit

<h1>
    <a href="http://www.markupboy.com">Markupboy</a>
</h1>

and adjust the css slightly

h1 a {
    background: url(/images/bkg.h1.png) left top no-repeat;
    height: 80px;
    width: 240px;
    display: block;
    overflow: hidden;
    text-indent: -9999px;
}

and now we've got a fully text replaced link in all it's clickable glory.

Markupboy

The main difference you'll see here is the addition of 'display: block' to our CSS. This is necessary simply because anchors are inline elements, which means height, width and text-indent will have no effect on them.

One thing to note, this example does only work for block-level elements so be careful in how you use it. I'll be going over inline text-image replacement in the near future.

Well, that's it for the first entry in the 101 series. If you have any questions, comments, or suggestions, feel free to drop me a line at blake[at]markupboy[dot]com.