I’ve finally figured out the difference between Twitter and Facebook. Groucho Marx famously said,

I don’t care to belong to a club that accepts people like me as members.

And therein lies my problem with Facebook. I do not care to hear about the minutiae of life from any of the people that would care to hear about mine. The requirement of mutual friendship makes Facebook less interesting, at least to me.

Twitter on the other hand lets me listen in on the people who seem interesting to me, even if I’m uninteresting to them. It lets me crash the good clubs, even if they wouldn’t accept people like me as members.

A number of people have replied to my post about with suggestions like:

“Just pick one.”
“Go with your gut.”
“Choose whatever seems simplest.”
“Ask a User Experience expert.”

Those are all great suggestions. OK, maybe the last one’s a dud, I mean anyone who goes by that title probably isn’t, but anyway…

I don’t think these are acceptable solutions in this case. This is a different class of problem. I had a good sleep on it, and now I think it comes down to one important fact: Something trumps the right way.

What does that mean? Well, let me give you a concrete example. Let’s look at the user interface for browser bookmarks. In Safari, arguably one of the least feature laden browsers around, there is:

• a top sites display that 6–24 bookmark-like-things.
• a bookmark bar that can show about 15 shorter length bookmarks.
• a bookmark menu that shows a lot (there’s probably a limit, a high one).
• a bookmark window that shows a practically unlimited number of bookmarks.
• methods to add hierarchy to most of the above

Some might say that the developers just couldn’t decide which presentation method was the right one. Or that they didn’t have the stones to actually eliminate the other options. I don’t think so.

When it comes to bookmarks, personal browsing style governs which user interface is most useful. Choosing one method might be right for one group of people, but would be wrong for all of the others. Put another way: Simplification of the user interface would hurt most of the users.

Bookmarks defy simplification because a browser is a very general purpose tool. This means that there are many varied use cases. A single bookmark interface doesn’t cover them all — or at least a single interface has not yet been found that does.

Widely varying use cases is a good example, but it’s just one of many reasons why right is sometimes not good enough. Idioms, or the well established use cases, come to mind. Even tasks that seem simple can’t always be simplified if there are groups of users that are very accustomed to their way of doing things.

A good example is the email reply: Some may find that the right way is to always reply on top, or perhaps always on the bottom, or perhaps you like inline replies. My guess is that most experienced users have a preference and that none of the three methods could be eliminated without alienating a large number of users. Company standards, well worn habits, cultural expectations all play a role. All these things have the power to trump the right way, if such a way even exists.
Sometimes a revolutionary interface can break the idiom deadlock. But short of think different, there may be no solution other than a user preference.

I think some of these problems do have right answers, perhaps just waiting to be found, but sometimes I just like my way of doing it wrong.

There’s this little feature in my new app. I can’t tell you about it, of course, because it’s in an app that’s not yet public, but ignore that for the moment. Work with me, here, people!

The problem.
I can’t quite decide how it should work. It’s not a rocket-science sort of feature, it’s just a user experience type of thing. I’ve tested out a number of ways to get the job done. Some implementations are good, some are bad, and plenty are good enough for me.

But which one is perfect? That’s the problem.

The other guys.
I’ve surveyed the landscape of the competition, too. That’s when I found out how many ways there were to build this widget. The other apps aren’t just different, they’re uniform only in their dissimilarity. I’m convinced they couldn’t possibly be any more different than they are.

Maybe I should ask some users?
According to blog post after blog post, users “don’t know what they want.” That’s always struck me as a pinch of sage wisdom on a pile of cynicism, but it doesn’t really matter. I can’t ask the wider public because it’s still [redacted]. Polling the masses is out.

Phone a friend?
I talked things over with a few techy friends. What I found is that each friend is not only passionate about the way this feature should work, but each is sure that this is the feature that must work their way. Each wants it to work completely differently, too — but you guessed that, right?

