Here's a nice article on form design. This is something that is often hard to do really well, yet can have a big payoff if it is done right.
John Rhodes has an interesting take on usability spending in a new B&A article:
Investing in Usability: Testing versus Training. To quote:
It might shock people to hear this from me, but when I am acting as a project manager, I’d rather have a great designer on my side than a usability specialist. Given limited time and money, I need someone who can get the job done right. Designers and developers produce tangible results, and the great ones produce incredible work. For most projects, I don’t need a usability professional if I have a great designer. Furthermore, most usability professionals can’t design or develop their way out of a wet paper bag. They are often limited because they can only do research and testing, which doesn’t mean anything until it is applied to a design. So, usability specialists are usually limited in two ways: they want to test everything and most of them can’t design worth a damn.
I'm always on the lookout for new quality tools. Here's one that is probably worth keeping an eye on:
widgEditor. It is a lightweight WYSIWYG editor built in javascript/CSS.
Here's a lovely little post from Colin MacDonald that should be required reading for anyone in management:
It's like you're asking them to hang a picture for you, but they've never done it before. You understand what you need done - the trick is getting them to do it. In fact, it's so obvious to you that there are constraints and expectations that you don't even think to explain. So you've got some junior guy working for you, and you say, "Go hang this picture over there. Let me know when you're done." It's obvious, right? How could he screw that up? Truth is, there are a whole lot of things he doesn't know that he'll need to learn before he can hang that picture. There are also a surprising number of things that you can overlook.
Update: Thanks to Beth Rhinelander for letting me know I had mis-attributed the above post to a different author. The correct author, as stated above, is Colin MacDonald.
I identified with this comment from CD Baby's Derek Sivers on learning a new programming language (Ruby):
It took a lot to get me to switch from PHP, the only language I really know, to Ruby. I tell my non-computer friends, "It's like the week before sitting down to write a book, I decided to write it in Portuguese instead of English, because it'll be easier." It sounds crazy, but we'll see.
I've been playing in Ruby for a few weeks now. I'm coming at it from a bit broader perspective than Derek, I think, in that I know a few more languages (PHP, Python, ColdFusion, to name the ones I've spent the most time in). But, making the transition is rather painful. You spend a lot of time looking up syntax stuff, which can be frustrating. The good news is that I"m working within a powerful framework (Rails). Makes things much less painful.
Continuing on the simplicity theme:
From the Good Experience Blog, 'Interview: Barry Schwartz, author, "The Paradox of Choice"'
Q - How then should a store be designed?There's no general answer except "restrict options" - though in what way depends on what you're selling.
For example, e-commerce sites should be designed so that the complexity is hidden, so that people who really care, or know a lot, can find their way to the complexity, and the rest of us who can't be bothered to find it, won't have to. That's how software, websites, and retail stores should be designed.
I've been thinking about simplicity a lot lately.
Maybe it's because I'm mentally getting ready for the Building Basecamp workshop next week. Two of the bullet points in their agenda are:
They clearly practice what they preach. Look no further than the recently launched Ta-Da Lists. The site features just about the easiest to use UI this side of pen and paper.
Or, I could be thinking about simplicity because of Phillip J. Eby's post entitled "The Courage to do things Simply." Phillip tells the story of a former boss who pushed his team to look for simplicity.
Maybe my mind is on simplicity because of Phil Windley's mention of a project that is anything but simple: FBI's Virtual Case File May Be Unusable.
I've been feeling that many of things I've been working on tend toward the FBI rather than Ta-Da. Not because we're spending $170 Million on a failure (we're not spending that much, nor will we fail). But because often real life is messy, and trying to bring technology into it—either as a tool or to model it—is hard work. But Ta-Da and Eby remind me that I need to keep striving for simplicity among the complexity.
I've never been a huge fan of portals. Well, actually, one of the reasons I've been down on them was the lack of a clear definition--like so many biz-words, it seems to mean many different things to different people. I've pushed my coworkers on the issue enough that most can't say "portal" without throwing me a scared/amused glance.
Anyway, with that background out of the way, do go read Janus Boye's take on the world of Portals (meaning large software systems sold to create "Portals"): " Portal Software: Passing Fad or Real Value?"
I like this distinction he made:
Maybe you should start by creating a small-p portal deploying a simple website on top of any existing Intranet sites, and invest in big-P portal software only after you have put in place successful processes for publishing and aggregating high-value, highly-sought information. You may find you don't need portal software at all.
It seems to me that in the past year or two, the smart folks thinking the content management space have moved past CM-as-software and are doing CM-as-concept or process. In other words, paying attention to creating the right content for the right audience (and removing it when it's stale) rather than focusing on implementing a big, hairy bundle of software. I think people working in the "portal" space will probably end up there soon enough, too.
As I mentioned in a previous post, I ended up setting up an account at TextDrive to play with Ruby on Rails. The setup wasn't as smooth as I hoped (some .htaccess and conceptual issues to work through), but I eventually got everything set up.
I highly recommend Rails newbies go through the Making a todo list tutorial. Very well done introduction to what looks like a very cool framework.
No, this isn't a post about Napoleon Dynamite (that's not going to make any sense unless you've seen it...).
Rather, I'd like to point to a very interesting article by Walter Parker: Teaching Against Idiocy. To quote:
IDIOCY IS the scourge of our time and place. Idiocy was a problem for the ancient Greeks, too, for they coined the term. "Idiocy" in its original sense is not what it means to us today -- stupid or mentally deficient. The recent meaning is deservedly and entirely out of usage by educators, but the original meaning needs to be revived as a conceptual tool for clarifying a pivotal social problem and for understanding the central goal of education.
A must read for anyone interested in democracy and/or education.
Library geeks and information architects (often one in the same) will enjoy this short Technology Review article on tabs:
How many college students today ever flip through trays of library catalogue cards? Some of them may never have used an actual tabbed file. But the tab as an information technology metaphor is everywhere in use. And whether our tabs are cardboard extensions or digital projections, they all date to an invention little more than a hundred years old. The original tab signaled an information storage revolution and helped enable everything from management consulting to electronic data processing.
So I've been hearing about this nifty thing called Rails. A couple of very cool web apps--Basecamp and 43Things--were built on Rails. Rails, for those who haven't heard of it, is a web application framework for the Ruby programming language.
I've been messing around with a little project--written just for my own enjoyment so far. The app is in python, but I'm realizing that it won't scale in its current incarnation, and I made some architectural mistakes that it'd be a pain to back out of. So, I'm looking longingly at this Rails thing. I think to myself, why not port my little app to Ruby and Rails? It'd be fun! I'd get to play with a language I haven't had a chance to use, and perhaps create something that might have some actual use.
So, I set out to set up a development environment on my very humble old Windows XP box (the Apple mini is looking better and better all the time). How hard should this be? After spending a few hours over a few days, I'm pretty well frustrated. Installing Ruby was a snap. Installing Rails was easy. I already had MySQL on my machine, but I zapped the old version and downloaded the latest and greatest. Apache has been running on this machine for years. But when it came time to put it all together and make it run, things fell apart. I spent way to much time figuring out if I needed an extra library to connect Ruby and MySQL (I'm still not sure if this comes with Rails or not). The one I did find wouldn't install. So, I figured I'd check out SQLite and it's Ruby Interface. SQLite works, but I couldn't figure out how to get Ruby to see it. Bah! Next I figure I'll just forge ahead with the Rails setup, just to see if that part works. But, I hit a snag there because there is a space in my pathname when doing the install.
Now, I'm sure there is a perfectly decent solution to every one of my glitches. But, I've done my due dilegence on this one. I've docs on a number of sites. Google searches. Mailing list archives. Still looking.
But, I'm a reasonably smart guy. More computer savvy than 99% of the population (okay, that really isn't saying much). I'll admit that there are plenty of areas that I'm not that strong in. I came from a web development background, not the usual C/C++ or even Java route. I do feel more comfortable in a unix shell than the Windows command line. I'm not a system administrator, nor do I want to be one. But c'mon, it really shouldn't be this hard!!
So, I have a couple of options.
a) Give up. My time is, quite frankly, too valuable to spend fighting with computers when I'm not being paid for it. This isn't productive work, I'm not enjoying it. I want to program, not screw with balky installers.
b) Pay for an already set up environment on TextDrive. This is probably a good option, but jeez, I just want to kick the tires on this Rails thing, and I was hoping not to have to pay to do it...
c) Keep fighting. Yet, see time comment in a).
Well, it's late, and my head is fuzzy (no doubt the source of some issues). So I'll put this one to bed.
Update: I went with b). Haven't had a chance to play with it yet. Hopefully, I'll be able to change my Ruby Rant to a Ruby Rave soon...
Fans of Edward Tufte need to check out Sparkline.org, a PHP Graphing Library used to create small charts that can be included inline with text. For more on the concept, see Tufte's chapter on the subject, as well as a discussion of creating sparklines.