Sassy Romano

Hmm, that's not my profile, my profile in in the viewer not a web page, that one is similar to my profile but it's not the same. I'd still like to see the top sellers shown as the products in the result of the search when searching for a merchant. What's the logic in showing non best sellers in the thumbnail results? That's not sensible. We want to promote what sells, not just randomly pick some products. Please ask the dev team to engage with the stakeholders (that's us) to ask us what we want. Thanks, it'd work well, trust me!

PeterCanessa Oh wrote: Monti Messmer wrote: the scripters might want to kill me for ... BAD scripters might want to kill you, but they probably don't even realise they are bad because they don't keep up with forums and wiki. GOOD scripters would almost certainly agree or explain why they have scripts for 'trivial' things. We are always concerned with the quality and efficiency of our scripts. But please remember scripts are the last priority for processing-time on SL servers so they can only cause each other to lag. If you are experiencing other types of lag - moving around or 'odd' collisions between things, for instance - it will be connection/internet/graphics card issues or an overworked physics-engine. Presently this is not exactly true. The mono rez issue in SVC-3895 would not exist if scripts did not exist. I know this isn't exactly the scripts themselves which is why I said "not exactly" but rezzing or tp'ing into a region when laden down with hundreds of mono scripts will very much lag the sim, cause movement issues etc. and not just cause each other to lag. Also, having worked a homestead pretty hard with vendors and servers, I can tell you that it very much slowed down regardless of who else was around so i'm very unconvinced that scripts are so partitioned off that they don't affect anything else but themselves.

To begin with i'll say that I agree with you however there's a but... In order to help those with less interest in building but just who want to shop and look good so we have texture huds, resizers and similar. I have no problem with these as long as the product remains copy and modify so that they can be removed or worst case, copy and scripts that can be deleted. Unpacking scripts, I don't mind, the item isn't permanently rezzed and for those who insist on no rez shops, at least people can get to it there and then. Sending people away from a shop to unpack is in my mind, not a good idea, they're out of the shop at that point, forget to return, no further business. As for vendors, if you want sales tracking, redelivery facilities, ability to configure all your vendors gridwide from a central admin point, you won't achieve that with boxes set to sale. So there are some ways which are better and as I said, I do agree with the sentiment but it has to be weighed against encouraging users.

Actually, I can see that with Direct Delivery, it would be quite straightforward to build in the ability to have a common store front across multiple creators. Lets say they all wanted to create bunnies that they could sell, lets call the shop "Magic Bunnies". If each had say a folder called "Magic Bunnies" within their "Marketplace" folder, the one the would be the source for direct delivery. Then a simple web UI for "share this folder with store <insert name>" so Magic Bunnies. They could have other folders that they could choose to share with another store independent of Magic Bunnies. They *could* also do the same for any item that was uploaded via magic box, it would only need an option in the web UI to choose which store the product was to be associated with. My partner and I do this for our own vending system, we each have our own products in our own servers but can configure, choose and manage the items that make up our combined inworld shopping experience. The implementation of Direct Delivery doesn't change their ability to do multiple storefronts or shared merchandising, the source of the products is of no consequence, it's the continuing inability to follow even the most basic project management methodology of engaging with the major stakeholders that prevents any sensible input around this and other highly valuable features that are of benefit to merchants. I do agree though that they would have better a chance at building this from the beginning with all the stakeholder requirements in place and actually understood. It is beyond my comprehension as to the continued practice of developing a solution with (apparent) utter contempt for those who use it, especially in the face of such rich feedback.

Ai Velde wrote: I don't know why the merchant would say to use the redelivery terminal in-world. Last I checked, items purchased on the MARKETPLACE were on the marketplace server, not a store delivery server in world for in-world shops. If you purchased the item inworld and the items were on a delivery server, you could use the redelivery terminal and get them redelivered. But the Marketplace is separate. You can't use an in-world redelivery terminal to redelivery marketplace delivered products. You can if your inworld store vending system permits it

My response is that while searching on storefront/merchant is welcome, it would be far more sensible and logical to present thumbnails of products that were the merchants top selling ones. I can see no logic whatsoever behind the selected ones of mine.

