It’s just a simple file input box, why is that the “hardest part”? Think what that input box represents.

1. User has a device capable of capturing a photo
2. User has transferred that photo to his/her computer
3. User knows the location of that photo file on his/her computer
4. User is ready to brave the file selection dialog box to select it

In a form like this, if the user doesn’t have a digital photo ready to go, they really shouldn’t be filling out the submit form. Having the file input as the first thing stops folks from doing any unnecessary work.

Conversely, users that do have an digital photo ready to go get to choose it right away. That act of choosing a file gets them heavily engaged in the process of filling out this form from the get-go. Choosing a file is a pretty intimate experience as far as web forms go. Once that is done, there will be some excitement in filling the rest of it out so it can be submitted.

I think this goes beyond this particular form. The overall message being: let users do the thing they want to do right away (likely “the hard part”) and the rest of the form will be a breeze for them. Take this example:

Here we ask if the user has a question right away. They are probably at this form to begin with because they do have a question. Let’s let them ask it first thing. Once they’ve written it out, they are pretty committed to this form and have some momentum. Filling out their name/email/phone will be easy.

As opposed to this:

I can imagine this being met with far less enthusiasm. Ugh, more hoops to jump through, I just want to ask a question. Of course you are asking the exact same questions in both examples and a purely logical user would understand that of course name and contact information needs to gathered. But that doesn’t matter, the user is thinking about their question, not what other information this form wants. Let them do the hard part first.

I wish I had some A/B testing to throw at you here, but I don’t. I’d like to do some on this some day. So this is just me tossing out what I think is a good UI choice based on my own professional judgment.

Many things are the same, some are different.

This is true with anything: your watch, a remote control, even your relationships. It’s certainly true with websites. If your website used to work fine, but now it won’t load, then something changed. To fix it, you need to figure out what that thing was.

Pretty obvious? Sure, if everything is working great for you right now. But the minute something breaks, it’s really easy to get into the WELL EVERYTHING WAS WORKING FINE YESTERDAY mode.

What could it have been?

• Has any new software been installed?
• Has any code changed?
• Have you asked everyone with access to it?
• Is your allowed disk space full? Maybe something you don’t often think about was filling it, like server logs.
• Did any file permissions change?
• Are all the external resources your site depends on functioning properly and up to speed? Think: external JavaScript links, external RSS feeds, advertising services, APIs, etc.
• How is incoming traffic? Major spike? Are you watching analytics? More traffic means more server resources, so you’ll need to watch things like your memory usage.
• Is your database server responding properly? Is your database itself in good condition?
• Did anything change with your web host?
• Is your domain registration up to date?
• Is the DNS server you use responding properly?
• Is there a chance you were hacked?

I once had a conversation with a Joyent employee who said that in the overwhelming majority of cases, a website was down because of something the user did, not the hosting. But still, I think a good host will help you figure out what the problem is if it is their fault or not.

a:hover {
 /* Yep, hover is a pseudo class */
}

They are immensely useful in a variety of situations. Some of them are CSS3, some CSS2… it depends on each particular one. Outside of IE, they have great browser support. In IE land, even IE8, support is pretty barren. However, the IE9 preview has full support of them. The link-related ones work but not much else. Let’s take a brief look at each one of them. Don’t worry, there isn’t that many.

Link-related pseudo class selectors

:link – Perhaps the most confusion-causing link-related pseudo selector. Aren’t all <a>’s links? Well not if they don’t have an href attribute. This selects only those that do, thus is essentially the same as a[href]. This selector will become a lot more useful should any-element linking become reality.

:visited – Selects links that have already been visited by the current browser.

:hover – When the mouse cursor rolls over a link, that link is in it’s hover state and this will select it.

:active – Selects when the link while it is being activated (being clicked on or otherwise activated). For example, for the “pressed” state of a button-style link or to make all links feel more button-like.

There is a fun technique to remember all the link pseduo class selectors. Look at the first letter if each: LVHA … LOVE HATE.

Input & link related pseudo class selectors

:focus – Defining hover styles for links is great, but it doesn’t help out those who used keyboard navigation to get to the link. :focus will select links that are the current focus of the keyboard. This is not limited to links, but can be used (and really should be used) on inputs and textareas as well. Some would tell you to define a :focus style for anything that has a :hover style.

