The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Thoughts on the Steam Client Library Update

A brief look at 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.

More Spatial UIs

Computers don’t present to humans in the most natural ways, but VR may give us the opportunity to change that.

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.

Knowing the Greatest Bug Number

Looking at the idea of using years and months as part of numbering bugs for bug trackers.

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?