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.
I remember sitting in a Microsoft presentation that first showed off Expression Web, and the promise of finally moving past the current way of working with designers:
Designer: "Here mate, enjoy this jpg"
Developer: "Ok, I cut it up and made it into a web page, but now I need to tweak this area, can you send me a new one?"
Designer: "Here mate, enjoy this jpg"
... repeat ...
Now it is Adobe's turn to have a swipe at the problem, and they have released Adobe Thermo to help you design RIAs and really use artifacts.
I don't think anyone refutes the wisdom of this suggestion, but many folks responded to Aza's article with the complaint that the implementation of undo is too hard to be generally feasible. Aza has now come back with his thoughts on a simple client-side implementation of undo for Ajax (part 1).
I admit I personally cut corners all the time in this matter, violating my own beliefs and issuing warnings. :-) Has anyone in the community had experience implementing a robust undo?
John Allsopp has developed XRAY, a bookmarklet that launches a tool to visualize the web page that you are on (a little like features in Firebug and Firefox). The look and feel is great, and the margin popups look like the new Safari/Webkit search functionality (mmm orange).
What is XRAY
XRAY is the first in hopefully a suite of free cross browser tools for helping web designers and developers better visualize what their code is doing in a browser. XRAY is designed to help you get beneath the skin of your web page.
XRAY let's you see the box model for any element on a page in action - where is the top and left of an element, how big is each margin, how big is the padding, how wide and high is the content box?
What platforms and browsers is XRAY available on?
XRAY currently has been tested on Safari 2 and 3 on Mac OS X, Webkit nightly builds, and Mozilla based browsers (Firefox, Camino and so on) on Mac OS X and Windows. At present it won't work on Internet Explorer (XRAY uses the canvas element, but plans are afoot to adapt it for Internet Explorer), and has not been adapted for Opera. We hope to have versions for Opera shortly, and Internet Explorer on Windows in the not too distant future. XRAY works in Safari 3 on Windows, but clicking a bookmark does not fire any Javascript it contains. To use XRAY on Safari 3 for windows at present, you'll need to paste the XRAY link into the address field and hit return.
