Jump to content

Apply for the Marketplace Direct Delivery Beta Program!


Brooke Linden
 Share

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

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

Recommended Posts

 


Toysoldier Thor wrote:


Darrius Gothly wrote:

I'm gonna disagree with one thing you say here Toy:

 

Toysoldier Thor wrote:

... LL never engages in any healthy solution discussions with Mechants) ...

 

Yesterday's CTUG meeting was a wonderful experience in open brainstorming about possible solutions to a "problem" .. AND happened at the behest of Amanda and her team. I left that meeting feeling energized and positive about the process. It may be that none of our ideas or suggestions get used .. but frankly I would be astonished if they did dump the whole lot of them because there were some gems in there.

Unfortunately .. and for whatever reason .. the Marketplace Team seems not to follow the same beneficial methods being proven effective by the CTUG and Sim Dev teams, but I can't say "LL never...." because I'm seeing examples of "LL doing..."

Whatever rope is around Brooke's neck holding her and her team back from talking WITH us .. I wish someone would cut it loose and let them ENGAGE with us.

Within the scope of what I am invited to or engaged with related to the LL staff, my position stands.

 

I am surprised Amanda called upon LL Merchants to engage in solution development and yet Brooke did not participate in this meeting?

I would also have to think that the whole Dash Deal concept had to - at least in part - have some Amanda input.

Anyway... I stand by my statement from my perspective.  I have seen COUNTLESS great ideas brought up and discussed and try to be championed inside the formal LL Commerce forums.  I challenge you Darrius to point me to 3 threads in these forums whereby Brooke or the Commerce team said - "wow you all make a good point lets discuss this further and see if we can figure this out or address it". 

AND PS - I dont mean Brooke calling a meeting with a common select few of her fave merchants to simply pretend to listen to the concerns and then simply say "thanks but we are still gonna do things our way"

PPS - What does CTUG stand for?

 

Community Tools User Group here are the minutes

 http://wiki.secondlife.com/wiki/Community_Tools_User_Group/21-April-2011

 

The problem solving was about new user help.

Link to comment
Share on other sites

  • Replies 136
  • Created
  • Last Reply

Top Posters In This Topic

Didn't see this one covered in Magic Boxes vs Direct Delivery and convenience.

I believe most merchants pack their products into boxes and put those boxes in their Magic Box. This box-in-box packing may be entirely eliminated for Merchants that decide to simply put those items in a product sub-folder.

Some Merchants may want to continue boxing their products within a Direct Delivery folder, even though they "may" not have to, but for those that want to eliminate that extra boxing step would save an enormous amount of packing time. They could still find ways to include their branding in product names and extra materials that go inside their product folder.

This also makes boxes a less attractive solution than inventory folders.

Not having that information makes this conjecuture as well, but it seems to be a reasonable assumption.

As for not having information yet, that's something that one just has to be patient for. It isn't a requirement that this information must be shared for conjecture to stop based on percieved past performance. Stomping your feet for more information doesn't mean FUD will stop. In fact, it may provide more ammunition for FUD. The information will be shared in due time, I'm sure.

Link to comment
Share on other sites

OK - thanks Argus for the clarification....

So then my position and point still stands as Darrius did not read the full sentence of my point...

 

Toysoldier Thor wrote:

... LL never engages in any healthy solution discussions with Mechants ...

I said... LL has never engaged in healthy solution discussions with "MERCHANTS"  which would mean to imply that topics and discussions between LL and Merchants talking about commerce and Merchant and SLM related issues.

The fact that a MERCHANT attended a meeting with a LL team that was not talking about the commerce issues does not qualify or is not in scope of my statement.

 

Link to comment
Share on other sites


Dartagan Shepherd wrote:

Didn't see this one covered in Magic Boxes vs Direct Delivery and convenience.

I believe most merchants pack their products into boxes and put those boxes in their Magic Box. This box-in-box packing may be entirely eliminated for Merchants that decide to simply put those items in a product sub-folder.

Some Merchants may want to continue boxing their products within a Direct Delivery folder, even though they "may" not have to, but for those that want to eliminate that extra boxing step would save an enormous amount of packing time. They could still find ways to include their branding in product names and extra materials that go inside their product folder.

