notes.husk.org

Chris Clark:

Camino jumped on the “Hey Guys! We could totally make it look like Exposé” bandwagon. 

… you know what’d be even more useful? Tabs that work with real Exposé.

Peter Bright:

All applications get thumbnails, but applications with explicit support for 7 will be able to add thumbnails on a finer-grained basis. IE8, for instance, has a thumbnail per tab (rather than per window).

Me:

As Matt Jones put it: You’re kidding, right? If you want tabs that behave like windows, just use bloody windows.

It’s too late for me to properly reply to Tim O’Reilly’s post about cloud computing, but there is one thing I’ve learnt during this week’s AppJet jaunt (as described over on Vox), and it relates to a point right at the bottom of his post:

the cloud platform, like the software platform before it, has new rules for competitive advantage. And chief among those advantages are those that we’ve identified as “Web 2.0”, the design of systems that harness network effects to get better the more people use them.

Well, AppJet’s library sharing (alluded to on Vox) has this property. You can see who’s importing your library, who’s cloned (forked) it, and the same goes, thinking about it, for apps. That’s not really that much of a big deal, but it’s inching towards something. (Compare: github.)

Sorry. I’m sure I’ll return to posting a stream of random pictures tomorrow.

I’m a big fan of meaningful titles. Not only do they make your web browser’s history easier to navigate, but they also give bookmarks - both local and shared - meaningful, and they’re good for IRC and IM conversations too. I’m told they’re important for SEO, but I’m not exactly bothered about that one.

When I first published my custom theme for notes.husk.org, the title was fairly useful:

<title>notes.husk.org. 
     {block:PostSummary}{PostSummary}{/block:PostSummary}</title>
     

This gives the index page a title of notes.husk.org (yes, I should be using {Title}, but I don’t care to make this theme public- yet), and if it’s a single post (for example, my previous text post), it also puts the post’s name into the title, so you end up with “notes.husk.org. Irony in Stamps”.

I decided to add a full stop after the PostSummary, but then considered some other cases. For example, what about archive by date pages, like this one? Well, there’s a set of tags for use when you’re on such pages for pagination, and you can (ab)use them like so:

{block:DayPagination} noted on {block:Posts}
     {block:NewDayDate}{Year}-{MonthNumberWithZero}-{DayOfMonthWithZero}.
     {/block:NewDayDate}{/block:Posts}{/block:DayPagination}
     

It’s not terribly clean, because you need to loop over the posts to get the day out, but it is there. However, that still leaves the other sort of pagination, the straightforward 10-per-page sort. That’s easy enough to deal with, though:

{block:PreviousPage} archive page {CurrentPage} 
        of {TotalPages}.{/block:PreviousPage}
        

Here, PreviousPage is only invoked if you’re not on the newest (ie front) page, so the title there is kept short. Thankfully this is more straightforward than the date archive version, but I might end up tweaking the wording a bit (especially as Tumblr has its own concept of “archives”, which are very pretty but not templatable).

Finally, there’s tag pages, which I don’t expose (edit: now I do, on single-post pages only) but you can still get to anyway. These are pretty straightforward:

{block:TagPage}tagged {Tag}.{/block:TagPage}

So that’s it. All the pages on notes.husk.org now have a unique title, even the ones that don’t have exposed navigation. Nifty, huh? The full block, in case you want to work with it, is as follows. Have fun!

<title>notes.husk.org. 
    {block:PostSummary}{PostSummary}.{/block:PostSummary}
    {block:DayPagination} noted on {block:Posts}
      {block:NewDayDate}{Year}-{MonthNumberWithZero}-{DayOfMonthWithZero}.
      {/block:NewDayDate}{/block:Posts}
    {/block:DayPagination}
    {block:PreviousPage} archive page {CurrentPage} of {TotalPages}.
      {/block:PreviousPage}
    {block:TagPage}tagged {Tag}.{/block:TagPage}</title>
    

A to Z of New Zealand stamps:

indirectly via pixelace.

Ned Richards just posted a link to an article on the armpit of usability. It suggests that there’s a correlation between a decrease in usability and the level of speciality of an application:

I don’t really disagree with this, but it did remind me of something else I noticed at my old job, when they changed from an in-house timesheet system to Maconomy (horrifying slogan: “People made profitable”). The former was a bit idiosyncractic, but it did a nice job of tying in to the (also homebrewed) ticketing system.

Maconomy, on the other hand, turned out to be a usability nightmare. Even logging in was a trial: for some reason it treated minor sub-versions of Firefox as incompatible (“you’re using 2.0.0.9? I’m not sure that’s ok, go back to 2.0.0.8!”) while ignoring the multiple patchlevel sins hidden behind IE’s user-visible “6” and “7” labels. Then there was the tendency not to let you log in if you had the slightest trouble with your password, the way it forgot your projects from week to week, and so on.

Eventually I came up with a theory to explain why the user experience was so horrific, and it was simply this: that Maconomy had spent all their time optimising the UI for the 5% of the company that saw as administrators. I have no idea if this is true, as I never was one; it’s quite possibly their interface was terrible as well. However, it seemed to be a reasonable hypothesis: companies will optimise for the people who most directly pay them, not their end users. No wonder so much “enterprise” software is awful.