I think the initial interface should not require the use of nested folders. I'd rather have a dialog that listed all my outfits and had buttons with the common operations to perform on each one. Creating nested folders is an advanced user operation.

Witness Microsoft and Apple's recent Save As... dialogs. Apple defaults you to selecting a name for the file and one item from a menu of recent destination directories, defaulting to the Documents folder.

James Linden 16:40, 12 March 2007 (PDT)

UI Inventory Design

Here we can toss ideas around without having to edit the considerable work that has already gone into the article. Feel free to add your own comments below, but also please leave others alone so we can collect a variety of opinion. Also please keep individual posts brief and on the topic.

Ronor Beck

Personally, I've worked with huge mesh, texture and script inventories for many years as a 3D modeler and Poser developer. We all go through phases where we get one bright idea after the other about how to manage the ever-growing inventories. In the end, it all comes down organizing folders, reasonable file naming and having a few simple tools to make the process as efficient as possible. It is a case of Simple Is Better in the long run for both experts and newcomers.

The tools I use constantly in managing my libraries are 1) Duplicate Finder 2) Smart Search (with filters and wildcards) 3) Batch Renamers - that's about it. No fancy database managers, gizmos or auto-this-and-that because even though we are lured into trying them, they just lack the flexibility and simplicity to use on a daily basis.

Translating this to Second Life should be fairly simple. Adding a good duplicate finder would be extremely helpful - especially one that could search UUIDs for duplicates as well as the file names. I know we all have several versions of the same object with different names that we would like to track down and group or delete. Second, a more powerful "Advanced Search" capability would also be tremendously helpful - even just to limit searches to specific folders and (optionally-at user discretion) sub-folders. Beyond that - the ability to add keywords to files would be a giant leap toward organization - folders alone don't do the job (which is why I use a Re-namer to append keywords to a file name that becomes searchable).

Above all, we should resist the temptation to implement any sort of imposed "default" structure on a user's files or any "auto-sort" processes. - let the user define his/her own priorities and structure because there is no common denominator and no two users have the same file requirements. I think the idea above is exactly the type of thing that sounds great on paper, but in the long run just becomes another limitation for which people will find a work-around.

I like the "advanced search", possibly merged with the "filter" functionality. I still think search amd filters at least need to go into tabs. -- Argent Stonecutter 09:07, 13 March 2007 (PDT)

Strife Onizuka

A flat view of my inventory would be good to start with but as the inventory fills up it should change modes. When the user has say 15 items, it asks them if they want to switch to the more complex interface. Asking again at 25, 40, 60, 80, 100, 150. At 200 it switching over automatically.

The idea of having containers is a good one but too ridged when it comes to outfits. Outfits are currently sold with multiple parts for the same location; allowing for different looks. So a top and bottom set may come with a skirt, jacket, two shirts, pants, short-shorts, and socks. It is not intended that the user wear all of those at the same time, they are multiple outfits that share common parts. Selling outfits this way makes sense.

Outfit container
- Has a default Style attribute
- Can contain multiple styles.
- When a user wears an outfit it pops up a box saying what styles it contains
  - If the user has never worn the outfit then the default is selected
  - If the user has worn the outfit the default is at the top of the list but the last style worn is selected.
  - Each style can have a preview image/texture, this would be a static texture associated with the style.
  - Buttons to specify if it should replace, overlap, or augment, existing styles worn.
    - Replace: remove all existing an only use those in the selected style
    - Overlap: wear everything in the style but do not remove pre-existing items.
    - Augment: only wear items in the style that do not conflict with items already worn.
- When the user right clicks on their av there should be a menu containing outfits worn, when an outfit is selected, it brings up it's Outfit window like when it was worn.
- It should be possible for the user to wear multiple outfits and specify which ones have priority to attach objects and clothing.
Style object - a list of attachments and clothing to wear if the style is selected
- The attachments, clothing, etc associated with the style must be in the inventory.
  - Styles in outfits can only reference items in the outfit inventory.
  - Styles outside outfits can access...
    - Should either be...
      - Styles in outfits and containers
      - all items in outfits and containers
- Preview image/texture/icon
- Style editor
  - Double pained
    - on left, items the style uses from the inventory
    - On right, inventory tree
    - drag and drop will work but there will also be buttons to add and remove items.
- Styles will reference inventory by hash or id (one of those); this is so items can be renamed; but it still must exist in the inventory.
- When moving a style from inventory into an outfit or container, the system will ask if the user wants to copy/move the associated items into the container as well.
- A style can reference another style even a style in an outfit.

The user should always be able to control what they are wearing at all times.

Dzonatas Sol

