A Ruby gem is a library you can use in your Ruby applications. It’s really easy to install a gem. You just need to know the name of the gem you want to install. In this Treehouse Quick Tip, Ruby teacher Jason shows you how to install the Bundler gem.

The post How to Install Gems in Ruby on Rails – Treehouse Quick Tip appeared first on Treehouse Blog.

The HTML Working Group has published a Working Draft of Public Identifiers for entity resolution in XHTML. This document adds an additional public identifier that should be recognised by XHTML user agents and cause the HTML character entity definitions to be loaded. Unlike the identifiers already listed by the HTML5 specification, the identifier added by this extension references the set of defintions that is used by HTML. Learn more about the HTML Activity.

Back when I did the Kickstarter for this site, one of the rewards I offered was a critique, public or private, of any website. The only taker was Gus Fune, who opted for the public critique of a site he worked on: epicawesome.co. Thank you Gus for allowing this to be a public learning opportunity!

Here's the desktop view:

Before you get there though, the site has a loading screen:

That was common in the Flash days, but you don't see it much anymore. This site is indeed a normal HTML5 site. There is a "preloader" script that must do some fancy stuff making sure images are loaded before revealing the site. When the pre-loader finishes the overlay slides away revealing the site.

It's tempting to harp on the size of the site and recommend reducing the size so that a pre-loader isn't necessary. But I didn't mind it so much here. The loading time for me was about 8 seconds. Without a pre-loader I would have been annoyed, but showing me the loading progress kept me around. Bear in mind I have fairly decent broadband internet. If my 8 seconds was someone else's 60 seconds, I bet they wouldn't have the same patience.

I would recommend some slow-bandwidth testing. There is a Mac app called SpeedLimit which could help with this, by throttling your fast internet down.

Here's the network waterfall:

The DOM ready happens at a healthy 1 second, which makes it all the more tempting to figure out another loading strategy. Perhaps you could only load the top biggest image right away, and then wait for a scroll event to trigger the loading of the rest of them. You'd save on bandwidth as a bonus.

I'm not going to harp on the huge images. It looks like that is the stylistic direction you wanted to go and you can do that if you want. I ran the images through an image optimizer and got zero savings, so you are optimizing correctly!

As you scroll down the page, the content is divided into sections each with new colors, new styles, and a new hero background image. If the screen is tall enough, the next section is revealed and the transition is rather abrupt.

While it's probably good to have these images separate rather than one enormous image (for caching reasons), perhaps they could be designed to morph into each other a little more smoothly. I also think it would be a good idea to do a little viewport size detection and make each section exactly one browser window large, so that next section isn't revealed until scroll.

The mobile version is this:

It is a smart move to not show the 7.7 MB version to a small screen mobile device!

This version is so worlds away different though that it has me thinking. Is this enough to function for you as a web experience? If it is, can some of this minimalism be present on the large screen version? The large screen version is so intense and colorful you might even describe it as "maximalist"! I'd wonder if people would even realize it's the same agency.

I think it stands to reason someone on a mobile device might want to know more than your blurb and phone number. The large screen version explains your services, shows who you have worked with, shows examples of past work, and more. I might try and get a little closer to content parity with the mobile version and bring the stylistic direction closer one way or the other.

Mobile detection is always tough too. On a retina iPad, it goes mobile:

I would think that device could handle the desktop version OK.

One easy win might be to offer some kind of action to "View the full site".

I feel like the site could benefit from some reigning in of the typography. I'm counting about 13 different typefaces in use. Some of that is just fun variation, and I get that, so I don't want you to think I'm just regurgitating some arbitrary rule about how many you can use in any given situation.

Here's some specifics.

The only place Tahoma is used is here:

I feel like you could pick something else that is already in use elsewhere, or pick a new font that screams "venue sign lettering" more than Tahoma does. I think this is a perfect opportunity to go the extra mile and make sure those letters line up on the lines in the image. That would demonstrate a dedication to craft I know I would appreciate.

The font 'SeasideResortNF' is only used in two places. One of them is this language switcher:

I feel like that typeface was designed to be used only much larger than that and it's breaking down at this small size. Good opportunity to cut it and pick one of the other faces in use on the site.

The 'eurostileregular' font looks pretty good here:

So I'd use it again here rather than busting out Helvetica for the first time on the site.

Super clever how the text is hidden behind the lamp here.

I just might see if you can introduce a shadow somehow to complete the illusion of depth and possibly ditch the Courier for one of the other typefaces already established. If it was coming out of a typewriter or something, sure, but this looks just like a poster on a wall and could be anything.

As far as resources, I already mentioned the images are nicely optimized, so that's great. The CSS is minified and the JS is minified, so great work there! Since this is a one-page site, you could squish the three JavaScript resources together (jQuery + Preloader + Scripts). They aren't big enough for that to be a bad idea.

Stylesheets in the header, scripts in the footer, perfect.

Semantically, it looks pretty solid to me. The header is a <header>. Sections are <sections>. Each section has a proper header. Stylistic-only stuff is a <div>.

One suggestion I would have would be to get the navigation inside of an unordered list. Right now it's just <nav> <a> - which is semantic enough, but after some healthy community debate, navigation in lists seems to be the best practice.

It's somewhat hard to comment on the CSS because, in all honestly, I don't think little one-page sites like this need to be scrutinized to death for their architectural choices. But for the sake of critique, let's find a few things.

I'm looking at the style.less file specifically.

LESS can do includes, so no need to dump the Normalize.css stuff at the top.

@import "normalize.css";

I love Normalize, but might be overkill for a one-page super stylized site like this. Probably 2/3 of it deals with elements you don't have on this site. And some of the other stuff you reset anyway. For instance Normalize sets margins and sizes on headers which you later reset.

There are mixins specifically for box-shadow and border-radius included, which aren't necessary anymore. On the subject of vendor prefixes, I'd suggest removing them entirely and using Autoprefixer as part of your build.

There are quite a few IDs used in the stylesheet. You might just disagree with me philosophically, but I'm a fan of never ever using them to style elements. I'd especially avoid tag-qualifying them like you have in some cases like section#home. ID's are unique so there will never be an article#home, for instance. If you like the tag there for readability or a reminder, you can do /*section*/#home. Tag qualifying anything is generally a bad idea only rarely should you style elements themselves (rather than use a meaningful class), so that's something to look out for in general.

Toward the bottom you have a retina display media query, which you can simplify to:

@media 
    (-webkit-min-device-pixel-ratio: 1.5), 
    (min-resolution: 192dpi) { 
        /* Retina-specific stuff here */
    }

I hope this was useful to you Gus!

If anyone else has any thoughtful critique, share it in the comments.

Website Critique: epicawesome.co is a post from CSS-Tricks