Communications: It isn’t always the Lab

I’ve been somewhat critical towards Linden Lab were their overall approach to communications is concerned – although I’ve tried to temper my critiques with practical suggestions as to how things might be improved. I also hope that I’m not backward in coming forward to acknowledge those times when they do go out of their way to make the effort – such as with Oz standing front-and-centre regarding the recent TPV Policy changes.

However, when it comes to communications and impressions, the Lab is only one side of the coin. Whether we like it or not, we, as users can be as much to blame for the poor state of communications; we are quick and loud to anger when the Lab errs – or more particularly – is perceived to have erred, and we are equally slow to forgive.

I give emphasis to the concept of perception deliberately here. While there are times when taking the Lab to task may be justified, equally there are times when it is automatically assumed that whatever has happened, the Lab has acted with malice aforethought in a deliberate attempt to nefariously ruin the Second Life experience. Often in these circumstances, even the presentation of the most reasoned argument to the contrary will not prevent such views being publicly repeated to the point where the act of repetition itself establishes them as “fact”.

This was recently brought home to me once again by three inter-related incidents relating to a single code change that impacted a very specific use-case for RLV.  In all three, which included a wider exchange I had with someone in Tateru’s blog wherein the claim was again made that LL is a malicious entity, people were insistent that the code change was nothing less that “obvious” proof that LL were attempting to deliberately “break” RLV – and any evidence to the contrary was summarily dismissed.

It mattered not that the code change in question was a) limited in impact (one specific use of RLV restricted to two RC channels on the main grid); b) rolled back by Linden Lab at the earliest opportunity following a JIRA being raised; and that c) even if the underpinning issue itself couldn’t be fixed by LL, Marine Kelley (RLV’s creator) reported that it could be circumvented from within RLV. So the issue as a whole was hardly going to “break” RLV; nevertheless, people had made up their minds, and no discussion to the contrary would be heard  – even after the code change itself had been rolled back.

It’s a similar story with the mesh parametric deformer, where rumours are circulating that LL is trying to “kill” the project simply because they do not appear to be working on it; rumours that recently prompted Oz to comment on matters. Here the assumption is that  because Qarl released an alpha version of the code in January but it has yet to appear in the official SL Viewer, then LL must be trying to stop the project. That in the intervening months Qarl himself has been soliciting feedback from the community and refining the code, and has made further releases – any of which could have been adversely impacted by LL taking the code and developing it themselves – makes little difference to those who see LL’s lack of activity on the project as being somehow malicious.

I’ve dealt with the whole “LL is malicious” nonsense in both the recent and not-so-recent past, and I’m not going to re-harsh what I’ve said on those occasions now.  While it is right and proper to be critical of LL when the company does demonstrate poor judgement, it is also fair to say that there is also an onus on many within the community to stop treating every action or comment from Linden Lab as being adversarial in nature and / or intent.

Communications run both ways. While the onus is, as I’ve commented before, very much on LL needing to take the initial steps and start focusing as a company on more open and pro-active communications directly with the user community as a whole; it is equally important that we be prepared to lay aside subjective prejudices and preconceptions and make the effort to meet them half-way. Because if we don’t, then frankly, communications in either direction are liable to remain as dysfunctional as they’ve ever been.

Direct Delivery: emerging issues

Update April 1st: LL issue revised DD migration deadline based on issues occurring on the Marketplace

Update March 29th: Updates on payment problems (see below)

Update: As noted in the comments, it appears the Linux version of Niran’s Viewer is capable of running the Merchant’s Outbox without incident. If you’re a Linux user and keen to make the migration / stuck part-way through migrating, you might try it.

Issues are starting to be reported in relation to Direct Delivery.

Outbox Initialisation Failure

People are reporting that the Merchant Outbox is failing to initialise. The issue seems to be most closely related to Linux, but has also been reported for Windows and Mac, and JIRAs for all three have been created:

  • Outbox initialisation fails on Linux (JIRA VWR-28629)
  • Outbox initialisation fails on Windows (JIRA  VWR-28630)
  • Outbox initialisation fails on Mac (JIRA  VWR-28631) builds

I’ve used the Outbox on all current Viewers with the capability and using Windows 7 32-bit, with no issues. These currently are: the latest SL Viewer (3.3.0.251182), Firestorm 4.0.1, Niran’s Viewer (1.30+), and Zen viewer 3.3.2.0. However, I may have escaped issues for two reasons:

  • I am logged-in to my Merchant’s page on SL Marketplace
  • I use the English language version of the Viewers.

Linden Lab are still investigating problems, but if you are experiencing issues with the Outbox on Windows or Mac OS, you might try the following:

  • Ensure you are logged-in to your Merchant home page / manage listing page prior to trying to run the Outbox in the Viewer
  • Run the English language version of the SL Viewer

