The Shift-Click, it does nothing!

…or: the new Unified Invetory and the issues that come with it.

It's been a long time coming, but EVE's inventory UI is finally getting some attention. A while back, a dev blog on the new “Unified Inventory” was published and since then, the UI has been available on Singularity for testing. As it turns out, it's a mixed bag of good and bad with some definite improvements but also quite a few issues. The main worry is that these issues are not just bugs and the occasional thinko, but also some genuine bad design and regression in functionality.

Here, I'll present some of the nicer points, some of the troublesome spots, and some ideas on what could be changed to address these issues. For the TL;WITYTHR version, see the illustration video below.

…but let's start on a positive note.

The good stuff.

There is indeed a lot to like about the new inventory framework. The most immediately obvious change is the addition of the ubiquitous tree list view, which makes the inventory work much like the basic file manager in an every-day OS, such as Windows Explorer or the Finder. Cargo containers now function a lot more like folders, and this brings renewed hope that we will some day see actual folders by letting us set up “virtual containers” — a cargo container that has no physical object and which has an unlimited storage capacity (or at least the same storage capacity as the cargo bay it's sitting in). Combined, these two features provide a much improved way to manage large collections of items and quickly find exactly what's needed.

There are also some underlying changes that look very promising. While I normally get kind of annoyed with graphical effects on functional parts of a UI, the (fairly subtle) animations used also give the impression that the new UI is a lot snappier than the old one — the entire screen doesn't lock up just because things are loading, and moving stuff around feels more fluent. The ISK-value roll-over information is perhaps a bit distracting, but mainly because it appears immediately and can obscure things that you're looking for when mousing over the inventory. Perhaps it should be given a slight delay so you can work without obstructions but still gain access to that information. The ISK guesstimate overall is a very nice feature, but then I would say so since I spend a fair amount of time collecting and trucking valuables back and forth…

Overall, the UI feels like a great foundation for item management, but it is not without its issues.

The single-window paradigm.

The fundamental problem with the Unified Inventory is, paradoxically, both that it is unified and that it is missing key parts. It is quite clearly intended to be a single-window interface to all the item manipulation one might come across, and this is perhaps expressed most clearly in the dev blog where the UI is presented:

CCP Arrow
So, what’s the opposite of multiple windows? After weeks of research and multiple rejected hypotheses we came up with what we are certain is the correct answer: a single window (please tell us it’s the right one).

No. Well, yes, it's the answer to “what's the opposite of multiple windows,” but unfortunately, multiple windows is not the correct answer to “what is the problem” so the single-window answer is an answer to a non-issue. In fact, a single window comes with just as many problems as having multiple windows (if not more).

What it boils down to is essentially this: all inventories are not equal, and unifying them tries to make them equal. The Unified Inventory on Sisi does a stellar job with de-cluttering and managing large inventories (personal and corp hangars), but it is missing the largest of them all: the corp and personal asset lists, and instead it tries to take on all the tiny inventories as well. For locations like a combat ship's cargo hold, or the speciality bays on most ships — drone bays, ore bays, ship bays, etc. — only a handful of items will ever be placed there. At the end of the day, unifying these two broad categories into one window doesn't make much sense because they have such vastly different needs. Some of the core functionality — ISK approximation, a generally more fluent interaction, and so on — is naturally welcome for these inventories as well, but the kind of space and overview that is needed for a hangar full of stuff simply isn't needed for a fuel bay with a single pile of fuel.

As a result, you can never really set up this one inventory window to match all needs: for the aforementioned fuel bay, covering half the screen in inventory UI is a massive waste of space; for a corp hangar, the tiny corner needed to monitor ship fuel is far too little to gain any clarity to what items you have. The problem here is one of context: the context of monitoring supplies is quite different from the context of moving items around, and the UI tries (and fails) to capture these different context in a single window. The two are begging for different windows with different layouts and setups. On a related note, a single window also by very definition cannot be used to monitor the status of multiple inventories at once: it doesn't let you see both your ammo status and your fuel status at once, nor does it let you see how much ammo you have (in a hangar somewhere) and how much ammo you need (in your cargo hold) at once. Some of it could simply be committed to memory, but it will still require a lot of needless clicking back and forth between the two locations even for a single type of item… and heaven forbid that you plan to carry multiple stacks of multiple items.

These are a couple of the core design issues that come as a direct result of trying to use a single window for everything:

• It inherently removes the ability to provide an overview of multiple locations at once; it is completely devoid of context, so all inventory use has to follow the same general pattern (which may or may not be at all suited for the context).
• It inherently requires more clicking to do the same amount of work compared to if it was possible to set up a static multi-location workspace
• It cannot be balanced for all uses, and will be far too large and bloated for some inventories and/or far too small and cramped for others. Constantly adjusting the single window for the current need once again introduces more clicking and more work.

Basically, there is no right answer to how many windows are needed to manage your inventory. In a select few cases, the correct answer may indeed be “1”, but in many, many other cases, the answer will be a whole lot more. Also, the dev blog kind of starts out on a false notion: the current UI doesn't require you to open a ton of windows. It is actually very easy to set up stacks of windows, where each stack contains exactly what you need at exactly the size you need.

All of these design issues really come down to the simple fact that a single window very often isn't a good or efficient way of managing items. To be more precise: it's a good way of displaying large amounts of items, but not of actually managing them. For that, multiple windows are often called for. As kind of a band-aid to this issue, it is indeed possible to use the titular shift-click to open a new window with the inventory you need to monitor, but unfortunately, this solution suffers from a plethora of implementation issues and ends up being nothing more than a temporary measure since such additional windows are never saved and cannot be used to create a static workspace where you always see the same things. Trying to use multiple windows on Sisi at the moment will very quickly reveal a number of bugs, misfeatures, and gaps in functionality that effectively renders the shift-click band aid entirely pointless.

• Fundamentally, the system doesn't reuse old windows. Shift-clicking does exactly what it says it does: it opens a new window, with new default settings, and is completely oblivious to any old settings you might have had for previous windows that served the same purpose. The settings are tied to the window, not to what the window is displaying.
• As such, any new window will not retain any kind of size, position, stacking, list column setup, view mode, or any other customisation you might want.
• New windows are treated as if they don't exist as far as the inventory system is concerned (as of the latest build — in previous builds, it treated all windows as if they were the one single inventory window, neither is a good solution). Opening cargo containers or cans will only make them appear in the primary inventory window, overwriting whatever was shown there before.
• Similarly, there is quirks in how the main inventory and any secondary inventory windows behave. The latter can occasionally close themselves if they are considered no longer needed, whereas the main window will never do this, and the two seem to follow slightly different rules when determining if they should reset themselves to some default inventory (e.g. a can in space is no longer available — the main window resets itself to show the ship cargo hold, whereas a secondary window will either reset itself or just close, depending on why that container can no longer be used)
• There is a sharp disconnect between “external” open-inventory commands and those internal to the inventory management. Using the “selected item” toolbar in space only ever makes things appear in the main inventory window — it's impossible to open new windows from this toolbar, for instance. The open command also assumes that certain containers will have their own windows, which they no longer do. For instance, opening a corp hangar at a POS would previous open a (surprise!) corp hangar window. This no longer exists. Corp hangars are now just a heading in the tree view, and it cannot be opened — only the individual hangar divisions can be opened. Therefore, trying to open a hangar array the traditional way makes absolutely nothing happen.
• New windows do not update properly. This is most likely a bug, but it is very easy to come across a situation when dragging items to or from a secondary inventory window makes it appear as if the items never left that window — they are still listed, and the user has to manually update the window to show its actual contents.

Similarly, but not necessarily tied to the use of multiple windows, the implementation of the new inventory turns old quirky design decisions into outright bugs:

• Limitations in what items can be named and not becomes a problem in distinguishing these items in the inventory manager. This is most apparent with corp hangar hangar arrays at POSes: it is possible to anchor multiple such hangars, but they cannot be named, and thus appear as a long list of “corporation hangar array” in the tree view without any means of distinguishing them.
• There are some deeply flawed assumptions about how different inventories should be categorised. For instance, the corporation delivery hangar is, perhaps unsurprisingly, categorised as a corp hangar, but the inventory system only displays corp hangars in the tree view if a corporation actually has a corp hangar in the station in question. As a result, buying stuff for a corp in a station where that corp has no office will result in the stuff being delivered to a delivery hangar that cannot be reached through the inventory management.
• Exactly what counts as a “container” isn't entirely consistent and whether or not something counts as a container determines how it can be used. For instance, the actual ship hangar is, somewhat non-intuitively, something completely different from the ship category that appears in the tree view, causing two very similar lists to behave in rather different ways. I'll come back to this one a bit later

Why are multiple windows useful?

Again, one of the fundamental issues with the new inventory system is that it assumes that the many different places where one might store items are universally the same and that they can (or should) generally be treated the same. It is a context-blind system that features a number of handy solution for large collections of items, such as (personal and corp) hangars and the (personal and corp) asset lists… while still not actually supporting half of those since the asset window isn't unified yet, and it tries to shoe-horn every kind of item list into that mould. In reality, many of these smaller item collections are far better handled with separate, small, and simple windows that only ever show that one location.

Having multiple windows means that you can set up such contexts: one window might only ever contain small inventories with one or two items in them, but which need constant monitoring — they can be tucked away in a corner of the screen and just be left to sit there at all times. Another window might show temporary inventories, be it cans that will self-destruct when emptied or ship bays that are just filled to the brim (or completely emptied) and otherwise left alone — it can be placed just about anywhere and its temporary nature means that, while it may appear on top of some other window, it'll soon be gone. A third window might contain these vast collections of items that the new UI is so proficient at handling, and which therefore need a bit of well-planned screen placement and takes up a fair amount of real-estate.

Finally, there is the numerous permutations of a point that has already been mentioned on a couple of occasions: multiple windows lets you monitor the status of multiple locations at a glance, as opposed to having to click between them in a single window when there are better and more critical uses for your time (and mouse clicks). Once again, it should be noted that while it is indeed possible to set this up with the new UI, it is not persistent — it has to be set up every time you dock, undock, jump, or otherwise change you location in the world. The ability to do this setup may be slightly improved in that many of the inventories you might want to see can be accessed from the tree view, but at the same time, the direct access to those inventories through dedicated buttons has been lost and the slight improvement does not nearly make up for the fact that this setup needs to constantly be repeated.

An couple of illustrations.

I've put together a demonstration of what the current UI offers that the new one doesn't, and why this is actually having the effect of drastically reducing the efficiency with which you can manage your inventory.

This video highlights the following key points:

• It's a false notion that the current UI enforces “tons of windows” — it doesn't. It enforces tons of tabs, but these can easily (and permanently) be collated into logical stacks to reduce both screen clutter in general and the number of windows. The tabs have just been turned into a hierarchical list in the tree view and is, if anything, longer than ever.
• The new UI suffers from assuming that every inventory is the same and that every inventory window is the same. This leads to a problem where there is no a priori control over what opens where.
• The shift-click band-aid to create multiple windows suffers from the implementation of letting every new window be a new window: no settings or setups are being retained. It is functionally impossible to create a static setup where things consistently behave in the same way, especially in use cases where the previous point comes into effect as well.
• The tree view offers direct access to a lot of things, but having to scroll through it and open layers upon layers of containers means it's actually more fiddly to set up (even setting aside the fact that doing so becomes pointless since nothing is saved) than with the old system, where you had direct-access buttons and tabs.
• Tied to this, there is a missed opportunity in not tying this UI more closely to the new NeoCom — everything is hidden behind a single button, rather than letting me set up direct access to certain inventory views through custom buttons on the NeoCom.

Container-centric inventory.

Another issue that isn't addressed in the video, but which deserves a longer mention, is how the unified inventory has become strangely ”container-centric.“ Again, this seems to be an artefact of the devs wanting to solve the problem of large collections of items and then carelessly applying that design to everything. As a result, things that one might not think of as containers are now treated as containers, and this leads to a couple of oddities. This is most notable with the replacement for the ship hangar. This hangar is now a category in the tree view, and clicking on it displays the familiar view of the list of all ships you have in station. At the same time, the tree view itself lists the ships you have… almost. There is a key distinction here: the ships in the tree list are capable of acting as containers. They have been assembled and have cargo holds and all all the numerous bays EVE ships can have, but ships that do not fulfil this requirement — most notably unassembled ships — do not appear in this list.

In numerous threads, this particular distinction has been shown to cause a bit of confusion because people don't generally think of ships this way. Instead, a list of ships is intuitively assumed to be a list of ships, and when this list turns out to be “incomplete”, it raises eyebrows. Initially, this ship list also didn't feature the full set of functions you normally expect from a ship, and you had to go to the actual ship hangar to activate those functions. This confusion led CCP RubberBAND to ask “Why are so many people intent on interacting with items via the tree view and not via the ships window properly?” The answer to this question is fairly obvious and it also perfectly sums up the fundamental issue with the new UI: people try to interact through the tree view because it's already there — it's immediately available. The reason you want more windows rather than a single one is that more stuff is immediately available.

What the unified inventory does is give an illusion of immediate access, but in reality, that access requires more clicking around than the old system did. You do not actually have access to more locations — you have access to one inventory location, and a tweaked method to switch between different inventories. This tweak is occasionally quicker than the old one, but equally occasionally, it's slower because it requires you to scroll through and unfold lists of available containers, whereas in the old system, there were direct-access buttons.

Solutions?

So what is needed to solve all of this? Both the test server thread and the dev blog feedback thread feature long lists of ideas, and they all boil down to versions of having multiple locations open. Some toy with the idea of having split or dual-pane views, similar to advanced file managers such as Total Commander or PathFinder (common “upgrades” from the Windows Explorer or OSX Finder, which the unified inventory tries to emulate). A lot of ideas hinges on the ability to set up fixed windows and have them remember their settings from one session to the next.

My preferred solution is a bit more complex. What I would like to see is the ability to set any kind of container or category as a “root object” for an inventory window, and then have that window remember its settings (or, rather, among the window's settings, it also remember which is its root object). For instance, I could create an inventory window and assign it to the “ship” root object. Any ships I have at my disposal and nothing else will now be available in this window and in its tree view, effectively replacing the stacks of ship cargo holds I currently use. I can even go further and assign “current ship” as the window root, at which point no other ships in-station or in a POS array will show up — only the ship's drone bay/ore bay/corp hangar bay/etc will show up. Likewise, I could set up a “station” window, that only shows the inventories that are available in a station: my hangar, my corp hangar, my corp deliveries (which shouldn't be a sub-category to the corp hangars due to the bug mentioned earlier), etc.

This might also open up for a solution for the problem of what opens up where: if I have designated a window as holding the “cargo can” root object, any cans I open will show up here (after the system has automagically figured out that this would be the window where can is as close to the top of the hierarchy as possible). It might also allow for a closer integration into the NeoCom: the ability to create and assign NeoCom buttons to specific root objects and thus let the user (re)create the direct-access buttons that we currently have for things like the item and ship hangars and the corp hangars and deliveries. For logistics (as in transportation) pilots, this could give them instant access to that special station warehouse inside the specific corp hangar division where people dump stuff they want moved.

FTL;DR: The new unified inventory is a very nice update, both visually and functionally, to the management of large piles of items, but it is only a framework. On top of this, CCP now needs to build an inventory management system that doesn't try to unify fundamentally different types of inventories, and which offers the same kind of flexibility and customisability as the old system did. With one week left until the release of Inferno, it will not happen, but it really needs to…