Carpool Conversations - Trip #1

Background Information

This is the first dispatch from Carpool Conversations. I live in San Francisco, but work in Sunnyvale about 43 miles south, in the heart of Silicon Valley. The long drive sucks, but the great thing about it is that it's an protected time to think, to reflect, to brainstorm, and to explore. There are no distractions in the car; no Internet connection and nobody popping into my cube.

I often carpool with my friend Jon Koshi, and we have great conversations about the web, design, interface, the future, and the present. We both tend to bring complimentary sides of the same topics to the conversation. We both like to think big, and, if I do say so myself, we're more aware than average of current events, practices, trends, and developments. Jon is a visual designer by practice and I'm a technologist by practice, so we've got both sides covered in that regard too. (We talk politics and currents and news and life too, but this series will largely focus on technology and human beings.)

Koshi and I both believe in words and word smithing. We believe that examining and designing frameworks for ideas to operate within creates stronger ideas while helping to vet the root concepts. We like to discuss nuance and subtle distinctions, and in the process gain a deeper understanding.

I'm writing this from the road right now. I'd like to resist editing too much, and instead share the thoughts as they appear in the carpool. Hopefully this will be on interest to some of my good readers.

And with that, I can't resist saying, "start your engines!".

Posted by Nate Koechley on March 17, 2005 at 07:52 PM in Idea, Location: San Francisco, My life..., Visual Design, Web Development, Yahoo! | Permalink | Comments (1) | TrackBack


Semantic Markup - Create, Support and Extract

Semantic Data Extractor

As Kevin Ryan pointed out at work yesterday, the W3's Semantic Data Extractor is a pretty sweet tool. I've been steadily promoting Layered Semantic Markup at work -- the importance of meaningful markup as the core of web development. This is a great tool to show that value, and remind that the reason you put meaning in is to get meaning out.

The tool tries to extract information from a semantically-rich HTML document. It only uses information available through the good usage of the semantics provided by HTML. “The aim is to show that providing semantically rich HTML gives much more value to your code: using semantically rich HTML allows a better use of CSS, and makes your HTML intelligible to a wider range of user agents (especially search engines bots).”

To see it in action, check out the new next.yahoo.com page. The Extractor handles it pretty well, showing a clear document hierarchy.

What is Layered Semantic Markup?

Today’s Wrong Solution is Tomorrow’s Constraint

Layered Semantic Markup (LSM) is not a technology, but a framework comprised of HTML, XHTML, Cascading Style Sheets (CSS), Javascript, DOM and other Web technologies. LSM allows for appropriately implemented principles and standards.

LSM is a development framework for creating Web documents and experiences. LSM builds for the least capable devices first, then enhances those documents with separate logic for presentation, in ways that do not place an undue burden on baseline devices but which allow a richer experience for those users with modern graphical browser software. LSM supports all user agents, and is inclusive by design. (Progressive Enhancement - Unobtrusive Javascript)

LSM has structural semantic markup at its core, which provides lean, meaningful, accessible pages. This well-built core and the clear separation of structural, presentational and behavioral layers make this development philosophy superior to many short-sighted approaches.

Today’s wrong solution is tomorrow’s constraint. A holistic vision - an underlying philosophy - must guide technical decisions. LSM provides the strategy for a sound and future-ready approach.

LSM embraces Graded Browser Support by using one markup document, subsequently layered with stylesheets and scripts that provide a gradually enhanced experience across a wide variety of browsers and devices.

This approach has profound advantages over other browser support approaches such as graceful degradation. Graded Browser Support recognizes that advanced technology support is not a guarantee of the future, and that legacy software as well as alternative devices (mobile) must always be considered. Graded Browser Support defines support in terms of current capabilities, not in terms of legacy or obsolete software; it embraces accessibility, universality, and peaceful coexistence with more feature-rich browsers/devices; and it allows for adoption of new technology and strategies without leaving any browser/device behind.


This work is heavily influenced and contains directly passages from Debra Chamra's "Progressive Enhancement: Paving the Way for Future Web Design", Steven Champeon and Nick Finck's presentation "Inclusive Web Design For the Future with Progressive Enhancement", and Steven Champeon's "Progressive Enhancement and the Future of Web Design", all of which may be found here.

Thanks also to the great people who have endlessly debated and developed these topics with me: James Berry, Sean Imler, Todd Kloots, Jon Koshi, Mike Lee, Thomas Sha, Matt Sweeney, Chanel Wheeler, and Christina Wodtke; and everybody else; and to everybody who puts their ideas online so that others may be inspired. Thanks.

Posted by Nate Koechley on February 9, 2005 at 03:22 PM in Accessibility, Internationalization, CSS Media Types, Browsers, Design, Engineering, Idea, Information Architecture, Interaction Design, Layered Semantic Markup, References, Search, Search Engines, Search Engine Optimization (SEO), Software and Tools, Visual Design, Web Development | Permalink | Comments (7) | TrackBack