Form with a text input in focus. Yellow background is a focus style.

:target – The target pseudo class is used in conjunction with ID’s, and match when the hash tag in the current URL match that ID. So if you are at URL www.yoursite.com/#home then the selector #home:target will match. Then can be extremely powerful. For example, you can create a tabbed area where the tabs link to hash tags and then the panels “activate” by matching :target selectors and (for example) using z-index to move to the top.

:enabled – Selects inputs that are in the default state of enabled and ready to be used.

:disabled – Selects inputs that have the disabled attribute. A lot of browsers will make the input a faded out gray, you can control that with this selector.

:checked – Selects checkboxes that are, wait for it, checked.

:indeterminate – Selects radio buttons that are in the purgatory state of neither chosen or unchosen (like when a page loads with radio button choices but no default is set).

Set of radio buttons in purgatory. Or more accurately, in their :indeterminate status.

Position/Number-based pseudo class selectors

:root – Selects the element that is at the root of the document. Almost certainly will select the <html> element, unless you are specifically working in some weird environment that somehow also allows CSS. Perhaps XML.

:first-child – Selects the first element of its type within a parent.

:last-child – Selects the last element of its type within a parent.

:nth-child(N) – Selects elements based on a simple provided algebraic expression (e.g. “2n” or “4n-1″). Has the ability to do things like select even/odd elements, “every third”, “the first five”, and things like that. Covered in more detail here with a tester tool.

:nth-of-type(N) – Works like :nth-child, but used in places where the elements at the same level are of different types. Like if inside a div you had a number of paragraphs and a number of images. You wanted to select all the odd images. :nth-child won’t work there, you’d use div img:nth-of-type(odd). Particularly useful when working with definition lists and their alternating <dt> and <dd> elements.

:first-of-type – Selects the first element of this type within any parent. So if you have two divs, each had within it a paragraph, image, paragraph, image. Then div img:first-of-type would select the first image inside the first div and the first image inside the second div.

:last-of-type – Same as above, only would select the last image inside the first div and the last image inside the second div.

:nth-last-of-type(N) – Works like :nth-of-type, but it counts up from the bottom instead of the top.

:nth-last-child(N) – Works like :nth-child, but it counts up from the bottom instead of the top.

:only-of-type – Selects only if the element is the only one of its kind within the current parent.

Relational pseudo class selectors

:not(S) – Removes elements from an existing matched set that match the selector inside the parameter of :not(). So for example, all divs except those with a class of “music” = div:not(.music). The spec says that :not selectors cannot be nested, but they can be chained. Some browsers (Firefox) also support comma-separated selectors as the selector parameter, although chaining them would be a far safter bet. Also useful in conjunction with attribute selectors, e.g. input:not([disabled]).

:empty – Selects elements which contain no text and no child elements. e.g. <p></p>

Text-related pseudo class selectors / elements

:first-letter – Selects the first letter of the text in the element. Typical use: dropcaps.

:first-line – Selects the first line of text in the element. Typical use: setting the first sentence in small-caps as a typographical eye-catcher / lead-in.

:lang – This pseudo selector is in the CSS3 spec but only implemented in IE 8+. Will match anything that either has or is a descendant of an element with a matching lang attribute. For example, :lang(fr) will match any paragraph, even without a lang attribute, if the parent body had lang=”fr” as an attribute.

::selection – Allows the changing of style of selected text. For Firefox, you can use ::-moz-selection. More information here.

Quick note

You can chain pseduo selectors just like you can chain class and ID selectors. This is particularly useful here while we are looking at :first-letter and :first-line. You probably wouldn’t want to drop cap every single paragraph on the page, but just the first one, so, p:first-child:first-letter { }

Dropcap using :first-letter, which enlarges the font size and floats to the left.

Content-related pseudo “elements”

:before – Is able to add content before a certain element. For example, adding an opening quote before a blockquote or perhaps an preceding image to set apart a particular paragraph.

:after – Is able to add content after a certain element. For example, a closing quote to a blockquote. Also used commonly for the clearfix, where an empty space is added after the element which clears the float without any need for extra HTML markup.

Quick note

These are appropriately called pseudo “elements” (not selectors) because they don’t select any “real” element that exists on the page. This goes for these two, as well as the previous sections :first-letter and :first-line. Make sense? Like the first letter that :first-letter selects isn’t an element all to itself, it’s just a part of an existing element, hence, pseudo element.