Lance Corrimal suggests the Linux problem is related to an OpenSSL issue with Linux builds of the Viewer (which has impacted Linux users’ ability to upload snapshots to their profile feed).

If you do have repeated issues with trying to get the Merchant Outbox to work, and the suggested solutions above do not work, please visit the relevant operating system JIRA and logged your error, giving full details of your Viewer environment (available by option HELP->ABOUT (Viewer name), and copying the information given there.

Payment System Failures – Updated

There are also reports that some merchants who converted to Direct Delivery are experiencing issues over payment for transactions.  While a similar issue existed prior to DD going live (transactions stalled at “being delivered”), the issue appears to be more noticeable now, with some merchants reporting that converting back to Magic Boxes seems to clear their particular problem.

A number of JIRAs are open on issues at present:

  • WEB-4441: Delivery status frozen with Being Delivered Status on marketplace transaction. 1399L lost and item never delivered (merged with WEB-4559, previously referred to in this article, now closed)
  • WEB-4580: Direct Delivery Issue – Item named with unicode characters causes order/payment system to fail
  • WEB-4596: Direct Delivery is hanging in “Being Delivered” rather than forwarding funds to Merchants even when the item has been paid for and received by the Customer. This is for NON-UNICODE Listings

Related Links

Linden Research seek Beta testers

Daniel Voyager is once again on the ball, noting on Plurk that Linden Lab has put out a call for potential beta testers.

The opportunity is presented on the Lab’s official website home page:

Call for Beta volunteers

Clicking on the link will open a form requesting various information from you.

The form (click to enlarge)

Some have taken this to be about Second Life, and have questioned the need for LL to ask for information “they already have”. However, it should be clear from the form itself that the call is not specifically about Second Life, but rather about Linden Lab’s upcoming new products.

There is no guarantee that those submitting details will be accepted for any Beta trials of products, and there will clearly be more involved in the process than simply filling-out a form (NDAs almost certainly will be involved).

Even so, it’s an interesting step for the Lab to take, and suggests that at least one of their new products is reaching a point where it is ready to be seen by something of a larger audience. If this is the case, then it would suggest that Rod Humble will be a step closer to his goal of talking more openly about the products – something he was finding hard not to do in a recent interview with Games Industry, which I reported on earlier this month.

With thanks to Daniel Voyager

Direct Delivery: the launch


Update: I’ve been informed that Viewers that have the Merchant Outbox as a folder may need a code port in order for it to work.  

The long-awaited Direct Delivery system was launched today in what amounts to a very low-key announcement that hasn’t been promoted to the Featured News section of the blogs and people’s dashboard. In development for around a year or so, the system has been subject to a range of issues, technical and otherwise and – at time – a dearth of information coming out of the Lab, something which itself has caused no small amount of concern from merchants.

What is Direct Delivery?

New DD folders as they might appear in some TPVs.(Note the Merchant Outbox FOLDER as displayed may be non-functional in the early days of DD)

For those not in the know – and there are some going on the number of “What’s that?” I’ve received when asking if people are ready for its introduction – Direct Delivery is, in a nutshell:

  • A means by which content creators and merchants can manage the goods they sell through the SL Marketplace without the need to use Magic Boxes to store inventory in-world. Everything can be handled directly from within their inventory / within their Viewer
  • A new means by which anyone buying from the SL Marketplace will receive items they buy / received gifts other have brought for them via the Marketplace, using a new section of the inventory panel / a new folder called Received Items.

The system uses two new elements in the Viewer: the Merchant’s Outbox panel / folder and the Received Items panel / folder. Whether a panel or folder is used is the choice of the Viewer developer.

Torley is back (Go, Torley!) with a video overview of Direct Delivery:

Essential Information for Merchants

As a part of the launch, LL have announced the following for the overall migration from Magic Boxes to Direct Delivery:

  • April 2 through 13, 2012: In-world Q&A sessions on using and migrating to Direct Delivery
  • April 18, 2012: All listings priced L$10 and lower must use Direct Delivery
  • May 16, 2012: Magic Boxes no longer allowed for any Marketplace listing
  • ANS is currently NOT supported with Direct Delivery – it will be “turned on in the next couple of weeks”.

Receiving Goods via Direct Delivery

Until the launch of Direct Delivery, items from the Marketplace would require that you manually accept them (via an in-world pop-up) before they would be delivered to the OBJECTS folder in your inventory.

With the launch of Direct Delivery, this now changes:

  • Any items you purchase from the Marketplace  – or which are bought for you as a gift – will automatically be received; there is no need for you to be on-line when they arrive
  • Items will be received into a new panel, called RECEIVED ITEMS, which is either a panel that will become visible at the bottom of your inventory floater when you have received one or more items from the Marketplace (most V3-based Viewers), or which will appear as a folder in your inventory (V1-style Viewers – see image above).
Direct Delivery: from the Marketplace to you (some steps omitted, example uses a V3-based Viewer with Received Items panel within the inventory floater) – click to enlarge

You can then drag and drop folders from the Received Items area into your inventory, from where you can rez items in-world as usual.

Notes: 

  1. If you don’t see Received Items ether as a panel in your Inventory floater or as a folder, then try following this link and obtaining your Direct Delivery Linden Bear (limited time offer from LL) – note you may have to log-in to SLM to get to the page. This will trigger a delivery to your Received Items panel / floater.
  2. Until the 16th May, merchants can continue to use Magic Boxes if they wish, and some may opt to do so while Direct Delivery “beds in”. Where this is the case, please note that items purchased from the Marketplace will continue to arrive in the OBJECTS folder of your inventory.

Converting Magic Box Contents to Folders for Direct Delivery

Note that boxed items can still be delivered via Direct Delivery, if required – boxes will be delivered within their own folder.

You can convert your current Magic Box items ready for Direct Delivery as follows:

  • OPEN the magic box and COPY TO INVENTORY. This will create a folder of all the items in your magic box – including the Magic Box’s own scripts
  • Delete the Magic Box scripts, as they are not required
  • Drag the first item from the Magic Box folder in your inventory to the ground and:
    •  EDIT it
    • Copy the name of the item from the General tab (highlight & CTRL-C)
    • Create a new folder in the Magic Box folder in your inventory and re-name it the same as your item (CTRL-V)
    • Open the Contents tab of the item in EDIT, and select / drag the contents from the item into the newly created folder in your Magic Box folder.
  • Make any required adjustments to the contents of the folder itself (i.e. if you have additional boxed items, these can be placed in suitably named sub-folders and the additional boxes themselves deleted)
  • Delete the original item from in-world and your Magic Box folder
  • Repeat for the next item.

This process is summarised in the diagram below.

Notes:

  1. In order for your items to be automatically linked with your existing Magic Box listings, it is important that the folder is given the same name as the original item (hence the advised use of copy/paste above when creating the folder).
  2. If a folder is named differently to the original item, it can still be linked to an existing listing, but this must be done manually.
  3. Once you have converted your Magic Box items and uploaded them to the Marketplace (see below), there is no need to keep the Magic Box folder – you can upload to the Marketplace from anywhere in your inventory.

Continue reading “Direct Delivery: the launch” →

Parcel encroachment live across the grid

It appears that parcel encroachment is now active across the grid (with thanks to Nalates Urriah).

The feature, which allows objects encroaching on one parcel from another to be returned, has been rolling-out across the grid for a while, and was turned-on last Thursday.

The feature has some guiding parameters to help manage / control the return of objects, which should provide a reasonable level of control, including:

  • For private regions, the feature must be turned on at a per region basis
  • Return is based on an object’s physical shape, not its visible shape, so while an object may appear to encroach on a region boundary, it may not actually be returned orthat it may not appear to encroach, but is still returned. LL currently list the objects most likely to suffer such mismatches as:
    • Trees and grass
    • Sculpt and flexiprims (and, one assumes, mesh)
    • static objects using the llTargetOmega() feature — they appear to be spinning but are not spinning in the physics engine
  • “Estate content” and public works content (Mainland) is protected against return (so, for example, items on a parcel that are owned by an Estate Manager / owner will not be returned)

Phantom and Volume Detect objects will still collide for encroachment. At the time the feature was first documented (January 2011), cross-region encroachment was under development. Whether this is still the case is unclear.

Some of the details as to how the feature works – and how to enable it – may change when the wiki page on the feature is updated.

No blog post / forum post appears to be on the horizon to announce the change. However, those wishing to find out more may want to keep an eye on the wiki page for updates.

New users: the shared experience

Note: This article has been taken to mean I was unaware of the Community Gateway programme. Not so; rather I wanted to focus on the Destination Islands in this piece. As it is, and subsequent to this being published, a comment was passed elsewhere indicating the new Destination Islands are in fact something of a collaborative effort between the Lab and residents. 

“Shared” is a word that has gained increasing prominence where Second Life is concerned over the last year. We’ve had Rod Humble talking about “shared creativity” and more recently, Oz raising the issue of the “shared experience”.  Now there would appear to be an opportunity available for LL to come together with members of the user community to share creativity in order to develop a shared experience that can be of great potential benefit.

As I reported recently, LL have – at some point – launched a new range of “Destination Islands” to which new users are delivered. Currently, it’s hard to see what these regions actually achieve; they provide no introduction to SL, they don’t build on information given to the new user through the Viewer installation process, etc. As some have commented, they could even result in people thinking they’ve entered little more than a cartoon-based game with no obvious goal or function.

However, they are evidence that LL are still trying to address the issue of the “new user experience” by at least providing a means to direct newcomers to experiences they might be interested in. The problem is, the entire process is very hit-and-miss, and actually leaves much that is attractive about SL completely hidden – such as building and content creation.

New destination islands: low-key

It’s Not Easy

In fairness to the Lab, providing a means of supporting new users is no easy task. As we all tend to point out, SL cannot be taught in a day, and when one goes from talking about the “first hour experience” to the “first five hours experience” – as Mark Kingdon famously did – then something, somewhere is going more than a little pear-shaped when considering new users. At the same time LL have been presented with ample evidence that help centres that rely on direct user / user interaction don’t always work.

However, there is also a risk in going too far in the other direction as well and simply providing too little help and support – and this is the issue one tends to have with the new Destination Islands; they are minimalist in approach, both in terms of appearance and information, to the point of being mere way-stations that direct people elsewhere in SL without doing anything to help them understand where they are or what they might be doing.

How much better might it be if, rather than trying to deal with the “new user experience” without actually addressing it, LL were to seek to collaborate with the user community to provide a means by which new users entering Second Life for the first time are faced with an immersive, engaging experience that helps them understand the basic mechanisms in using the Viewer and the nuances of performing basic tasks SL before passing on elsewhere.

The Competitive Edge

This could be run as a form of a competition or a request for proposals (RFP) process, with Linden Lab providing a set of guidelines as to what is required, together with access to capabilities such as the new advanced creation tools, allowing those in the community to offer potential solutions / responses that meet the requirements /criteria in imaginative and innovative ways, with people free to work either individually or as a collaborative group.

Obviously, not every eventuality for user interaction in SL needs to be covered – just enough to get users reasonably acquainted with getting on with things in SL – and the experience could finish be delivering users to the style of portals currently positioned on the Destination Islands, allowing them to continue their adventures elsewhere. As such, potential criteria for the competition / proposal might be:

  • Provide users with sufficient information on using key aspects of the official Viewer 3.x UI – HOW TO, setting-up buttons, key menu options, etc.
  • How to walk, talk, IM perhaps leveraging HOW TO)
  • Provide an overview of inventory, including the basics of wearing clothing
  • Show how basic interaction with in-world objects work: opening doors, selecting and opening objects with contents
  • Use the advanced tools to demonstrate more advance interactions with in-world objects, such as opening an item and wearing the contents
  • Provide an introduction to building in SL, perhaps with some explanation of what sandboxes are