For all the news junkies out there, and for those of you interested in visualizations, check out newsmap if you haven't seen it before.

  • Notice the legend in the lower right corner. Color = age.
  • The size of the area represents the number of sources.
  • Layout controls are in the lower right corner too. I think I prefer "standard" over "square".
  • You can select countries across the top. Each country will get a proportional section of the page. Turn on US, NZ and Canada, and notice how different stories are variously prominent.
  • Archive controls are in the lower left. You can examine news from earlier in the day, or earlier in the week.

Posted by Nate Koechley on January 11, 2005 at 02:41 AM in Design, Information Architecture, Interaction Design, News, Social Networking and Community, Visual Design | Permalink | Comments (1) | TrackBack


Today's Quote

I was catching up on reading Jeremy Keith's Adactio blog. The entry is primarily about the beautiful "typeface that London Transport use on all the tube stations and bus stops in London". Frank Pick commissioned the typeface in 1916, the work of Edward Johnston. Jeremy says "Frank Pick's philosophy is clear from this quote:"

The test of the goodness of a thing is its fitness for use. If it fails on this first test, no amount of ornamentation or finish will make it better; it will only become more expensive and more foolish.

I enjoy quotes in general, and I like this one in particular.

Posted by Nate Koechley on January 4, 2005 at 05:13 PM in Design, Visual Design | Permalink | Comments (0) | TrackBack

Wikis, RSS and Wikipedia history visualization by the Media Lab

Jeremy Zawodny writes Why do Wiki RSS Feeds Suck?. I'm a big fan of Wikis. Jeremy writes that he's not. His two reasons are 1) he "find[s] the markup annoying"; 2) Change notification, especially when offered by RSS, "all suck".

The first is quickly disposed of: Wikis generally allow HTML or XHTML markup in addition to their own markup. If you don't like Wiki markup, don't use it. (The system is converting it to XHTML anyways, so you can view-source grab it.) Wiki markup is there for people who prefer it.

His second issue is that Wiki change notification (RSS or other) is often nearly useless. I generally agree: either it's too technical, or it's too vague. Too specific, or too broad. My work Wiki, for example, only allows you to subscribe to changes in general -- the entire Wiki -- not to a particular page.

While the notification could be better, perhaps the information is of a type not suited to per-instance notification. RSS is a natural medium for "change notifications", but not necessarily for "change visualization". The MIT Media Lab's Fernanda B. Viégas, in collaboration with IMB's Martin Wattenberg, have done some beautiful, insightful and important work visualizing dynamic, evolving documents and the interactions of multiple collaborating authors. That have mainly focused on the interactions on Wikipedia, which are massive, controversial at times, and exceedingly active. Check out their gallery, it's pretty sweet. It's amazing that in some cases, 20-word sentences have each word contributed by a different author. Also, that files that have been exited tens of thousands of times will still retain unchanged content from initial authors. (I saw them present this work at CHI2004 in Vienna.)

Posted by Nate Koechley on January 4, 2005 at 08:29 AM in Blogging, RSS, Knowledge & Content Management, Social Networking and Community, Software and Tools, Visual Design | Permalink | Comments (0) | TrackBack


Digital Web Magazine: a Fast Company's 2005 Fast 50 Nominee

If you don't read Digital Web Magazine, you should. If you do, you should leave a testimonial over at the Fast Company's 2005 Fast 50 - their 4th annual - where Nick Finch, DWM's publisher and driving force is nominated this year.

Posted by Nate Koechley on December 8, 2004 at 03:01 PM in Blogging, RSS, Design, Information Architecture, Interaction Design, Visual Design, Web Development | Permalink | Comments (0) | TrackBack


New Hillman Curtis documentary video

My friend Hillman points us to his latest documentary, of designer Paula Scher for AdobeStudio. You can find it in the Showcase at AdobeStudio.

If you missed the first one - on Stefan Sagmeister - it archived on Hillman's site.

I like seeing video online. Our culture is largely video based, yet it hasn't really blossomed online yet. As long as Hillman has a camera, I know we're in good hands. Keep watching.

Posted by Nate Koechley on November 1, 2004 at 02:35 PM in Design, Visual Design | Permalink | Comments (0) | TrackBack


Paper vs. Pixels - Part 3

It's fun being a Web Developer because we're right in the thick of it all. I once defined a Web Developer as the team member with the most software. Webdev's are in the middle of a triangle between (1) Project Management/Business, (2) Design and (3) Engineering. Therefore, we use all their software, and often act as liaison between the groups. I often use:

  • Photoshop and Illustrator, tools of the Visual Designers trade
  • InDesign and Viseo, tools of the Interaction Designers trade
  • MS Project, Excel, PowerPoint - tools of the Project Manager
  • Apache, PHP, MySQL, vi, SecureCRT - tools of the Engineer
  • Homesite, about 30 browsers, validators, and various small tools like sruler, Iconico...

