More Spatial UIs

If you’ve ever played the kid’s game Memory, you would probably cringe playing it on a computer desktop, with each card being its own window, non-tiled, overlapping. Or what if you played it by picking a card, choosing a filename, then having to remember the filename to remember the card.

Studies have shown taking pad-and-paper notes beats typed notes for memory recall. Part of the reason for that is likely the spatiality of the notebook. If you had students write or type the same material, then ask them where something was in their notes, I bet the writers would beat the typers on anything that wasn’t on the first screen/page of notes or the last.

That’s because in a long text document the middle becomes a blur. There are no signposts. That’s why programmers use line numbers, to give them back signposts, but even these are somewhat cumbersome, the longer the document gets.

When you’re writing and hit the end of the page, you move to a whole new page. When typing (depending on the editor), you may just get stuck at the bottom of the file. So-called word processors do better, usually putting you on a new logical page at the top, but most text editors and IDEs I’ve seen simply keep you on the last line of the file, at the bottom of the screen.

When you’re reviewing a dead tree document, handwritten or not, you can flip pages and again get something akin to landmarks. With a digital document, you have this endless scroll, where everything in the middle is middle. It would be like drinking out of a straw in a wall, not knowing how full the reservoir of drink behind it was. After the first dozen-or-so sips, you sort of assume you’re in the middle, until you hit the gurgle at the end.

Some books even have chapter styles that have printing on the margin edge of the page, making it easy to see where chapters begin. You can see if you’re about to start a long chapter, and postpone until you have time. With a computer, it could mark the scroll positions of the chapter breaks, but as scrollbars vary by the length of content it would still not be as calibrated as a book.

The same goes for notecards. You can fan them out on a table, shuffle them, stick them on a wall. They are great spatially. But try to recreate those options with a computer and you usually either shrink their size or distort them. You lose their spatialness.

That is the real promise of Virtual Reality: bringing enhanced spatial awareness to computer interfaces. It’s not clear whether or not we could have the same enhancements without VR, but it’s at least likely that we could. The difference with VR is that it more-naturally fits that sort of interface, and it also provides a reset of expectations and aspirations for design, allowing people to experiment and find the spatial uses.


Canonical and GNOME

Removing the minimize button?  Not giving a preference to turn off the display and not suspend when you close your laptop?  Moving the window controls to the other side of the window? Making the tabs square instead of round? Not allowing the editbox to be manually resized? Hiding the RSS icon? Moving the link preview to the URL bar? Removing the status bar?

And those are just the ones I can recall at the moment.

The computer is so central to peoples’ activities, that there is a certain fear that someone will break it for them.  That’s one of the major motivations behind Free Software in the first place: if I can build it myself, then you can’t force me to use the broken one.  If I can’t, then MicrosoftAppleSonyPaypalMastercard can up and decide to force their will upon me, and my recourse is simply to stop using them.  No stabbing big corporations with a fork.

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

I don’t think this is a bad thing, excepting the bickering.  The larger community of desktop Linux users will get to see two different approaches in the wild for at least a year, which will inform the next iteration of the Linux desktop landscape.  There’s also an open-ended possibility for reunion later.

The dispute is territorial, which is not uncommon in open source.  The uncommon part of this is simply that it’s between two big players rather than between one big player and the users.  Though, the latter has occurred for both reinventions as well (see a few of the questions posed in the first paragraph).

Project governance is hard.  Cooperation is hard.  Finding the best way is hard.

If it weren’t for the bickering, nothing would be wrong.  There’s too much distrust and fear, because that’s what we’ve been taught by the proprietary realm.  When we used proprietary software, we could be stuck with a bug indefinitely.  Or things could change with no warning.

So we’re edgy.  But when the source is open, we shouldn’t be.  And if we weren’t, it would make project governance easier, it would make progress easier.  We should be willing to give the code an honest run.

At the end of the day any shift in any system will require a new equilibrium to be reached.  In open source that means some users will switch, forks might be created, etc.  But it also means that most users will find a slightly better workflow, will be a little (or a lot) happier and more productive.

I just wish that the developers weren’t so quick to assign blame, because they’re both building the foundation for the future, and they should be proud of their efforts even if they fail.


The Woes of Color

As anyone that’s watched this blog when it’s changed, or looked at Sequlr knows, I’m not the most gifted person when it comes to picking colors.  Part of that is the fact that not all color combinations even work to begin with.  There’s this notion of contrast, and without contrast you simply cannot have a foreground and background at all.  The WCAG 2 guidelines for color contrast makes picking colors something of a minefield.

Many websites (I might even guess a majority, but I haven’t done any serious sampling) completely ignore WCAG/color contrast, assuming all of their users have perfect vision.  They are more concerned with the visual appeal of their design than the functionality.  This goes even for very prominent websites and those that at least pay lip service to accessibility.

But even for the few, the proud that make earnest attempts to comply, to contrast correctly, the obstacles are considerable.  Consider Mozilla Firefox, which is currently in the late beta versions of its fourth release.  They have a CSS color, GrayText, which is hardcoded and bad for accessibility in certain circumstances.  In the case I noticed, it’s used for the hovered link, now that the status bar is going away.  Of course, they shouldn’t be trying to indicate placeholder or non-standard text by making it gray, but it wouldn’t be so bad if they derived its value from the OS theme.

And there’s the second hit: the OS likely doesn’t provide a specific color for this use case.  It probably doesn’t provide guidance for link/visited link colors either.  The OS justification for this is likely that adding more color choices for the theme would complicate it.  That’s true, but you have to choose your direction of complication: either provide the choice that can be ignored by the user or end up with the application developer painting themselves into a corner.  In the latter case you end up harming your users anyway, as they may find their theme incompatible with a variety of software despite it being an otherwise usable theme.

My own experience with color has been that it’s very difficult even if you ignore accessibility.  If you do take contrast into account, it’s harder because you have to pick some colors and then tweak them or at least check them for proper contrast.

I think the solution is better allowance for user choice in colors.  At the OS level, as I’ve noted, but these color choices need to bleed through to the web.  The web application should be able to get a set of colors the OS theme uses, and apply them correctly to the presentation.  This would make the web blend better with the desktop, and it would improve the accessibility of the web a bit.  The other change needed is for the web to get over art.  Where the goal is art, the web can keep going, but where the goal is actually to present information, the tendency for art to trump function is alarming and harmful to the platform.