I haven’t been as frequent on here as I was expecting, but hopefully that’ll change soon. :)

As winter approaches and there’ll soon be ice on the sidewalks again, I got to thinking about my dress shoes and their alarming lack of traction. I wear them every day to work, and last winter I remember the woeful struggle I made each day penguin-waddling home down the hill so I wouldn’t slip and fall on the ice. Loads of fun, let me tell you.

I wonder if there’s a good way to deal with this. De-icing the sidewalks is hard, so the most cost-effective way seems to be on the shoe end of things. Maybe some removable shoe-cleatish kind of wrapping that goes around one’s shoes, like chains on tires? It’d have to be easy to slip on and take off, lightweight (so you could take it with you), and preferably fold into a bag or something so it wouldn’t get your pocket/purse dirty when you’re inside. I’m envisioning some kind of plastic, perhaps, almost like bubble wrap but sturdier and with more traction. Or something. Anything, really, so long as I don’t have to wear huge boots to work. :)

Some thoughts that have been going through my mind lately…

In writing software, it seems like there are two distinct creative philosophies: planned vs. organic. With the first, you blueprint the whole project out in advance, thinking through everything as much as possible, sketching out the program with broad strokes first. You then go through the blueprint and implement it. The second philosophy takes a more laid-back approach, starting with the bare minimum and then letting the needs of the users define the design. It’s an iterative process, something more grown than engineered.

As is often the case in life, both of these methods have their place. For me, the general flow of a project should be organic (if possible), but the details should be planned. Let me explain.

When writing software, you often don’t know what’s best for the user. You have ideas, sure, but you don’t know for certain. Rather than bloat the software up with unnecessary features, it’s better to let the project’s requirements evolve as you proceed. Experience will dictate the course.

Down in the trenches, however, it helps a lot to have a plan. Not a long-term plan, mind you, but a right-here-and-now list of what needs to happen in the next hour or day. Yes, I can code without a plan, but my thinking gets murky and there’s only so much state you can hold in your mind before you start to lose things. Writing out a list of to-do items, along with pseudocode for whatever it is I’m working on, has proven invaluable.

My other lifesaver is freewriting. If I get stuck, I open up my work log in Google Docs and start writing about what I’m working on, raising questions that need to be answered, describing obstacles in my path, trying to map out the next few steps so I don’t stay bogged down. It’s worked almost every time. And when it doesn’t work, I know it’s time to take a break and do something else for a bit — read a book, draw, take a walk — anything to recharge the batteries.

Oh, and I’m going to try to be better about posting here more than once a month. :)

Jeff Croft writes about personal content management:

[A CMS] ought to make your content more useful simply by virtue of the content being in the system. But more often than not, it doesn’t. Most of time, you actually make your data (read: content) as dumb as possible by way of entering it into a CMS. Seriously.

He’s got a good point — with most content management systems, we flatten out the structure (or square-peg a round hole, as he puts it) and lose important information. Rolling your own is sounding better and better every day. I’ve been meaning to do that for Riverglen Press, and it wouldn’t be a bad idea to extend it to Blank Slate either (once I figure out what on earth I want Blank Slate to be — at the moment it’s just a neglected child, most of the time forgotten while its siblings bask in the spotlight, but ironically it gets more traffic than the others).

At any rate, I’m itching to make these sites more my own, and writing a custom CMS is a great way to do that. (I also really need to revamp the graphic design…) The main thing is to decide what I need this CMS to do. Most features I don’t really need, really, and my tastes have sharply turned to lightweight lately.

More to come later, once I have more time. :)

Seeing Jeff Han’s multi-touch demonstration over at TED (and I’d seen a similar demonstration before, on Jeff’s website) made me drool with goosebumpy excitement. (There’s a bunch of other cool stuff on his site, too, like the LED touch display and the Media Mirror.) Innovation is soooo cool. :)

So now it’s just a matter of time before these multi-touch devices go mainstream. Mmm…

Technorati Tags: multi-touch

Garrett Dimon’s got a good post today, on interface design:

For me, I’ve found that by writing a paragraph or some bullet points, I come up with ideas I wouldn’t have otherwise. It also helps to expose oversights and logic errors. This only takes me about 30 seconds per feature, but it dramatically increases the amount of quality thought I put into its implementation. Any more than 30 seconds or a minute, and it’s a waste of time. Once it’s implemented, chances are you’re going to need to make other changes.

From the comments, I found this 37signals paper, An Introduction to Using Patterns in Web Design:

The biggest challenge for web designers is the unthinkably huge number of possible ways to solve any given problem. We usually don’t think of this because we have our habits and traditions to fall back on, but there are literally billions of possible pixel combinations for each page we make.

There is a better way to manage this vast complexity than by making big decisions up front and hoping for the best. To make better sites — sites that are functional, beautiful, and “usable” — we have to break our design problems up into small independent chunks based on the real issues within our requirements. Christopher Alexander, who came up with this stuff, calls these chunks patterns.

And finally, Adobe Design Center has an interview with Jason Fried of 37signals on Getting Real:

Another thing I find interesting is that when big groups really want to get things done, they don’t make the group bigger, they make the group smaller. For example, when Lockheed wanted to design the Stealth [bomber], they didn’t scale up the team, they scaled the team down. When Congress really needs to consider something important, they form committees. When the military needs to conduct an operation with absolute precision, they usually call on the best small team they have. I think there’s a lot corporate America can learn from that.

For me, the main reminder I got was that you have to go to HTML (i.e., real stuff) as soon as possible, not getting caught up in mockups like I’ve done:

Yes, seeing and interacting with the real thing is the key. It’s not about seeing, it’s about using. You can see an Adobe® Photoshop® mockup of a site or application, but you can’t use a Photoshop mockup. That’s the point of Getting Real. To experience the real thing early and often. That’s the best way to improve the real thing. You can improve a Photoshop mockup all day long, but your customers don’t buy products or search or make a to-do list in a Photoshop mockup.

Granted, I’ve been doing HTML mockups as well, but I still think I’ve been spending way too much time on paper and in Photoshop. It’s about time to read Getting Real again…

Technorati Tags: Getting Real

A while ago I discovered the Yahoo! Design Pattern Library, but I didn’t really look into it (it was one of those put-on-the-shelf-for-future-reference things). Then I found Functioning Form, which is interviewing various interface designers right now. From there I checked the Yahoo library out again, and also found Jenifer Tidwell’s Designing Interfaces book and Martin van Welie’s UI Patterns and Techniques. This is really cool stuff — enough so that I’m going to read through it all as soon as I can, because I can already tell that it’s going to be extremely useful in designing Beyond. (For example, the collapse transition is a good way to keep information accessible but not in the way.) I’m excited. And schoolwork suffers another blow. :)

On a side note, I can’t wait till my library gets a copy of Edward Tufte’s new book, Beautiful Evidence. You can read the chapter on sparklines on his webboard.

Technorati Tags: design patterns, Edward Tufte