Anyways, one of the more common questions a Webdev gets asked relates to the different between designing and building for The Web versus the controlled and familiar world of Print.

I've been reading Web Page Design for Designers for years now, and in this months issue Joe talks about just that in part 3 of Paper vs. Pixels. It's worth a read, as he covers key points including:

Apart from providing an index or glossary, navigation is not usually an issue in print. ...
Unless you produce comics that require special 3D glasses, print never requires on the reader having a 'plug-in'.

Once the artwork has left your studio, duly checked for correctness and signed-off, what you get depends on the printer. There are lots of variables but you will have certain expectations and decent printers will do their best to meet them. If they don't, you will have good cause to complain and if they don't satisfy you, stand a good chance of losing future business.

The equivalent of a printer on the Web is the browser, the piece of software that interprets your instructions and displays it as a page on a computer screen. Just in the same way that you wouldn't expect different printers to produce identical results from the same artwork, browsers won't either. Sadly, there will probably be a much greater divergence in browser results than you would expect from printers.

This installment, the third, covers Navigation, Plug-ins, Browsers, and Multimedia. For the full story, be sure to read the earlier Part 1 (The ever-changing screen, Statistics, and Judging a design on your own screen) and Part 2 (Font sizes, Colours change, and Resolution).

Posted by Nate Koechley on October 1, 2004 at 04:36 PM in Browsers, Design, HOWTO's and Tutorials, Visual Design, Web Development | Permalink | Comments (0) | TrackBack


Introducing sIFR

Mike Davidson, in conjunction with Shaun Inman and Tomas Jogin has released "a scalable, multi line, Flash 6 compatible version of IFR to help you reduce the amount of browser text in your life and free the world from the scourge of Arial."

This system uses JS, DOM and Flash to provide scalable, typographically-rich headlines and font treatments through dynamic replacement of H1, H2 and DIV tags.

Seems interesting.

I'm historically pretty anti Flash. I believe in HyperText and meaningful, semantic markup. I believe in access to information to all. I believe that pure text is faster, better, and more "Web". Just being up front about it. (On the other hand, I also believe in Progressive Enhancement, which is consistent with this approach.)

So I'm not yet sure what I think about this technique.

I know I'm more fixated on edge cases than many people, and that my work necessitates a never-wavering focus on speed, performance and efficiency, and that I have strong feelings about the benefits of "built-in" usability. But...

One reason I generally don't like text as images is because you can't select or copy-paste the content when it's locked in an image. Organizations that have their address locked in an image prevent me from Yahoo-mapping their address and therefore lose my business.

My first test was to select the text of this flash headline. Happily, I was successful (though it's pretty clunky, and much more difficult than normal HTML text).

One of Flash's historic downsides is that .swf text is more or less unknown to the browser. They seem to have fixed this for mouse-based text selection, but using the keyboard doesn't seem to work. Modern browsers have started introducing "Find As You Type" functionality, which lets you navigate (and select) the text of a page from your keyboard. This isn't compatible with sIFR in my testing. Further, the standard "Control-F" on-page search isn't aware of sIFR text. I, and many people, use Control-Find often. That IFR is for headlines instead of body content is some consolation, but... I'll lump those together as one strike.

I wonder how well .swf text is indexed by search engines? I don't have an easy way to test this, but because I can't select the .swf text via the keyboard, and because test uses of Control-F "find" failed, I'm skeptical.

Interesting technique. Definitely one to keep an eye on.


Posted by Nate Koechley on September 10, 2004 at 04:40 PM in Accessibility, Internationalization, CSS Media Types, HOWTO's and Tutorials, Layered Semantic Markup, Search, Search Engines, Search Engine Optimization (SEO), Visual Design, Web Development | Permalink | Comments (2) | TrackBack


Exceptional Eyetracking and Analysis

Wow!: Eyetrack III


The Poynter Institute, a school for journalists, has just released the results of a comprehensive and fabulously documented eye tracking study. Very interesting information.

They analyzed their data internally, and with external analysis by Jared, Jakob, Rusty, Adrian Holovaty and Alan Jacobson.

They've made a lovely self-contained site with all the goodies which you can also download in it's entirety in PDF.

There are many interesting findings, which did you find most enlightening?

Posted by Nate Koechley on September 9, 2004 at 03:04 AM in Design, HOWTO's and Tutorials, Information Architecture, Interaction Design, News, Other, References, Software and Tools, Visual Design | Permalink | Comments (2) | TrackBack