Toysoldier Thor

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.

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 guess its an "out of sight - out of mind". For those invited to engage with Lindens like Amanda, Brooke, whomever, my statement would seem incorrect. So I will clarify... FOR ME AND MY EXPERIENCE WITH LL - specially the LL Commerce Team - LL never engages in healthy solution brain storming with its merchants. 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?

Claireschen Hesten wrote: i did get the email about this the email account for my alt didn't i'm not to fussed about it i don't mind about the 50% off deal because as merchants we were able to apply for this what i did object to was several months back when the breeding bunnies got their own advertising mail out from LL in some secret deal To a certain level, LL's internal friends that we know include a Breedable Bunny merchant - are gettng free biased advertising again. The past couple weeks LL SLM is pumping and promoting the Breedables industry. I have been in XSTREET SLM since 2008. I have never seen LL ever promote merchant industries like the building, landscaping, housewares. Outside of promote SEASONAL events (which makes sense), LL seems to only provide biased promotion of breedables (specifically Bunnies) and the clothing industry. I can even agree that the clothing industry is sooo huge and wide spread with a huge group of merchants.... but Bunny Breeding or even the Breedables? I know the market is huge in sales volume but how many merchants are in that category? Then compare it to how many Merchants creates textures, sculpty maps, landscaping, housewares. So, even the current BREEDABLE top front page promotion is absolutely no surprise. This is LL promoting their internal friends in that industry. Not fair.... but LL is God so I guess glad handing is the world we live in.

Yesterday I did poke at Rodvik about the serious concerns I have on LL Commerce Team's misguided activities, like the Dash Deal efforts and the weak architecture of the upcoming Direct Delivery. He did respond saying he would bring these concerns to the LL Commerce Team. I would stop pumping the "FUD" as Sassy calls it if Brooke's development team would engage an open discussion with us interested merchants with concerns of the current DD design and with what we feel are much more solids designs on DD. I truly do hope Rodvik does talk to Brooke and company and asks them and the development team to look more seriously at our concerns as well as our ideas for what would be a much more SEAMLESS DD solution to deploy. Its not just for our benefit - its for theirs! If the cutover to the new DD is simple, with little development effort and much lower risk of migration / transition issues, it means less post implementation work and less lost sales on SLM.

Rya, I so agree that an issue of inactive SLM Merchant accounts and inactive selling items should be addressed. This was an issue that LL tried via a wrong approach to address in 2009 with the Money grabbing Monthly LISTING TAXES. But yes - if a proper solution could be deployed (some ideas were brought forward to LL via forums but as usual LL never engages in any healthy solution discussions with Mechants) then I would be all for it. but like you said... that is a different subject.

Sassy Romano wrote: What's not to like about MP inventory in a single prim? Go and manipulate 1000+ objects in a single prim content and you'll have the answer! As Rya pointed out, some dislike the need to tp back to that box, find the object with a huge number of objects is a pain. Our inventory has "search", object content does not. If the region is down, I can't get to it. If i'm not logged in with a gui client, I can't get to it but I can log in using a text SL client and get to my inventory and deliver. Still needs land to put it on, some people would prefer not to have that need and it will be redundant to own land if it's direct from inventory. (I'm not suggesting the land thing is good or bad, just that's what some would prefer) Finally, as you say, there's no need to have redundant boxes, so can consolidate all into one which at that point is no different to just copying all to a folder in inventory so it's all around how that's handled by LL, in fact it's less steps to leave them in the right folder in inventory than to then drag them back to the single box. Either way not all will be happy but i'd rather just see what's offered than have the constant FUD going around. First of all Sassy... I wish ppl would stop calling this FUD in the terms of it being some negative connotation. 1) The only reason we can call discussing concerns of an upcoming system that will impact ALL OF US and that has to-date no released details by LL as FUD is because all we have to go on right now is what little trickle of information LL has allowed to leak into the public (or that their first wave of secret Merchants in the know have let leak). In light of the little data we have now - we know enough to know the general idea and we are discussing the potential concerns of a DD system that would follow this model. If that is called FUD... then great. 2) Even if we knew more details, discussing the potential negative impacts of a system is not FUD... its a healthy and extremely important component of proper system design that helps detect potential future issues at deploy / prodcution time. Sassy - you sound like a person in the tech industry. I would have to guess you must have been in some large scale systems developments and deployments. If so, are you telling me that your design team NEVER discussed the potential negative impacts of a solution from transition and production/operations views? As a solution designer myself, this FUD process as you are calling it is a major part of my week for my own designs and those of others on my teams. As for your points on the negatives of the Magicbox solution... I will challenge you and ask you how many times in your career as a Merchant of SLM has your Magicbox not been available to you to access it (i.e. to have it available to ADD or REMOVE an item) because your sim, parcel, region has been down? I know your SLM store is likely much larger than mine but are you saying your magicbox is on a sim (likely where your store is) that is down so often that you have frequently not been able to access your Magicbox? If so Sassy, I would suggest that you have MUCH BIGGER ISSUE! Even if your store sim where you locate your magicbox on is crashing so many times that you cannot effectively access your magicbox (which I debate how many times this really happens to you), how critical is it really that you NEED access to the magicbox at that exact time to add or remove an item. Remember, in the new DD Magicbox soruce model, the only time you need access to the Magicbox is to add or remove an item. NOTHING ELSE. If its an emergency issue - you can delist an item on the SLM site. So, you brought it the issue of FUD... I challenge you that your points on access to the magicbox truly qualifies as FUD since the issue rarely happens now on a real live system and the impact of this problem is not critical at all - when the sim comes back up - you can access your magic box. As such, any of your points / issues with the magicbox model that relate to accessing it the MINUTE YOU NEED IT would also not be a big concern since for 99.9% of Merchants - this would be something most merchants would simply wait till the magicbox is available again. I would agree that it would be nice if the SOURCE (regardless of what is the source) would have a form of subfolder management but the magicboxes nor the SLM system folder would likely have this feature. I would agree that currently you would have the ability to search in a system folder vs a magicbox and if you had a box with 1000 item - this becomes more important. But, at least for me, of ALL the SLM Merchant activities I have in a given day week year - one of the smallest activities I have is working inside my Magicbox. So I am quite surprised that all your issues you bring up against the Magicbox as the first source related to maintaining it. In the grand scheme of all the benefits and impacts that either DD solution should be considering - I do not see this as a big one.

