Category: design

Categories
design

Thoughts on the Steam Client Library Update

First, what is the update and what is it not? The update covers the Steam library, listing the user’s games and the display of individual games themselves. It’s not a revamp of all the web pages and application views that form parts of the library, like achievement pages or the downloads view. Those will likely be updated in look and feel to match the new styles over time.

The biggest change is the addition of the new home section, which is a jumping-off point to other parts of the library. It adds a new events/news serial at the top, where you can see game news including media and updates to games.

The primary art for games is now in portrait format (600×900). This, alongside the addition of a large banner image at the top of each game page, are the biggest visual changes. The portrait format affords space for text and art with some separation where the old banner style (what Valve calls capsule) really require putting the two together. But the capsule format is still used in at least a few places, including for the most-recently played game and on the downloads view.

The collections system, formerly more like tags, now allows for dynamic grouping. I tend to track several properties of games, like whether I played them yet and what their style of game is, besides noting of they require a EULA or have broken features on Linux (a few games I’ve played required using Proton in order for achievements to unlock).

One downside of the collection system is that if you navigate to a game from the home screen, it will be opened from the first collection alphabetically. It might be useful to let users designate a primary collection that a game belongs to, so that it will be shown as selected from the most sensible category and not one that happens to be first in some old song that lists letters.

On the whole this is a nice update. The most notable thing is that it matches design changes that are happening across the larger digital space. While books developed a fairly consistent design schema a long time ago, the digital sphere is still trying to do so. It still has a way to go, as seen in the choice to maintain website icons as squares (which, far as I can tell, was a change driven by Apple and their iOS choices) while something like the Steam library uses portraits.

In terms of the future of Steam, a lot of this will depend on developers using the new events system and updating their artwork. As of writing, roughly 2/3 of my games have updated art for the beta, with the rest using the capsule-style art with a blur effect to fill the extra space.

As mentioned, other parts of the client experience still use the old capsules. While it takes work to create the separate representations, having the visual differentiation is useful as far as it goes. One wonders whether a compositing system wouldn’t work better, with separate images for graphical logos and backgrounds being able to be adjusted to aspect ratio requirements at display time, with some caching for frequently composited elements. Ah well.

Categories
design

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.

Categories
design

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?

Categories
design

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.

Categories
design

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.