One Step Forward, Two Steps Back

There is this old joke about the kid that, upon arriving late at school, was stopped and scolded by his teacher for his tardiness. Instead of being contrite, the kid said to the teacher “you should be proud of me instead of being mad.” When the teacher asked why, he replied “because when I left home today, every step forward I took, I fell back two steps.” A bit amused, the teacher inquired as to why she should be proud of him for that. To which he replied “because I was smart enough to turn around backwards … and thus gained a step in the right direction all the way here.”

CommerceTeam Linden (the designated functional for LL that speaks via the Second Life Forums on all matters related to commerce in Second Life) recently announced a new feature they were planning to release soon called “Received Items”. I’m quite sure they expected people to respond with some measure of acceptance or at least not burn down the barn, but that is not what happened. Shortly after posting the announcement in the Merchants Forum, the Merchant Community as well as some non-Merchants stormed the gates of the LL Castle with pitchforks and torches ablaze. You can read the announcement and the public reaction in the Forum Thread here.

(Fair Warning – This post contains some fairly technical descriptions. I’ve done my best to make them understandable to those that don’t dream in hexadecimal, but you have been warned. I will not be held responsible for any brain leakage that occurs. Also note this post is this year’s sure-fire winner for the “tl;dr” category … hands down.)

The Why-For of the Received Items Folder

Coming Real Soon Now is possibly the biggest and most technically challenging change in the commercial function of Second Life. It’s called Direct Delivery and it really has the potential to be a massive improvement in how the SL Marketplace offline shopping site works. Considering how badly the Marketplace was developed and released, and in light of the fact that none of the promised improvements have ever materialized, and furthermore considering that so far they’ve not managed to pull off any sort of upgrade without seriously borking the entire market, Direct Delivery also has the potential to deal a near-death blow to SL Commerce in general and offline shopping in particular.

In short, Direct Delivery eliminates all the interlocking processes that must work properly in order for a purchased item to make its way into the Customer’s Inventory. Instead of using a Magic Box to send the item using the standard In-World function (llGiveInventory), Direct Delivery is supposed to perform a simple database copy operation to place the item directly into the Asset Server’s record of the Customer’s Inventory. This has two really excellent benefits: 1) The KISS Principle applies by removing a lot of unnecessary steps in delivering the product, and 2) It will work even when the Customer is not online at the time the purchase is made.

But the kicker is that the Commerce Team couldn’t stick with KISS in order to make this work. No, instead they have found several ways to totally complicate the issue and in the process have involved a few other development groups in LL as well. (I knew there was a reason I didn’t like the 10+ months of development this change was taking … I just KNEW IT!)

The Received Items Folder

One of the biggest fears voiced by the Merchant Community was the fear that Direct Delivery, suddenly being granted access to add items to our personal Inventories, was that Direct Delivery would in short order perform massive (and unfixable) digital lobotomies and totally destroy the years of hard work and investment that is embodied in our Inventory. To their credit, the Commerce Dev Team listened and changed their target specification for DD to deliver the items into a new and totally separate folder tree called “Received Items”. Yay! One step forward.

But instead of stopping there and leaving the purpose of the Received Items folder as used only for the delivery of purchased goods from the SL Marketplace, they realized that the ability to receive items even when the recipient was offline could be useful for lots of other “issues” that have plagued Second Life for some time. Before long the Received Items folder had grown into a totally overloaded and illogical beast. That beast is rather poorly described in the Received Items Beta Launch blog post here. *SIGH* Two steps back.

What Gozinta – Version One

The details  that caused immediate negative response from the SL Community are somewhat poorly described in the Wiki article posted at the same time as the blog post. I’ll copy them here as well:

  • Anything new to your inventory that you Take or Take Copy.
  • Anything you rezzed in someone else’s parcel and they have Returned.
  • Inventory offers from other users.
  • Inventory from scripted objects.
  • Marketplace purchased items.

As you may notice, the original purpose (items purchased from SLM) is last on the list. It worries me when a spec like this puts the original intended purpose last. That indicates that the project has not only suffered “Scope Creep” (grown beyond its initial goals), it has suffered Scope Nuclear Detonation. Let’s examine each of these new added functions in a bit more detail.

Anything new to your inventory that you Take or Take Copy

