Simian Design

Doug Bowman has a _fantastic_ read on how he, and the rest of the team over at Google, recreated some buttons that just launched the other day over at gMail.  The problem they were looking to fix was one of complex actions, where a button can do more than one thing.

A basic 

<input type="submit">

 could be used for single actions, a 

<select>

element could be used for a compact menu of actions, and 

<input type="radio">

 could be used for selecting mutually exclusive options. But we’re left with no way to represent other interactions common in desktop apps. Such as a checkbox that represents more than just on or off. Or the use of auto-complete to refine or narrow the options in a drop-down menu. On top of this, the controls we can render have significantly different appearances across browsers and platforms. Even within a single browser, buttons and select menus have quite different designs.

Enter: the concept of custom buttons.

If you care reading about interaction design, functionality, usability or things about how to sweat the details like making pillbox buttons then go read this, read it now.  It’s fantastic.

Dan Wellman has written an excellent article, The Definitive Guide to Creating a Practical jQuery Plugin. He takes you step-by-step through the entire process.

In this article we’re going to be building our very own jQuery plugin step-by-step from scratch; jQuery makes this task exceptionally easy for us, giving us a simple method of packaging up our scripts and exposing their functionality, and encouraging the use of scalable and reusable object-oriented techniques.

Writing a jQuery plugin makes sense if you have code you reuse a great deal. You can drop code into your site and have it work right away with little or no tweaking of the code.

He takes you through the Adding Configurable Properties, building Constructor Methods, and adding to the plugin’s API.

It’s a very well written tutorial, easy to follow, easy to help you along.

Jon Hobbs-Smith has written an excellent article on 25 ways to improve your jQuery.  It’s a quite well-written list of tips and tricks.  

It’s not written for super-advanced users, nor beginners, rather intermediate users. So you won’t find entry-level tips here, nor will you find advanced explanations on why you should enclose items, or the fastest way to render something to the DOM.  It’s a series of real-life, useful, in-the-trenches-kind of tips.

My favorite tip so far is tip #23: Add a JS class to your HTML attribute.  By adding a class to your HTML attribute on the javascript load, you get a CSS declarator that is valid only if JS is turned on, which allows you a very easy way to hide things if JS is turned off.

Very slick.

The entire article is worth reading, and worth bookmarking.  Nicely done.

Flickr recently released a Flickr site custom tailored for the iPhone.  They wrote about some of the rules they learnt doing this site, which I find fascinating.  I’m pulling out the main points, but you really need to go read the detailed description of why they’re doing things the way they are.

1. Don’t Use a JavaScript Library or CSS Framework
2. Load Page Fragments Instead of Full Pages
3. Don’t Build for Just One Device
4. Optimize Everything
5. Tell the User What is Happening

Now they’ve put together a library just for the iPhone that handles many of these items. The iUI framework seems to be a iPhone version of the YUI framework, but it’s a good start.

I don’t like the default SharePoint breadcrumbs. They annoy me in multiple ways.  And I’m not alone in my disdain.

MOSS 2007 has two breadcrumbs that are included on the master page.  Not one, but two.  The Global Breadcrumb appears in the upper left of a default SharePoint site, and it shows the site levels as a person delves into a site.   A very high-level breadcrumb.  

The Page Level breadcrumb is also included on the master page, wrapped in a content placeholder.   This allows the master page to provide default information, but allowing the pages to replace that default content with it’s own.  If on the page level you empty out that content placeholder, you can zero out the Page Level breadcrumbs.  Annoying.

Heather Solomon has a great writeup on breadcrumbs (shocker), which is well worth a read.  I particularly like the demo image she provides showing the difference between the two main providers you can choose from.

The next challenge with the breadcrumb is the site map provider it uses.  There are several available in SharePoint, and two that are used predominantly for WSS and MOSS sites in the breadcrumb.   The problem is the WSS one is great for lists and libraries, and the MOSS one is great for publishing pages.  But they each are not great for the other. 

Breadcrumb with site map provider best for WSS: 
<asp:SiteMapPath SiteMapProvider=”SPContentMapProvider“ id=”ContentMap” SkipLinkText=”" NodeStyle-CssClass=”ms-sitemapdirectional” runat=”server”/>

Breadcrumb with site map provider best for MOSS (publishing sites):
<asp:SiteMapPath ID=”siteMapPath” Runat=”server” SiteMapProvider=”CurrentNavSiteMapProviderNoEncode“ RenderCurrentNodeAsLink=”false” CurrentNodeStyle-CssClass=”breadcrumbCurrent” NodeStyle-CssClass=”ms-sitemapdirectional”/>

The main issue with the WSS site map provider is it will show directories you don’t want it to (mainly the Pages library) in the breadcrumb, and on some pages it will show “.aspx” on the end of the page name. The MOSS site map provider is more graceful, it just doesn’t show the list or library name in the breadcrumb.

There is also a great collection of reference links at the bottom of the post as well.

A really great chart to determine the Pixels to Ems Conversion Table for CSS. Thank you Jon Tan.  A quick over-view/sampling below.

What this chart allows you to do is determine the em width of something. Say you have something that is 770px wide, and using a font-size of 1em. You know then that the em-width of the layout is: 1 ÷ 16 × 770 = 48.125em.

I’m working on a project that requires some vertical text.  But I was unsure as to the “correct” way for the vertical text to be set, 90 degrees clockwise or counter-clockwise.  Luckily, I didn’t have to do a lot of research, as it’s been done for me. Robust Vertical Text Layout outlines the basic rules for vertical text for me.

In a purely physical layout scheme, each of these text layout properties would be given as an absolute: The inline progression of this run of English is top to bottom, its glyph orientation is 90 degrees clockwise, its block progression is from right to left.

But absolutes don’t hold much water.

For scripts in a non-native orientation, the natural inline text flow depends on the direction of line stacking: the text is most comfortably laid out as if the whole text block were merely rotated from the horizontal. For example, English text in vertical lines that stack from left to right will face with the glyphs’ tops towards the left and the text direction running from bottom to top. The same text, by the same logic, would in a right-to-left line stacking context face right and flow within each line from top to bottom.

Basically it boils down to this from what I can determine: Have the bottom of the text point in the direction of the block progression.

Eric Meyers Reset CSS has found a permanent home now. Reset CSS is a useful tool to help you default a lot of generic styles built into browsers.

” The reset styles given here are intentionally very generic. There isn’t any default color or background set for the

body

element, for example. I don’t particularly recommend that you just use this in its unaltered state in your own projects. It should be tweaked, edited, extended, and otherwise tuned to match your specific reset baseline. Fill in your preferred colors for the page, links, and so on.”

Also be sure to check out his diagnositic css file as well.

“With a diagnostic stylesheet, you can quickly see where your markup might have some trouble. If you want to see this in action, there are two demos to check out:”

Incredibly useful tools, check them out.

Poolie Studios has a nice collection off icons that he uses to iconify links.  This process is a fairly lightweight, unobtrusive way to show what your links are.

a[href$=".pdf"] { BLAH BLAH } is the core of the it all.  This CSS selector object (easily done via jQuery for older browsers) allows you to showcase exactly what your links are.

I’m not 100% positive that this is always a good idea, but this is a nice collection of icons that fit the link sizes, and thus I’m linking it to you.

d’bug has a nice writeup on recreating the search field using CSS.

Normally I wouldn’t be a giant fan of changing the default input/form fields in a browser.  I think having those standards that everyone recognizes and know how to use is a powerful tool. Deviating too much from them is a risky proposition at times.   At least in my opinion it is.
But that being said, his end result is nice.  It seems to work.  And as a concept piece it’s cool. Go check it out.