Difference between revisions of "Talk:Inventory UI Design"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
__NOTOC__
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.
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.


Line 5: Line 6:
[[User:James Linden|James Linden]] 16:40, 12 March 2007 (PDT)
[[User:James Linden|James Linden]] 16:40, 12 March 2007 (PDT)


'''Open Discussion - UI Inventory Design'''
=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.''
''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.''


Submitted by Ronor Beck:
<div id="box">
== [[User:Ronor Beck|Ronor Beck]] ==
<div style="padding: 0.5em;">
 
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.
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.


Line 17: Line 21:


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.
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.
------------------------------------------------------------------------------
 
</div></div>
<div id="box">
== [[User:Strife Onizuka|Strife Onizuka]] ==
<div style="padding: 0.5em;">
 
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 while wearing an Outfit, there will be a menu somewhere to select the Style
**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 same inventory scope.
***They must be in the same folder as the style or in the same Outfit.
**Preview image/texture/icon
 
The user should always be able to control what they are wearing at all times.
 
</div></div>

Revision as of 00:30, 13 March 2007

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.

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 while wearing an Outfit, there will be a menu somewhere to select the Style
    • 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 same inventory scope.
      • They must be in the same folder as the style or in the same Outfit.
    • Preview image/texture/icon

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