Jump to content

Try out the new Received Items Beta


Guest
 Share

You are about to reply to a thread that has been inactive for 4422 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Thank you both, but allow me to explain why I answered as I did. What follows is my perception of how things came to pass inside the hallowed Linden halls:

The Commerce Team undertook this monster issue called Direct Delivery because they felt that offline deliveries were the "Root of all evil" when it came to delivery problems from the Marketplace. As they looked toward a solution, they began to realize that implementing a method of putting items directly into the purchaser's inventory would be a solution with many advantages. That much is true.

However as they developed the devices and mechanisms to make this possible, the Received Items folder (being a brand new thing of inestimable value .. in the programmer's mind at least), someone realized it could also be used to solve other offline delivery problems. And again, that much is true.

But then the lack of expertise, the lack of understanding on how SL works and how people use it, and the lack of trust that exists between LL and its customers kicked in and shot holes into their grand plan.

Back when I was a Junior Code Slinger, I was smart enough to figure stuff out really fast. I was also intelligent enough to comprehend some really hairy algorithms. But I was so wet behind the ears that I rarely wrote code that was a real solution for the problem first presented. I didn't understand how to marry the needs of my "customer" with the algorithms and digital beings I could create. I would get lost in the pure act of creation and forget what I was meant to do in the first place .. fix a problem.

That is exactly what happened here as well. And the fact that I can see the symptoms of this behavior all over the face of DD and RI is why I know that LL has been employing and putting to work some incredibly new and green programmers.

Yes, they can do some neat stuff. But doing neat stuff is by no means a reason for said neat stuff to exist. LL needs to understand that the point of that code is to solve a problem. To ensure they solve the right problem, they must also understand the problem too. And so far, they do not do that reliably .. or very often.

The true problem is stuff getting lost that is sent to someone when they are offline. The problem is not stuff disappearing when you Take it or Take a copy. The problem is not scripts that check if you are online before they deliver it. The problem is that items are delivered and signaled by the same device that sends IMs .. and that device is prone to capping and planned failure which means the whole methodology is prone to failure too.

RI should be used to fix the delivery of items when the user is offline, and nothing more. The Marketplace is a perfect example because a delivery can be started by the user even when they are offline. Thus it should always go to RI. But other cases, scripted delivery and people sending you stuff they promised to give you .. those are not cases that can be started by the user, so they should be sensitive to your online/offline status and behave differently for each case. And finally, those things that you trigger yourself only when you are online .. that behavior should not be changed. It's not broken and thus should be left alone.

But this is a nuance, a seemingly insignificant but oh so important distinction amongst the cases that are present. Yet it is something that a newbie programmer and an SL-ignorant programmer would never see nor understand.

Thus, I presented my "rules" .. to show them the right path to solve the problem that really needs solving .. and to convince them to leave alone those parts that are not broken at all.

Link to comment
Share on other sites

  • Replies 225
  • Created
  • Last Reply

Top Posters In This Topic

If the problem can be stated succinctly and concisely, then the solution can be tested against that problem definition by a fairly small number of educated testers. For that Aditi or a Beta team can work. But I agree, their current definition of RI is too far off the mark to be properly implemented and tested reliably.

Define the problem. Put the problem definition into the community and ensure that all agree it is the right definition of the right problem .. and THEN start slinging code.

Anything you do to solve a problem BEFORE you understand that problem .. is just making pretty lights blink for no valid reason whatsoever.

Link to comment
Share on other sites

Darrius, I totally understand what you are saying and suspect you are "on the money".

One "however":

DD was supposed to solve one problem: delivery of goods from Magic Boxes AND the Shopping Cart. As we all have learned the Magic Box system (Magic Box + Shopping Cart) is vulnerable to a multitude of variables (is it the most recent version of Magic Box, is the Shopping Cart filled with multiple items, is the sim where my Magic Box is housed operating correctly, is the Magic Box stuffed with too many items, is the User online when the order is sent, etc...)

As it pertains to the Merchant-side of delivery of purchased items from the Marketplace, it's not soley an issue of is the Purchaser/Recipient online to receive it. Failed deliveries happen all the time, under all different circumstances (for any and all of the reasons given above, and probably more). All that was ever discussed was a folder to receive the MP purchases. That's it.

It's disheartening if this "RI" folder morphed into this catch-all location due to junior programmers. Very possibly it is. But now is the time to get back to the original and very simple purpose of the folder: MP purchases, period.

Link to comment
Share on other sites

Great point about picking the right problems to solve.


Darrius Gothly wrote:

The problem is that items are delivered and signaled by the same device that sends IMs .. and that device is prone to capping and planned failure which means the whole methodology is prone to failure too.

 

Yes the fact that everything is treated the same is also an issue; ideally it would be great to choose yourself what happens to each type of delivery.

Also, at first it might seem great to get rid of capping altogether, but after experiencing the absence of capping in Inworldz, I'd hate to see it go completely. I find that if I haven't logged in there for a while there are so many notices, etc, that I just log off and log in again to clear them (having already read IMs offline).

Link to comment
Share on other sites

I don't have a problem with "new" items going into a received items folder. Actually, I tend to lose things like notecards and textures that people send me, and I have to go digging for them. I have often wished those things went into a convenient place where I could find them quickly, so for me that would be a plus. Sorting by date is a must for that folder though. New stuff has to float to the top.

Returned items should go to Lost and Found, or maybe rename it "Returned Items". Those things are not new, they are old things that got left somewhere. I don't want to have to sort through them and figure out what's new and what's returned.

Things we rez and take back again should to to their original folders. The current behavior is correct.

New builds are trickier. I don't really want those in a Received Items folder. I could live with it, but better would be a way to directly save new builds to a folder of our choice in Inventory. My first preference would be a right-click menu item that says "Take to..." and lets me choose a place to store the new item.

Maybe there's another way to handle new builds, but dumping them into Received doesn't feel right. They may be new to inventory but they aren't new to me. I could live with it though; it isn't really much different than dumping them into Objects as they do now. I never much liked that either.

 

Link to comment
Share on other sites

I hope everyone with reasonable ways to express their opinions and logic will take the survey. :) 