This also makes boxes a less attractive solution than inventory folders.

Not having that information makes this conjecuture as well, but it seems to be a reasonable assumption.

As for not having information yet, that's something that one just has to be patient for. It isn't a requirement that this information must be shared for conjecture to stop based on percieved past performance. Stomping your feet for more information doesn't mean FUD will stop. In fact, it may provide more ammunition for FUD. The information will be shared in due time, I'm sure.

  1. Direct Delivery from an Avatar's inventory SLM System folder or from a Magicbox is still DIRECT DELIVERY.  Your first point made it appear that the Magicbox source for DD would not be a DD.  Both are - since DD means the direct transfer of an ASSET within the Asset Server from the Merchant's control to the Shoppers inventory. 
  2. Since there is no further details from LL on how DD actually works, the assumption is that Folders will not be allowed in this new SLM System Folder and is just a flat folder.  As such, the Magicbox and the System folder sources provide the same level of functionality - unless of course Dart you know something we dont know about the details of DD.   Until then - we assume a System Folder is single level
  3. I am sure there might be some Merchant that for whatever reason would rather not box their sellable item into a Product Box.  But even if this option were available to me... not boxing my product up as a clean single purchased boxed item to sell to my customers seems to be a non-professional poor practice that you are saying the new DD service will now further encourage.  Maybe this is a benefit to some Merchants - but I would box my product up regardless if DD lets me do it another way.    I dont know - just not my way of doing things but if that is a benefit to some... ok
  4. As for the time it takes to take ALL that has to be in a product folder - boxed or non-boxed - and say that this creates an emormous amount of time??  Dart, did you know creating a Prim Box and dragging all the contents from a folder into the prim box and putting a nice product label on it (which a product better have anyway) doesn take an EMORMOUS amount of time.   Once again... this is an example of FUD.  Turning a molehill into a mountain.
  5. So you happen to be a Merchant that does not believe in properly packaging  / boxing up your complex product (filled with demos, LMs, Notecards, License notecards, etc.) and would rather dump it to a shopper as a folder on the customer's root inventory.  So, outside of the SLM marketplace - if you are running an inworld store or you need to make a sale or hand off this product to a customer... and all you have is a product folder full of stuff.  Now what?  So you will be creating a boxed product for your inworld vendors or for these custom deliveries but JUST FOR THE NEW SLM DD - you will want to delivery as an unboxed folder?  OK... that makes sense.

So Dart, let me challenge you... this is a good one lets see if you are up for the challenge.  Myself and Darrius would have to be complete idiots to have come up and strongly believe that the idea of DD sourcing from the MAgicbox has a very strong set of powerful benefits - but that we are completely wrong on our ideas.

So... provide this thread with 5 merits on why the DD sourcing from the Magicbox IS a better idea.  We know that its tough for you to promote an idea that was not first thought of by the Merchants.... so... lets see if you can openly post 5 benefits over the current LL approach.  I know they are there and they are valid - but it would be neat to see if you could actually agree with us and post it.

Link to comment
Share on other sites

As to your innuendo that I know something you don't, this is not true and I said as much here in what you've quoted.

As for your challenge, no thank you ... treating this as a discussion and not something that needs challenging.

You said: "Since there is no further details from LL on how DD actually works, the assumption is that Folders will not be allowed in this new SLM System Folder and is just a flat folder."

I don't see why any assumption is valid over another. My assumption is that it will be something like library folders, with each product being a sub-folder. Since we're assuming, one is as good as any other.

Benefit to Merchants:

Don't have to pack a box inside another box, everything is packed in a sub-folder. Saves time on packing if you decide not to use a product box.

Saves time on updating products, simply go to product folder and update landmarks, version of product, etc. Would be nice to just rename that product folder from Widget Version 1, to Widget Version 2, swap out product and documentation notecard and off you go.

Benefit to Customers:

No need to unpack a box, simply rez or right click and wear/attach and the customer instantly gets to play with their new purchase.

Drag and drop folder to another location for organization.

That may have inadvertently fulfilled your "5 points" challenge, regardless. I'm sure there are other benefits, but I haven't given that much thought because of lack of information so far.

Link to comment
Share on other sites

 