Platonic, look it up.
I’m convinced that there are some apps or at least some features that don’t have a single perfect solution. It’s not that the perfect platonic solid for this feature doesn’t exist, it’s that there are many perfect solutions, each one perfect for a certain group of people.

I guess this is why user preferences exist even in great software.

I recently read an article by John Welch, about Gus Mueller’s Acorn and JSTalk. I don’t normally read Welch’s blog, I don’t really like it. It’s not that I mind his profanity, and there’s a lot there to dislike, it’s just the forcefully flamboyant writing style. I like plain: plain clothes, plain people, and plain writing. John Welch is not plain, and I don’t have time for that.

But I read the article and it just seemed to miss the point entirely. I wanted to write a comment, but I knew that would mean a flamboyant response. I don’t have time for that either. So I’m writing this instead.

OK, let’s back up. Let me fill you in on the subject of the article. Here’s the quick summary:

1. Gus wrote Acorn.
2. Lots of people wanted to script it.
3. Gus releases Acorn 2 with JSTalk, a Javascript scripting engine.
4. It’s awesome.
5. John writes a blog post which says Gus should have used AppleScript.
6. John shouts some more stuff.
7. John says that if Acorn had Applescript, it would also have a bunch of other languages for free.
8. John shouts some more stuff.

Now you’re caught up. If you like flamboyant writing, you can go read all about it, too.

I don’t really know the details of Gus’s real decision, just what he’s written. I do like Gus’s blog, though. In fact, I definitely think a few of those posts helped me to bust my ass, save my dollars, and go indy myself. Thanks Gus. But back to what Gus wrote about the decision: Namely, that AppleScript was a hard, so he wrote JSTalk instead. He also points out in Welch’s blog comments that he was not talking about AppleScript itself being hard, but about it being hard to add to your app. It’s the API that’s hard, not the scripting. OK, I got it.

I can’t say I know much about implementing AppleScript, either. I’m sure Welch is right, though, I bet you really do get all sorts of awesome if you build it into your app. Point taken.

What I do know is that I often come to these same crossroads when building my own products. My decision usually goes like this:

1. OK, what’s the next thing in the bugtracker: feature request — scripting!
2. Let me just open up these Apple developer docs on Apple Script. How hard can it be?
3. Five days later, still reading docs. No code written.
4. Holy crap, this sucks! Applescript is really, really hard.
5. Bugtracker: Refile feature request: won’t fix.

You see, sometimes in life, the decision isn’t between a perfect solution and an imperfect solution, it’s between an imperfect solution and no solution. For the indy developer, many things fall in the no solution bin. Finding things that are both feasible and marketable is what it’s all about.

Welch says that JSTalk will miss many users that use/like/know only AppleScript. He’s probably right. But there is undoubtably a group of web designers that need a graphics program that are familiar with Javascript. Javascript is definitely the de facto scripting language of the moment for web designers. Acorn will probably miss many folks, but it will definitely hit some folks. Marketable and feasible!

And when Welch says he thinks Acorn would be better with AppleScript, he might be right. AppleScript is pretty nifty. But JSTalk is pretty damn cool and way way way … way… better than nothing.

My current email system

I have three accounts, one for personal, one for support, and one for the sales notifications.

The personal account is through .Mac or Mobile.me or whatever they’re calling it today. The other two are hosted on DreamHost and they’ve treated me pretty well. I’ll admit that I really only like the .Mac account because it has a nice email address.

To actually read and compose I use Mac OS X Mail. I have every email I’ve received since I started using Mail back during the Mac OS X 1.0 beta, minus the spam and a few huge attachments. It’s a lot of email, but somehow, through the magic of databases and indexing, its all searchable at nearly impossible speeds right from spotlight. It’s pretty convenient for looking up ancient support questions, finding old serial numbers, or digging for that cool snippet of code someone sent a few years back.

How I use it

I don’t do much sorting or filing. I have a simple rule that puts customer data in one folder and transaction data in another. That’s about as much automation as I’ve installed.