Under the existing system when you Take an item from In-World, if it is an object owned by you (such as a build you are working on or anything else that you placed there yourself), that item goes back to its original source folder. If you’ve deleted that folder for some reason then the object will wind up in your Objects folder. When you Take Copy, since you are making a copy and then putting that into your Inventory, it doesn’t have an original source folder and thus will wind up in your Objects folder. (I’ve always felt that the Copy operation should also copy the original source folder too, but that’s another matter.)

Under the new RI Scheme, these two events result in the object being placed in the RI folder. Double-Holy-Ugh! This means that every time you put a build away for safekeeping (like at the end of a build session for example), you will have to go dig it out of the RI folder and drag-n-drop it back to its original location. This is not so bad with the Take Copy function as you have to go “rescue” it now, but the number of times you Take something back turns into a 2-step process instead of the simple 1-step now.

The only way to do this effectively is to open a second Inventory window so you can quickly drag it back out of RI from one window and drop it into the proper location in the second window.

Anything you rezzed in someone else’s parcel and they have Returned

Currently anything Returned to you (whether you are online or offline) will be placed into your Lost and Found folder. You are then notified of this event by an IM sent by Second Life. The Lost and Found folder is sorted by Date/Time (normally) thus it’s pretty easy to find the items at the top of the folder list and drag-n-drop them back where they belong.

The Received Items folder will be the new destination of these items. Not only does that mix them in with all the other “stuff” that shows up there, but the RI folder appears to be sorted alphabetically. This means it is no longer easy to find them in that (soon to be) massive folder, but apparently they were planning to ax the IM notification, further complicating your task of Inventory management by forcing you to periodically scan the folder to see if anything showed up that might be a returned item. *facepalm*

Inventory offers from other users

When someone offers you an item In-World now, if you are online you get an IM and a dialog box that allows you to Keep, Discard or Ignore. When you are offline, the IM is sent to your email (if you have that option set, and if you don’t have it set, you really should). The next time you log on, you get the dialog box … but only IF your IMs aren’t capped. If your IMs are capped then the item simply vanishes and you have no way of accepting it. This is only a medium level annoyance with copyable (read easily replaceable) items, but it’s a total nightmare with non-copyable items; the sender doesn’t have it anymore but neither do you.

This is one of the faults of the existing system that makes sense to route to the Received Items folder, but only if you are not online at the time the inventory offer is made. If you are online then the process should behave as it does now. However with the new RI process it doesn’t matter if you’re online or offline; every inventory offer goes into Received Items. However it’s unclear when and if you will receive the dialog box. (My assumption is that the dialog box will appear when you log on only if your IMs have not been capped.)

Inventory from scripted objects

This is the method that the existing Magic Boxes use to deliver items purchased on the SL Marketplace. In short, it behaves in exactly the same manner as if a user offered you an item. The fact that a purchase can vanish into the digital ozone is one of the most common complaints about the whole process. Even though the Checkout page on the Marketplace warns you to make sure you are online before completing the purchase, very few do. If your IMs are capped, your purchase vanishes and you’ll have to contact the Merchant to send you a new copy or wind up filing a Support Ticket. If it was a copyable item, your chances are pretty good at getting the Merchant to replace it, however with non-copyable items the Merchant is never sure if you truly didn’t get it or if you’re just trying to scam them out of a second copy. (This happens a lot, so don’t get upset if the Merchant is less than anxious to replace the item. You’re best bet is to just file a Support Ticket with LL if you lose a non-copyable purchase.)

The process for filing a Support Ticket to get your lost item replaced is detailed in the post on the Forums titled Best ways to contact the Commerce Team under the heading “Submitting a Customer Support Ticket”.

As with inventory offers from users, under the new Received Items scheme the items will always go into the RI folder. Even when you are online, you will still have to find and drag-n-drop them out of the RI folder to put them into the proper folder. However the dialog box handling is still a bit unclear, so again I’ll make the assumption that it will work like other inventory offers; the dialog box appears if you are online or when you log on and your IMs are not capped.

Marketplace purchased items

At present, Marketplace purchases are nothing more than inventory offers from scripted objects. Since the Received Items folder was dreamed up especially to handle Direct Delivery, this is something new that doesn’t exist now. With Marketplace purchases, the purchased item(s) will be placed into a sub-folder under the root of the RI folder. The new folder will have the same name as the product listing on Marketplace, so it should be a bit easier to find it. I am not exactly sure how the Accept Inventory dialog box will be handled. The original description of how DD will work contains some information on the way that Received Items will work, but you will have to read the Knowledge Base article – Second Life Marketplace Direct Delivery FAQ for the full details.

