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.
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 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:
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:
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.
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:
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.
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:
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.
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…