Christi, my wife, answers a lot of the support email. She also connects to the support account via IMAP. If I flag something, she answers it. It’s a simple system. Once answered, we just drag stuff over to and answered folder. Again, simple. I’m really not sure this system could be improved much. Although I would love to be able to annotate messages. I’ve always wanted that feature — no email client I’ve ever seen supports it.

This has all worked without a hiccup for several years now. When the IMAP folders reach a few GB I archive them. I have to do that once a year or so and it takes maybe 10 minutes. That’s probably the sole maintenance task I do.

What changed

Recently I picked up a very inexpensive and very lightweight eeePC. I wasn’t initially enamored by netbooks, but at $125 and about a pound, I’m willing to trade off a lot. That 17” MacBook Pro is a killer peddling up hills. But the question of accessing my email from this teeny machine has been on my mind. I know I don’t want to use Outlook. And I can’t use the Linux tools because my Verizon AirCard only has Windows and Mac drivers. This struck me as a perfect opportunity to research into cross-platform, hosted, webapp-type solutions. Things like Backpack, GitHub, and BitBucket are so amazing that they really prove that some applications actually work better online then their desktop competitors.

Hello Google

This is when all those “GMail is awesome” blog posts I’ve read got me to go try it out.

I did try it… and almost immediately hated it. I’ve really only given it a week, but I don’t think I can bare any more. Here’s why:

1. Ads. There seem to be adds all over the place. I have managed to turn off a few, but not all of them. It’s one thing on the occasional Google search, but I have to look at my email all day long. It’s open 24/7, 365. I can’t cope with that many ads. Listen Google. I’ll pay to not have this crap. Please.
2. UI nightmare. GMail violates rule #1 — if the button doesn’t do anything then you shouldn’t be able to push it. Moreover, if you’re a developer and you build a dialog box that says, “You just did X, which isn’t allowed for reason Y,” then stop. Go back and make it so the user can’t do it. Now, the next time you reach inbox zero with GMail, go push the archive button. That’s rule #1 staring right back at’cha.
3. They also violate rule #2 — if an action is probably infrequent, then it shouldn’t be in your face all the time. It’s cluttered with lots of stuff that I’ll never do. Do I really need that big “GMAIL” image taking up all that space? It has a huge search bar when search is something I only use occasionally. And lots of other wasted screen real-estate… Does anyone use Google Chat? And why is it in my email on the screen all the time?
4. The UI configuration amounts to: you can change the colors. I’m persnickety about how I like email to feel. I just want more, dammit!

What do you do?

So I started asking around about how others use it. It seems to me that most of the people I trust, most of the power users, are actually using GMail for nothing more than a mail host — they’re piping it back to Mac OS X Mail via IMAP, or Mobile.Me via POP, or Thunderbird or whatever. Only a few folks admitted to using it via the web as their default mail UI. But here’s the deal, I love my mail host. DreamHost gives me gobs of bandwidth, tons of techy options, forwarding, filtering, etc. etc. I don’t need an ad laden, free alternative, when DreamHost is cheap and awesome.

I’ve looked into other web mail clients. I didn’t turn up very much. Most things make Outlook seem advanced and make GMail look well designed. It’s pretty sad.

Back to the desktop

So, I’ve come full circle. I’ve given up on GMail. Mac OS X Mail is working well on my Mac. And on the little eeePC, I think I’ve settled on ThunderBird. It’s a pretty reasonable UI on top of the IMAP experience that works well.

Still, I can’t help but think that if the 37 Signals guys did an online email client that I’d pay some serious cash for that sort of thing. And I bet I’m not the only one.

All of my tools are compliant to the latest HTML/CSS/W3C. I strive not just to be “valid strict” but to follow best-practices, to separating content from style, to use semantic markup, and in many other ways make the generated code look like it came from the ultimate perfectionist coder.

My secret

