The new Expanded Inventory View design

[Yunuen]

They could do a compromis version:
- small (1 block for each per page; all in all 4 pages) [current "small"]
- middle (2 blocks for each per page; all in all 2 pages) [current "big"]
- big (4 blocks for each per page; all in all 1 page) [old "big"]

I wish they had done something like that instead. I really liked seeing my entire inventory all at once. I don't like smaller views because it feels so cramped, but I'll just have to get used to it for now lol.

[Santherelle]

Found this on the Japanese Forum

(auto translated)

Hiroshi_Minagawa
Dev Team
Hiroshi_Minagawa's Avatar Join Date

Hello, this is Minagawa in the UI section.

Many opinions and requests from you,
A) "I want you to be able to select by leaving the traditional display"
　* Including "I want you to return to the previous display"
B) "140 items of 10 x 14 with one tab I want to display "
I will answer about two of the above.

A) very difficult for, uneasy you but revert to the previous display, or
　 there are no plans to add a display of choices.
　 I will explain what is difficult next.

B) is planned to be added in the future as a dedicated option for PS 4 version, Windows 64 bit version.


※ following, we will explain why, but
　if you know the conclusion reason (excuse) is unnecessary, is not the content of the problem I am skip anyone who wants.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
￭ why it is difficult to revert to the previous display?
The history of changing the display of items this time goes back to the
time of development of the extended version 4.0 which increased the number of items possessed and
the UI design of the old new version.

The
following two ideas were considered when renovating to increase the number of items possessed by player characters in Enhanced Version 4.0 .

Proposal 1. Handling 25 items as one group
　　　How to increase from 4 groups to 6 groups (150 items) while maintaining the conventional database configuration .
　　　If there is no problem on the load, it is assumed to increase by group.

Proposal 2.1 How to increase the number of items in the group itself from 25 to 35.
　　　If there is no load problem, we assume that we will increase the number of groups.

Thinking normally, I think that it is determined by "plan 1".
With this addition method, you should have had no sense of incongruity.

Originally, at the UI design stage of the new-generation version, the number of item holdings is increased by 25 units. In
the concept screen shot at the time of announcing the new version ,
we published 25 screens of 6 groups screen
, In
order to promote implementation as fast as possible while raising the use efficiency of the data storage area for items during development, it is
necessary to add items attached to the moogretter and a temporary item storage area at the time of trade after the area where player items are stored
It was decided to install it continuously, and to implement item related processing and storage area collectively.

This will affect (now).
As compensation for capacity efficiency and development speed, it became difficult to add belongings on a group basis.

As for how difficult it is, you
will need to modify functions (such as Moglets and Trades) that appear to be irrelevant to the addition of item holdings (rather than remaking).

In case 1,
because there are many functions that the engineers widely involved in the extent of influence due to addition are handed over and there are many functions that are handed over from the original program personnel,
unless we actually start the revision work, how much development time It
was an opinion that it is difficult to estimate whether it is necessary . (Concern that it will not be in time for the release of the extended version is strong)
On the other hand, Proposal 2 was clear in man-hour estimation.

As a result, we abandoned "plan 1"
to increase the number of groups and increased items in the extended version 4.0 with "plan 2" which increases the number of items in one group.


When the extended
communication version 4.0 was released and the communication load of the server was counted with the
number of possessed items increased,
we also found that if the number of items possessed is increased and the data of the character increase, the server can not tolerate traffic .

Therefore, addition of possession of the PC and the possession of the army chest is switched
to the
policy of enlarging version 4.0 as the last , increasing the number of items possessed by another method, and converting the item to another format and saving it.
※ This is a chocobo bag and dresser related function that was implemented this time.

　+ + + Although the

introduction has become longer, based on the above circumstances
I will explain "Reason for changing the display method" and "Why it is difficult to return to the original display".

As we adopted plan 2, at the time of 4.0, the display on the application side and
the management method for the item information on the server side were not engaged, but
as a temporary response until the additional policy of item holding number is determined
, I was overwhelmed with a program to tailor it.

It is
very difficult to add item related processing as it is with such a program, and the stability of the program can not be secured.

Therefore, in order to arrange
the display method of the application to the configuration contents of the changed database in order to increase the number of items, and to
organize it once in a program that is easy to expand in the future, we carried out this renovation.

