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)

Study Users

Is there a team that spends a lot of time with real users? Almost by definition, those of us that post here are not representative.

Real users, real usability studies, and real designers would help a lot. Lee Ponzu 08:51, 27 December 2007 (PST)

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.

Uploads

This idea has been kicking around in my head for a while now. Instead of having to upload an asset and then find out if it works, the upload folder would serve as an intermediate solution. Anything in the folder would be stored on the users computer and not incur an upload cost. They could then be used in-world as if they existed (but would only be visible to the creator). This way animations and textures could be experimented with, without filling the asset server with those experiments and saving the user L$. All this could be achieved by putting the assets into the client cache. This would also give an inroad for developing an integrated animation editor for SL. Full permission assets could be moved to the upload folder for editing. Items in the upload folder could then be moved into the main inventory, and at that time would incur the upload cost. A range of UUID's would be reserved for Upload folder assets so they could be filtered and not create hits on the asset server.

Integrated Animation Editor

Need I say more, it needs to support every feature of the animation format. It would have two display modes, a dummy display (like used for uploads now) or on the av in-world. The in-world display mode does not require the avatar to be standing (this way animations could be designed for furniture and perfect while the avatar is sitting on them). Animations would be saved back to the Upload folder (or appropriate sub-folder in the upload folder).

Key Frames
Priorities
- Bone Priority
- Emote Priority
Emote
Hand Style
Base Position
Bone Rotation
Time
- Loop Begin
- Loop End
- Length

External Application Integration

Assets in the Upload folder could be exported and opened by external applications and saved back into the uploads folder. Additionally assets could be associated with files on the disk so that those files could be edited and then imported into SL (so if you have a Photoshop file with multiple layers that file can be associated and opened instead).

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)

Probably only look in the root, like when you "Open" an object in-world. -- Argent Stonecutter 07:47, 26 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.

You could copy Apple's "Time Machine" interface? (just kidding) I like the addition of tabs, and I do think 'since login' is probably the ideal default. I just think that they shouldn't be limited to "Recent Items". How about this: right click on a folder and select "Add tab"... and that folder would become the top level of a new tab. Then add "save filter as tab", "save search as tab" and "delete tab" to the inventory window menus... and the tabs would immediately become a huge new capability.

Search for "(worn" and save as tab, and no you have a tab you can click to to show you what you're currently wearing.
When you're organizing a folder, make it a tab, drop stuff onto the tab to drop it reliably into that folder. Argent Stonecutter 14:53, 31 December 2007 (PST)

Draco18s Majestic

I have few opinions on the ideas presented, but the "tags are the description feild only replace the spaces with commas" doesn't sit well with me. Mainly because a description is more than a series of word-tags. "A large dragon avatar" description would convert to a series of tags, only two of which actually make sense: "dragon" and "avatar." Large is an ajective that doesn't have any relevance until you pair it with another word, a tag like "large dragon" or "large avatar" and "A" has even less use. Another bad conversion would be something like "This is a replica 1920s Ford Model T." Subsequent bad tags: "This","T","a","Model","is","1920s" I believe that there are even scripts out there that modify the description (and retreive it) to store significant quantities of data (about 1023 characters worth), mucking about with spaces and commas might impare these scripts. I think description and tags should be separate entities, one becoming the other only when the other is absent.

illovich Psaltery

I agree with the posts that stress UI simplicity and lack of bloat.

My main suggestion would be that it would be much easier to organize an inventory with a lot of items with any (or all) of the following Folder UI standards:

Being able to open two inventory windows at once, or being able to open sub folders in their own windows
A dual-pane/ "Windows Explorer" type view (folder structure on one side, current open folder on the other)
A "Send To (location)" right-click contextual menu item (should be customizable, but have the normal Body Parts/Clothing/Landmarks/Objects/Textures/etc. folders as a default) for both inventory and objects that an avatar has rights to pick up (so I can pick up something and "automatically" send it to a subfolder in my inventory, not necessarily the "Objects" folder

Additionally, it would be great if there was a way to route things to a specific folder via LSL, like add an optional switch to LLGiveInventory that would allow an item to be put in a sub-folder automatically (i.e. a folder of jeans would be copied into the Clothing folder, not the Inventory root.

Other thoughts:

A duplicate finder would be awesome.
It would be nice it Outfits (saved as a folder in Clothing) could alias no-copy items so that if I buy a no-copy hair style or hud I could easily include it in multiple outfits.

A paper doll window that showed what you were wearing would be nice (even if it was really just an outline, and not really in the "paper doll" style
If objects that will automatically attach somewhere when worn (like I buy a prim-hair, it's an Object -- but if I wear it, iot attaches to my skull), it would be nice if the properties contained that information

It would be great if an object could be marked as a "container" when that's all it is, and it woudl simply behave as a folder in inventory view.
On that note--it would be great if all objects were that way in inventory (permissions permitting)

Talk:Inventory UI Design