Not sure I understand. What do you mean *exactly* by "one avatar licence"? If you only permit one avatar to use it, why bother giving Transfer permission? Or do you mean "Regardless of how many avatars the human has, only the purchasing avatar may use this for their products"?

It's in the queue to be processed/delivered

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.

A typical Project worksheet for stakeholder involvement:- http://sites.google.com/site/ravisat/Project_Planning_Stakeholder_Involve.GIF The one for LL results in a 404.

We don't know the exact process yet Darius, hence my mention of not adding any more FUD. I understood what was being proposed and yes doing nothing is often preferable but doing something that's little effort and even has both short and long term benefit is even more preferable. Well it is to me anyway.

Hintswen Guardian wrote: Sassy Romano wrote: Plus needing a bit of land for each of those box locations. Many merchants who have multiple magic boxes also have multiple stores, there are also rent a prim places which will allow people to keep a second box rezzed without the need for extra land. Sassy Romano wrote: As for redundancy, redundancy of what? Adding multiple extra links to the same central asset UUID in the asset cluster doesn't gain anything if direct delivery is already sending from that central asset UUID. Having lots of apparent redundant magic boxes would be of no benefit if the central asset server was not available. The scripts. If the region is down the scripts will not be running and cannot deliver any inventory. It has nothing to do with the asser server not bieng availiable. Sassy Romano wrote: Bloating inventory? Surely creators already have the original version in their inventory of their item? I'm expecting DD to introduce a "Sales folder" and all you'd do is add an inventory link to that or move the original. No bloat. Not all people keep their original copy in their inventory. I know some of my products are not in my inventory, only my Magic Boxes. Multiple boxes = lots more administrative effort, I mentioned, that, i'm happy to move from that model. You mentioned scripts, there will be no scripts needed for Direct Delivery, that's the point and why I said multiple magic boxes in the way that was mentioned will not introduce any redundancy at all, only perceived.

Toy...on all of what you just said here.. I AGREE WITH YOU! ok maybe not all of it, after all, there will always be those in a more privileged position who have more favours, better profile, more "general appeal" but I certainly don't want my LL subscribed email for communications from the company to be reduced to nothing more than irrelevant spam. As someone else already commented, they can't send us useful information like when a product has been flagged, reviewed or whatever but can spam us without a moments thought. We need an opt out of Dash Deal spam without any doubt.

For those with many products, splitting them across boxes and then maintaining mutliple copies of those magic boxes can be an unwanted administrative burden, prone to accidental product version issues, plus needing a bit of land for each of those box locations. As for redundancy, redundancy of what? Adding multiple extra links to the same central asset UUID in the asset cluster doesn't gain anything if direct delivery is already sending from that central asset UUID. Having lots of apparent redundant magic boxes would be of no benefit if the central asset server was not available. Bloating inventory? Surely creators already have the original version in their inventory of their item? I'm expecting DD to introduce a "Sales folder" and all you'd do is add an inventory link to that or move the original. No bloat. Also bear in mind that the object UUID inside the magic box is just a pointer to the item in the asset server so ... if all you had to do was drag back the content of your magic boxes, all those that you scattered around, to the "Sales folder" and that was it, how hard would that be? I could have done that faster than write this response and I don't know if it would be as simple as that, i'm sure it could be made so that it's not I do agree that the Marketplace team operates in isolation from their key stakeholders and display little evidence of what we actually need and how their changes affect us but if I have the opportunity to participate in the beta then i'd rather know what i'm going to be dealing with than not. We shall see, until then FUD really doesn't help anyone.

Darrius Gothly wrote: There's 50,000+ merchants on Marketplace. That's 50,000+ voices that can expand their understanding of what it takes to be a Merchant. To date, they seem to have ignored all 50,000+ .. and that's a damn shame. How quickly you have forgotten Bunnygate, they listened to the bunnies...

In that I agree Darius which is why they are asking for people to sign up to the beta and are asking for feedback. Again, the present FUD that some have over the NDA is misplaced since merely applying to join does not place anyone in a detrimental position prior to actually reading the NDA and accepting it. Of course if after reading it they're not happy then no need to participate but if nobody does, then people will happily complain that Direct Delivery doesn't do what merchants want and they still won't be happy. LL cannot win. Anyway, yes this belongs in the other thread but it wasn't us that started on about Direct Delivery