My Proposal – Received Items Folder

I think part of the problem that LL faces is they are not routine users of Second Life and thus don’t have a lot of working knowledge of the tool’s use itself. Since I’m also a systems designer (and constant busy body with an over-inflated ego LOL), I’ve decided to lay out my approach to the issue. After my long-winded System Description, I’ll dive back into LL’s latest proposal for the RI folder and talk about how it will work.

The Original Problem

Anytime an extensive development project goes off the path, suffers Scope Creep, or just needs a bit more focus applied, it is always best to revisit the original problem that gave birth to the project in the first place. In the beginning, the Direct Delivery project (and thus the Received Items folder) was created in order to solve two problems: 1) Eliminate the complicated machinery between the Merchant’s inventory and the Customer’s inventory when an item is purchased from the Marketplace, and 2) Eliminate the delivery problems that occur when a purchase is made while the customer is offline. Solving any other problems with Direct Delivery and the Received Items folder, although possibly beneficial, should not be allowed to dictate the features and functionality of the project. However in this case, that is exactly what has happened.

(I haven’t mentioned it so far, but the Received Item folder has even been cited by Oz Linden in the other nuke dropped on users recently regarding disabling the LSL function llRequestAgentData that detects if a user is really online … even when they mark themselves as hidden. You can read up on that “Disaster about to happen” in the related JIRA Issue.)

These two problems are somewhat related, but of the two it is my opinion the most annoying one (and the one that needs fixing most of all) is the delivery to offline users. Since the inventory delivery depends on the Accept Inventory dialog box being displayed and completed, if there is a problem that prevents this from happening, the entire delivery process goes into the dumper. That’s a big problem not only with Marketplace, but with every Merchant delivering updated products, friends sending items to friends, and many other common and very important instances. Being able to give inventory to someone even when they are offline and being assured that they will get it no matter how deep their offline IM stack has grown would be a VERY big improvement to Second Life.

The Deciding Factor

How new items arrive in the Received Items folder depends on one deciding factor; whether the user is online or offline. When the user is online at the time of arrival, the process should appear very similar to the way it appears now. However when the user is offline, the process has to change a little bit, but those changes won’t be difficult to implement or understand.

Received Items – User Is Online

When the user is online and a new item appears in the Received Items folder, the user should see a dialog box to alert them of the arrival. However the dialog box will have additional options that will greatly ease acceptance and proper filing of the new item. The dialog box will appear slightly different depending on what is being received as well.

Received Item is a Folder of Items or a Marketplace Purchase

When the received item is either a folder of other items, or is a purchase made on the SL Marketplace, the dialog box should have the following options:

  • Keep – The folder stays in the Received Items folder and is marked as having been “Accepted”.
  • Keep and Move To Inventory – The folder is kept and is automatically moved to the Inventory root so that it becomes a new top-level folder (just like happens when you open a box In-World and then use the Copy To Inventory function now). The folder will not remain in the Received Items folder.
  • Reject – The folder will be discarded, however it should only be discarded after the user answers “Yes” to a secondary “Are You Sure” dialog box prompt. (This secondary prompt is new and should be added to help prevent accidents.)
  • Ignore – This option will only appear if the source giver is not the SL Marketplace. (You shouldn’t be allowed to ignore the Marketplace.) The item will be discarded and the Sender will be muted (ignored). The item should only be discarded after the user answers “Yes” to a secondary “Are You Sure” dialog box prompt. (This secondary prompt is new and should be added to help prevent accidents.)

The one new option added is “Keep and Move To Inventory”. This saves the user having to secondarily drag and drop the folder anywhere once accepted. Sometimes, especially when the user has a very large Inventory already, the drag-n-drop operation can be difficult to perform without error.

Received Item is a Basic Second Life Item

When the received item is one of the basic Second Life item types (such as an Object, Notecard, Script, Texture, etc.) then the dialog box should have the following options:

  • Keep – The item stays in the Received Item folder and is marked as having been “Accepted”.
  • Keep and Move To Inventory – The item is automatically moved to the root of the user’s Inventory. (This is not really a common choice and could be easily deleted.)
  • Keep and Move To ____ – The item is automatically moved to the corresponding item type Inventory System Folder. For example, objects would go to the Objects folder, notecards would go into the Notecards folder, etc. Automating this process will save the user a lot of extra trouble and will help prevent errors during a drag-n-drop operation, especially if the user Inventory is already large.
  • Reject – The item will be discarded, however it should only be discarded after the user answers “Yes” to a secondary “Are You Sure” dialog box prompt. (This secondary prompt is new and should be added to help prevent accidents.)
  • Ignore – The item will be discarded and the Sender will be muted (ignored). The item should only be discarded after the user answers “Yes” to a secondary “Are You Sure” dialog box prompt. (This secondary prompt is new and should be added to help prevent accidents.)