That said, the revised blog post needs to be worded more clearly, as it sounds like "The Received Items feature won't happen but the DD system will depend on this feature which is not happening"...

Here's my survey response:

"After testing on ADITI, the Received Items feature just seemed way too inconsistent... perhaps because I was mostly testing with buying my own items which had already been in my inventory, marking them for sale and 'buying' them myself.

I can see how new items such as LMs and notecards, textures, etc, might be good to all go into one folder.. they are more easy to discard or file when they are all in one place (in theory) and the user would be forced to see how much new stuff they have. Instead of it all auto-lumping into 'appropriate' folders, the user would decide if they even want to keep it first.. however, returned items and "take copies" of already owned items should go to respective folders of Lost and Found and Objects.  

Very Important: If all received items are going into one folder, it definitely needs to be sortable by date. I have filed a JIRA to that effect already.  

But you have a TON of people against the 'put everything new in one folder' idea, so even though I personally don't think I would have a problem as long as the Received Items folder is sortable by date or name, I don't think it's a good idea as the support for it just isn't there.  

I think the best way to go about it is introduce Direct Delivery, change "Received Items" to "Marketplace Deliveries" if possible to avoid new (and old) user confusion, and review how the situation is working after 6 months.  

The most important thing to most merchants (and users!) is that the Marketplace deliveries, among other Marketplace problems like the messed up shopping cart, orders being made and delivered but showing as not delivered and merchants not getting paid, and ways to prevent what happened on V-day, be placed on the highest priority before introducing a feature that will change the way all items get introduced into a user's inventory.  

So... I think this idea is good if implemented correctly, but it's just not the right time for it. It's time to get the Marketplace working nicely first.  Thanks!