Psst… I’ve got a little secret. When I want to make a web page load really fast and look great on a ton of browsers, you know what I do? I hack the code and ignore rules. I delete the closing tags. I remove the alt properties. I take all the CSS and JS, compress the hell out of it, and shove it in the index file.

Why? Because it works better. It solves the real problems of speed and usability on real browsers. And many of these things can be done without losing an ounce of usability, accessibility or any other buzzwords.

It’s just practical.

So, when I see a new specification, even when pragmatism is its driving philosophy, I’m skeptical. Already I’ve read dozens of blog posts about “best practices”, about what things to do, and what not to. Most of the things they’re recommending don’t have any practical value. It’s just hand waving and “Valid” badges. All this stuff is crap.

But rather than just get mad about it, I want to do something. I want to help you identify when your article is a big pile of crap. Here’s how:

Is your article crap?

1. If your article refers to “screen readers” without any specifics, your article is crap.

Screen readers that you’ve made up in your head and other mythical devices, widgets, and indexers that rely on semantic perfection probably don’t really exist. Real devices do, and their needs are important. But assuming semantic coding style guides will solve all their challenges is idiotic.
If so much of our effort is based on these devices, we must take the time to understand the real devices and their real needs? I want real world accessibility for real people — not style guidelines for platonic solids.

2. If your article describes a solution, without describing a real problem, your article is crap.

I’ve read too many theories on the “best solution” to problems that don’t actually exist. Many rules seem invented to please the OCD coders, geeks with a fetish for angle brackets, and XML specification nerds. These rules don’t help anyone, they trade the art of coding for the mechanics of pretty-printing.
There are lots of real problems to solve, don’t bother me unless you know about at least one of them.

3. If your article ignores IE or any browser that has substantial market share, your article is crap.

This doesn’t help designers build sites for real people. We build things for the actual browsing public as it is today. And about half of those people, whether we like it or not, are still browsing with IE. If you tell us how to do things with new and advanced features, with streaming media tags, and CSS3 drop shadows, then make sure and tell us how to help the other half of the world see the content too, even if it’s not with so much panache.

Now you know.

Now that you know how to tell if your article is crap, you no longer need to write these articles. You can now focus that intellect on solving actual problems and making the world better. Also, please no stupid little badges, OK?

Beta five brings more refinements and and few more fixes. It’s primarily focused on changes to the lightbox animation behaviors, new mootools version, and the way it works on the page with other plugins and effects.

New Moo

This version has the MooTools “load once” and complete MooTools More library that we blogged about recently. It’s still MooTools 1.2.3, but it’s synchronized with Accordion sot that they can work with the exact same MooTools file and smoothly, even on the same page. So feel free to include Accordion and Collage in those Blocks page-blocks and with PlusKit.

Beta-matic

We’re also going to try rolling out beta version via a beta-auto-update. So this will be the last blogged announcement about the Collage 2.1 beta. Any further changes will come automatically — so make sure you have the auto-update feature switched on in the RapidWeaver prefs. And when the beta is done and the release comes out the beta version should auto-update to the release version.

Here’s the complete Changelist.

And here’s the Download.

With Accordion and Collage moving to MooTools 1.2.3, many plugin and theme developers are wondering if/when/how they should update their tools too.

In particular, how do we load a theme’s MooTools and a plugin (or more than one) that also includes MooTools? Brute force techniques of simply loading them sequentially have proven problematic.

In my next round of plugin releases I’ll be including three specific changes in order to combat this and hopefully improve the overall compatibility of all these MooTools sources.

Load Once

I’ve included a single line check to see if MooTools has already been loaded. If it has, I don’t load it again. This means that even if multiple versions are coming from a number of sources only a single instance of MooTools will be loaded.

if (typeof MooTools == 'undefined') {
// The regular mootools library
}

MooTools More