Deprecated

:contains() – As far as I know, this is gone. The current CSS3 spec has removed it. I don’t know the story, let me know if you do. At a glance, it looks ridiculously useful (being able to select objects based on the textual content they contain). It may be because of problems, or having content in selectors being undesirable. My preference would be to have it select by elements rather than text, like p:contains(img), but alas, no such luck.

:required / :optional / :read-only / :read-write – Just use attribute selectors instead.

jQuery Usage

jQuery can use all of these in its selectors, which if awesome. Even awesomer, jQuery has additional pseudo class selectors available.

:first – The same as :nth-child(1)

:eq(X) – The same as :nth-child(X)

:contains(‘text’) – This is removed from CSS, but still works in jQuery.

:lt(X) – The same as :nth-child(-n+X), as in it selects the “first X elements”

:gt(X) - The same as :nth-child(n+X), as in it selects everything except the “first (X-1) elements”

:even – The same as :nth-child(even) or :nth-child(2n)

:odd – The same as :nth-child(odd) or :nth-child(2n+1)

:has(S) – Works like I wish CSS :contain did, where it tests if the element has a descendant of a certain selector before matching.

There are actually a whole bunch more, and all of them are clever and useful (or at least an improvement on readability) See the selector documentation for more.

Specificity

The specificity of a pseudo class selector is less than a regular class selector. It’s the lowest value, the same value as an element selector:

li            {}  /* specificity = 0,0,0,1 */
li:first-line {}  /* specificity = 0,0,0,2 */
li.red  {}        /* specificity = 0,0,1,1 */

So in the example above, the :first-line selector would “beat” the regular list item selector, but the class selector will “beat” both of them.

LightCMS is a Light CMS

Really easy updates. That is the whole point of a “light” CMS. They don’t have as many features or as much extensibility as a “full” CMS (e.g. WordPress), but they do make the job of editing content on a site more intuitive, especially for less technology-inclined clients.

For example, to log in to your site, you append /login to the URL, and you’ll be presented with a login screen directly in the skin of your site.

Any client can appreciate that.

Some of what LightCMS does is common to many CMSs. It is for managing content and building websites. It lets clients do this themselves (literally every single client I’ve had in the past many years has wanted this, whether they actually do it or not). There are users. There are templates. Some features of LightCMS are unique to it, which I’ll cover later.

Editing

The most important part, the editing of content, is a nice clean process. Content is kept on the page in modules. The modules can be drag ‘n dropped around (or manually moved) as well as of course editing and deleted.

Drag and drop modules

Module menu

I enjoy how clean and polished all of this is. There is a lot of detail in an app with this many features and options, and it easily could have been half-assed.

Differentiation

Hosted

A common approach to the “light CMS” thing is to either give the CMS access to your site via FTP credentials, or put files on your server which do the job of editing. Either way, it’s your server. That can be a good thing, I know a lot of times I like having things under my control a lot of times. However, none of them are free, so it’s an expense you have on top of what you already pay for hosting. LightCMS is fully hosted.

They have a bunch of plans (literally 6) from free to a premier $99/month plan. The plans vary in number of users who can access the account, number of pages you can control, and the storage.

Some of the pricing plans

Fully hosted means that, by default, your site lives at a subdomain on lightcms, for example: http://yourwebsite.publishpath.com/. That may work for you, but probably not. Not very professional and all. You can easily use your own domain name though, with a simple CNAME change.

Fully hosted also means no manual upgrading. Not to mention customer support.

FTP

Even with the hosting, and the otherwise kind of clean/sanitized environment, you can get direct FTP access. Nice.

Widgetry

Another unique feature is how they give you functional bits you can add to pages as modules (I think they call them “elements”) just like your own custom ones. For example, a blog element, calendar element, a robust form builders, photo gallery, donations buttons, etc.

Reselling

They have kind of a white label option, where you can have your clients pay for the service, and you earn money from that. They charge $19/month, and you can set the price at whatever you want (you earn whatever on top of 19 you charge). Might be nice for some folks, but probably not something I would use. I prefer billing my own clients, so I’ll just pay for it and mark it up in my own invoices, but hey whatever works.

Your own designs

