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.

16 May, 2015

Knowing the Greatest Bug Number

Most open-source projects have a bug tracker, and bugs are numbered sequentially. Thus, knowing the highest existing bug number (GBN) is an important piece of information if you’re looking for what you believe is a new (globally, not just new to you) bug.

You do a search for bugs, and one of the things you see is their number. If you know roughly what the GBN is, you can tell at a glance whether the bugs in your search results are new or old. That will give you important information, as a bug from ten years ago, from a deprecated version that won’t even run with your current libraries, etc. is probably not your bug.

Of course, technically knowing the GBN isn’t sufficient. You must also have some vague idea of the reporting cadence. That is, if GNB is 600K, and you’re looking at bug 550K, the rough time to accumulate the intervening 50K bugs could be large or small. And the cadence changes, probably following an elliptical orbit (speeding up close to release, slowing down at the midpoint between releases).

The question is, would it make sense to change how bugs are numbered? Would it make more sense to have bugs numbered like: YYYYMM-NNN? Adding in DD would probably be too fine-grained, but months probably fit well for most projects.

Bug numbers do not have an inherent meaning. They are already security-compromised in terms of giving away the timeframe they were filed. (That can be avoided by squirreling away some numbers and filing them late, but it’s unlikely to be done in open source. Even if it were, you could still squirrel some date-stamped bug numbers.)

You would lose guess-the-date-for-bug-N contests, though you could technically still hold one, it would just be using bug numbers people don’t refer to as often.

You might also gain a benefit: developers would have the date-of-filing staring them in the face every time they referenced a bug. I don’t think that would really matter; software gets built as best it can. Most unfixed bugs aren’t from laziness, but from difficulty, lack of information, and lack of time.

The other side of that is the users who will say, “this bug is five years old.” They already exist, though, so it doesn’t seem like this adds to that problem.

But having a year-month-numbered bug can, in some cases, give an immediate idea of a project’s size. A bug like YYYYMM-1 won’t, but a bug like YYYYMM-2468 will. They’re getting at least thousands of bugs per month.

There might be some technical issues. Will a bug database handle a lookup as easily when fragmented into years and months? Should there be that dash or should it be YYYYMMNN? Will people think the Ns are days?

What other benefits would this scheme achieve? Could you type MMNNN for the current year in a search? Or NNN for the current month? Will people get frustrated when it’s the first day of the month and their bug now needs to be typed out? Could you use some shorthand for that case?

I think using partial dates rather than purely sequential bug numbers (at least as an alias; there’s probably value in keeping the regular, sequential numbers, too) may have some use, but what do you think?

25 April, 2015

Save Games in Gaming

One of the features most story-based games have is the ability to save your progress. Although some game companies are more focused on multiplayer games, singleplayer isn’t going anywhere, and multiplayer may include some singleplayer components in the future.

But if you’ve played a handful of games with a save game feature, you probably noticed they all work a little bit differently. And those differences may actually impact your play style.

Up-to-you Save Games

The up-to-you style is where the game simply has a feature and you can save whenever. It doesn’t save for you, and often you can name the save games. This style seems adequate, but in my experience I would only use one or two out of dozens of available save slots.

Usually I would stick to one slot, and then if things got hairy or I thought I might want to keep the other as a known-good save, I would add another. After progressing far enough, I might repeat that process since the known-good slot had aged too much.

Up-to-us Save Games

This is the opposite extreme. The game saves when it wants, and you have no control over it. In this sort of game, I would tend to be increasingly cautious as I moved farther from the last save. I would know that if I failed a mission or died, I would have to go all the way back. That inhibits risk-taking, which is not what games are about.

Games can encourage risks and teach us about when risk is appropriate. But if the game administrivia function itself discourages risk, that limits the game experience.

Hybrids

A number of hybrids exist. You get automatic checkpoints, which protects you from having a lone save game in a situation where you can’t progress, but you can add your own on top of it, giving you some say, too. This model seems the best of those currently available.

The main pain point with hybrids is that you might tend to accumulate save games that aren’t useful in the future, but if the save data is small and disk space is abundant, it shouldn’t really matter.

The Sandbox Model

Some games aren’t normal story-driven games, but sandbox or open-world games. In these what’s generally saved is the state of your playthrough: your inventory and completed missions, plus some sort of general location. This seems to be a pretty strong model for this type of game, but it doesn’t necessarily translate to more linear games.

Early games didn’t have saving available, though some used elaborate codes, as consoles lacked storage. They also had limited lives, which meant you could have to start the whole game over if you died. We’ve come a long way since those days, but I’m hopeful that future games will have save options that are even more powerful and reduce the friction of playing the game.

29 November, 2014