Darrius Gothly wrote: The beauty of moving the DD system's "source" to the inventory inside our Magic Boxes is that you will no longer "need" to maintain multiple boxes on multiple Sims. The whole purpose of those multiple boxes is to eliminate delivery lag when items need to be sent out. After the switch to DD begins, the items will not be sent by commanding a remote script to deliver the item, but by simply copying the item's data record to the recipient's inventory "file". Basically the logic to figure out which item to send remains in place .. the only change is that instead of calling a routine that ultimately sends a command to the magic box, DD calls a replacement routine that copies the data record. Net result .. very small code changes .. further resulting in faster implementation with higher success rate. Next comes the UI design. There is none to be done. The Marketplace already has in place everything needed to accept "Contents Updates" from the Magic Boxes. In fact, all of our listings already have Magic Box content items associated properly. In order to add an item, you simply drop it into one of your Magic Boxes and .. in short order it is available. You won't need boxes on multiple Sims anymore because the contents list of the Magic Boxes will never be "offline" the way Sims go offline now. So after the switch to DD begins, you can immediately go pick up all your duplicated boxes .. they aren't needed any more. But you will leave the set you have on your "home" Sim and continue updating them in exactly the same way you do now. If you want, you can even eliminate the extra boxes in your home Sim too. The only reason to restrict the number of items in a Magic Box now is to speed the delivery process .. specifically reduce the amount of inventory lookup the Magic Box must do when told to deliver an item. But since that will happen on the Asset Server, it happens at DBMS key lookup speed (which is VERY fast) and not at the molasses-like speed of the scripted lookup that happens now. However it ALSO allows you to keep multiple Magic Boxes so you can organize your deliverables into categories, product lines, or whatever classification you might wish, without adding extra folders or other confusing hierarchical nonsense. Starting a new Product Line? Drop out a new Magic Box, put your items in it .. and presto the entire process of making those items ready for delivery is done. And ALL that code works now! There is nothing new to write or test! As for disabling (or weeding out) items from inactive Merchants .. LL missed that boat already when they ported everything over to the Marketplace. They could have easily said "Mark the items you want ported over and we will copy them for you." Or they could have said "All items will be migrated in the inactive state and you must mark them active to make them deliverable." They had several ways to weed out those inactive merchants then .. and they completely avoided those options. I think they WANT to keep those items listed, just as they do not want to remove old and clearly abandoned user accounts. It must be painfully obvious to them, just by looking at accounts that have a "last login date" prior to the migration, which ones are truly unserviced and unattended. It would take a simple SQL Select query to wipe out every single "dead" account .. in a matter of minutes. They do not need to put all 50,000 of us through another marathon drill to figure out which accounts are no longer attended. (In fact, their move to connect the In-World account balance with the XStreet account balance made it even more possible for people to become absentee merchants ... as there was no longer a need for anyone to log in to Second Life at all in order to cash out their proceeds from sales.) The benefits to this plan are many. The development time is greatly reduced .. the introduction of new and untested code minimized .. the need for complicated UI interfaces eliminated .. the need for multiple Magic Boxes spread over the grid eliminated .. and the overall disruption to the Merchant community reduced to almost zero. What's NOT to like about this idea? I really cannot add much more to the benefits of changing the DD source to the already existing MagicBoxes that Darrius didnt already say above. We can debate and discuss how the LL "System Folder in your Inventory" has some benefits but honestly, they cannot compared to the development, migration, and simplicity of using the Magicboxes as a source. Remember ppl, we ARE NOT talking about deploying a DD system that will impact: a small system, with a small amount of information (over a million SLM items / listings), that currently stores all their items in a small number of locations (guessing 3 x Merchants or 150K Magicboxes) very small number of direct system Users (roughly guessing 50,000 impacted Merchants), with and a small number of indirect users of the system (All the SLM shoppers), that generates a few daily transactions (I can only guess the daily sales transactions in SLM) So, when designing new systems and system function into a service of this size and magnitude, a systems architect and a solution developer CANNOT dismiss the impacts of their changes to this large a systems. What might seem like the perfect solution to one Merchant who is willing to take a little pain for the convenience of having his/her inventory in their personal inventory, does not make it the best larger scale solution for the entire system. A solution designer needs to look at the bigger picture and risks/impact to transition are MAJOR ones that cannot be dismissed. And as Darrius pointed out, there is no arguing that if the new DD system were to change its source to the MagicBox instead of switching ALL 50,000 merchant's SLM items to their personal inventory, HANDS DOWN the easiest and most simple solution for LL to go forward with is a DD that leverages the Magicboxes. THAT BEING SAID.... and thinking strategically.... If LL were smart and changed the DD to source the Magicboxes as the first deploy.... they would have perfectly positioned their DD service to execute on phase two (which is what I have been advocating all along) of the DD service expansion.... They could later exapnd the DD service to ADDITIONAL & CONFIGURABLE SOURCES !! Phase 2 of DD: to add Personal Inventory SLM System Folder as a source & a means for the Merchant to set which one they would prefer to use (for those that want ultra convenience vs security) Phase 3 of DD: to add the source of an Alt Account (i.e. the account of a business partner or central business account) BUT.... the 1st phase must be to deploy the solution with the smallest transition impact to the huge userbase of SLM. That is the source of the Magicboxes.