Most of the reasons for using MooTools are contained in the MooTools More library. “More” includes the “fx” animations and lots of other goodies. In previous releases I used the MooTools More Builder to create a restricted version of More just for that plugin. This seemed like the optimal solution. But each of my plugins and each theme usually use a different set from the More library. And loading them sequentially causes problems. This means that we need to include the “just once” conditional load above for the More library too. But if we’re going to include just a single copy of More — it had better have everything that all plugins and themes will need.

I’ve included the entire More set. I do think this is a bit of a conservative approach, but it ensures that no one gets left out. If you’re familiar with MooTools and think there is some way of cutting this down a bit in a practical way, please let me know. I’d like to collect some opinions about this.

I’ve concatenated the More library onto the MooTools file so a single file load gets them both.

File Names

Several of the methods for including multiple plugins (like PlusKit and Stacks) export all the files to a common folder for upload. I’ve chosen to name the MooTools library as generically as possible: mootools-1.2.3.js. In this way each of the plugins will use this same generic file. This will ensure that the the publishing upload is small and that the browser will cache this when the page is viewed.

Since MooTools is often the largest single download when accessing a page, it’s important to squeeze as much as possible out of caching and reuse.

What’s Next

I would appreciate feedback, either from users or other developers, about these technique. There are tons of tradeoffs, lots of variables, and an ever changing environment — we’ll probably all have to work together to create a solid platform that is stable and user friendly.

The snow is coming

Not so long ago early builds of RapidWeaver for Snow Leopard start to leak out of RMS for plugin devs, like me. I really have to hand it to the RMS crew for making this happen early enough for us to react. A few days later I was testing my plugins to find that there were definitely a few incompatibilities.
Not to worry though, Snow Leopard wasn’t due until September. Weeks away. Loads of Time. Right? Right!?!?

Christmas came early this year

Then the news hit: the final developer seed was the Snow Leopard GM. In English that meant that Apple was doing something unprecedented. They were going to release a major OS EARLY. Weeks early! Just days away! What to do…
Time to barricade yourself in the office with lots of coffee. Ready, set go!

A week of crazy

Since the middle of last week I’ve shipped:

• Accordion 1.5
• Stacks 1.2
• Collage 2.1
• Blocks 3.2
• plus beta versions, test versions, regression test pages, etc., etc., etc.

And where does that leave us?

If you’re running Snow Leopard, then you should be good to go with YourHead plugins, but there are two caveats:

1. Use the RapidWeaver RC release.
2. Use Collage 2.1 beta 4.

So how’d it go?

So far so good.
The Collage beta still needs some more work, before the final release. We expected that, and made huge improvements over beta 3. Accordion, which had some substantial changes to the UI, has a few cosmetic bugs that will have to be fixed.
The Blocks build that went out yesterday went out with a bug. In all these fixes, I was bound to mess one up. But, auto-update should have a new version that does do Accordion page blocks, even with inline media. And hopefully before you’ve finished you second coffee.

More to Come

Really we only had a couple bugs. But each update spawned more changes to other plugins. Little tweaks to refine interoperability. And we’re not done.
Both Collage and Accordion are now working on MooTools 1.2.3. We plan on moving Carousel and Kwix too, but we’re going to take a few weeks breather, first.

This is a small release. It modifies how Blocks treats an Accordion page when you use Accordion in a page block.

Get it Now

More Info about Blocks

What’s New

• Fix: Supports Accordion 1.5 in page blocks.
• Fix: Better memory use while exporting pages.

Requirements

You must have RapidWeaver 4.2.1 or newer to use Blocks. Although we strongly encourage people to use the latest version of RapidWeaver at all times. Please double check to make sure you’re not still running RapidWeaver 4.2(.0). And see this post for more details: Update RapidWeaver!

How much?

Blocks is $24.95, but you can try the demo for free. The demo has all the features, but just limits the number of items on the page.

How do I install it?

1. Open RapidWeaver
2. Close any open documents.
3. Download the Blocks disk image.
4. Double click on the Blocks plugin in the disk image window.
5. Quit and restart RapidWeaver