Andrée Hansson has created 960 Gridder, a grid layout tool for web developers that you can either use as an integrated component to layout your websites or use it as a bookmarklet. The grid is fully customizable but it defaults to the “960px grid standard”.
960 Gridder will automatically identify if jQuery is present at the website and if it is not, it will include it.
It injects your website of choice and you can then work with this tool to help you out with whichever layout/design task you find it useful for.
By default, it is set to work with 12 columns, 60 pixel wide columns with a 10 pixel spacer left and right of the column, making it a 20 pixel wide gutter (which actually is the ones this gridder renders).
You can see and read about the “960 standard” at http://960.gs.
Sean Martell is my hero. He did the Bespin logos and a bunch of the Mozilla works in general. When Ben and I were in Toronto we got to see him at work at his WACOM tablet, and it is a sight to behold.
I wish I could do that kind of design work, but for me it isn't to be.... my design is left to code :/
Designing UI elements for a mobile browser has taught me a great deal when it comes to creating interactive graphical elements that are to be used in a very small space. Of course, when I say small space, I mean a small space that has the potential to be different for each handset out there. Not only are we talking resolution differences, but the screen DPI can change from device to device as well.
So after resizing and re-slicing the Fennec UI for the second time, I quickly realized that this could be a full-time job for a team of designers depending on the list of handsets Fennec will be appearing on.
Hold the phone… whats this? Firefox 3.5 enables a new slew of fun CSS3 design styles eh? Rounded edges eh? Embedded fonts eh?
What if we could replace almost all of the graphical UI elements within Fennec with CSS created equivalents? As a designer, am I comfortable bypassing Photoshop and letting CSS run the pixel rodeo? After a few initial tests, the answer to both of those questions was a very solid “yes”. A solid “friggin’ right” if in Cape Breton.
Francisco Tolmasky presented on the latest goodies from 280North at JSConf. In the past we've given the 280North guys a bad time for talking about 280Slides and their other stuff using... Keynote. I don't know if he used Keynote at JSConf, but Francisco published the slides using the 280Slides web-based presentation viewer, which is also embeddable:
(We like the embedded viewer, but did they have to make it swallow common keystrokes? On Firefox OS X, once we embed this IFrame, APPLE-W makes the slide turn white. 10 points for a cool feature, -100 points for hijacking the browser in this context.)
The slides make for a good review of Cappuccino but just include brief mentions of the other interesting bits, such as the new Aristo theme designed by SOFA and the amazing Atlas.
Fortunately, there is a recent video of a talk by Francisco on March 30 to the CocoaHeads user group:
A reader recently pointed us to Quince, an on-line directory of UX design patterns created by Infragistics. At first glance, Quince seems an Ajax application with some interesting animated effects, but it turns out to have been written using Silverlight (no surprise given Infragistics background).
Run-time platform notwithstanding, Quince contains around 100 patterns with large numbers of examples from desktop, web, and other platforms.
What other UX design pattern resources do you use?
Richard Rutter of Clearleft has a nice presentation up on facing up to fonts that goes into nice detail on the world of typography and the Web.
First he takes some time discussing fonts and various choices out there. Did you know about the various numbered font weights out there? From 100 to 900. Well, on Firefox 3 and WebKit. And there is font-stretch which no one supports. Then we have the EOT versus Open/TrueType wars:
There are a slew of HTML/CSS design sharing template sites out there. What if there was a manifest that defined what they had, and tools could work with that so you could import repositories.
We've been watching over the last little while as the Humanized crew has leveraged their experience with Enso to create Ubiquity, an in-development command-line interface for the browser. But what about folks who aren't as enamored with their keyboard as they are with their mouse?
Aza Raskin has recently published an interesting video showing how Ubiquity could work with just a mouse. It centers around this little nib which is barely visible when text is selected:
Hover over it, and it becomes more opaque:
Click on it, and a side-panel appears with the applicable Ubiquity commands:
I've seen more ways to create application prototypes than I can count, from PowerPoint (I'm look at you Chuck) to FileMaker Pro (and you, Bob) and everything in-between. Often, I see folks skip prototypes entirely and just using good ol' OmniGraffle / Illustrator / Photoshop / hand-drawn wireframes with sticky notes. Never have any of the mechanisms I've seen or used felt quite right.
A recent post on Boxes and Arrows, Prototyping with XHTML, got me thinking about this again. In the article Anders Ramsay and Leah Buley write towards a design audience to advocate what the title implies: using XHTML to create prototypes. (The comment thread goes on to provide links to severalprototypes and the discussion turns to Protonotes, which we covered sometime ago, and PolyPage for jQuery, which we have not yet covered.)
Is hand-coded semantic mark-up with applied styles really the state-of-the-art for prototyping? Shouldn't a primarily visual medium be used in the prototype stage? Or is semantic mark-up the way to go because it frees you to change the design of the same content quickly? How do you prototype your user interfaces? Or do you skip prototypes entirely?
Thanks to Nexus I saw a new project called typeface.js that offers a solution to typeface management (where you can use any typeface that you want, whether it be on the users system or not) without using Flash (which the popular, oft-mentioned sIFR uses):
Instead of creating images or using flash just to show your site's graphic text in the font you want, you can use typeface.js and write in plain HTML and CSS, just as if your visitors had the font installed locally. This is a work in progress, but functional enough at least to render the the graphic text on this site. Here's what it takes to get going: load the typeface.js library and some typeface.js fonts, then proceed like normal:
Looking at standard development phases, as a background.
Lo-fi using stickies (post-it notes) to capture design features. Then lo-fi UI sketches. For some sites, this is where we would stop, no need to go any further because it's obvious - can just go straight to detailed visual design.
Richard's showing some detailed wireframes. These are actual web pages. ratemyarea.com - the final site ended up very different from the wireframe, but that's fine. The wireframe contained all the basic content. Yes, CSS isn't magic and they did have to re-code HTML and CSS, but still, can retain some things like usage of microformats.
Looking at sites like Kayak and Google Analytics with a ton of Ajaxy complexity. Can't get a feel for this until you play around with it.
Patterns - design that can be reused: e.g. headers and footers.
Behaviours - e.g. progressive disclosure. e.g. including a lightbox in the wireframe because it's trivial for us to put it in there (using a standard library, without bothering to customise it at this stage), and it is significant to the interaction, so we can see if it feels right. e.g. on e-commerce site, adding to basket updates the basket field - doing this in the wireframe lets us see if users notice the update.
Views - Exploring/experimenting with views of particular interest. e.g. how a significant table or list might be ordered.
Notes - Embedding design notes inside the page, using CSS to toggle them on and off. e.g. simulate login/logout by stylesheet toggle (not real login). (a specific css class for "logged in" or "logged out"). See polypage library.
You can use a single CSS attribute to reference whichever is supported on the currently browser and gracefully degrade on browsers that don't support either technology:
What's the greater of these evils: contorting site designs around the standard Web-safe fonts, using images to render type, or relying on sIFR to render type with Flash?
Who knows, but man, it sure would be nice if we could reliably use any font we wanted in our web work. And, as it turns out, IE4+ and Safari 3.1 offer mechanisms for doing just that.
The linked font can be a regular old TrueType font. Compare this to IE6/7 which also support the @font-face at-rule but only support special "Embedded OpenType" fonts.
At first blush, you and I might think, "Yay for Safari! And, thanks IE for yet another screw." But that was before we considered the DRM issues. You see, there's an established technology for enforcing the use of fonts in embedded applications, and CSS's @font-face bypasses it by directly linking to TrueType fonts. At least one major font foundry is mighty uncomfortable with the thought of more browsers following Safari's lead.
Hence fontembedding.com, a newly-launched site promoting the virtues of the long-misunderstood and under-loved Embedded OpenType (EOT) format and the evils of linking to TrueType on the Web, complete with a call to action to other browsers to support EOT once the recent W3C EOT submission is ratified (i.e., maybe we can expect to use them cross-browser in 2014). EOT, you see, embeds the URL of the website that licensed the font for embedded use so that User-Agents can enforce font licensing restrictions.
Fascinating.
I wish them luck with EOT; in the meantime I suspect Firefox will implement @font-face and enough high-quality freely embeddable TrueType fonts will emerge to ensure that EOT remains as irrelevant as it ever was.
But then, I've been wrong before.
Still, fun to realize that as soon as Firefox implements @font-face, thanks to TrueType-EOT converters, we can finally use fonts on the web. Myspace will never be the same.
Jake Brumby of the European Ajax development shop Magic Toolbox recently pointed us to three of their creations: Magic Zoom, Magic Magnify, and Magic Thumb.
Each of these effects has a really nice implementation that works across a large number of browsers:
Jake shared some of their experiences building these effects with us:
Initially, our key challenge was making it work in all browsers. As usual, IE 6 and IE 5.5 gave the most headaches and we spent a long time finding workarounds. Getting the expand/contract effect to work smoothly in IE took quite a while. Getting the close/next/previous buttons to fade in and out in IE was also tough.
Another lesson is that when you are building a tool that will be used on many websites, you need to test under a lot more conditions than a script for a single website. One of our first customers used it on a site with Flash navigation. The Flash navigation continued to be visible after the image had expanded, which is not what you want. So we needed a way to keep the enlarged image above all the other content. No matter how much testing you do, there are likely to be small bugs after launch and you need to be able to react quickly to fix them.
To ensure the smallest possible script, they built it without using an existing JS library:
One other lesson was that for the best results, you need to code from scratch. We did an initial trial using MooTools and we achieved the effect we wanted but the source code was well over 100kb which we deemed too high. It was useful as a proof of concept, but the final version of the tool was coded entirely from scratch.
This is all well and good, but... are they worth paying for? Each of these three effects is sold separately. On the one hand, with such excellent open-source frameworks out there for doing Ajax effects, etc., having to buy these seems... weird. On the other hand, they are free for non-commercial sites and if you're an e-commerce site, if you apply these effects all across your site, they can have a big impact, and having someone else deal with all the cross-browser issues for you (or else you get your money back) seems like a good deal, along with the 30 minutes of free support they throw in.
I confess I have a soft spot for ISVs (Independent Software Vendors). I love to see small teams out there making quality software for a living, especially now that so many have to compete against free software. Do these products from Magic Toolbox compel you to consider purchase? Or do you feel the open-source stuff is good enough?
A final note from the Magic Toolbox team:
Magic Thumb provides a lot of customisation features that you don't get with other lighbox effects. It's also the only one we've come across that "grows" the image immediately in front of the user. It gives the user a greater feel of control and because it loads immediately it keeps them flowing through the website. That's good for usability.
I'm trying to masquerade as a hip and trendy designer-type today at IxDA's Interaction08 conference, but I fear my geeky ways will betray my role on the implementation side of the aisle. We know that many Ajaxian readers are designers or interested in creating well-designed products. Indeed, Ajax has been about empowering us to create websites that don't suck. I'll be blogging various Interaction08 sessions over at my personal blog, and for those sessions that seem to relate to Ajax development, I'll repost them here as well.
In particular, I thought Alan Cooper's keynote, An Insurgency of Quality, was extremely interesting. It's a verbose transcript; hope you don't mind.
===
Robert Reimann kicked off the first (full) day of Interaction08. He started with a charged introduction, telling us that this is the first-ever conference of the IxDA group and represented a major milestone in the emergence of "Interaction Design" as the pre-eminent discipline involved in the creation of digital products.
The energy level in the room is very high--it reminds me of the first Ajax Experience, though enthusiasm is higher here as the IxDA community has been around in various forms for so much longer.
Alan Cooper just took the stage. Alan co-authored "The Inmates are Running the Asylum" (a difficult word to spell, by the way) and has long been an authority in the space. I've read much of his work over the years.
Both Robert and now Alan talked about the self-identification of Interaction Designers (Alan: "We're not prototypers, testers, or eyeball-tracking wonks"); some of the rhetoric sounds like a social movement.
Alan's first point is that "Best-to-market trumps first-to-market", offering as examples:
- an ergonomic peeler versus a dinky metal peeler
- some clunky MP3 player versus the iPod
- AltaVista versus Google
Good design--innovative products--creates loyalty and enthusiasm in users that overcomes the advantages of first-movers.
If best-to-market is so important, why is "first-to-market" deemed so important by business people?
I don't think we ought to be emphasizing innovation; in our industry, it will happen. Innovation means invention, but in the minds of business people, I believe it has come to mean "success". But innovation doesn't mean success (holds up that original clunky MP3 player that failed--"this was innovative, but was never successful").
It's design that leads to success, not first-to-market. Business people accept the need for design, but don't understand its importance. Business people who rush to market and then innovative in subsequent versions--that's hellishly expensive.
The Seek Paradigm: Have the user ask for what they want.
The Show Paradigm: Display everything up front, and let the user explore and organize it.
"The first is usually more prevalent on the web. The latter usually more prevalent on desktop or deeper web applications. Theresa lists 10 different patterns illustrating Seek and Show."
She details both paradigm with very nice real world examples.
, Design