I don't share your paranoia over this perceived risk regarding DD. As with the above list, IF there is a risk which I actually doubt very much there is, then as with the actions I listed, i'll mitigate that in an appropriate way. DD will be pretty much a SQL SELECT statement of a UUID from a database table. It would be pretty hard to crosslink that UUID with just any UUID any more than if you rezzed an object and instead of rezzing a table with a particular UUID you ended up with a chair or a shoe instead and exclaimed "huh? I rezzed a chair and that's what I got?"

Darkraven Danick wrote: but how did I know! >.< nobody comes up and tell me that they recieve the refund from LL, but they just ask for refund from me.... and I already refunded.... magic box finally goes back to normal and delievering products now.... I even make it 2 boxes in two different sims so that they always has back-up delievery... (did anyone ever said that they will not double-deliever? but I just saw it happened.... >.>) While I have a very willing policy around helping my customers inworld, the Marketplace is outside of my control and that makes my options somewhat different. Why did you refund if you hadn't received any money? It's wise to understand the way that Marketplace works and what the remedial action is before getting in a fluster. What I generally offer with such issues is for the customer to purchase again but inworld this time and if their payment does get refunded by MP the they're happy and if their transaction does complete and they end up buying two, then I'll gladly refund them for one of them. I find this the fastest and simplest resolution since most people want their item "NOW!" Your mistake was to circumvent the Marketplace process by refunding and then having it also do the same.

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.

No it won't but that's not Toy's rant here which is about marketplace delivery failures which will be addressed with DD. That page about capping has also changed, the old page always referred to object to avatar inventory transfers as getting capped while avatar to avatar did not. That is still my belief to be the case.

Toysoldier Thor wrote: I think removing Inventory Gives from the caps would go a long way to addressing many of the SLM delivery failures. They won't spend any time on this for SLM because direct delivery will render the effort uneccessary as has already been stated by others. Whether it's right or wrong there are many other features that do require attention that will not be fixed by direct delivery, such as inventory offers going to trash when you have busy set. https://jira.secondlife.com/browse/SVC-2707 What about access to transaction records older than 30 days? That would be a huge benefit and there's no excuse for not doing it. LL will have it all in their SQL database, it's a mere SQL query to retrieve it, ask about that one while you're on. There are many limits in SL, any software will have constraints for various reasons, some arbitrarily chosen at the time, others that come back to bite and some that are later realised to be plain silly and some that are based upon calculations around the storage required data processing. Here are the limits for SL http://community.secondlife.com/t5/English-Knowledge-Base/Limits/ta-p/700099 It is what it is but this isn't one that's required to fix Marketplace, DD will address this.

Again, if the money has not reached the seller, you get a message telling you what action is being taken. It is not up to the merchant to refund or deliver at this point, you should follow the Marketplace procedure which is to file a support ticket. There is a category precisely for non delivery of item.

It hasn't scammed anyone, the money hasn't disappeared, you don't have to refund anyone. Money goes first to Marketplace Linden, then if the sale fails, it will refund but it can take up to 8 hours. If it fails to do this, then the published resolution is for the customer to file a support ticket and there is a category for delivery failure. In some cases, LL support is faster to resolve this than some merchants who never bother to reply. That is the end of the drama.

No need to write a ticket, just read the guidelines:- Adult Content Is Only For 18+ Year-Old Residents. Strong sexual content, including:Depictions of anatomical nudity, including exposed genitals and/or female nipples. Sexual avatar animations, including ones depicting explicit or highly-realistic sexual intercourse or oral sex. Content or items intended for use in, or primarily associated with, erotic or sexual roleplay. Regardless of whether there is nudity, the word "sex" in the title, if the items is intended for use in erotic or sexual roleplay then it's adult. sex bed...what do you think? This then puts lingerie in the same category. Equally, the marketplace is infested with NON adult items coming up when Adult only is chosen. That's equally unacceptable and is nothing more than wrong category spam. If people have made the conscious decision to search only for adult content, they shouldn't be seeing page after page of freebies which are unrelated.

General consensus from the last meeting was that the value in attending was low. Typed excruciatingly slowly, no time for questions (only a rare hand picked easy to answer set were chosen). Save everyone the time and frustration, "JUST BLOG IT".