Received Items – User Is Offline

No matter the source of an inventory offer, whether from another user, from a scripted object or from the SL Marketplace, the behavior of the Received Items folder and the items placed inside should be the same when the user is offline. As of now, the inventory delivery method depends on the problematic IM function, using the IM for an item delivery as the trigger to launch the Accept Inventory dialog box. Because offline IMs have a limit before they are capped, dependence on this function guarantees that inventory offers and delivery will be just as much trouble.

Instead of this behavior and mechanism, the Received Items folder should be the initial destination of all inventory offered while the user is offline. This requires that the inventory offer and transfer mechanism be changed to “intercept” inventory offers, place them in the Received Items folder and then mark them as “Pending”. An IM should also be sent (as done now) so that users with the “Offline IMs to Email” option set will receive notification that something has been delivered and is awaiting their approval.

The next time the user logs on, the Viewer will scan the Received Items folder for “Pending” items. If any items are marked as Pending, the Viewer should notify the user that there are items pending. However it should be up to the user to process these items. When the user right-clicks on the Received Items folder itself, one of the options displayed should be “Process Pending Items”. When the process option is chosen, every item in the RI folder that is still marked as Pending should be presented to the user using the same dialog box and options discussed above in the “User Is Online” section.

When an item is in the RI folder and is marked as Pending, its name should be displayed in italic font; the names of all accepted (kept) items will be displayed in the normal font. This allows the user to quickly spot items that arrived while they were offline. When the user right-clicks on a Pending item, the “User Is Online” process detailed above should be used.

What Gozinta – Version Two

The other day, CommerceTeam Linden (by way of Dakota Linden .. ty Dakota) sent out notecards to everyone that had filled out their first survey with links to their new proposal and a new survey. The new Proposal can be seen here.

It contains some clarification on their first proposal, some changes that take into account a lot of the feedback on the original Forum thread, and overall shows they are at least trying. Kudos to the various Dev Teams in Linden Lab for that. However once again they’ve missed the mark a bit. Herewith are the high points.

  • No Change From Current Behavior: Take or take copy will go to the folder it came from. If the folder does not exist in the current user’s inventory, the item will go the Objects folder
  • Minor Change From Current Behavior: Items returned to a user’s inventory will go to the user’s Lost and Found folder AND an IM will be sent to alert the user (the IM is new)
  • Change With Direct Delivery: Items purchased (and sent as gifts) from the Marketplace will go to Received Items folder (this will always happen with Direct Delivery purchases)
  • Change In Behavior: Objects received from any other source (LLGiveInventory, shared inworld, group notice attachment, etc.) will go to the root of the Received Items folder–read on for more discussion about this.

No Change From Current Behavior

Thankfully they reversed their ideas for the Take and Take Copy operations. Since the user must be online to perform these, and since the purpose of the Received Items folder is to “catch” inventory that arrives while the user is offline, there really was no need for them to alter this behavior at all. (However I still want Take Copy to go back to the original object’s source folder and not to Objects.)

Minor Change From Current Behavior

This is actually no change at all. Returned items go into the Lost and Found folder now, AND an IM is sent to that effect. (This makes me think no Linden has ever had something returned to them … which on second thought makes perfect sense. Would YOU right-click and return something that said “WillDeleteYourPreciousAccount Linden” under the Creator name? LOL)

Change With Direct Delivery

Another Kudo for this. All items purchased from the Marketplace and delivered using Direct Delivery should always go to the Received Items folder. This is, after all, what it was originally created for. Someone looked back and got hold of the original purpose of the RI folder … and put noses to the grindstone apparently. Well done!

Change In Behavior

This section deserves a lot more description and discussion, and thankfully they’ve added more (three more pages worth). All in all, what they’re proposing seems right on the money. I’ll repeat it here:

“We are aware of the concern with sending all items to the root of the Received Items folder. Some of you suggested that if we fixed the offline delivery problem, you would be amenable to the Received Items folder. So that is what we are going to do. Objects will be sent to the Received Items folder EVEN WHEN THE RESIDENT IS OFFLINE and the Resident will be notified via IM. The objects will be sent even if the IM fails to deliver because of the IM cap.”

