Advertising Beta to end

In December 2010 Nelson Linden announced the Second Life Advertising Beta, a programme by which merchants could, for a fee or two, enjoy wider advertising exposure through various Second Life “properties” (or “websites” as we call them elsewhere) such as the SL Marketplace, the SL Land Auction site, and (I assume, as it came along later) within the advertising spaces of Web Profiles.

Essentially, the programme allowed merchants to target niche markets, thus allowing them to have their products advertised directly to those with a specific interest in that market. So, for example, a merchant selling animals could set-up their ads to appear on SL Marketplace pages displayed to those people searching for animals. Prices were based on a number of impressions per month for the add, the size of the ad itself and a minimum purchase amount of some $10.00 USD.

While payments could initially only be made in USD (i.e. via credit / debit card), the basic idea seemed sound enough, and it seems that a number of merchants did sign-up to the programme.

But not enough, it seems, as the programme has now been cancelled, and will formally close on May 31st.

There has been no official announcement of the programme ending; all that has happened is that merchants who did sign-up received the following e-mail yesterday:

“Hello,

“Thank you for participating in the Second Life Advertising Beta program. Based on our evaluation of the SL Advertising Beta during the last six months, we have decided to discontinue the program on May 31, 2011. Access to advertise.secondlife.com for performance information and data downloads will remain open until June 7, 2011. For those that have active campaigns, we will ensure that all of the impressions that you’ve already paid for are delivered prior to closing the program.

“Thanks to all of the Merchants who have helped us test this display advertising beta and for all of your helpful feedback. Your participation and insights will help us drive our ongoing efforts to help you promote your products and services to Second Life shoppers. We look forward to partnering with you on future promotional endeavors.

“If you have any questions regarding this announcement, please email sladsbeta@lindenlab.com and we’ll get back to you as soon as possible.

“Signed,

“The Second Life Advertising Team”

In addition, if you try to reach the advertising site, you’ll simply get this message.

Precisely why the programme is closing remains unclear. Whether it proved difficult to maintain or whether too few merchants signed-up to make it viable long-term as a revenue generator for LL is simply anyone’s guess. It might even conceivably be because LL are planning to replace it with something more refined – although one would have thought those that had made the effort to participate would be given some indication that this was the case, if so.

As it stands the cancellation of the programme, coupled with what appears to be an attempt to quietly sweep it under the carpet does suggest the performance of the programme was less than stellar. If this is the case, then there is a question as to why it didn’t – and forgive the unintentional pun – make the desired impression.

Certainly those merchants that did participate had a favourable view of the programme and tended to find it did help boost sales. But if we’re honest, it wasn’t exactly the most well-supported initiative where LL is concerned: after the initial launch announcement from Nelson, and the video tutorial from Torley, the programme was never given another mention. During the six months it was operating, LL didn’t seek to promote it, report on it or give any further encouragement for merchants to sign-up.

Which is a shame, as with more participation and the promised means of paying via Linden Dollars, the scheme could have become very popular.

Of channels and restarts

Once upon a time server roll-outs for Second Life were handled in what, on the surface, would seem a fairly straightforward manner:

  • New code would be tested on the Beta Grid, with users reporting any bugs or issues to LL for fixing
  • When considered relatively stable, the code would be rolled out on a limited basis to the Main Grid (affecting around 20% of the grid in total) for further “testing”; if major problems were found, the limited roll-out (or “pilot”), would be rolled back
  • If considered stable, the code would be rolled out to the remaining 80% of the grid, generally around 24 hours after the pilot.

The system wasn’t flawless; the complexity of the server code meant that many small (and one would guess conflicting) updates would be “rolled-up” into a single release, often with unpredictable results, despite testing on the Beta Grid. This would result in what I call the “tidal effect”: a change would be rolled out as a pilot, then rolled back for fixing, then rolled out before being rolled back for further fixing, and then rolled out once more, then rolled out again to the entire Main Grid. Sometimes even then, it would go through one more rollback / rollout.