It should go without saying, but you can use your own designs with this. Basically you create a template with HTML files in a specific naming convention (Home.html, Inside.html, Admin.html, etc). Inside those templates you declare editable regions with “tokens” like this:

<$region$> <$/region$>

Once you got it all together, you just zip it up and upload it and your new design will be available as a template.

Try it

I think it’s a pretty decent little system. Go check out their Why LightCMS? page (and the tour) for a more thorough overview of what it does than what I presented.

Winners

Of course all these people did a great job. For their benefit, we’re just going to nitpick offer a little constructive criticism.

1^st Place – Steven Schrab – View entry

Notes: Take it a little easier on the image compression. CSS image replacement on title looked good, but would be impractical.

2^nd Place – Edd Sowden – View entry

Notes: IE 8 could have used some fallback alpha transparency support. IE 6 had the raw stylesheet, which usually is awesome, but would have been good to support for this contest.

3^rd Place – Mustafa Quilon – View entry

Notes: Would have preferred a Helvetica at the top of the font stack over Gill Sans. Missed the shadows on the footer lines as they go under the article page.

4^th Place – Pam Griffith – View entry

Notes: The font-stretch property caused some big differences in the header type between WebKit and Gecko.

These winners have been contacted, who will then in turn select the winning commenters on the original post. Once they have been selected, those people will be contacted and then prize selecting will begin.

As a whole

Everyone who entered should pat themselves on the back. As a whole everyone did a great job and should be proud. It was a for a good cause and good practice. I just mention this because I’m sure there will be some of you who are unhappy with their score. Don’t take it too seriously…

Judging

Entries were judged by myself and Doug Neiner. We each judged different alternating parts of each entry. You probably know me. Here is Doug:

Doug is a designer, developer, and owner of Pixel Graphic Design Studio. He is CTO of Fuel and blogger at Fuel Your Coding. He also has a personal website.

We judged on the following 100 point scale:

Specific Problem Areas

We were fairly lenient on fonts when it came to all the Helvetica Neue business. PC’s don’t come with that font, so if you used image replacement in the header, that was fine. Using image replacement for the article title isn’t a good idea though, so that was taken off for. I would have rather seen a wrong font than something that unflexible.

After all that judging, these are the things that tripped people up the most:

1. Line Height

There was text all over this mockup, with a variety of line-heights. This was often overlooked or misjudged. Line height is crucial for displaying text that feels good to read.

2. Subtle Shadows

As the three little lines went under the article box, there was a subtle shadow there.

3. Grid

The legs of the clock lined up nicely with the edges of the three photo boxes in the mockup. Many designs didn’t get that right. If the clock was placed in a fluid width manner yet lined up when the window size was about the size of the mockup, that was acceptable.

4. Web text

The text in the three “quote” boxes at the bottom was Georgia in three different colors. That definitely should have been web text sitting on top of those boxes, not an image, even if it was image replacement or had proper ALT text. Web text renders better, is easier to update, is selectable, etc.

Interesting Entries

None of these entries were winners, but they all did interesting stuff, check it out!

#103 – Fixed position footer and the content slides underneath it.
#117 – View source =)
#104 – One of the examples with animations for the arms of the clock
#58 – Total reinvention of the design
#127 – Maybe the only attempt at fixed positioning the clock
#11 – Used the MagicLine

Wrap up

It has been a long road! The important lesson we learned from putting on the event is that it’s a lot more work that the original idea seemed to be. But we got through it! Next time we’ll be more upfront about the timeframe and have the process more ironed out. Some sponsors will be good to to keep the thing cost neutral for everyone.

If you missed it up top, the results are here.

What is your server-side language of choice?

Poll is on the site in the sidebar for your voting pleasure.

I know many of you probably know multiple languages. Some of you probably are forced to write in particular languages for you job. For this poll, choose the language that you actually like the most.

And yes, I know the are more choices than in the list, that’s what “Other” is for, and I’d love to hear what those others are and why you prefer that language. For example, I’ve been hearing more and more about server-side JavaScript. Also if it’s not obvious, this is sans-framework. If you like Rails, clearly that’s Ruby. Django is Python. CodeIgnitor is PHP. Etc, etc.

Should tags like em and strong go <em>(outside)</em> punctuation characters, or (<strong>inside them</strong>)?