Porky Gorky wrote: Yay I am back in the #1 spot for my best keywords. I hereby declare that Search is fixed! If we are talking inworld search, I will say that based on my tests last night of the inworld search to find my store and the products I sell in my store, they seemed to have done something right. In the many different ways I tried searching for things related to me - my store showed up in the first page of results almost every time. Of course I am limited in that my store is in a mall on mature land so that hampers how I can search, but I was expecting that. What I do see that seems to have changed - and I might be wrong - some of my competing landscape & sculpty store merchants that were using tricks to get their stores to show up multiple times on the top of search results - is not happening now. Again, I didnt look too closely yet but it seems that the results are filtered to only show one instance of a store. If this is true and LL has fixed this - then I give them Kudos for fixing this. Unfortunately, as I said in a previous posting, SL residents have been so strongly conditioned to know that inworld search was useless for product searching, most do not use it to find products. So I dont expect ANY traffic or sales increases (just like I never saw any last year when I fixed my configurations to get me visible in the search in the first place). But its good to see that they seemed to have got it right this time.

Rya Nitely wrote: Darrius Gothly wrote: The effort required to set up DD using a new delivery folder for the merchants is ... everyone must create the new folder (unless LL creates it for them), then build the appropriate product folders inside the special folder, then copy or move the delivery versions into the new product folders, then verify on Marketplace that everything matches up by editing each and every listing. The effort required to set up DD with existing Magic Boxes being the source of objects is .. nothing. The Marketplace already knows all of our Magic Boxes, it already has the association of the Product Listings to the objects inside those Magic Boxes, and all the necessary relationships are already in place. I'm reasonably sure that given a choice between editing every single listing AGAIN or simply having things automatically switch over to DD .. most merchants will choose the automatic option. Over time, if you want to go through the process, you can move everything into one overstuffed Magic Box and remove all the others. But even if you don't, it won't matter because everything will work using Asset Server database copies and totally eliminate the need for scripted delivery. The reward for the effort of setting up DD using a new delivery folder is long term convenience. Darrius, If you had a larger inventory, and you were actively updating and adding new items, making small changes and having to TP over 3 sims to replace the item in your magic box then you would know how inconvenient they are. I have to update mine everyday, usually several times a day, and I only have one magic box - I can only imagine how much harder it would be if you had multiple.The best thing about this system is that your marketplace inventory will be with you all the time, no matter where you are you will be able to update or add to your inventory or do fast manual deliveries to customers directly from your marketplace inventory. I often grab an item from my magic box to manually deliver to customers (this insures they get the latest version), and to do this I have to TP over to the magic box, rez the item and then take it into my inventory and then send it. It's a big headache. And as for merchants taking the time to move items to the new DD folder - this is good because all those merchants who are no longer actively maintaining their products will be left behind when Magic boxes become obsolete. This is where although I see your points (and sassy's) I disagree that this is that big of an inconvenience. Specially with one Magic box - like I have. again... I like the idea that the DD migration would have ZERO involvement for the 50,000 merchants versus the System Folder - which will impact all 50,000 merchants. And this is being dismissed by both u and sassy as not a big deal and in fact for the Greater good. totally disagree with you on this. A system geek that only thinks of technology would dismiss the migration inconvenience of 50,000 merchants. You need to think about your users. short and long term. you both mention the greater good of the convenience of the SLM inventory in your main inventory as a system folder but totally dismiss the risks and security and the performance lag. Unlike you.... I have one magic box and I LOVE and deeply want to maintain my SLM sellable inventory in a seperate rezzed object that is apart from my personal inventory. I do not see how its so inconvenient that I would want to have to add the risk of DD accessing my personal inventory and increase my inventory size to add more lag and to have a folder i can accidently manipulate. You both dismiss the benefits of the SLM items having distinct isolation. AND it will clean up as much as the painful migration from xstreet to slm did. That cleanup of SLM will not do ANYTHING to help slm or your sales. so that is a wasted benefit.

Inworld search has been screwed up for so long ... that provides my inworld store literally near zero additional traffic even if my store shows up on the top of search pages. No kidding... last June Rachel helped me fix up my inworld search (made several changes to my parcel, store, classifieds, etc.) so that I went from "you couldnt find my store/products if you tried" to being on the first page of relevent searches. I expected this this will surely help my traffic a little. After 4 weeks of monitoring.... NOT ONE BIT OF A NOTICABLE CHANGE IN TRAFFIC OR SALES INWORLD. My daily store visitor count was exactlty the same. Most SL Residents looking for product and content has longgggggggg sincceeeee learned that inworld search is like talking to a rock. Most go to the SLM search to find product. Some come back inworld to buy. So - at least for me... fixing the search algorithms will not solve the problem with inworld search. The inworld search model is just not designed to find SELLABLE BUYABLE CONTENT inworld. Its so polluted with 1millions of other inworld rezzed items that are marked as for sale that is being used as a way of keyword gaming the inworld search. So... it dont matter to me what they do to inworld search. I wished they keep focusing on effective true unbiased SLM Search by Relevance.

My accounts have LUCKILY not received any of these LL Dash Deal Advertising emails. BUT... the bad part is that I rarely get any of LL's important Merchant notifications or surveys either. And before Linden reads this or - heaven forbid - posts the response saying that I have spam filtered LL... I HAVE NOT. I did receive an email from LL back in ealy January from Brooke about an SLM change. But nothing since. LL cant even spam properly - lol !!

Ricky Zhichao wrote: Quite a whining thread again. First deal of that test dash deal and worth so many cries. Sure anyway good to know what could be better as testing just started. Anyway my point is that everything is worth try. Or if not ..then not worth to do anything. Right? And sure there is other grids to make things better. At least I just dont know any better virtual worlds for commerce working. Not even near sl. No Ricky... contrary to your statement.... "Everything is NOT worth a try". If you are running a business (like LL is) and you are majorly resource constrained to the point that you must ration all your customer complaints, requests, demands, issues onto a long lengthy backlog of things that you can never seem to get to (like LL is)... Then a SMART COMPANY doesnt follow a philosophy of "Everything is worth a try". A smart company and smart management team assess what are critical drivers and goals to attain and what efforts / activities / ideas would have either little or even negagtive impact to attaining these goals. They then allocate their rationed resources to focus on the projects and activities that have the highest impact to meet their goals. The DASH DEAL - in almost every way - does absolutely NOTHING to help meet the larger goals of SLM. It's long term deployment would (even if the test was somehow successful and LL was able to increase ONE MERCHANT of 50,000+ Merchants sales by 500%) also be a strategic mistake because LL would never be able to promote the vast majority of SLM Merchants that would want to be in the queue to have LL ADVERTISE SPAM its customer base. There are only 365 days in a year and if one participant's merchant was correct, even if there were 2000 Merchant applications to the Dash Deal and no more joined after day 1, it would take up to 5.4 years for a Merchant to get their product SPAMMED but LL. By then, most SL Residents that have not already requested LL to stop spamming them daily or have already blocked LL Emails as a filter, would surely do so within the first 6 months ! LL would have essentially destroyed their important Customer Service Email communication tool to the greater SL Customer base (a tool that is meant to be used by LL to send important notices). So Ricky... NOT EVERYTHING IS WORTH A TRY - Not if a company wants to be smart. This thread is not whining - this thread is trying to inform LL Commerce Team that they are wasting time on Dash Deal which was a bad idea from the start and to focus on the critical SLM issues. Some day the LL Commerce Team will listen.

Yeah... so exactly how would this promotion serve the SLM Merchant community if out of 1000's of applicants they can only serve a few of their friend merchants? so even if LL did a Dummy Dash each day evey day.... with thousands of applications - as u said - they could only do 365 a year! AND... LL would be sending daily advertising spam to all their residents EVERY STINKING DAY! Are we all seeing a problem here??? Apparently not Brooke and her team. DUMB IDEA (or an excuse LL created to allow them to promote LL friend merhants under a lame promo excuse that most will never get to see even if they wanted to. explains why Brooke forged ahead with the idea even though there was almost not good comments about the idea)

Kornscope Komachi wrote: It's competition people! The Linden is marketing against you. I suggest merchants have their own "Double Dash", "Triple Dash" and "Quadro Dash Deals" Mark Make up some prices content and join in the fun. Its not as if any SLM merchant wanted to out-price / under-price the LL Dash Deal of the day that they couldnt. In fact, we all could cut our prices by 60% or even 70% and make our Dash Deal far more attractive then LL's Dash Deal and even lose less money than if LL blessed the rare merchant by promoting their product (since for the LL Dash Deal, the Merchant is cutting their revenue on the item by 75% - LL get 50% of the cut of any DD deal). The one major disadvantage these DD competing merchants would have with LL's Dash Deals is that none of us have access to LL's customer user database where they use their spam their customers, and have huge followers on their SL wide twitter and facebook groups, and wherever else they use their monopoly access to promote ONE SLM MERCHANT. You cant compete with that. Not that most merchants want to anyway - or else we will now further propogate the devastating SL Content price collapse that Midnight Mania and Lucky Chairs and other desperate sales grabbing gimmicks have already done to the SL economy. But if LL wants to promote the marketing concept of generating SLM traffic at any cost by promoting some few specially selected Merchant's content based on unknown secret selection criteria... THEN... maybe the Merchant Community needs to create a third-party SLM MIDNIGHT MANIA site where the scavaging freebie and super bargain hunters can flock to and find out what AWESOME 60% 70% super 24 hour sales are available on SLM. If LL wants to encourage this... then there is no stopping the creation of a SLM FIRE SALE promo site. At least it will be fair in that LL would be secretly hand selecting with of the 10s 100s 1000s of participating DD Merchants they will promote. For those that are saying this is the first they heard of LL's Dumb Dash, I will say that Brooke advertised this like a month ago and then her team had to promote it again since I assume so many SLM Merchant put up their palms to this really bad marketing idea from LL. I so much home Rodvik engages and sits the LL Commerce Team down and asks them: "What the heck is your team doing with ideas like this Dash Deal ?"... "Why is your team promoting one or two or even 10 specific Merchant's and their products over the 10's of thousands of other SLM Merchants?" "How does this marketing and promotion strategy in any way help SLM and address the bigger issues with SLM?" "Why do you want to generate traffic by gutting / cutting prices?" "Show me the increase in general SLM traffic and sales because your team is spamming our customer-base with the products of a couple Merchants". I sure hope Rodvik starts sitting his teams down and asking some tough questions. LL COMMERCE TEAM needs to be asked some serious questions - the Merchants of SL are generating a lot of LL's revenue... dont abandon them Rod.

Darrius Gothly wrote: ROFLMAO!! Toy!! That is BRILLIANT in its simplicity. HAHAHAH!! I didn't think of that either till I read your post. A Magic Box is already the PERFECT place to pull the delivery inventory from. As long as it exists, it has space in the Asset Server. Why go to all the trouble of building a new folder in your own inventory? Just use the Contents of the existing Magic boxes!! Thanks! Seems to make all the sense to me. Now even Sassy and Zanara who both believe that "it all happens in the Asset Server/DB" and the DD is just a simple SQL call process, might agree that a DD process happening on the 1 million+ SLM ASSETS inside the already existing 100,000+ magicboxes which all have their Assets/UUID located in the Asset Server, might be the better system design idea than... to force the 50K+ Merchants to migrate/transfer all their SLM item assets in their magicboxes (or wherever they will be forced to populate this new DD system folder from) and further bloat already oversized personal avatar account inventories. But, as you know Darrius, LL has a 99.9% track record of not listening to any customers or merchants (except the rare exclusive few) - no matter how good an idea it is. The reason, the LL Dev team has likely 90% coded and internally released this DD code based on a fundamentally weak/flawed solution they came up with. 1) they are too stubborn/impatient to actually back track on all the work they already did... 2) they egos would be majorly bruised that a group of Merchant knowing a fraction of the system layout of SLM and SL actually come up with a much more simple and elegent and painless DD solution than they did. So.... this good idea will just go under... "Good Concept - Kudos! Now shutup and let us drive" But thank Darrius !

Honestly there is NO GOOD WAY for LL to be proceeding with DASH DEAL. Many Merchants have already chimed in from the first hour that LL Commerce announced this hair-brain idea. Its a bad idea as... Does nothing to promote SLM as a whole to increase sales (only bargain hunters snagging the firesale) It has LL selectively promoting only favored Merchants that they select based on some secret LL formula Similar to how the Midnight Mania and Lucky Chairs were fundamental factors to depress SL content across most of the economy - LL is using the same style of "give away" bargain prices as a desperate strategy to increase SLM traffic As to point #3 - this approach for most MM merchants has proven to not be successful in actually increasing sale - just traffic that is purely targetted to snagging the good deal and running (like smart mice to a trap) It distracts the LL Commerce Team's efforts to focus on the issues and critical SLM problems that their customers/merchants have constantly been asking for LL Commerce to address LL COMMERCE should not be marketing and promoting an absolutely microcosm of LL selected/favors SLM merchants - in fact they should not be marketing the SLM market at all. They should focus on building an effective set of marketing / advertising tools and offering these tools at reasonable prices for MERCHANTS to do the marketing with. Brooke..... LISTEN TO YOUR CUSTOMERS.... to pretend to be listening.

Darrius Gothly wrote: Many years ago, my aunt commented to my uncle how much she liked looking out the window and seeing the rose bushes in the spring. Being the type of man he was, he took the hint and later that day took one of the farm hands to town, bought a number of rosebushes, returned home and began fixing things up. He removed a peach tree, some other shrubbery and put in a lovely curved row of the new rose bushes right under the front window. Total success, right? Nope. My aunt wanted him to open the bedroom drapes so she could see the rose bushes already planted there. Moral of the story? Oh heck .. you don't need me to explain it really .. do ya? Darrius - you always say things just the right way ! That is the best way I would have responded to Dart. Very few would agrue that there are issues with the current SCRIPTED MAGICBOXES and that a new solution to address the problems could resolve a lot of these issue. But, as Darrius said so nicely, LL sees the problem and complaints and they feel that this is the Merchant Feedback they needed for them to proceed to coming up with a solution. A form of the DD model / solution has some strong potential merits, BUT, LL has decided to throw out the baby with the bathwater. It was not the REZZED BOX that was what Merchants were / are complaining about. Its the process that involves the script in the magicbox and the issues that can happen because of the Magicbox srcipt process as well as the inherent issues of any script operating on a rezzed object inworld (i.e. lag) and its limited abilities to communicate with others. Since LL never even considered getting a group of merchants together to talk about the issue in more detail, or to even consider some brainstorming of alternatives, or to ask what Merchants actually liked about the Magicboxes... LL just made a load of half-baked assumptions and designed a solution that specifically solved what they thought was the problem. So... here is something that LL did not think about that would have likely appeased many more merchants.... just leave the MagicBoxes alone - with all their content in place - for the 10's of thousands of merchants and likely 100's of thousands of Magicboxes in place now.... and just develop a DD solution that would use the Magicbox as the SOURCE for direct delivery? As Zanara has even pointed out and others - all assets are in the Asset Server. Both assets that are categorized and processed and handled within the bounds of our account's personal inventory and assets/objects that are rezzed inworld (although not part of our inventory). As such, why does LL believe that the ONLY form of DD is "direct" from our inventory? A Direct Delivery from the new DD service could just as easy perform a direct delivery (i.e. a process that simply transfers an object/asset from one owner to another owner in the Asset Server without need to use messaging etc) from the current Magicbox rezzed object to the buyer. This is still DIRECT. By following this model, the DD solution would not require 50,000+ Merchants to go through yet another majore mgration of their SLM items from the Magicbox to this new System Folder in our own inventory. (this will be yet another major inconvenience LL has no problem forcing us merchants to endure). The new DD would simply start delivering merchant items from the same magicbox via the asset server that the scripts in the magicbox has been doing all these year. By leaving all the merchant SLM items in the magic boxes, LL will not be forcing the 50K+ merchants to bloat their already huge personal inventories even larger with all these "production" SLM items (trust me, most merchants will treat the system folder as an isolated area for SLM even though that is naive - its all still in their inventory). Basically, with the current DD solution, LL will be forcing about 1,000,000+ SLM items to be transferred into Merchant's inventory!! We all thought our personal inventories were too large and already causing us inworld lag issues - thank LL for making it worse with this DD solution. The biggest benefit of using the current MagicBox as the source for the new DD is that it give merchants like me - that seem to care about security of these transactions and isolation of my SLM activities from my personal activities/items - a much strong confidence level. With this model, the DD is only performing transaction on the items that I have deemed safe to expose to SLM. All my other personal items are safely isolated from SLM and DD's automated processes. This model also would likely provide LL and the Merchants with much higher availability of service - since the DD would be designed to deal with processing from multiple "DUMB" Magicboxes ("dumb" meaning the script would be removed or ignored with the new DD). Unlike many long know issues that impact our personal inventory (no they are not all related to our viewer's cache}, with multiple magicboxes still in use, the new DD could provide fault tolerance in being able to source content from the magicbox that is available - or even load balance the transactions. With this model... if a Merchant makes a mistake in their own personal inventory - and yes we make mistakes - these mistakes would not impact our SLM transactions or items. I could go on... but you get the drift. THIS would have been a much much more acceptable architected solution of a DD, but as Darrius nicely pointed out, LL heard loved the sight of roses and started ripping up the garden to give us more roses - at any cost.

Zanara Zenovka wrote: Toysoldier: Reading comprehension really isn't your forte, is it? I haven't said the implementation of DD is going to be all sweetness and light, I'm merely trying to inject some basic technical information into this discussion, having seen people getting all worried because of erroneous assumptions that demonstrate a lack of understanding of how asset storage and delivery currently works. I'm actually trying to help people by sharing information, and a couple of lines of impassive technical facts from me do not warrant the histrionics and personal attacks you're determined to indulge in. You need to pull your head in and stop just trying to wind up hysteria for the sake of it, because you are one of the least knowledgable people here. A week ago you were *amazed* when I explained the basics of how magic boxes work. A few days ago you were seeing LL conspiracies everywhere because *OMG your messages had been capped for the first time!!111!!! and LL must have changed something!* You didn't even know how ordinary transfers of inventory and messages occur, let alone scripted ones, yet you want to carry on here like people should listen to you as some sort of expert. Get a grip, really. Don't you have some rocks to bang together or something? The alternative to banging rocks loudly NOW while there might be a twinkle of hope that its not too late to convince LL that their solution to the problem they are solving may have some serious flaw (where MAYYYYBEEE they might be able to change the code to address the concerns) ... is to just sit on my concerns and put trust in LL's development team to see the issues I see and hope and secretly pray that they will do it right when it comes out of the secret close beta and right into production. So... since I have seen how LL operates, following the approach that 1) LL will do it right, and 2) LL will listen to Merchants if they dont do it right... well that has historically being a 100% STUPID ASSUMPTION. Look at the SLM deploy (which left alot of merchants hurting during migration and to date has many functions worse than xstreet and a shopping cart of questionable value and potential source of some delivery failures)... Look at the Maturity Filters (which no merchant wanted)... Look at the countless fallout issues from LL's TEENIFICATION of the Adult Grid... Look at LL's tinkering with Search.... So, you take your approach and blissfully hope that LL will do things right and LL will fix the Merchant's concerns if / when they screw things up again. I will continue to waves the serious potential concerns of the DD solution in public until Brooke and team public announces / responds that she understands the concerns we have brought forward and that her team plans to ignore it / or address it. Until then... maybe its best to just mute my postings.... it will save you a lot of personal grief. There is a simple solution.