As we’re all only too aware, this approach meant fairly large and constant upheavals for just about everyone concerned, and the cause of much gnashing of teeth and dark mutterings towards Linden Lab.

To try and minimise the overall impact of server code updates and roll-outs, Linden Lab switched over to a “channel” system. Under this system, server code is operated across four channels: the Release Channel, with the latest “release version” of the server code (and supposedly the most stable), and three “Release Candidate” channels, code-named Blue Steel, Magnum and Le Tigre.

Each of the RC channels comprises about 10% of the total Main Grid, and is used to roll-out a “beta” of a specific server code package. This might be a series of bug fixes (e.g. specific SVC JIRA fixes), it might be a general maintenance release (e.g. security updates, etc.), or it may be related to a specific, on-going project (such as display Names, the “Fast Assets” project, the “Inventory Capabilities” project, and so on). Broadly speaking, specific projects tend to be rolled out through specific channels (The Inventory Capabilities project tends to rollout via Blue Steel, for example, as do changes related to the forthcoming arrival of Mesh) – although this is not a hard and fast rule. General maintenance releases, on the other hand, are distributed between all three channels, depending on which has the capacity at the time a release package is ready for beta testing.

So, at any one point in time, some 30% of the grid is hosting what is effectively “beta” software, but in very discrete “chunks”, so to speak, confined to known sets of simulators. The releases themselves are also smaller and more easily managed / identifiable, making everything that much easier to manage and, in theory at least, making issues that much easier to identify and correct.