Dartagan Shepherd wrote:

As to your innuendo that I know something you don't, this is not true and I said as much here in what you've quoted.

As for your challenge, no thank you ... treating this as a discussion and not something that needs challenging.

You said: "Since there is no further details from LL on how DD actually works, the assumption is that Folders will not be allowed in this new SLM System Folder and is just a flat folder."

I don't see why any assumption is valid over another. My assumption is that it will be something like library folders, with each product being a sub-folder. Since we're assuming, one is as good as any other.

Benefit to Merchants:

Don't have to pack a box inside another box, everything is packed in a sub-folder. Saves time on packing if you decide not to use a product box.

Saves time on updating products, simply go to product folder and update landmarks, version of product, etc. Would be nice to just rename that product folder from Widget Version 1, to Widget Version 2, swap out product and documentation notecard and off you go.

Benefit to Customers:

No need to unpack a box, simply rez or right click and wear/attach and the customer instantly gets to play with their new purchase.

Drag and drop folder to another location for organization.

That may have inadvertently fulfilled your "5 points" challenge, regardless. I'm sure there are other benefits, but I haven't given that much thought because of lack of information so far.

 

As I stated above (and have always maintained):

There are some valid points you raise Mr. Shepherd. To wit, I also envision the "Delivery Folder" to be similar to the Trash or Lost and Found folder, meaning it will be able to contain subfolders and subfolders of subfolders. I also agree that for some Merchants, the delivery of product to the customer in an unboxed "ready to run" manner will be something that brings them great benefit. One of my products would be an excellent candidate for this style of delivery as it contains several other products bundled. It would be really nice if instead of delivering a box of boxes, I could deliver a folder of subfolders or, even better specify that the subfolders be delivered as "top level" folders. (However that last option is one I do not expect them to provide .. but nevertheless it's a tweak that would make sense and enhance the "Deliver Folders" method.)

I will also agree that for some Merchants, maintaining their finished product in a folder can be a great time saver. As Rya pointed out earlier, being able to "grab a copy of the working version" and then move it to an Inventory Folder would be a great time saver as well. (Especially when multiple Inventory Windows are used as per Torley's excellent video tutorial.)

But it also has some drawbacks. For example, the Viewers currently employed in SL do not "Focus" on new folders in the recipient's inventory whereas they do offer the option to focus on new objects. For a new Resident (and even us long-term users) the highlighting of the newly arrived single item is a great aid to finding what you just purchased. When combined with the fact that the newly delivered folder may not necessarily have the same name as the product purchased, this will lead to more confusion and thus greater support issues for Merchants.

(There is also something knocking around in my brain about folder transfers being limited to 42 items, but I can't find where I read that off the cuff, and the LSL Wiki page for llGiveInventoryList no longer lists that as a limit .. so I may be incorrect in that memory.)

Another concern that I have regards the Viewer actions when a folder is transferred vs. its actions when a Box is unpacked. With a folder transfer, the items are simply copied without the opportunity to automatically display any of them. However when a box is unpacked the items are actually copied one at a time and thus Notecards and Textures will be opened and displayed to the recipient. (This is the default behavior, however many of the TPVs allow the user to turn this off if desired.)

The display of Notecards helps Merchants by giving the customer an "in your face" Notecard of basic instructions. With new users and those that have not turned off preview display, this not only ensures they at least see that instructions are provided, but can even serve as a defacto EULA. (In all fairness, the dependence on a EULA displayed in this fashion is very iffy .. but it can help.)

My next concern involves the existing frailty of the Inventory Download and Display mechanism. We are all familiar with the constant hew and cry regarding "My Inventory never fully loads." It is a well known "secret" that the primary cause for this is because of the manner used to communicate the contents of the user's Inventory from the Asset Server to the Viewer. In almost every case, the Inventory is really there .. but when the Viewer downloaded the full list from the Asset Server, some items (or some folders) got lost and thus are not displayed in the Viewer's list. They really are "there", but the Viewer didn't hear the message saying they were .. so it never added them to its own local copy.

This is just a basic communications error .. but nevertheless it leads to some amazing histrionics and panic from people that don't understand what happened. (And that's not limited to new users either. Even long time Residents will periodically freak when a very vital part of their Inventory "vanishes".)

When a purchase is made using Folder Delivery, the Asset Server will notify the recipient's Viewer "Got a new folder of stuff for ya. You want the list?" Whereupon the Viewer will say "Sure, give me the full list and I'll add it to my local copy." But as can so often happen, some of the items sent by the Asset Server will "get lost" in the transfer and thus won't be displayed in the recipient's local copy of their Inventory. Thus the customer, the recipient, will look at the list and scream "OMG! I got all the accessories and NO DRESS!" (or whatever item might be missing).

Now I must stress again, the FULL SET OF ITEMS is in their actual Inventory as stored on the Asset Server .. but in the process of sending that list to the Viewer, some of the items may not get communicated and thus will not appear. From the customer's point of view they have just been "cheated" .. and they have NO way of knowing that it's just a simple communication error. (Are you hearing the howls from unhappy customers yet?)

I believe that there are efforts underway to switch the Inventory List Download from its current method to a more reliable one, but that is not yet implemented. Until it is and furthermore is supported by 100% of the Viewers in use in Second Life, this problem will turn into an ugly customer support nightmare that cannot be quelled with Forum Posts, Policy Statements or any other "you should have read the instructions first" solutions now available to Merchants.

Whew! (Gotta take a break to flex my fingers .. another of my typical "Forum Novellas" .. sorry)

The one last point of yours that I want to address in this reply is from a just prior post.

 


Dartagan Shepherd wrote:

As for not having information yet, that's something that one just has to be patient for. It isn't a requirement that this information must be shared for conjecture to stop based on percieved past performance. Stomping your feet for more information doesn't mean FUD will stop. In fact, it may provide more ammunition for FUD. The information will be shared in due time, I'm sure.

 

This statement is not strictly true. If you had any actual experience with software development, especially in an environment where thousands of customers depend on the software itself (depend on as in "derive income from its use") you would know that failure to communicate with the end-user is an unforgiveable sin. Refusing to keep the customer apprised of even basic level details is a mangement style that went out with the white shirt, black tie "Secret Inner Sanctum" style of software development YEARS ago.

You are (according to your own statements) an avid believer in Open Source software development. While that method is anathema to some types of commercial enterprises (of which I believe the Marketplace amply qualifies) the benefits of sharing some level of detail is very clearly proven across all forms of software development.

I maintain, and with quite a bit of personal direct experience as well as reams of Project Management expertise, that "Due Time" is not only here .. it's long OVER due. We have been treated to a teaser that "It's coming real soon now" for several months. But even when faced with rational, logical and clearly necessary calls to shine more light on what "It" is .. the Marketplace Dev Team has maintained a complete cone of silence.

Releasing the whole package as one giant "bomb" .. in one giant release .. will absolutely guarantee that it lands as a total fiasco. Every single mistake, oversight, misconception and plain old dumb idea will be locked into a solid concrete block and dropped on everyone all at once .. and that will doom it to being another giant source of discontent and user mistrust. If they had instead opened up the ideas at an early stage, engaged the user community as sources of feedback and input .. and made it a truly organic process that grew and took shape with the consideration of all opinions then it would arrive as a highly anticipated and well respected success.

We all know that once released, any glaring errors will remain locked inside for a good long while .. and possibly forever .. because they've never had time to "go back and fix" anything. (Hello? Marketplace Reports?) So once again we have a great idea that could become an amazing improvement in the service provided by Linden Lab .. but because they've locked the doors and again repeated the same broken methods that failed every time before, they have guaranteed an uphill battle against a decidedly unhappy customer community.

Link to comment
Share on other sites

 


Darrius Gothly wrote:

 

 

Makes sense .. and that is one of the "Magic" things in SL .. taking a giant sim-sized build and squishing it down into a tiny box small enough to fit inside another box.

Thinking of the "now" situation, have you thought about putting separate magic boxes on each Sim? That way you'd be on the same Sim as the items being sold at least .. and you could reduce the inventory in your Magic Box by 2/3rds. It doesn't sound like you're having any delivery issues (at least none I remember seeing you mention) but it's one of those "no pain" optimizations that would shorten your trips and add a layer of organization that might be beneficial.

Now wouldn't it be really cool if I could just carry that magic box around with me? :smileywink:

 

Link to comment
Share on other sites

 


Rya Nitely wrote:

 

Darrius Gothly wrote:

 

 

Makes sense .. and that is one of the "Magic" things in SL .. taking a giant sim-sized build and squishing it down into a tiny box small enough to fit inside another box.

Thinking of the "now" situation, have you thought about putting separate magic boxes on each Sim? That way you'd be on the same Sim as the items being sold at least .. and you could reduce the inventory in your Magic Box by 2/3rds. It doesn't sound like you're having any delivery issues (at least none I remember seeing you mention) but it's one of those "no pain" optimizations that would shorten your trips and add a layer of organization that might be beneficial.

Now wouldn't it be really cool if I could just carry that magic box around with me? :smileywink:

 

 

LOL Smart-ass!

But yes, it will be. However I don't wanna put it inside my pants when people and computers are sticking their hands in it all day long. I'd much rather have it in a backpack so I don't have to worry about anyone "touching my junk". *winks back*

Link to comment
Share on other sites


Josh Susanto wrote:

Inspired by the direct delivery idea, I just went downstairs and spent half an hour opening all the canned food in the house, so that I can get at it faster when I need it.

 

LOL that one made me smile and it has such a good meaning behind it !

The only benefits that the defenders of the LL proposed DD design of sourcing from the Merchant's avatar all seem centered around promoting an idea tha purely caters the the EXTREME in Merrchant Convenience - regardless of the potential risks of the design and regardless of the impending imposed migration efforts that the LL design will force on us!  This disadvantages are dismissed as 1) not critical issues that only relate to FUD,  2) its for the Merchant community's own good and worth the suffering to migrate.

All benefits that the alternative DD approach of sourcing from the existing production Magicboxes are dismissed or shrugged off or responded to with another form of FUD.

 

So, this analogy ranks up there with Darrius's usually witty analogies as hitting it home on putting the benefits touted byt those that believe and defend the LL DD design.

It might actually inspire me to come up with other "SOLUTIONS WITH THE ONLY PRIORITY BEING EXTREME CONVENIENCE - FOR CONVENIENCE'S SAKE" analogies...

The one I personally like is the one that targets the reason I started this DD DESIGN FLAW discussion campaign in the first place (security risks of the LL DD model by removing the layer of isolation between SLM items and the rest of a Merchants inventory - all in the name of extreme convenience)...

I run a RL business with my manufactured products in my warehouse.  In order to provide the most extreme convenience to me and my main retailer, I am going give them the keys to my entire warehouse of stuff which also holds my products for sale to them.  I will tell them to feel free and have their delivery truck arrive at my un-manned warehouse to unlock the shipping doors and take what ever they need to deliver it to their customers. 

There is no need for me to pay for staff to meet them at the door, ask what they need, confirm that they are taking, and make sure that other warehouse items are not accidently or purposely taken as well.  Therefore, for pure convenience to me, I will not staff my warehouse and I will completely trust my retailer to do the right thing ALWAYS in the years to come.

Ohhh BTW... in order to allow this retailer to have free unrestricted and un-audited access to give my products away directly to my end customers through them, my retailer is telling me that they REQUIRE that I move all my products from my current warehouse that I have worked with all these years and everything is set up, to a new location where they would rather pickup my stuff freely.  My current warehouse ONLY has my products related to them - but they want me to move all my products to my SUPER WAREHOUSE where I keep everything.  

SURE! NO PROBLEM!!  SOUND REASONABLE!  Afterall - CONVENIENCE IS MY ONLY PRIORITY!

 

Link to comment
Share on other sites

Yeah, what's so great about convenience?

 

Why do people have to change things that work perfectly well just for convenience? 
Lets take that stupid invention, the remote control - what was so difficult about getting up and walking over to change the channel?
Who needs mobile (cell) phones when you've got the good old payphone? And talking about phones, why did they remove the cord that attached the receiver to the base?
And WIFI internet, oh please - stupidest idea ever. What is so hard about cables?
I don't know why the world has such an addiction to changing things for the sake of convenience, but it happens all the time.
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4750 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...