Rya Nitely wrote: Toysoldier Thor wrote: The Beta Testers are simply guinea pigs of the functions developed - they will not have any real say on changing/adding festures that the merchants feel need to be part of the deploy. Yes, this is generally the role of beta testers - testing systems for errors, not redesigning, demanding and derailing. A beta tester will normally get attention if they raise a genuine problem with the system that will hinder/prevent functionality. A beta tester will probably not get attention if they come up with new ideas and demand implementation. And that is why I would steer clear from any Alpha testing involvement. Best strategy is to start implementing my own transaction isolation/protection strategy from DD.

Sassy Romano wrote: So it's quite easy to mitigate some of this:- 1. Capped IM's from customers? Send IM's to email. Email busy with other activity? Set up a different email account for SL messages. 2. Avatar to avatar inventory offers aren't capped (it seems) so you shouldn't lose notecards if you prefer those. 3. Solve the capped messages that your customers get by using a mailer that sends your marketing information to someone only when they're online. 4. Direct delivery will reduce the failed deliveries due to capping 5. I had a lot of my "systems" (vendors and other business tools IM'ing me when things happened), I changed those to only send me information when i'm online, if i'm offline, I generally didn't need what I was being sent so that reduced my likelihood of being capped, leaving the only remaining issue for me being capped messages that should have been a group invite to a land group to rez prims at a mall spot. See, it's not so bad after all. With virtually no pain, stress or fuss, you can just continue BAU by navigating around LL's activities, personally I find this the far simpler path to follow. Your list of solutions does not address the RISK that DD at this point in time plans to introduce to yoru general SL Avatar account's inventory. If we can assume that LL will not address the risk of DD automatically performing direct withdrawals from the Merchant's account's inventory AND if we assume that LL will not allow Merchants the option of staying with MagicBoxes, the only solution right now is for concerned Merchants to begin the process of creating a SLM ALT MERCHANT account, establishing a new SLM store with this account, and beginning the process of migrating content to this new MERCHANT ACCOUNT. This will ensure that IM Capping is not an issue and that LL's ultimate cutover to the DD will be against an SLM isolated inventory.

Tari Landar wrote: That is my belief too, that avatar to avatar inventory offers don't count in the cap limit. But that's just been based on my own experience. Even when I DO cap, if the inventory offer comes from an av, I never miss/lose it. If it comes from an object I would normally lose it after capping. But since I turned auto accept on, I don't lose those either. Because they aren't things I have to acknowledge/accept, it just drops directly into my inventory insteading of adding to the already qued list of "messages". I never did understand why object delivery of any sort would count as a "message". It doesn't make a whole lot of sense to me. I've no clue which linden ought to be responsible for these issues(cap limits, and failed deliveries). I just know that whoever *is* in charge(if anyone), clearly isn't doing their job. Both have been huge issues for a long time now. DD may solve the failed delivery issue, in theory, I'll save my opinion for when I see it live. But it still doesn't address the cap limit, which is obnoxious in it's own right. I haven't seen a linden employee address the cap limit in quite some time. I don't hold much hope that they ever will. I know it may be a minor annoyance to some and not exactly a priority to fix. But it's been a pretty big complaint for quite a long time without so much as a second look. I don't think it would require that much work on their part to at least up the limit. Well the IM CAP Limits were never an annoyance to me personally until a couple months ago. But now - after this thread discussion - it has changed (nagatively) how I interact with SL. It is more important to me as a Merchant that I receive critical IMs, NOTICES, INVETORY ITEMS (like notecards), etc. from my customers and with those that are important to my SL business operations, than to make sure I get group notices from my casual entertainment groups that are all promoting their next events or items for sale to me. As such, sadly, I have disabled two of my busiest Group notices. I have always liked their notices as they told me which singers / entertainers that I like are going to sing where. That is now off. This will surely mean I will be missing/attending less club/singer events.... tipping less... further impacting SL economy spending. Merchants that rely heavily on Group Notices (not via subscribeomatic) to advertise sales, events, special, should also realize that these IM CAPS have been and will continue to worsen their ability to advertise. I have removed myself from any merchant groups so they will not be able to advertise to me. LL should care to remove these limitations so that it does not restrict the SL Economy. This limitation of IMs / NOTICES / INVENTORY GIVES is also another reason why I am seriously making plans to go thru the painful process of creating a new TOY SLM MERCHANT ALT that will be used to own and operate my SLM store. I am 99% sure LL Commerce / Development will not put the critical protections in place for the up-coming DD service that would allow me to configure DD to take my SLM sold items from a rezzed box or another alt. As such, I can protect my personal inventory as well as my SLM Business but migrating my SLM store to an ALT. This will also now allow my business to reduce the chances for IM CAPS since my merchant will not join any "personal" groups and their notices, not receive inventory for personal reasons, and IMs for personal reason. All these discussions with DD and IM CAPS has been very valuable and helpful to me to adjust my SLM Merchant strategy.

I also want to clarify one point that maybe some of you have lost in my strong concerns about how DD works. I think that a PROPERLY ARCHITECTED , DESIGNED AND DEPLOYED DD model is very likely a better and more flexible solution than the CURRENT deployment of the Magicbox. IF DONE RIGHT - I would totally endorse the DD model. But the fact that Brooked did not even understand why SLM Inventory Isolation for the automated DD model was important - something that most "middleman" sales transation systems would see as a mandatory design component, this is my #1 scary red flag I have. My other big concern is that the upcoming LL design of the DD will likely follow LL's historical approach to systems/software design and deployment - i.e. LL has a very poor track record for not thinking and designing strategically. They practice "knee-jerk" "shoot-from-the-hip" "solve the problem at hand" software development. So.... as much as I would be the first to endorse the DD approach, LL's secrecy, history, and response to flexible SLM sourcing of DD transactions tells me that Merchants should be scared!

Zanara Zenovka wrote: Everyone needs to stop worrying about this until the technical specifications of its actual implementation are announced, because people are making all sorts of assumptions based on a lack of understanding of how asset storage and delivery actually works. For example, people are so worried about their inventory. **The inventory is just a file structure showing the items on the asset server that you have access to. ** When your items in your inventory aren't loading, that's happening at your end - the files are still there on the asset server. Why do you think you're able to fix "lost inventory" by clearing your cache, ie by actually deleting something? http://wiki.secondlife.com/wiki/Inventory So lets all stop worrying about this DD until LL comes out with some Technical Specs on its implementation? How bout seeing ANY DETAILS? I want to see details of the design - not just the implementation. Brooke promised this at the last and final office hours meeting. To date - this has not happened. So here we are now... LL has teased everyone over two months ago that this demise of the Magicbox is coming. Some of the details have trickled out from some merchants that have insight on how it works already - even though both them and Brooke swear that there has not been any closed beta to date or information released to anyone outside the team on the details of DD. Enough details have leaked out that SERIOUS concerns on how LL might be deploying this has escalated in the forums. Brooke's ONLY forum discussion about my concerns about security and transaction isolation has been "why would we want an ALT MERCHANT as part of DD?". Nothing since from her or the team that has since mentioned it - even at the last office hours meeting. NOW... Brooke announces a request for Close Beta testers of DD... even though she has yet to still provide details on how it works and the risks that they Beta Testers might take on (some have actually been willing to risk their merchant / personal inventory without knowing even how it works to be part of this Beta). Why should we WORRY about this Zanara? Because if there was NOTHING to worry about, then why the big secrets from Brooke? Why are there no details yet even though the beta has been announced? Why does the Beta require NDA? If there is nothing to fear and you are even suggesting all us merchants shouldnt be worried about it based on your understanding on how inventory works... where is the details that will confirm that a LL DD screwup of the software does will NEVER mess up our personal inventory? I sure hope I dont have to point back to this posting of your Zanara and say... (just like the Japanese Nuke Plant) "I told you so". Here is how I say its going to go down Zanara... The closed beta will start - testers will be gagged with an NDA and testing will begin Even though we have brought up concerns that we want to see reflected into th final DD deployment - i.e. the flexibility that the DD SLM Source asset that the DD transaction draws from could be the Merchant's personal inventory OR a rezzed SLM Box OR and Alternative Merchant Inventory OR an Alternative Merchant account... it is likely already too late. I am pretty sure the DD code has already been written to meet all the functionality that LL wants AND that even if they wanted to provide us this functional flexibility - they cant/wont. We are ALL going to get the DD design and coded function that was likely written and internally already tested 2 months ago. LL almost NEVER changes their initial designs based on customer feedback. The Beta Testers are simply guinea pigs of the functions developed - they will not have any real say on changing/adding festures that the merchants feel need to be part of the deploy. For any missing new merchant demanded feature... we will likely get this statement from Brooke... "This is a good idea for a future feature - we will look at possibly adding this in an upcoming release". That will be the last we will ever hear of that. But at least I feel more comfortable that you feel we have nothing to fear about LL's development of DD - it will be flawless and because of your understanding of how the LL Asset DB and our inventory works... we have nothing to worry about. The LL I have watched deploy applications does make me worry.

So Darrius... as Tari mentioned, why is it so hard to get any straight answer from some smart Linden in the know that can tell us... Why the IM/Notice/Give caps are set so low - regardless of the countless requests to up the cap limits? What would be the issue and also the possibility that INVENTORY GIVES could be removed from this cap? I mean honestly, when you consider all the IMs, NOTICES, and INVENTORY GIVES one person gets in a day, which of the three types of in-comings would have the lowest fequency of inbounds? I can tell you for me - in a given day I might get one or two INVENTORY ITEMS vs 1 or 2 dozen IM's and Notices. So, who can we contact in LL to get a straight answer on these questions? I have a few contacts of Lindens. Can you poke around your contacts? Are there any other SL Merchants or SL Residents that have some strong contacts to a Linden Engineer to get a straight answer to these? We will have to use backdoor efforts since its rare to get an answer in the forums from LL. I think removing Inventory Gives from the caps would go a long way to addressing many of the SLM delivery failures.

Tari.... You dont HAVE TO be logged in to receive a SLM gift or delivery. I am getting the impression you believe its a MUST... its not. I have sent quite a few items to friends when they were not logged in. The problem is that with IM Capping ... and other lagging issues... there is a much higher chance of the delivery failing if the receiver is not logged in. BUT its not mandatory. IF... my friend didnt have her IMs capped and logged in ... she would likely have received her gift at login time... it was the IM caps that screwed the delivery.