For such circumstances, revival is difficult in the conventional 5x5 display
has to answer for disadvantage after the correspondence is as large as, "There is no corresponding schedule."
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
￭ expand: the 140 items for batch display
We are thinking that this can be added as a dedicated setting for PS 4 version and Windows 64 bit version.
Windows 32bit version, Mac version can not cope because the UI memory required for icon display is insufficient.
However, since difference processing is added for each OS,
please wait as we need more time than adding a normal function .
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

or more, will be the description of the display change of this belongings widget.

Although it is very hard for me to become inconvenient due to familiar operation and change of display,
I think that it is necessary to add various functions from now on and decided as lead UI.

I think that there are also people who can not be convinced, but I thought that the
development side would like to tell you what additions and changes of functions are being
done.

I would be pleased if you continue to give us your feedback.

[Altena]

My favorite part is the 105 Key Item slots we have now.

I ranted to my FC about this the moment I logged in..

I have a whopping 3 key items. None of which I even need to hold on to.
I don't think I've ever broken 10 KI's at one time..

If they can afford to give us this many slots for KI's, why can't they afford to replace 50 of these slots for regular inventory slots?
Hell.. If KI's are so important, just let them overflow into my main inventory if I somehow manage to hit 50+ KI's...

[Krotoan]

Found this on the Japanese Forum

(auto translated)

interesting. So there are "chunks" of inventory and the server reacted poorly to larger chunks, so they pared it to more chunks and swapped some over to a whole new way of saving it in the dresser and the chocobo bag.
looks like the UI is a problem in mac and 32 bit clients too.
Nice to have some insight.

[Zhexos]

Greetings,

We'd like to share a comment from Hiroshi Minagawa from the UI team in regards to the inventory display adjustments made in Patch 4.2.

Greetings, this is Minagawa from the UI team.

I'd like to discuss the two big requests we've been seeing from the community:

A) Keep the previous expanded display method and make it available as an option.
* Including requests to revert back to the previous display method.

B) Make the expanded inventory display as a single tab 10x14 (140 total).

Option A would be extremely difficult to do, so I'm sorry to say that there are no plans to revert it or make an option to choose. I'll explain the reason why it would be difficult in a moment.

As for option B, we're planning to implement this as an option for the PS4 and Windows 64-bit version.

* I'll go over the reasons below; but if you only want to read the conclusion, you can skip over the following section.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Why is it difficult to revert to the previous display method?

The reason behind the new item layout goes back to when we expanded the inventory slots during 4.0 development, and goes even further back to when we designed the UI for the A Ream Reborn (ARR) version.

When we considered increasing the a character's inventory slots, we looked into the following two methods:

1. Keep the previous database which treats 25 items as one group, and increasing the number of groups from four to six (150 items).
2. Increase the number of items in a group from 25 to 35. If there's no stress on the load, assume we can increase the number of items available in one group.

I imagine everyone would agree that the first method is the way to go, as it would feel most natural for everyone.

During the structure development for the ARR version, we had planned to increase item slots in increments of 25. When we announced ARR, the concept screenshot showed six groups of 25. However, while ARR development continued, in order to speed up development as much as possible (while also increasing the efficiency of the save data storage) we incorporated temporary item storage (i.e. items attached to Moogle letters and items for trading with others) into the player's storage capacity to implement item-related processes and storage capacity together.

This ended up affecting us later (now). At a cost of development speed and space efficiency, it became difficult to add inventory slots in groups.

It became difficult because we need to fix (more like rebuild) features such as the Moogle letters and trading, which doesn't seem like it would be related to the addition of inventory slots.

