Ethan Marcotte has just published Responsive Web Design, a short book on the techniques described in some of the articles we’ve read. And the ebook version (which includes a plain old PDF) is just $9.
While looking for documentation on HTML5 I found this really interesting site on the history of HTML. It describes some very interesting things. It also has some archived e-mails from 1993 about developing new tags and trying to adopt web standards. I also learned a little more about MIME types and XHTML. You should check it out if you're really interested in learning more about web development.
Here is an interesting web article on the trends in web development for 2011. Some of these we focused on in the Web 1 class. One thing I was intrigued by is the QR (Quick Response Barcode). You can generate different types of QR barcodes here. The QR barcode seems like an interesting way to advertise websites and even bring data and information to the public.
Your work is now up on the projects page.
Thank you all for a great semester! Please feel free to email me this summer if you have questions, thoughts, or suggestions about Web 2. This site will be sticking around until the fall, at which point I’ll probably move it to a different address (and post a note here).
Here’s a quick summary of last night’s review of servers and hosting.
A domain costs $8-10 per year. You buy it through a registrar who may or may not be the same as your web host. It usually makes sense to keep those two things separate, so that you don’t get locked in to one provider (especially when they raise prices after the first year). I recommend NameCheap. Other good registrars are Gandi and Hover. Marco Arment, an iPhone app developer, has some theories about the pitfalls and problems with registrars.
Hosting costs $10-20 per month (unless your site has unusual needs or receives a lot of traffic). Some of the most reputable hosts are MediaTemple, Linode, and Slicehost. They all have $20 per month plans.
Make sure you choose a host that lets you run PHP 5 and MySQL. Ideally they should offer sFTP, in addition to FTP: it means your password and files get transmitted much more securely. Web hosts try to distinguish themselves through spec lists (20GB of storage, 200GB of bandwidth, 20 Databases!). But at least in the short term, what matters more is their customer service: if something goes wrong, or you can’t get something configured, you want them to answer your support request within a day or two. All that said, there are some budget options: Bluehost has a $6/mo. plan.
Once you have both a domain name and a host, you connect the two so that the domain name is associated with your server space. Your host will give you four to six Domain Name Server addresses for you to punch into your registrar’s control panel. After doing so, it usually takes 24 hours or so for the domain connection to “propagate” throughout the internet. After that, you’re in business: the files you FTP to your server space will be served from your domain name on the web.
Here I’ve typed in those four DNS addresses to tell Namecheap that the domain “jamesmuspratt.com” is hosted over at Joyent. You only have to do this once, unless you change hosts.
Some web hosts allow you to upload files to your server space over a web interface, but that gets tedious quickly. Instead, you should use an FTP program. Transmit is the hands-down winner here. It’s $39 but that gets you a whole bunch of features that are extremely useful, so it’s worth it in the long run. Fetch ($29) is a popular alternative, and a free option is Cyberduck, which is open-source.
Jeremy Keith is live-blogging the An Event Apart web conference going on in Boston this week. He’s written up notes from all of the presentations; the ones by Luke Wroblewski, Ethan Marcotte, and Jeffrey Zeldman are particularly relevant to the themes of information architecture and responsive design that we’ve been discussing.
I shared this site because it inspired to to build my single page scrolling site and to make my logo in the top left change colors using a transparency like I did. Hope you all enjoyed!
I shared this site because of the cool ping image in the background that changes from robots to zombies.
Interesting take on setting blocks of text in columns on the web from Khoi Vinh:
I take a different position, though. I think that the desire to approach screen-based layout with columnized text is misguided. Multiple columns are an effective layout technique in print because they improve legibility for long blocks of text. But for digital media, it’s my feeling that they make it harder to read text.
This is primarily a branding site which also offers shopping. There is not a way to reach the landing page unless you visit the site again. There are inconsistencies in the navigation of different shopping pages. Requires one to click on several pages if you saw something you liked but wanted to return to it.
The FLOWmarket is a company that sells non-tangible items in small cans. Initially, I found the product really interesting but I also think the websThe FLOWmarket is a company that sells non-tangible items in small cans. Initially, I found the product really interesting but I also think the website is very nice being only in black and white and set in a very basic beautiful type. It matches the product very well.
Oliver Kavanagh's portfolio really caught my eye with the overlapping and very LARGE typography. Even though it is very interesting to the eye, I don't think its the most effective as far as navigation goes.
A content heavy shopping site for safety equipment. The tabs at top have drop down lists which is not new, but the delay seems to be too long. Included is the contact drop down which is a nice feature because it saves one from having to visit another page.
The black content titles are hover reveals. They are able to hide descriptions to make the page a little cleaner and provide content when one may choose to see it.
Responsive design is the evolution of a general principal that promotes flexibility and accessibility over “pixel precision.” It has picked up a lot of steam in the past two year as mobile internet use has surged and the debate over the roles of websites versus proprietary apps has raged.
Big media sites often dedicate entire mini-sites to mobile users: sometimes known as the “m dot” approach, these sites display much of the same content as their “desktop” versions, but simplify the layout to a single column, skip the ads and video features, and move the navigation to the top of the page. Take a look at the Guardian mobile, BBC News mobile, or Facebook mobile for examples. The logic used to make a good amount of sense: site developers knew that mobile phones have low-resolution screens, expensive internet access rates, and that users would be in a hurry to see the content, preferably unadorned by a desktop-optimized design. Therefore, they reason, those users should be re-directed to a separate “mobile experience” specifically tuned to their needs.
But this logic has started to fall apart in recent years. What about tablet computers — are they “mobile”? Should iPad users be sent to mobile-optimized sites or given the desktop version? What about iPod touches connected via wifi, which have high bandwidth and higher resolution screens than computers from the mid-90s? For that matter, why should desktop computer users always get image-heavy versions of the site? Things get even more problematic when developers have to manage multiple URLs that serve up similar content: when a desktop user emails a link (e.g. http://nytimes.com/obama-article) and it is opened by a mobile user, should it redirect to http://m.nytimes.com/obama-article? What if content the desktop user was referring to is now missing? And what about search engines — should the mobile versions of all pages be hidden from them, so they don’t water down the SEO value of the desktop URLs?
Responsive design does not answer all of these questions, but it certainly takes a new approach: We shouldn’t slice our website up into multiple versions based on our guesses about the needs that go with particular devices: after all, the mobile user might well want the “full” experience, while the desktop user might still be on dial up or like to keep his or her browser window skinny.
It is better and simpler, the argument goes, to create a single website that adapts to particular features of the user’s software. This is distinct from the discredited practice of using Javascript to “sniff” the user’s particular browser or OS, since feature detection is “future compatible”: that is, it is likely to keep working as new versions of the browsers are introduced. Jeremy Keith explains this argument well in his post One Web.
As described by designer/developer Ethan Marcotte, today responsive design can take advantage of at least three techniques: (1) a flexible grid design, (2) images that scale, and (3) media queries. Combining the three techniques enables the layout of a site to adapt to radically different browser widths.
It is common to use a grid system to organize information into a set of visually-pleasing columns. Like print designers, web designers often like to use particular mathematical relationships to create their grid: a sidebar’s width might be a half or a third of the main column’s width, and then contain elements that are each half of that width. (See the 960 grid system for one popular framework).
Suppose you design such a layout using a series of floated div containers, each set to pixel widths. (You probably would not set any heights with CSS, but instead allow the content to define the height of each div). Your HTML outline might look like this:
<div id="content">
<div id="main">
[content]
</div> <!-- /main -->
<div id="side">
<div id="bio">
[content]
</div> <!-- /bio -->
<div id="links">
[content]
</div> <!-- /links -->
</div> <!-- /side -->
</div> <!-- /content -->
And your CSS might look like this
content {float:left; width:800px;}
#main {float:left; width:475px;}
#side {float:right; width:300px;}
#bio {float:left; width:145px;}
#links {float:right; width:145px;}
Creating a “flexible grid” means converting those pixel values to percentages. But first, we need to set an overall maximum width for our page, to prevent lines of text from getting too long. So even though our pixel-width for content was 800 px, we might choose a larger maximum value for the flexible design.
#content {max-width: 1200px}
Now we dive into the main work of converting container widths from pixels to percentages. The key point here is that you must always calculate the percentage based on the parent container of your element. In other words, when we set the width of <div id="bio">, we should divide 145 px by 300 px (since side is its parent), not by 800 px. Ethan Marcotte describes the formula as follows: target ÷ context = result, where “context” means the parent container. Following this procedure, we get the following:
content {float:left; max-width:1200px;}
#main {float:left; width:59.4%;}
#side {float:right; width:37.5%;}
#bio {float:left; width:48%;}
#links {float:right; width:48%;}
I’ve left out margins for simplicity, but they follow the same rules. margin-right:10px on the main div would come out to margin-right: 8%;
This is already a much better web layout: users with Cinema Displays will actually get the benefit of having such a large screen, while iPad users won’t have to scroll sideways or zoom in and out.
Images, of course, have defined dimensions by default: for a responsive design, you will usually embed relatively large-size images in your pages (maybe 1000 px wide), and then allow the browser to scale them down as needed. To allow images to scale, we first need to remove any height and width attributes from the image tags themselves, since they will prevent the scaling from working: So <img src="myphoto.jpg" alt="My photo" width="200" height="100" /> becomes <img src="myphoto.jpg" alt="My photo" />. (Both versions are valid XHTML, though only the former allows the browser to draw the shape of the image before it has entirely loaded).
Second, we need to write a max-width declaration for images that we want to scale. The beauty of max-width is that it scales the images down when their container gets skinny (100% means 100% of the container), but it doesn’t scale the image up when the container gets very wide (which would cause pixelization). So we target the content images with a CSS rule:
#content img {
max-width:100%;
}
Even a flexible grid, however, starts to break down as the browser gets extremely skinny. Media queries — a CSS3 technique — come to our rescue here. This special syntax allows us to change the layout based on the browser’s width. We can therefore create three (or four, or five…) layouts that kick in at particular widths. And since our design is percentage-based, the site will continually adapt itself to the browser within each of these layouts.
Media queries use a strange syntax and add an extra nesting of curly braces, but if you follow the format below, you should be able to get them working. And because they contain regular CSS rules, you are free to change any element (such as font-size) for any of the layouts.
Here we just use media queries to turn off floats and change widths, creating a two-column layout optimized for smaller screens and a single-column layout optimized for phones.
content {float:left; max-width:1200px;}
#main {float:left; width:59.4%;}
#side {float:right; width:37.5%;}
#bio {float:left; width:48%;}
#links {float:right; width:48%;}
/* Begin medium, two-column layout */
@media screen and (min-width: 601px) and (max-width: 800px) {
#bio, #links {float:none; width:100%;}
}
/* end two-column layout*/
/* Begin single-column layout */
@media screen and (max-width: 600px) {
#main, #bio, #links, #side {float;none; width:100%;}
}
}
It’s important to note that these techniques are only part of the picture, and “responsive design” may end up meaning different things for different websites. More importantly, there are techniques still being developed that will help responsive design live up to its own philosophy: chief among these are techniques for serving up images appropriate to the size at which they will be rendered, rather than wasting bandwidth by serving very large images to all users.
Safari for iOS (aka “MobileSafari”) assumes that websites are 980 px wide, which will usually defeat the “small screen” media query you write. To fix it, put the following meta tag in the <head> of your pages:
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
Most of the CSS properties we have used so far are technically from the CSS 2.1 specification, and browser support for them is quite good in the latest versions of the major browsers (Internet Explorer 8 and 9, Safari 5, Firefox 3 and 4, and Chrome 11).
CSS3 is not finalized, and browser support is very uneven, but its new properties enable all sorts of interesting styles and animations. Very often you will have to declare the same property and value multiple times, once in a generic way, and several times again with “vendor prefixes”, similar-looking properties that target particular browsers or rendering engines. -webkit targets Safari and Chrome, -moz is for Firefox, and -o is for Opera. Be sure to write the vendor-specific declarations first, followed by the generic declaration. That way, any browser that supports the generic declaration will use it.
In a few years we will be able to drop the vendor prefixes and just use the generic properties, but we’re stuck with them for now. For more on the reasons behind vendor prefixes, read Prefix for Posthack, by Eric Meyer. For a brief look at browser support, look at Deep Blue Sky: CSS3 Support by Browser.
We’re used to specifying text, border, and background colors as English words (color:gray;) and hexademical codes (color:#555555;). The RGB model lets you specify colors with red, green, and blue values (each numbered 0 to 255). Like hexadecimal codes, these are visible in the color pickers in Adobe programs.
#main a {
color: rgb(76,149,224); /* blue */
}
RGBa builds on this syntax: you use RGBa to specify an RGB color and then an amount of alpha transparency, which uses a scale of 0 to 1, where 1 is the normal, opaque setting.
#main a {
color: rgba(76,149,224, .8); /* blue with 80% opacity */
background-color: yellow;
}
Why have transparency on your text, rather than just pick a lighter color? You might want to allow a background color — or more often a texture or image — to mix with the text color. Keep in mind you can use RGBa wherever colors are specified. Here’s how to create a semi-transparent border on div:
div#main {
border: 10px solid rgba(255, 255, 255, 0.3);
}
The opacity property controls the transparency of the entire contents of the HTML element, images, background images, and text included — not just the background. Unfortunately, this is a property that neither Internet Explorer 6 or 7 supports. Although Microsoft hasn’t adopted the standard vendor prefix syntax, you can add the Explorer-specific filter property. Use the syntax below:
#main a:hover {
filter: alpha(opacity=80);
-moz-opacity: .8;
opacity: .8;
}
Note that border-radius might better be named “box-roundness” — you might well put a background color on an element and round its corners without adding a border at all.
#main {
-webkit-border-radius: 12px;
-moz-border-radius: 12px;
border-radius: 12px;
}
CSS3 lets you put a single chunk of text into multiple (equal-size) columns, without floats or complex positioning. This is an impressive trick, but in practice columns have big usability problems. You don’t know the height of the user’s browser window, and so anything but very short columns might require the user to scroll up and down repeatedly to read your text. The basic syntax for the two approaches is below. See Quirksmode’s article on CSS3 columns for more info.
/* Define the column COUNT */
div#main {
/* column count */
-moz-column-count: 3;
-webkit-column-count: 3;
column-count: 3;
/* gutters, aka gaps */
-moz-column-gap: 20px;
-webkit-column-gap: 20px;
/* rules: same syntax as borders*/
-moz-column-rule: 1px solid black;
-webkit-column-rule: 1px solid black;
}
/* Define the column WIDTH */
div#main {
/* column width */
-moz-column-width: 150px;
-webkit-column-width: 150px;
column-width: 150px;
/* gutters, aka gaps */
-moz-column-gap: 20px;
-webkit-column-gap: 20px;
/* rules: same syntax as borders*/
-moz-column-rule: 1px solid black;
-webkit-column-rule: 1px solid black;
}
CSS3 lets you attach multiple background images to a single element. The trick is to use comma-separated values and the verbose, hyphenated properties instead of the customary, all-in-one background property:
#side {
background-image: url(background1.png), url(background2.png);
background-position: 0 0, 10px 10px;
}
Drop shadows are easily generated with CSS3, too, and you can control the shadow offset (how far it is shifted from the element’s edges), how blurry the shadow is, and the shadow color. The syntax goes like this: offset-x offset-y blur-amount shadow-color:
img {
-moz-box-shadow: 0 0 10px #00b4ff;
-webkit-box-shadow: 0 0 10px #00b4ff;
box-shadow: 0 0 10px #00b4ff;
}
CSS3 Transformations manipulate HTML elements in ways that older CSS properties can’t. You can combine these effects with smooth CSS transitions (below) for a more fluid effect. Here’s a quick way to scale images up to 120% size on hover:
#img:hover {
margin:0;
-webkit-transform: scale(1.2);
-moz-transform: scale(1.2);
-o-transform: scale(1.2);
transform: scale(1.2);
}
Other transform values include rotate(), skew(), and translate().
Probably the most interesting part of CSS3 is enabling transitions. The most common use is to make the change from a normal state to a hover state gradual, rather than instantaneous (this effect is very common with Flash).
For instance, suppose we have already created a few links that have a class of “button”, and we set them to be blue. On hover, we change them to green and move them 2 pixels down (using margin-top). By default, these changes kick in the moment the user’s mouse passes over the button. Adding a smooth transition requires just four lines of CSS3 code:
a.button {
color:blue;
-webkit-transition: all 1s ease;
-moz-transition: all 1s ease;
-o-transition: all 1s ease;
transition: all 1s ease;
}
a.button:hover {
margin-top:2px;
color:green;
}
Notice that you must put the transitions on the a.button style, not on a.button:hover. This seems illogical, since the effect only happens on hover, but remember that CSS uses pseudo-classes for other states besides hover: a:link, a:target, a:active, a:visited. Since the transition would generally be intended to occur for those states too, it was decided to simplify things by requiring the transition info only on the default style.
Our transition is composed of three values: first, we specify which properties should be affected by the transition. Most of the time, all is the easiest choice. However, if we’d only wanted the color change to be gradual, and the margin change to happen instantly, we could have written: transition: color 1s ease;. Second, we write the transition duration, in seconds. Finally, we specify easing. Easing is mostly visible when moving, scaling, or rotating an element: it means making the animation fast at the slow at the beginning and end, making it act more like a real life object. Your options include linear (no easing), ease-in, ease-out, and ease. Again, most of the time ease is a good choice. See Dan Cederholm’s Understanding CSS3 Transitions for more.
I've really wanted to embrace this fluid, flexible and responsive web design. I think it's the best darn thing ever. Here is a really good article about media queries. We discussed this a bit in class and had an exercise on it, but this goes a little more in-depth.
A List Apart: Responsive Design
I really enjoyed the "responsive architecture" description.
Next week we will be doing critiques. I realize this project is more hurried than the last, and there is a lot of new material. Nevertheless, it is important for you to get your sites to a state that you can get meaningful feedback from the group. Please be ready to do a quick overview of the material you are working with, then show your design concept (wireframe and/or photoshop mockup), and finally your in-progress HTML and CSS, even if they are not fully functional. If you need help accomplishing some specific goal with your code, feel free to email me.
Good luck with all your work as the semester comes to an end!
Like HTML and CSS, Javascript is a “web standard,” meaning its functions and implementation are defined by a standards body. But historically browser implementation of Javascript has been inconsistent and buggy. Add in a legacy of bad coding practices (“hijacking the browser” with pop-ups, manipulated scroll bars, etc.), and its reputation is less than stellar. But browser support has improved in recent years, and today Javascript libraries can help smooth out the remaining differences.
Note that Javascript, a client-side scripting language, has no relationship to Java, a full-fledged programming language used on everything from servers to mobile phones.
Javascript should always be implemented in such a way that its absence doesn’t affect the core functionality of your site. This is sometimes called the principle of “graceful degradation” or “progressive enhancement.” Many screenreaders, mobile browsers (especially on non-smartphones), and older desktop browsers have limited or no support for Javascript — we still want our sites to be as accessible as possible for users (and search engines) using such software. You can think of Javascript as the third conceptual layer in the construction of a web page:
| Content Layer | Presentation/Style Layer | Behavior Layer |
|---|---|---|
| HTML | CSS | Javascript |
We’ll skip the basics of Javascript and jump into jQuery, a Javascript library that enables a huge variety of animations, page manipulations, and other tricks and enhancements. You can think of a library as a middleman that protects you from writing actual Javascript (which can be ugly and tedious) and instead lets you write clearer, simpler code in a syntax that builds on your knowledge of CSS. (Other popular libraries include Prototype, Mootools, and Yahoo’s YUI.)
With jQuery, you always add a <script> tag in the <head> of your page (usually after the CSS link) that embeds the library file itself (a chunk of illegible code). You then write your custom code after it to accomplish something specific with that page. Your custom code might well be written inline (between <script> and </script> tags) or linked to an external file. I usually put all my Javascripts in one folder and link to the files:
<script type="text/Javascript" src="js/jquery-1.3.2.min.js"></script>
<script type="text/Javascript" src="js/mycustomscript.js"></script>
In addition, jQuery supports a variety of plugins, which are themselves chunks of code or mini-libraries that extend the functionality of jQuery. If you want to use my all-time favorite slideshow plugin Cycle, you would include jQuery itself, then the Cycle plugin, and finally your custom code:
<script type="text/Javascript" src="js/jquery-1.3.2.min.js"></script>
<script type="text/Javascript" src="js/jquery.cycle.all.js"></script>
<script type="text/Javascript" src="js/mycustomscript.js"></script>
Javascripts work by manipulating your page, or specifically, the “Document Object Model,” which simply means the structure of nested tags that comprise your page. This manipulation generally only affects the page’s contents as they exist in the memory of the browser. No files are changed, and unless you are using advanced techniques, reloading the page will reset any manipulations Javascript has performed.
Take a look at this Expand/Collapse Demo from Soh Tanaka. If you view source and scroll past the inline CSS, you’ll see two lines of Javascript. First, the jQuery library is included — here it is being pulled straight from the jQuery serves (compared to embedding a local copy, this has the downsides of being slower and reliant on jQuery.com’s servers). Notice how the script tags open and close without any text inside them:
<script type="text/Javascript" src="http://code.jquery.com/jquery-latest.js"></script>
Then comes a chunk of custom jQuery code, written inline between a <script> and a </script> tag:
<script type="text/Javascript">
$(document).ready(function(){
$(".toggle_container").hide();
$("h2.trigger").click(function(){
$(this).toggleClass("active").next().slideToggle("slow");
});
});
</script>
You don’t need to understand all the syntax here to use and adapt this script to your site. The key points are as follows:
jQuery targets HTML elements using the CSS selectors that you already know and love. In the above example, any <div class="toggle_container"> is hidden as soon as the page is “ready” (i.e. enough of it has loaded for the script to safely start working). Then a function is attached to each <h2 class="trigger">: when clicking the h2, the function adds a class to that h2 named active; it then looks for the HTML element that follows the h2 in the HTML and slides it open slowly.
Finally, even though your HTML is not “really” being altered, you can still style the altered state of the page. In the above example, you can write a CSS rule that changes the h2 only when it has a class of active.
In the above example, the “+” icon is a background image attached to every h2.trigger via CSS:
h2.trigger {
padding: 0 0 0 50px;
margin: 0 0 5px 0;
background: url(h2_trigger_a.gif) no-repeat;
height: 46px;
}
Since we know the h2 will receive an additional class of active when it is clicked, we can write a rule for that situation (even though it doesn’t occur in the page as we have written it). In this case the designer has embedded the “-” symbol in the same background image, so it can be revealed simply by shifting its position:
h2.active {background-position: left bottom;}
As stated before, jQuery is not literally rewriting your HTML file — it is editing a virtual copy that sits in the browser’s memory. To see what it is doing, make use of the browser tools available for Safari, Firefox, and Chrome: they will show you the altered “state” created by the Javascript.
This author website seems to have a bit more going for it...
The challenge is to come up with a design that stands out from the pack, and I'm not at all sure how to do it. Any ideas would be welcome.
This guy is one of the hottest-selling authors on the planet, but again, there's nothing particularly special about his website...
This is Sharyn McCrumb's website. She's one of my favorite writers, but again, from a design sense, this website isn't going to knock anyone's socks off...
This is the first in a series of screen shots from websites built for authors. As you can see, they all seem to have certain elements in common and they aren't particularly impressive from a design sense.