Instead of mandatory icons, have each item render a snapshot of itself. The camera angle at which you took the item into inventory would be the default camera angle for a still image of the item. Allow the option to let the image spin on axis, too. These would be the preview of the items in the inventory windows.
- Each preview is automatically scaled to the bounds of the object. The previews are then resolution independent. Those with high resolution don't have to squint at a 16x16 icon.
- User's won't be forced to make an icon to generate a preview -- saves production time -- saves sim/server storage resources.
- The spin of a preview will allow one to see the object completely.
- allow a the preview to zoom to a larger view on the hud

Never actually "copy" items from one inventory folder to another. Only allow a potential "copy" when one tries to rez. Instead, force copies to actually link two or more entries to the same item. (This is how unix directories work with inodes.) That way, multiple entries across folders can refer to the same item.

Allow a graphic preview only -- no text mode, and that also includes the option to switch between text only, preview only, text and preview, etc.

Allow flat textures (a presentation image) to override preview images.
- Allow an option to switch between preview and presentation image.

Combine "Sound" with "Gesture & Animations" and just call it "Expressions"
- allow a command in the chat entry "/emote tag" to instantly emote/activate/play the first expression that matches the tag
  - even if a gesture is marked "inactive", allow "/emote tag" to still emote the matched expression
    - only allow specifically marked active gestures to have active chat line commands like "/tag"
- have an option to allow enabled and disabled expressions
  - disabled expressions are grayed and do not respond to and chat line command
- allow a sequence of expressions to emote, like "/emote smile & wave" will emote both expression "smile" and "wave" concurrently
- allow a subsequence of expressions to emote, like "/emote switchdance : turnaround : switchdance"

I've got mixed feelings about the idea of 'copy' becoming 'link', because that would confuse people who edit their appearance in with one link and then find they've changed their appearance with another. I think that aliases have to be introduced carefully, but I do agree they need to be introduced. -- Argent Stonecutter 09:11, 13 March 2007 (PDT)
Copies should be the default and aliases should only be created upon request. Linking has the potential to cause users alot of grief and confusion. The user takes a copy of an attachment as a backup, having them linked would destroy the backup. New users would complain about it. -- Strife Onizuka 12:57, 13 March 2007 (PDT)

Argent Stonecutter

Here's my first suggestion: rather than creating new "special folders" in the inventory, use objects. An object could have a "container" flag, and when an object has that flag its contents can be opened in your inventory as a folder. Use specially named textures and notecards to inform the system further.

This can be implemented efficiently by making the client and server aware of the flag and create whatever cached information that the inventory database needs when the object is taken into your inventory, or by creating any in-inventory structures when it's first opened as a folder in your inventory.

There's two advantages to this. First, and a small one, it doesn't require creating a new user interface to manage this kind of object, but it doesn't *prevent* the creation of a new user interface, and allows the development of new user interfaces to go on in the client.

The second advantage this has, and it's a HUGE one, over some kind of special folders explicitly managed by the inventory with new user interfaces for configuring them is the effect it has on the user experience of someone who buys a product. If the product is a container, then when they buy it it will be immediately available to them in inventory as a special folder.

My idea on implementing styles should work well with this, I like this idea. How would it handle multi-prim containers? -- Strife Onizuka 13:01, 13 March 2007 (PDT)

Richard Linden

As implementer of most of our inventory UI, you can hate me. I do want to say that the filter UI is definitely a stand-in and not meant to be the long term solution. Most of what is documented in the wiki page matches with my original thoughts on the inventory from years ago.

I will say that the idea of "unread" items was one I fought against when we added the recent items tab, because it simply doesn't scale, and requires a lot of manual fussing just to make sure that you've manually sorted items into "processed" and "yet to be processed" groups, where "processed" has too vague a meaning to map to search queries. In the case of email, where it has a very literal interpretation of having read and possibly responded to a message, it works fine, but still has scaling issues once you subscribe to a significant number of mailing lists, blogs, and so on.

The use case we wanted to support was "where is that object/texture/thing that I was given recently". Unfortunately, we default to "given to me since I last logged on", which has limited utility. The filter system allows you to specify a date range, but it is cumbersome to use. My ideal would be a logarithmic slider visible at the top of your inventory (in some sort of drop-down ui that appears when filtering is enabled) that lets you set a date range from last login->today->this week->this month->etc and combine with keyword searches and so on. So, in the common case of looking for a particular object, no text entry would be required...just slide until it appears. Of course, there is the issue of having to scroll to find the thing you want, which can be addressed through better visualization, such as tiled icons, or using keywords in parallel.

Talk:Inventory UI Design