Broadly speaking, this is how it works:

  • An update (be it bug fixes or whatever) is readied for release as a “beta”. If it is related to a specific project it may be targeted at a specific RC channel (Blue Steel, Magnum or le Tigre)
  •  On the Wednesday of each week, the Release Candidates for each channel are rolled out to their respective 10% of the Grid; if a specific channel doesn’t have a candidate waiting, this obviously, nothing is rolled out
  • Over the course of the next week, the candidate’s performance and impact on the Main Grid is monitored (and the channel servers may be subjected to numerous restarts. If the candidate proves particularly problematic, it may even be rolled back
  • If the candidate appears to be stable after 6 days, then it is (together with any candidates from the other two channels) rolled out to the entire Main Grid the following Tuesday
  • The cycle then repeats with the next RC in the channel dropping into its assigned servers on Wednesday.

If a specific RC causes problems, then the cycle for a specific channel may be broken for a week while the issue is worked on (for example, if a candidate on Le Tigre, say, proves that it is not ready for release as scheduled on a Wednesday, it will be “held over” for a week and made ready for release the next Wednesday).

There is one other channel worth mentioning that doesn’t get a lot of publicity: the “Snack” channel which handles releases related to (among other things) Mono-2 updates and various script monitoring tools. These are known to behave unpredictably, and so are initially rolled out to a very limited number of sims for testing. I understand that once tested, the fixes then go on for wider testing via (usually) Magnum prior to a full rollout.

The benefits of this system are obvious: if there is a major problem with a Release Candidate, it will only affect 10% of the Main Grid (rather than 20% with the old system); the releases are less complex, making it easier for the root cause of specific problems to be identified and corrected. Overall, the process means that there is less widespread upheaval across the Main Grid than tended to be the case with the old, larger-scale releases. There are many examples of these advantages; when a recent change impacted breedable horses, for example, it only affected a small percentage of horses on the grid (only those present on servers running the specific release channel software).

Of course, there are what appear to be downsides to the new system: the release channels (particularly, it would seem, Le Tigre), can be in a state of flux when problems do occur; and the weekly rollouts, with their need for sim restarts, on both Tuesday and Wednesday has been the topic of many a complaint. A minor irritant is the pop-up that comes up when moving between sims running different server releases, be they a release channel or the “full” release – it would be nice if these could be turned off by those who have no interest in what software is being run on a given simulator, just as other pop-ups can be user-disabled through the Viewer.

But, these grumbles aside, it has to be said the new system works. While it does cause a degree of pain for those “stuck” on simulators running one of the release channels, the vast majority of the grid has seen far less upset and upheaval when things have gone wrong. Certainly, the “tidal effect” of gird-wide rollouts/rollbacks has become largely a thing of the past, and while the rolling restarts associated with Tuesdays and Wednesdays might seem inconvenient when they begin, the truth is they’re probably less so than they were under the old system.

Listening and hearing

On Friday, Rod Humble kicked-off what he promised (via Twitter), to be a resumption of communications from the Lab regarding what is going on around SL and the Lab’s efforts relating to it. At the same time, we also got an update on what we can expect in terms of news on Mesh by the end of the month.

Many have critiqued LL – and Rodvik – for their use of Twitter; a commentator on this very blog took issue in the way communications are being handled –  claiming LL had “missed the boat” in their efforts. I’ve also been critical of the Lab, not just recently but throughout the life of this blog, for their lack of prowess when it comes to listening and engaging.

But, as Tateru today points out – things are changing. Rodvik is not only listening, he’s hearing and reacting- and kudos to him for doing so.

Just a few weeks ago, Theia Magic and others were making constructive blog posts and Tweets on the state of the new user welcome areas (notably Ahern and the lack of coordinated help for new users. The abuse is something a group of us had a round-robin on one evening (again via Twitter), when two of us pointed out the absurdity that when it comes to the official forums, LL are so paranoid about language and misunderstandings, that they actually blanked the use of the name “Dick van Dyke” for fear of upsetting the teens (or their parents) – and yet anyone arriving like Ahern risks being subjected to the most foul written and verbal (if Voice enabled) abuse which LL apparently deemed as “acceptable”.

Whether it came about as a result of Rodvik’s involvement in Twitter exchanges is 100% clear (although his intervention in issues is a matter of record), he has confirmed the return of the Resident Help Network. This cannot be anything but a good move – providing it is properly managed and coordinated. LL cannot be expected to keep their thumb on the pulse of everything in SL, so the proper used of something like SHN could be of major benefit – and it hopefully represents a first real step towards practical re-engagement with the user community – something that has again been something of a bee in my bonnet.

Also on Twitter, and while it received largely positive feedback, the new user sign-up process was critiqued because it only features human avatars. Again, Rodvik took time out to respond to these comments – and in his latest post he advises us that LL are expanding the available choice of avatars, “We know that the beauty of Second Life is the diversity and richness of how we choose to represent ourselves inworld. So, we’re adding 12 animal and 12 Robots and soon we’ll have Vehicles too. Then, we’ll also commission another set of human avatars that represent a wider, more diverse audience.”

Both of these responses indicate that not only is Rodvik – the man at the top  – listening, he’s hearing what is being said and reacting to it.

A critical part in communications – again, as Tateru notes – is feedback – and this is something that, while there are still frustrations over a number of issues – Rodvik is paving the way. His blog posts are refreshing as they provide information and feedback clearly, and place him squarely alongside Frank Ambrose (FJ Linden) for providing quality communications. LL aren’t out of the woods where the entire issue of company / user interaction / engagement is concerned, but Rodviks efforts on Twitter, and he openness in blogging are certain steps in the right direction.

Going social: increasing the relevancy of web Profiles?

According to Frederick Linden, we’re about to see a series of “cool social tools” and a web Profile tools released over summer (and possibly beyond) that will enhance “social networking” capabilities within Second Life.

Precisely what is coming down the line is unclear – Frederick was somewhat vague in the meeting where these tools were mentioned. However it would appear that we can expect:

  • The ability to manage Friends lists directly from web profiles (found at my.secondlife.com/first.last)
  • An ability to issue in-world, location-based status updates” from Second Life to your web profile
  • The development of a “Profile API” that will enable the functionality of web Profiles to be more easily extended in the future
  • Other undefined “cool tools”.

The first three items are particularly intriguing, and may potentially add a lot of benefits to using web-based profiles. The “location-based status updates” is somewhat eye-catching, as it comes close to describing a Twitter-like feed capability from in-world to people’s Profile pages – assuming I’m understanding Frederick’s broad hints correctly. Given that many of the SL-to-Twitter HUDs that are available have been broken as a result of changes to the server-side of Twitter, the provision of such an update capability might be seen by LL as a means of providing a reasonable alternative – although most people who use Twitter (like me) will probably want a more direct means of updating followers and friends as to what they are doing in-world.

The ability to manage Friends could be seen a boon as well – while it is nice to see your friends listed on your Dashboard, the fact that there is next to nothing you can do with the information (other than see where those who allow you Map might be in-world) tends to negate any real value in having the list visible.

However, given there is already an Action button on web Profiles, were the new API and Friends management tools to allow you to say, pay a Friend directly from your web Profile or IM them, then the value of web Profiles dramatically increases and would help them overshadow the static list presented in the Dashboard.

In fact, looking at the rough outline supplied by Frederick, one cannot help but wonder if we might not be seeing the first steps towards doing away with the Dashboard completely (which has become increasingly irrelevant since the launch of the Lithium-based Community Platform) and replacing it with our web Profile pages. Providing feeds to things like the Grid Status pages and to Events can be supplied the web Profiles, then the Dashboard becomes somewhat redundant.

Certainly, we’ve recently seen LL move positively to address privacy concerns surrounding web Profiles, actions which have clearly been intended to allay fears and increase the popularity of web Profiles. As such, making them more central to our SL lives would seem to be a direction LL would wish to move, and this would further marginalise the value of the Dashboard.

It’s going to be interesting to see what precisely emerges from Frederick’s broad hints in the coming months – and just how far things go in the other direction (an API can, after all, open up web Profiles for others to use…and possibly mine…). As such, this could well be the topic to watch between now and the end of the year.

Taking stock of your Inventory

The upcoming changes to the Marketplace – specifically, replacing the traditional in-world boxes with a Direct Delivery system is causing a lot of concern. Beta testing for the new system has begun – or is due to begin – shortly. However, even that isn’t without its problems, with people being asked – yet again – to sign-up “blind” to an NDA.

These changes to the Marketplace environment are part and parcel of a wider programme that used to go via the acronym AIS – the Avatar Inventory System. Now known as the Inventory API, this is an on-going series of improvements that are specifically targeting how inventory is handled between the Viewer, the Asset Server(s) that “store” your “inventory” (i.e. hold the “master” data for inventory items) and the simulator servers themselves. The idea appears to be to develop an extensible system that allows for better, more focused tweaking of the inventory handling code that, among other things, should allow Linden Lab to more readily identify and fix problems related to inventory management as well as making the inventory system more scalable and robust overall than is currently the case. Hopefully, this will provide:

  • A more stable inventory management environment, one that can comfortably handle active inventories of 60K+ per avatar without the current issues and frustrations people experience on hitting these levels (inexplicable inventory losses, inventory failing to load or constantly having to box-up “unused” inventory simply to get the damned inventory “list” to download to the Viewer in a reasonable space of time, etc.)
  • A more robust means of ensuring Viewer, simulator and asset server remain synchronised in terms of inventory asset data, leading to fewer user-experienced problems when moving around the grid in terms of object rezzing failures, etc.

Overall, the changes being planned are all to the good; one of the biggest banes of comfortable Second Life living is problems associated with inventory; as many are all too aware, when problems occur with inventory vanishing, 98% of the time users are effectively left to suck-it-and-see in attempts to resolve the problem using a variety of care-worn techniques such a manual cache clearing in the Viewer, frequent relogging, frequent sim hops and inventory loads – with (sadly and most irritatingly) an almost “well, t’ain’t our problem,” attitude from LL’s own help desk.

Discipline

However, the new system is not going to be all plain sailing. In order to work effectively, the new system apparently requires your inventory to be reasonably-well ordered and structured. In particular, Merchants using the new Direct Delivery system will have to have their goods specifically arranged and ordered, while there will be a limit as to the number of individual items that can be placed in a single folder (rumoured to be around the 650 mark).

Some have seen these requirements as being negative points against the new system; I have to say that personally, I find it hard to understand why. While it is true that many don’t manage their inventories that well, the fact of the matter is that we’re actually provided with a basic system of default – and protected – folders for inventory items by Linden Lab themselves (Body Parts, Clothing, Objects, etc.), which can be readily used to create a well-ordered  inventory system, providing one applies a little discipline.

I also suspect that the majority of merchants are like me, and already have a well-defined folder structure for their goods. While such systems more than likely won’t meet the requirements that the new Direct Delivery system, they do mean that merchants already have the necessary self-discipline to get their products sorted and ready for the new system. For others, many people already use the #RLV “shared folders” system – and not necessarily for BDSM-related items (although this is obviously its primary use); so again the concept of a well-ordered inventory may not be so alien to people as some may think.

Whether the new system will require an complete overhaul of a person’s inventory remains unclear; we’ve had the Client-side code in both Viewer 2.x and Viewer 1.x for night-on two years now with it impacting on everyday inventory manage, so again, undue critique of AIS / Inventory API in the widest sense  may be a little premature. And even if the new system doesn’t require widespread changes, for those that tend to leave everything in the top level of their inventory after unpacking (i.e. in folders directly under MY INVENTORY), the fact that Linden Lab are taking steps to try and make the inventory management system more robust might be seen as a reason to perhaps get things sorted.

If nothing else, the default folders provided by the Lab have a big advantage over user-created folders: they cannot be accidentally deleted. Ergo, moving, say, all of one’s clothing folders under CLOTHING, gives one (albeit small) measure of protection against accidentally right-clicking on a top level folder and deleting it and then purging it from Trash before you’ve taken stock of what you’ve done. Furthermore, and while I admittedly have no first-hand experience of this (I’ve always kept a very well-ordered inventory), there is much anecdotal evident that ordering your inventory within the default folders provided by LL decreases the chances of items becoming lost or vanishing.

Yes, there are issues around  some  of elements of the AIS / Inventory API – such as the Direct Delivery system  – in terms of the impact they’ll have elsewhere in Second Life (such as the impact on in-world stores on a variety of levels, some of which I touched on in my post on Direct Delivery itself. However, I’d respectfully suggest that such concerns are more a part of a wider dialogue that is required about the Marketplace in general, and its potential impact on in-world revenue streams – including LL’s tier-derived income – rather than restricting them to discussions on AIS / Inventory API in and of itself.

At the end of the day we’ve all suffered from inventory issues at one time or another. Given the woeful track record from LL in terms of helping people deal with the issues they encounter – such as frustratingly being able to see a portion of their inventory but be unable to use it, simply because the current system has “moved” folders up to the same level as MY INVENTORY, and thus made them inaccessible – then I’d tend to take the attitude that anything that comes along that decreases the chances of such errors occurring in future and which more readily enable LL to rectify inventory errors is to be welcomed; any additional effort required on our part to help get the system working more efficiently notwithstanding.

Local payments update

Frank Ambrose – FJ Linden – is an unsung hero of Linden Lab and Second Life. Since he’s been a part of Linden Lab, he has worked hard to communicate openly and directly with users in a manner that really cannot be faulted – and which should be taken as the standard be which others in the Lab should communicate.

Changes in the way non-US users can make payments has been the source of much controversy of late. Overseas Paypal payments were no longer acceptable, and the new local currency system has been less than confidence-inspiring.

These issues have lead to concerns among users as to what happens if payments fail – as has been the case – and Frank’s latest post on the subject is clear and concise on matters, and provides precisely the required level of reassurance on matters that is needed.

It’s also good to see that it actually shows up on the Featured News list on the Dashboard for once. Is this a sign that that particular problem is being fixed?