Tag Archives: Design

Tom’s Law: 445, where you are doesn’t matter

It just struck me… looking at site navigation and breadcrumbs how obsessed designers are in telling you where you are, when in actual fact, you can tell where you are from where you’ve been and where you can go next, the where you are now becomes obvious and irrelevant.

Where you are now really
doesn’t matter because either
a. You have found what you want (and here-ness just falls away)
b. You haven’t found what you want and where you are is the least interesting thing in the world

GPS on MacOS X (or Why Blogs are Rubbish)

http://gpsonmacosx.blogspot.com/

I’ve started a blog about GPS on MacOS X, not to teach or share expertise or show off or anything. This blog is to share my confusion and ignorance.

There are a few blogs out there about mapping but I realized that blogs are very bad at taking a novice on a learning journey.

I literally have no clue about mapping but like lots of people I’m drawn to maps, I’ve always loved them. And I love notions like grassroots mapping, taking control as a people of useful data (like maps).

But blogs throw you in at the deep end, mid conversation really… listing them chronologically wouldn’t really help either because there’d be so much guff and fluff. To be a useful guide a blog would need a lot of editing… I guess they call well edited blogs “books” don’t they? Or they would need for you and a cohort of bloggers to start with similar interests and goals in mind and to share questions and things you find out with each other.

I hope my blog serves to share (at least one) customers confusion. The world of GPS/GIS seems geeky in the extreme and yet it holds treasures of interest to everyone. Ever met anyone (nice) who didn’t like maps? Maybe by sharing my ignorance some people will help me by commenting. Maybe someone will make a Skiddoo thing to “Get Me Started”… maybe the people who make the tools will read it and have insights on how better to communicate the concepts and functionality in software.

Maybe it’ll be be another blog nobody reads… you never know do you?

Liquid vs Fixed Layouts

When choosing blog tools to use, one of the main factors I end up taking into account is what they look like. It’s silly really because what a blog looks like is up to me really. Except that it’s not. Having used and liked both Drupal (lots of community-oriented features) and WordPress (easy to hack) I started to like WordPress for the extremely shallow reason that it looks nicer.

A worring aspect of why a WordPress blog generally looks nicer is that, in general, WordPress templates tend to be fixed width. Now, normally I think I prefer liquid layouts because they put the user in charge. And usually a liquid layout means the bigger the window, the more data you get. Liquid seems better for all sorts of usability reasons.

But fixed width, somehow, seems to look nicer. Is it that fixed means that you end up with control over idea line lengths, a huge usability issue with regards to readability? Is it that fixed-width designs, by being easier to build and control get more “design time” spent on them?

I used to be so pro-liquid now I’m not so sure.

Interface, at times, is everything..

This is one slick video. Prepare to be amazed with the Crazy Multi-Input Touch Screen, which shows how a novel interface hooked to very smart software and of course big computer behind the scenes can dramatically alter how you think about everything.

Now, I’d like them to get Doug Englebart to play with one of these and do a demo that really blows me away, like the ones he did a million years ago.

The interaction designer’s nail gun (2nd edition)

Seeing Visio being used well, here…, sometimes make me wish I had a PC. Omnigraffle is great but lacks a few features (that maybe version 3 has… should I upgrade? … probably).

Omnigraffle, with scripting, is inches away from being “the holy grail of prototyping” in that you could very quickly build a system that worked well enought to be able to test it, but not so well that you would consider delivering code built in it, which was often the downfall of Hypercard. When used for prototyping at least, Hypercard was too often, too good for the job, meaning rather than throwing code away, you kept on building on it….