This is basically what I’ve proposed above with the exception that this will happen even when the user is online. I would prefer they change the behavior based on the user’s online/offline status, but it’s not a deal breaker. What IS very important is they’ve implemented my suggestion to have right-click context options that automatically move an item from the RI folder into the appropriate item type folders. For example, here is one of the screencaps where they are using a notecard as an example:

As you can see, they’ve provided not only the “Move to Notecards Folder” option I suggested, but also included the “Move to Objects Folder” option as well. While not really necessary, it’s not that annoying to argue for removal either. More kudos!

Stuff They Left Out

There are a couple of other UI enhancements that I really believe they should implement. One is the Viewer-side check for new items in the Received Items folder with the user given notification is there are new items present. Since this is purely a Viewer-side function, if LL doesn’t implement it, I’m sure one of the TPV’s will. (poke-poke-nudge-nudge Firestorm Team.)

Also missing is the use of Italic vs. Normal font to indicate an item that is new (and not yet processed) to those that have been processed. I have the feeling that people won’t always be able to completely empty the RI folder every time they’re on, so having some sort of indication (both visual and in the system itself) that an item in the RI folder has been “handled”. (It would also be very useful to have items in the RI folder sorted by date of arrival as an option.)

They’ve also done away with the “Reject” and “Ignore” options. I think being able to Ignore the sender directly from the RI folder is very crucial. If a Griefer is pounding you with objects, or just sending you annoying crap slow enough not to trigger the proposed throttle, it’s very useful to be able to mute them rapidly without having to hunt down the Creator, find their Profile and mute them from there.

Regarding the llGiveInventory throttle, I should think that 50 items per minute would be reasonable. Usually Griefers will overdo things and write a script that pummels the recipient with objects. However when updating one of my products, the various tests (for user online, etc.) make going above that rate a nice fantasy; realistic delivery of updates goes about 1 per second but only in short spurts.

Final Thoughts

So, did Linden Lab get it right? Yes, they pretty much did. They listened to the feedback (even though it was thoroughly buried under the howling screams of the community) and then they implemented most of what we told them needed fixing. I’d have to give them a passing grade while gently reminding them that listening IS a big bonus for all parties involved.

Overall their second proposal is MUCH better than their original. If you’re into keeping score, mark this one down in the “We Win!” column. As to which party is “We”, Linden Lab or the Users? I think the proper answer is:

Yes!


Visit the DGP4SL Store on SL Marketplace

Comments

6 Comments on One Step Forward, Two Steps Back

    […] DG says that the Lab did something… right? […]

  1. Nalates Urriah on Sun, 11th Mar 2012 11:58 AM
  2. It would have been nice if you had linked to a JIRA or forum discussion the Lindens are following, so we could all chime in on what else needs to be added.

    As much as SOME Lindens try to avoid getting feedback, it seems if it gets there early enough there is a chance they will use it and sometimes modify things accordingly.

  3. Darrius Gothly on Sun, 11th Mar 2012 12:09 PM
  4. @Nalates – I have dropped links to this blog post in various JIRA and Forum posts that discuss the Received Items feature. It didn’t dawn on me to reverse link them as I figured the Lindens would spot the links in their stuff and follow them here. I did link the initial forum discussion that resulted in the firestorm of responses at the top of this post though. Do you have a specific JIRA in mind?

  5. Tonya Souther on Mon, 12th Mar 2012 1:16 PM
  6. You almost got it right, Darrius. See SVC-7748 for the case that the version 2 DD proposal gets wrong. I think your original idea, that the Received Items functionality should only apply if the user is offline or the item is coming form the marketplace, is the right answer.

  7. Darrius Gothly on Mon, 12th Mar 2012 3:06 PM
  8. Yup, unfortunately I wrote this post just hours before learning of the massive borkage that the latest proposal does to the RLV market. Thankfully Sassy opened my eyes, and I’ve been active on that JIRA ever since. I sincerely hope LL does pay attention and amend the behavior to include the online vs. offline behavior. If not, oh lawdie .. it’s gonna be a blood bath for sure.

  9. Here Comes The Sun : DGP4SL Blog on Tue, 13th Mar 2012 1:08 AM
  10. […] still be in their inventory the next time they logged on. As mentioned in my previous post “One Step Forward, Two Steps Back” the specification and intended usage of that folder had grown over the interceding months […]