Okay developers, we now have three of the four major browsers supporting re-sizable textarea elements, so it’s about time to update those stylesheets! Here’s what you’re going to do:
- Find anywhere in your CSS that you have a textarea rule
- You probably have a width and height set on it, amirite?
- Set min-height to match the default height setting.
- Set max-height to be 2 or 3 times the default height.
- Which leaves us with width. Now, this whole resizing thing is actually a pretty cool usability feature, which is why I don’t have you turning it off completely. So finish the CSS off be setting resize: vertical. You could also set min and max widths, but this way is one less line of CSS and you will get a more appropriate resize cursor from your browser.
Now you’ve fool-proofed your textareas by limiting their minimum dimensions, while retaining the usability enhancement of allowing users to make the textarea bigger (should they so desire) in order to see more of what they are writing.
Javascript Morse Code Translator from Kevin Sweeney on Vimeo.
Started to play around with the new sound API in the Firefox 4 nightly. Pretty cool to see this in action…even if Flash has supported sound generation for years…and Processing before that!
Not yet playing at the “correct” speed with proper pauses and the like, but it’s a start.
Do you remember your first lightbox experience? Me neither, and yet, they’re on just about every website you visit these days. Not this one though; and I’d like to explain why that is and why this design pattern probably doesn’t belong on your website either.
Lightboxes as we have come to know them have been popularized on the web since 2004 and in that time over 50 varieties and plug-ins have come to be. Predecessors of the lightbox, modal windows have been with us for much longer in many of the applications we use on a daily basis. Before going any further, I’d like to make an extremely important distinction between these two terms. Modal windows serve to focus the user’s attention on content which has a clear relation to a given interaction. Within the context of the web, the two most common—and correct—uses include login windows (when clicking a link that leads to restricted content) and alerts (such as inactivity notifications on banking sites). Lightboxes, on the other hand, seek to augment existing content, often by enlarging images or playing back videos. While both seek to focus a user’s attention to a single piece of content, a lightbox doesn’t really tell the user anything they didn’t already know. Worse still, lightboxes abruptly exit the user from their current browsing mindset.
The most common platform for the lightbox is the portfolio site. This is an obvious and ultimately boring way to display your content! In the end, this shows an insecurity on your part to proudly show off your work at its best and a gross disrespect for your audience now that you’ve begun to force additional clicks upon them. Since the invention of the scroll wheel 15 years ago, scrolling has been, is, and will continue to be an easier mode of interaction than clicking.
And so I issue this plea to today’s web design community: before you download the latest and trendiest jQuery plug-in, first consider the content design, usability and overall architecture of your site!
This multi-window browser experience is probably unlike anything you’ve seen before, though eerily reminiscent of the Javascript-controlled browser window resizing and spawning we saw a decade ago (most notably with Flash sites).
The big headline here is that it’s built with HTML5. I’ve not dived into this enough to understand precisely what components of HTML5 are being used, and Google’s official post doesn’t offer details either. Given every link and article I’ve seen pointing to this today mentions HTML5, somebody oughta give us the deets.
Note: I’ve linked to the Wired article, as the actual site is getting hammered with traffic. It’s also very processor intensive, so close just about everything else running on your machine.
Update: The Chrome Experiments page includes a few snippets about the HTML5 components being used.
Here’s the thing about Facebook that really gets under my skin: They are slowly incorporating the features from every other independent web application on the internet. This is not inherently a problem—companies get bigger and they begin to have the resources to widen their feature set—the issue…
While researching some methods of lazy-loading images, I came across the following plug-in by Mika Tuupola which is based on the ImageLoader utility of the YUI library. A few different things don’t sit right with me with these existing solutions:
- The jQuery plug-in would seem to require that it be included in the <head> of the page. Otherwise, the DOM would be well on its way to being in a loaded state (images and all) before the plug-in even gets fired. Another consideration is that not all website frameworks that we work with will allow this amount of flexibility of picking and choosing where and how your scripts are included. Finally, you are also now committing to loading jQuery in the header of your document. Certainly the extra HTTP requests and blockage of parallel downloading aren’t likely to slow down your page as much as extra images might, but this is still not a perfect solution.
- The jQuery plug-in seems to be aborting the requests for the images, which means that those HTTP requests are still being fired.
- The YUI loader states that you should omit the “src” attribute. Not only is this extremely backwards to have the behavior dictate your markup, ignoring any consideration for progressive enhancement, but it also hurts accessibility and creates markup that will fail W3C markup validation. Devices with JavaScript disabled will not be able to view these images, nor will any type of feeds be able to pull the images down.
Alternate Solution
Where does that leave us? Before that, let’s revisit some of the goals that we’ve just established:
- Sites need control over which images are loaded immediate and which images have delayed loading. Images which are delayed should not make any HTTP requests (even if they are aborted).
- Images should be accessible without a dependency on JavaScript (feed-friendly too).
- Allow JavaScript to be included at bottom of page.
- Site must retain valid markup.
As it turns out, images which are included within the <noscript> tag will not be requested by the browser if JavaScript is enabled. Knowing this, we can use jQuery to read the contents of all <noscript> elements on the page and replace them with the image tags that they are wrapping. One caveat on this, however: browsers seem to interpret the content of the <noscript> tag as plain-text, and I was seeing “<” and “>” when trying the following code:
$('noscript').each(function() {
$(this).replaceWith($(this).find('img'));
});
The solution was to create a placeholder jQuery element:
$('noscript').each(function() {
var newMarkup = $($(this).find('img'));
$(this).replaceWith(newMarkup)
});
Cons
- Increased Markup: This actually isn’t as big of a problem until you hit a threshold of about 200 delayed images. After this point, the extra bytes generated will add up to just a little bit more than the size of the minified version of Mika’s plug-in.
- Maintainability: The JavaScript plug-ins grant a lot of flexibility in specifying where and how much of the images get loaded. This can still be done, but requires that logic to now be ported over into something like PHP.
I’ve been looking at a lot of redesigns of newspapers lately. While they’re at it, someone should start redesigning ads—especially supermarket weeklies. Sounds like a future post here!
I never intended to live in New Jersey. Suffice to say that I ended up there through a series of unfortunate events, but have learned to make my peace and have met plenty of people along the way who aren’t your stereotypical “Jersey Trash” types. This t-shirt concept is for all those people who I feel carry the need to apologize for “the rest of New Jersey”.
Sketch that I did for my idea of “the best alarm clock ever”. I plan on making some changes and turning this into a properly spec’d out wireframe some day. One change I notice immediately is that AM/FM should be a separate button—it should only be one slider that goes “Alarm | iPod | AM | FM”.
One feature I’m most proud of is the concept of an “armed” indicator. I currently have the Neverlate 7-Day Alarm, but my mild obsessive compulsiveness requires that I always hit the snooze button to confirm that the alarm is set. To address this, I would include two thing light panels which frame the time display. If the lights are on, then the alarm is set. I would also change the color of the backlight display to red, as this wavelength of light has the least affect on our night vision. Our eyes are more perceptive to blues and even more so to greens, which give a greater “shock” when reviewing the time after our eyes have adjusted to the dark.