The Evolution of Writing on the Web

A non-functional wire sculpture of a toilet. — By CCRI Artdepartment

Why New Styles are Needed

Articles should be swifter for the web.
People want to read less as they have more to read.
Top ten lists and bullet-point articles make it easier to get through.
You can skip around between parts, pick up where you left off.

How Did We Write?

Old writing was based on a longer attention span.
It had deeper stylistic integrity that the form afforded.
Structures of sections of paragraphs of sentences of words.

The New Style, Evolved from the Old

Headings of bullets of sentences of words.
Pictures to anchor each part (not shown here).
Barer sentences, with less complexity.
Like a powerpoint put through a wringer.

The Old Style Lives On

Books and periodicals, along with some traditionalist sites.
Nice for articles you want to go deeper into.
Side-by-side old and new allows for reader choice.

Benefits of the New Style

Students learn outline forms more easily.
Reading comprehension goes up for the new form.
Discussion is simplified through easily-referenced sentences?
Improves collaborative editing and creation.

Downsides of the New Style

Students dislike the old style even more than they already did.
Comprehension of the old style diminishes further.
Discussions are based on less nuance (Fox Newsier discussions prevail).

I Dunno.

I’m curious whether this sort of writing style should become more dominant.
I think it has some benefits for the way people use the modern web.
- Easier to read casually.
- Possibly more accessible to AI.
- Less opportunity for verbosity.
So I wrote this in a version of what the new style may be, to see what it’s like.
Oy vey. I’m hoping that there can be some balance. I do think language and writing styles need to evolve to fit the needs of readers, and long-winded writing can be a pain to read (especially as the number of things to read grows), but let’s hope it won’t be a bullet-point-riddled future.
One promising alternative is that AI will allow for real-time reorganization/editing of long texts to elicit the parts the reader is most interested in.

22 November, 2014

Better Time-passage Indicators

An old calendar stamp. — “Calendar” by John Nuttall

One of the things you see quite a bit on the web is indicators of when something was posted, edited, recorded, etc. And they have two predominant forms:

Posted two hours ago
Posted April 1, 2014

The web could use better time indicators, though. For example, if you are looking for a bug in some software, and there was a major release in March, you probably want to only see things since then. So having time indicators that show relations like that could help. If the site you’re using is showing a time-since indicator, you have to stop: “okay, it is November and this says six months ago, so that’s around the right time.” If it said March, it would be more convenient.

But if it’s a closer-to-now time, what then? A comment posted earlier in the day might say, “posted two hours ago.” Again, you have to do a mental conversion: it’s noon, so 10am. It’s 6pm, so 4pm.

And then you have earlier-in-the-week times. Instead of “three days ago,” why not, “Wednesday?” You remember Wednesday easier than thinking, “it’s Saturday, minus three…”

What will time indicators of the future do instead?

For one, they should age. After a month has passed, it’s better to say month and year versus n months ago. The switch-to-weekday if it’s in the past week thing is probably good, too.

For another, they should eventually (as we begin tracking ourselves) learn to incorporate personal markers. Saying, “this comment was posted just after you ate lunch” might give you better mental context than saying, “four hours ago.”

Intermediate times might be harder to fix. Three weeks ago on a Tuesday? If you keep up with elections, they could say, “on the day of the recent election.” But what if there wasn’t anything significant to tie it to?

The other part of this is the potential benefit of iconic time. We have icons for all sorts of things, but not for time. What is the symbol for an hour, for example? For a day? A week, month, year?

Having icons for these units could simplify visual recognition. A day might be some sort of sunrise-sunset icon. A week might be a seven-pipped design with the pips being suns. And so on. Searching through some of the Unicode symbols, there are:

Non-Western symbols (nth day)
Alchemical symbols (hour, day, month)
Weather symbols (sunrise, sunset, moon phases)
Food symbols
Holiday symbols
Sports/activity symbols

And so on. There are analog clock faces, but they probably wouldn’t simplify much. If a sporting event has a fixed time that everyone knows, it might work. Food symbols could signify specific meals (e.g., pizza for breakfast). Weather symbols for sunrise and sunset could be used, as could holidays under some circumstances. Animal symbols might work, too. A rooster for dawn and a cow for dusk/night. The British could use a teapot for whenever it is they sing “I’m a Little Teapot” every day. A beer mug could be used for happy hour.

But it might really be better to invent new, abstract symbols for times (or at least modernize something like the alchemical symbols for hour, day, and month).

Also, it’s important to note that improving time displays only makes sense for casual viewing. If you’re working in the context of times and dates, say in a spreadsheet, it’s not needed as much. But when your main focus is not time-related, having easily digestible times can save you a few cycles here and there.