These criteria could be met through anything from simple read-and-do style notices, to practical demonstrations and / or by the user exploring an immersive build, where they walk a path of their choosing and encounter objects and information boards along the way and are encouraged to apply what they are learning along the way (an example of this might start with a simple door into a building / in a room with the words “click me” written on it to encourage someone to click & open it).

Linden Lab would then be free to select the entry / proposal that most closely fulfils their requirements and proceed to work with those responsible for the entry / proposal to develop and enhance the current Destination Islands.

Portals to more directed experiences might even be provided along the way; for example: those particularly drawn to in-world content creation might be offered a portal taking them to the Ivory Tower of Prims or on reaching the end of the experience, be offered a portal connected to various sandboxes across the grid.

In order to simplify understanding things like the UI, portals could perhaps be included to the gated Orientation Island regions (assuming these are to be continued, given there only appears to be one left & they could be made somewhat more relevant) or to platforms over the Destination Islands, where those who need it can obtain more in-depth guidance. In turn, portals from them could allow new users to find their way back to specific elements of the Destination Islands experience.

Gated Orientation Islands: fold them into the mix?

Such an approach potentially achieves three goals:

  • Relieve LL of the burden of having the physically devote a large amount of time and effort to the development of a “new user experience” while allowing them to retain control over how such an experience should be framed
  • Leverage the core experience and familiarity with SL that the user community has
  • Promote a collaborative, shared experience between the Lab and the user community that can be used to benefit new users, the community and the platform as a whole.

Add to that the capability to “regionalise” the experience by sign-up language (so that those whose primary language is, say, Portuguese, arrive in a Portuguese Destination Island for example), then so much the better. (This may already be the case for the current system, hence the number of Destination Islands already on the grid; I’ve simply no idea.)

Working in this manner isn’t entirely new to Linden Lab  – they’ve recently taken a similar approach elsewhere in terms of issuing an RFP. Admittedly, this approach might require a little more structure from LL to avoid cried of “foul!” from elsewhere – but providing the process is as transparent as possible, there is no reason why it shouldn’t result in a positive outcome. Were the approach to be run as a competition, involvement from users needn’t be limited to those presenting entries: there is no reason why selected users shouldn’t sit on the “judging panel”.

Some would inevitably find fault were LL to take the opportunity to generate a project this way, but overall, given the potential benefit it could bring, it’s hard to find a show-stopping fault with the idea.