The Project to Save Second Life™
One of the most common complaints voiced on the Second Life Discussion boards is this whole issue of “Negativity”. I think this comes about because a lot of what is posted are complaints and gripes about how Second Life (or some other LL Property) has failed, glitched, broken or just plain not done the expected thing. The central argument the “Anti-Negativity Crowd” uses is the assertion that a steady diet of “This SUCKS” does nobody any good. I agree.
Thus was born The Project to Save Second Life™. The mission of the project is to set out, in a series of “Action Statements”, exactly what should be done to “Save” Second Life. Of course, the caveat here is that “exactly” refers to my opinion. This means that whatever I propose, suggest, recommend or just plain blather about … that’s stuff I think should happen.
The goal here is to present a Positive series that outlines ways the overall product can be improved and enhanced. I want to show how, with rational and realistic changes in course, goal and execution, the Second Life platform can be made more attractive to its users (new and old) and its overall ROI improved.
I will limit each post to a single topic or product function. Each post will explain the current implementation and functionality as best as possible. From there I will outline ideas for how to improve it.
There will be no logical progression through the topics. They will be posted as I think of them and feel like it. If you have a topic you’d really like to see me tackle, by all means suggest it.
Bundle In-World Search and the Marketplace
I suspect most of you are right now thinking ‘those are two different things!” Well, no they’re not. This is where I think SL can be easily enhanced. We’re already seeing some of that in the current plan to remove Magic Boxes and use delivery from our Inventory. But IMO that’s one step too short. Allow me to explain.
In-World Search – What It Really Does
The purpose of In-World Search is for a “Shopper” to find the exact product they wish to purchase. Yes, I realize that’s a really specific description. Search has many more uses than that. However the most profitable and (I believe) most utilized purpose is for people to find something they want to buy.
The really nifty thing that the LL Search Dev team has done is to retrieve a Parcel’s contents and associated data record and format it into a web page. Their next logical step was to shove the resulting page into a Web/Document Search Engine … namely the GSA from Google. Great start … and a stumble.
The Marketplace – What It Really Does
The Commerce team has just turned loose their Xstreet replacement dubbed “The Second Life Marketplace”. Taking the definition of “Product Inventory” that Xstreet utilized (meaning the contents of one or more Inventory Server boxes), the Marketplace dressed up the front-end, added a shopping cart and basically redid the whole experience from top to bottom. Growing Pains is a polite description of its acceptance by the Merchant and Shopper Communities.
However the Marketplace does one thing very nicely … it presents the “Product Inventory” in a very slick, even artful format that is uniform and easily viewed. Right now the major difficulties involve management of the Inventory and delivering products en masse; the old Magic Boxes just cannot really handle the load sometimes, On the table and soon to be released is a development plan that will replace the Magic Boxes with delivery straight from the Merchant’s Inventory. It’s not clear yet how that will work as far as exact details, but the goal is technically elegant and removes the weakest link, those damn Magic Boxes. In short, the Marketplace has been a halting stumble, hopefully about to be followed by a great step forward.
Head-On Collision – Marketplace and In-World Search
The one commonality that seems to have escaped everyone is the simple fact that both projects turn a logical grouping of Objects that exist in the Second Life virtual world into a web page.
In-World Search does a very Spartan rendition, primarily due to the fact that they have so little related data to work with. The Marketplace does a better job, but it also provides tools to upload and maintain the extra related data. Things like product photos, docs, descriptions, keywords, etc. can be associated with each Object. The only real difference is In-World Search delivers the Shopper to the products, whereas Marketplace delivers the Products to the Shopper. But hey, it’s a two-way system, so why does that little difference matter?
Step #1 – Add In-World Stores to Marketplace
The Marketplace needs a new Inventory function … call it “Add In-World Parcel”. A Merchant can add the URL (or just UUID) of their In-World store to the Marketplace. The result will be exactly as if the Merchant had just added a new Magic Box complete with its own unique inventory. There will be some additional data that can be used immediately; things like the product price, In-World Location (Slurl) and a simple description.
The Marketplace will create a corresponding Product Listing page just as it does now for Objects in a Magic Box. The Merchant can then use the existing tools and functionality of the Marketplace to add the In-World Objects to their web site Store.
Delivery of In-World Objects
This is where it gets a bit tricky … but only sorta. As mentioned above, the Commerce Dev Team is readying a release that will eliminate Magic Boxes. They are doing this by means of direct Asset Transfer from the Merchant’s In-World Inventory directly into the Recipient’s Inventory. There is no need to send commands to some external device; the Asset Transfer is accomplished by means of a direct data copy. Not only is this much more reliable, it is also faster and easily validated.
In order to arrange delivery from an In-World Store to the Recipient, it’s also just a data copy … kinda. The problem is that there are nearly as many different ways to deliver a product In-World as there are Residents logged on at any one time. From the very simplistic “Mark Item For Sale” checkbox to the sophisticated and highly functional Server-Based Vendor systems, the range of delivery and payment methods covers a massive range. So how do we arrange delivery of In-World Products in a fashion that covers every variation and exigency?
The Two Types of In-World Objects
There really are two Types of In-World Objects that are delivered to a Shopper as the result of a purchase: Direct Sale and Scripted Sale. The Direct Sale type uses the built-in “For Sale” checkbox to indicate the Object may be purchased. This option enables the ‘Buy” option in the popup Context Menu of the Viewer and automates the transfer of money and Objects to complete the sale. It has the advantage of being very reliable.
Scripted Sale Products have a much more complex process. Instead of using the “For Sale” option, this type of Object incorporates a script that can detect the payment of money, calculate any applicable refund or credit, record the sale and deliver the product. Scripted Sale Products have the advantage of flexibility but they lack a standard interface.
Marketplace Purchase of Direct Sale Products
The simplest enhancement is extending the Marketplace functionality to include the ability to Sell and Deliver an In-World Product. The interface already exists by virtue of the popup Context Menu. All that needs to be added is the inter-process communication to initiate a Purchase/Deliver transaction. Because the Marketplace also allows delivery to someone other than the Purchaser, there may be a need to add that functionality to the existing In-World Buy process, but that should be a fairly straightforward enhancement.
An immediate advantage is the ability to “Gift” a Product from an In-World store without the need to use a third-party Vendor system. I’m not dismissing Vendor systems in the least, but the reality is that a lot of small to medium sized Merchants would love to add the Gifting ability but simply cannot justify the expense or maintenance of a Vendor System simply to gain that feature. Extending the Marketplace to provide that feature encourages Merchants to establish an In-World presence and provides all the record keeping and transaction history extant in the Marketplace. Of course it also benefits from the fact that it eliminates the Magic Box and simplifies product delivery to the basic Asset Transfer Data Copy mechanism of an In-World purchase.
Marketplace Purchase of Scripted Sale Products
As mentioned above, the major drawback to this enhancement is the lack of a standard interface into the scripted pay/deliver mechanism of each type of Vendor. As it stands now, scripted vendors use the “Money” event that fires when a Shopper pays the Vendor. There are other on-ramps to starting the purchase as well. For example, some Vendor Systems allow the use of Gift Cards or Store Credit. No matter how the price is paid, the process begins with a scripted Event. Thus the logical method to enable Marketplace Selling of Scripted Sale Products is to create a new Event in the Second Life scripting language. This new event (call it “Marketplace” for example) would include the same details as the Money event does now, but could also be extended to include a separate UUID for the Recipient as well as more detail regarding fees charged and a unique Transaction ID.
The script language would also need a new function, called “llVerifyMarketplace” for example, that could be used to validate the data received through the initiating Marketplace Event. It would also be good to add a function to indicate delivery of the Product to the Recipient. This would allow the Vendor System to signal the Marketplace that delivery of the purchased product was completed, stalled or failed as needed. A good name for this new function might be “llMarketplaceDelivered” or similar.
Alternate Idea: Money and Asset Transfer operations often work well and reliably when implemented as a State Machine. An alternate to the llMarketplaceDelivered” function mentioned above could be one called “llMarketplaceOrderStatus”. The function could be called with various values indicating the State of the specific order. Ideally it would be implemented in an asynchronous fashion so the two parties are not “handcuffed” to each other during the process.
Advantages of Unified Product Sales and Delivery
There are many advantages that can be gained by unifying these two methods of Product Sales and Delivery. For starters it would erase the line currently dividing the two camps, In-World Sales vs. Web Site Sales. Because the two interfaces both deliver the exact same product, there is no longer a distinction between viewing the product directly In-World or by pictures on a web page. Whichever method is most apropos can be used.
If the Shopper just wants to do some offline shopping, they can use the Marketplace’s web interface, review their selections and make purchases as they do now. The only difference will be that the Merchant will not need to maintain a separate Inventory in a Magic Box nor even a separate folder within their personal Inventory; their In-World Store will serve as the Inventory Stockroom.
If the Shopper finds a product on the Marketplace web site and they want to get a more up close and personal look, a simple In-World TP directly to the product is all that is needed. Because the Marketplace will be delivering from an In-World store, the location information is automatically provided. This saves the Merchant the extra overhead and hassle of making sure Slurls to products are correct and up to date.
If the Shopper starts out In-World and finds a product in a store that interests them, they will have a very easy place to reference the full product description complete with details about operation, extra images, warranty information, upgrades available, etc. All the enhanced information the Marketplace provides for a product could be rapidly retrieved with a simple lookup. It would even be a simple process to add an option to the Context Menu that directly opens the proper web page either in the Viewer’s web browser or an external browser (depending on user preference settings).
Additional Benefits – In-World Search
Another major advantage to the marriage of In-World and Marketplace Inventory is seen in the way it affects In-World Search. At present the biggest problem facing the LL Search Dev Team is how to properly determine Relevancy while simultaneously guarding against gaming. As a step in this direction, the Marketplace has defined a new field for Keywords. Search within the Marketplace uses the Product Name, Keywords and Features as “Relevancy” targets. Granted it needs a bit of polishing yet, but it has good intentions. Mixing in the overall sales popularity and customer feedback will further improve the accuracy of Searches.
It also helps guard against one of the most common forms of gaming Search, Spamming or Keyword Stuffing. Since only those products marked for Sale and Listed on the Marketplace will be indexed and searchable, Merchants will not clutter their store listings with tons of objects that only serve to boost their relevancy for specific search terms. If they don’t have a product for sale that matches, they won’t “score” for that product in a Search result.
This does not eliminate a common form of Gaming on the Marketplace, Keyword Spamming in the various relevant fields, but it does centralize the problem into one location and makes it easier to monitor and manage. Any mechanism that reduces the overhead time policing listings and also “encourages” proper Product Listings has a double-edged benefit. At the risk of sounding trite, it’s one of those “Win-Win” solutions.
Conclusion – We All Win
Nothing presented above is a difficult design change. In all honesty the two ends of the bridge are already built. What is needed is a fairly simple final span connecting the two into a single functional bridge. It is an effort though that will require the intimate involvement of most every top level Development Group within Linden Lab, but since when is company-wide cooperation a bad thing?
The Server Group will have to add functionality to handle the new Asset Copy requirements, but since they’re already doing something similar for the push to eliminate Magic Boxes, they will have all the framework laid in and fluid enough to extend a tiny bit more.
The Scripting Group will nave to add some Events and Function Calls. Considering the ease with which they implemented the new llSetLinkPrimitiveParamsFast and related calls, I can’t honestly expect the new enhancements to be a pain either. All the “buttons inside the machine” that they will have to push are part of the Server Group’s work product.
The Search Group will need to cooperate with the Commerce Group to work out the interface between In-World Parcel listings and the Marketplace’s Product Lists. At present the external translation process already exists; it’s how they get the contents of a Magic Box to show up as Product listings. They should then marry the Search Engine development efforts into a single unified Search All, This new form of Search will primarily work like the Product Browse and Search functions of the Marketplace, but should be able to adapt to In-World style Search depending on User selection or some form of Contextual Cues. (For example, I’m standing In-World in a store and I want to find out where I can find the “Pink Raspberry Lemon Shorts”. Search All should recognize that I want an In-World search and “bias” the results accordingly.
The Viewer Group – The Lens to the Future
The Viewer Group is going to be standing on the shoulders of the aforementioned Groups and their efforts. Frankly I think the Viewer could be greatly improved if they gave it an “Offline” mode in which Money, Inventory and Message Management functions are combined with basic web browsing. The only functions not permitted in this offline mode are those that require moving or modifying an In-World Object. This would allow a Resident to handle a large number of their basic management functions without having to “Log In”. A small snippet of this functionality is already seen in the Marketplace’s ability to “Redeliver” a Product.
Furthermore, the Viewer really needs to be extended to enable moving money from account to account as needed, as well as handling basic messaging (IMs and perhaps Group Chats) without “Rezzing” In-World. These peripheral functions most often are short in duration but high in priority. Because they are implemented best in the Viewer, what can and should be a short process turns into an exercise in frustration as distractions arrive immediately upon logging and rezzing in. Being able to handle them without going “Online” (and thus interruptible), they can be held to short duration but high precision tasks.
I don’t have a ready made answer for that right now. Perhaps in a day or two, something will cross my desk that I’ll decide to share. But whatever it is, I promise it will piss at least one person off. *grin*