For the first method, the parts that are affected are numerous, and the engineers involved are different, and there are many features which carry over from the original program. For this reason, we needed to actually try it out to estimate how much development time would be required for this. (There were strong concerns of this not being able to make it by the expansion's release.)

On the other hand, the estimate for the development steps for the second method was much clearer.

As a result, for the 4.0 expansion, we abandoned the first method to increase the number of groups, and decided to go with the second method, to increase the number of inventory slots available by increasing the number of items per group.

Once 4.0 went live, we calculated that the server couldn't handle the amount of communication stress that the additional increased inventory slots and character item data brought with it.

Therefore, we switched our direction to adding other methods to increase the inventory, or by converting items to a different format to store them, and stopped adding spaces to inventory and the Armoury Chest with the 4.0 expansion.
* Methods such as the chocobo saddlebag and glamour dressers.

　＋　＋　＋

The introduction was a bit lengthy, but with the above in mind, I'd like to explain why we changed the display and why it is difficult to revert back to the previous method.

Because we applied the second method, during 4.0 the item information managed on the application side display and the server did not match; however, as a temporary measure until we decided how to increase additional inventory slots, we used a program to maintain the consistency of the display to make it work.

It is extremely difficult to keep using such a program to add item-related processes as we wouldn't be able to ensure the stability of the program.

So this time we made improvements and have matched the display method for the application into the database structure which was changed to increase the number of item slots, and made improvements to temporarily arrange it so it can be used on a program which can be easily expanded in the future.

Due to these reasons, it would be difficult to bring back the previous 5x5 display as there are numerous negative consequences. This is why I mentioned we have no plans for this.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Expanded Display: Displaying 140 items at once

We believe we can do this for the PS4 version and the Windows 64-bit version and we are looking into it. We cannot do this for the Windows 32-bit version or the Mac version, as there isn't enough UI memory required for displaying the icons. As this requires a different process for each OS, we would require more time than usual for when we add new features, so if you could please wait for this.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

And that is the explanation as to why the expanded inventory display method changed.

I'm very sorry that this has caused an inconvenience for things that you have long since grown accustomed to, or how it was displayed. However as a UI Lead, I made the decision to move forward with this, as I believe this was required in order to continue adding various features.

I'm sure there will be those that won't agree with this explanation, but I wanted to explain the thought process from the development team's perspective for features being added or changed.

We'd appreciate it if you all to continue to leave your feedback.

[Tint]

We believe we can do this for the PS4 version and the Windows 64-bit version and we are looking into it. We cannot do this for the Windows 32-bit version or the Mac version, as there isn't enough UI memory required for displaying the icons.

HAA!!!

PC limitiations confirmed! ^___________________^

[Callinon]

Total insanity

I cannot imagine the level of spaghetti code you guys must be dealing with to arrive at an explanation like that. My inner programmer has, in fact, curled up into a ball and is in the corner sucking his thumb. It's not pretty.

It does seem to re-emphasize the need to correct the underlying issue though. Your original database design was pants-on-head and that needs to be fixed. I appreciate the position you're in now having to work on a live product with this kind of design handicap, but that's the reality you're living in and if you ever want to make it to 7.0 you're going to need to address this sooner rather than later.

In the meantime I'll definitely take displaying everything on a single pane. I don't like tabs. After that, I recommend drinking.. a lot.

[Vaer]

interesting. So there are "chunks" of inventory and the server reacted poorly to larger chunks, so they pared it to more chunks and swapped some over to a whole new way of saving it in the dresser and the chocobo bag.
looks like the UI is a problem in mac and 32 bit clients too.
Nice to have some insight.

They wanted to add another 2 bags after the 4 bags we already have, but when they were making ARR to save time they appended other item data (temporary trade data, mog mail items) after the 4th bag.

To add the 2 more bags they wanted they would have to deal with all the other item data that is being stored after the 4th bag (according to this they would have to modify that block and get the original programmers on board).

Instead of wasting more time and resources doing that, they just increased the size of the 4 bags we already have by 10 slots. They then used some code to sort and parse the display of the 40 extra slots since the UI was still in groups of 25 instead of the new 35 in 4.0. (I guess this is why it looked like they just glued 40 slots to the end of the inventory)

In 4.1, they redid the UI to match the new 35 items per group and split it into 2 tabs to accommodate older OS and want to add 4 groups to one page for the OS that can handle it.

[Syrehn]

Snip.

That wall of text though... it's blowing my mind that the underlying code is so terrible. Also, regardless of the reasoning I still hate, loathe and despise the new "expanded" view. It's not even remotely expanded at all.

Put everything on a single plane and get rid of the 2 extra key items bags. Like seriously, why would we ever need that many key items. Actually, better yet, turn them into additional bag slots instead since they're already there.

[drebbe]

I cannot imagine the level of spaghetti code you guys must be dealing with to arrive at an explanation like that. My inner programmer has, in fact, curled up into a ball and is in the corner sucking his thumb. It's not pretty.

It does seem to re-emphasize the need to correct the underlying issue though. Your original database design was pants-on-head and that needs to be fixed. I appreciate the position you're in now having to work on a live product with this kind of design handicap, but that's the reality you're living in and if you ever want to make it to 7.0 you're going to need to address this sooner rather than later.

In the meantime I'll definitely take displaying everything on a single pane. I don't like tabs. After that, I recommend drinking.. a lot.

Basically this comes down to SE needs to hire more people to make up for the spaghetti code. Making a design decision due to lack of resources is sad (This happens all the time in software dev).