p.s. There is still much concern over deliveries that happen when a user is offline or marked to busy. As you know, the item gets completely discarded (not sent to trash) if a user is set to busy, and often the item gets lost if a user is offline and their messages get capped.  If the Received Items folder can remedy those problems, many people currently against the idea would likely embrace the feature."

Link to comment
Share on other sites


Pamela Galli wrote:

I also don't understand this statement:

 

We will be launching Direct Delivery without the Received Items feature. (Direct Delivery purchases will still be sent to the Received Items folder).

It means that LL actually listened.

Direct Delivery will launch as originally intented, i.e.delivery will be sent to the folder called "Received Items" which is for MP purchases.  Just like this picture suggests it should and NOT as a dumping repository for all things deemed cool.

Received Items.png

 

Link to comment
Share on other sites

My response to the survey was somewhat brief but I'll articulate my views should anyone from LL care to follow up, however it has all been said here already pretty much.

However, the issues that Received Items *could* fix include

"Items sent to trash is a non sensical way of dealing with offers of inventory" https://jira.secondlife.com/browse/SVC-2707

and as for avoiding the events of V-Day massacre

Commerce Linden as an escrow account breaks the nature of transactions and is not required when Direct Delivery is implemented, this intermediary should be removed

By doing so, the direct relationship between customer and merchant is restored, transactions wouldn't be pending for hours on end if any one of the several isolated process breaks and merchants can address problems with a degree of control and ownership.

I also spot a disconnect which relates to https://jira.secondlife.com/browse/SVC-4823 and the threat to breaking llRequestAgentData.