Like many polls around here, the question was interesting and stirred up some great conversation, but the question itself was probably flawed. There were only two choices: outside and inside, referring to placement of the HTML tags. So if “outside”, in the example in the question above, the parentheses would be italicized by the <em> tags. If “inside”, in the same example above, the parentheses would be regular text and the text inside them would be bolded by the <strong> tags.

What I was expecting was someone to chime in with the “absolute official rules on the right way to do it according to the typographic gods of the land.” That didn’t really happen. Instead the general consensus was “it depends.”

As for the poll results, at the time of this writing, 6,261 people have voted and the results are 55% in favor of “inside”:

It depends…

The following examples are still debatable, but these feel like the most correct way to go, as agreeded upon by most commenters in the original poll article.

The punctuation is left outside of the tag because the word “today” alone is what is being emphasized.

The punctuation is inside, because the whole phrase “Holy Crap!” is what is being emphasized.

There is split evidence on this one. Some would say that because that whole phrase is an “injection” into the sentence is should be grouped with the tag (outside) and all emphasized. Other more official sources say parentheses should never be emphasized. Personally I’d go outside. Seems like there could be awkward typography tension with the last letter being italic butting up against and upright parentheses.

Punctuation in book titles always go inside the tags.

Again it’s the title alone being emphasized, so having the question mark outside is the general consensus. I feel weird on this one, for some reason I like the opposite when it ends a sentence like this and prefer seeing the question mark follow suite with the previous words. This is a case where actually <i> may be more appropriate…

HTML5 and <b> & <i>

Ever since I’ve been a web designer I’ve been scoffing at the use of the deprecated <b> and <i> tags and dutifully fixing them with the more semantic <strong> and <em> tags. This always made sense to me as we are applying emphasis with these tags, not any specific styling. For example, you might want to leave the text roman for a strong tag but apply a background behind it instead to call it out.

But now that we are pretty much ready to rock with HTML5, we see the <b> and <i> tags return. WTF, you ask? Well, that’s what I thought, until you read up and think on it a bit. HTML5 is not replacing strong and em, these are just coming back in addition to them, and all four will live in harmony. In general, you’ll still use em and strong to emphasize words in text, but you should use b and i when you are bolding for the sake of bolding or italicizing for the sake of italicizing.

For example, book titles in text should be italicized. Not emphasized, italicized. That is a case of italicizing for the sake of italicizing and makes more sense to use the <i> tag.

I got a nice card from Doctors Without Borders from the donation made based on the number of entries, so in the meantime we can all feel good about that =).

CSS3 is a big mess! 4+ rules for making a corner round or adding a drop shadow! Preposterous! Where are the standards?!

I’ve been hearing a ton of that. There is something of a point here. We all like standards, no question they are a good thing for the industry. Seeing a bunch of messy/repeated code like CSS3 can produce doesn’t feel like the clean happy code that standards is supposed to be all about.

But here is the deal.

The specs for these things aren’t done yet. Standards move frigging slowly. Browser vendors know we want this stuff, so they don’t wait for the spec, the use vendor-specific CSS attributes so we can start using/testing them now. This is good. It means they aren’t sitting on their asses waiting for a slow train that answers to no one. When the spec does get finished, they can roll out support for it in the standard way much quicker.

In my opinion, it would be worse for browsers to implement the new attributes without the vendor-specific prefixes, as that would actually be abandoning standards.

I’m sure most of you read these sites anyway, but just in case…

I thought Nettuts ran a pretty sweet article about jQuery and it’s hidden features by James Padolsey. For example, I always forget how awesomely easy it is to serialize from inputs (like for AJAX submission). Serialize = find all the inputs in the form and build a query string with the name/value pairs, instead of doing all that yourself/hard coding it.

Then Smashing Magazine ran a great one by Andy Rutledge answering common questions about design professionalism. Andy is an opinionated dude and I love how he dished out some hard facts here. For example, if you are asking questions like “I’m just staring freelancing and I’m wondering how I can get more clients…” then you probably shouldn’t be freelancing. Plus, a heaping helping of personal responsibility.

Jeff Starr over on Digging Into WordPress wrote up a nice guide on getting a plugin into the official plugin repository. I’m a little disappointed in myself I’ve never done this before. I’m not much of a deep backend dude, but still, I have a few ideas that I think would make cool plugins.

I’m gonna close comments here just because anything that needs to be said about any of these things is probably best said at that article.