Given that one of the very valid reasons for LL NOT to break this function is reliable delivery mailers/vending systems and such, Oz Linden stated that the new Received Items thing would address this (even though it didn't work as he believed it did and items were still capped and lost).

So now that Received Items is NOT going to include all the other items including those sent from inworld objects (using llGiveInventory), the retraction from pushing this to us, brings up the question now as to what will LL do next?

I have a suggestion...

"Oz... meet Brooke.  Brooke, this is Oz...you should chat!"

Worse still was the question in the survey asks

"Do you think it is possible to make changes to the Received Items feature so that it will not negatively impact users who manage large inventories?"

So unless i'm missing the intent of the question, it's nothing to do with the size of an inventory but the frequency and type of incoming items that might all get lumped together.  I could have an inventory with 100k items but only buy one thing on MP per week and it be no bother, versus have a 10k inventory and have 100+ items land in there per day.

Finally, with regard to all to project management, the ONE thing that was missed (again) was engaging with the major stakeholder and finding out what the actual problem statement was.  I don't believe that anywhere in the Agile Project Management Methodology does it say "make stuff up, rush it out in a sprint and then ask the customer what the problem is?"  The Product Owner should be providing input to the team, the Product Owner should have a solid understanding of the users needs...uh oh! :)


 

 



Link to comment
Share on other sites


Sassy Romano wrote:


Pamela Galli wrote:

I also don't understand this statement:

 

We will be launching Direct Delivery without the Received Items feature. (Direct Delivery purchases will still be sent to the Received Items folder).

It means that LL actually listened.

Direct Delivery will launch as originally intented, i.e.delivery will be sent to the folder called "Received Items" which is for MP purchases.  Just like this picture suggests it should and NOT as a dumping repository for all things deemed cool.

Received Items.png

 

Ah -- so we will not have a Received Items feature but we will have a Received Items folder.

Link to comment
Share on other sites

Speaking as a consumer generally speaking I like this idea of a received items folder.  I've got items I purchased a week ago I haven't got around to unpacking or sorting and knowing exactly where they are would be a great help to me.

My only problem is once I sort an item, if I rez it In World, when I pick it up, I want it to go back into the place I sorted it too.  I don't know if the system is capable of distinguishing this.

I will say whoever wrote that survey may understand what it is they are trying to find out but as written, this question is silly or they are trying to game the outcome of the survey:

*

3. Do you think it is possible to make changes to the Received Items feature so that it will not negatively impact users who manage large inventories?

How am I supposed to know if something is possible or not?  Isn't the correct question, "What changes could be made so it will not negatively impact......"

Link to comment
Share on other sites

  • Resident

We apologize for the confusion about what will be launching. Here is a clarification:

  • Direct Delivery will launch with all Direct Delivery purchases going to the Received Items folder.
  • We will be speaking with Residents to get feedback before we release any ADDITIONAL changes that result in objects being sent to the Received Items folder.

 

Link to comment
Share on other sites


CommerceTeam Linden wrote:

We apologize for the confusion about what will be launching. Here is a clarification:
  • Direct Delivery will launch with all Direct Delivery purchases going to the Received Items folder.
  • We will be speaking with Residents to get feedback before we release any ADDITIONAL changes that result in objects being sent to the Received Items folder.

 

NOW THAT is what we wanted to hear.   Thank you!

Link to comment
Share on other sites

OK now THAT is the RIGHT answer. Finally!

FWIW, I replied to the survery as follows:

Yes it's possible to make changes. Here's how (options):

1. Get rid of the feature entirely.

2. Make it as per original intent -- for marketplace purchases.

3. If you want to make it do more, then Received items must have greater granularity. Perhaps some subfolders in it? Such as:

  • Marketplace Purchases
  • Lost & Found
  • New objects I create
  • Things received from scripted objects
  • New inworld purchases
  • Things others give me

Regardless of what you do, items that I rez (whether I copy, modify or simply take back) MUST go back into their original folders.

I'd now add to this -- individual items that come in (like clothing, textures, etc.) should continue to go to their appropriate defaults. OR, they could go to new granular subfolders or sub-sub-folders under Received Items. I'm not sure which is better for new users. The Recent Items view tab argues in favor of them going to their original defaults however, I understand the lure of a Received Items folder (just not the way it was implemented).

Link to comment
Share on other sites

>Direct Delivery will launch with all Direct Delivery purchases going to the Received Items folder.

Let me be the first to pre-challenge this claim.

I want to be clear, though:

I DO NOT challenge the claim that all Direct Delivery purchases will be SENT to the Received Items folder.

Link to comment
Share on other sites

I'm not against a Received Items section per se.  But please, let's do it sensibly!

Items from the Marketplace, and items I buy from a vendor, should go here.  I am forever going to my Objects folder, and looking for new folders of purchased items, and then sorting those things into the places in inventory where they should go.  Having only one place to check for my purchases would be a timesaver.

BUT

Items I build, and then Take, should NOT go here. 

Photos that I receive from others should NOT go here (and, while we are at it, they shouldn't go into my Textures folder either.  Put them in the Photo Album, please!)

I am uncertain about putting other sorts of items that people give me into Received Items.  If these sorts of transactions can be distinguished from photos, then maybe Received Items would be a good place for them.  But I think it would be even better if they went into the proper folder for the type of object they are...an Object, a clothing item, an animation, etc.

Link to comment
Share on other sites

Dear Commerce team, This is a horrible idea. Instead, change the default filter for the Recent tab in the viewer to 2 days instead of Since Last Logoff. You are trying to fix a problem for new residents right? This will address that. Existing residents don't need your change and don't want it.

Link to comment
Share on other sites


Gavin Hird wrote:

OK, I'll test copy of own creation and see where it ends. 

Actually I don't mind everything ending up in the received folder for instance when doing uploads. I usually have to hunt all over the place (with the recents tab) to place things in folders that keeps all items associated with the creation of a product together and not lump them all into the textures folder for instance. I suppose it falls down to working style and what you prefer. 

You should use Filters in conjunction with "Recent Items" Tab.....then it becomes dead easy to manage.

We dont need one bucket to capture all......it will end up be disorganised and over-bloated "Objects" Folder. Just because one or two might we very organised in filtering out the "Recieved" folder each and every day.....doesn't mean the vast majority of SL users will have that sort of discipline to order that RI folder each day.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4422 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share


×
×
  • Create New...