[Viewer 2.5 Beta Now Available]

Once your computer has a Facebook Connect or Facebook cookie in it, that innocent little "Like This" button whooshes up your browser history and all sorts of other data as soon as you start loading the page.

No it doesn't - it just lodges a cookie on your computer saying you visited that page.  That helps Facebook with targeted advertising (love it or hate it). It does not send your browser history to Facebook!

Specifically:

It doesn't touch your "Browser history" as such, in the technical sense of what makes your "Back" button in the browser work, and what you yourself can see you have visited.

It allows Facebook to one by one gather your unique browsing history between pages which has a "Like" button as you hit them, whether you have a Facebook account or not. If you have a Facebook account, it is also identifiable to that account.

[Viewer 2.5 Beta Now Available]

Wait ...so you're saying this thing sells me out to Facebook just because I opened somebody's (web) Profile????

Could you and/or Soto please post instructions on how to alter the hosts file to disable this Glorious Triumph Of Linden Fail?   I'm guessing there might be far more than passing interest ....

In fairness, this is just LL uncritically jumping on the bandwagon; not really them having designed the system to sell out their users.

But a growing awareness of just how dirty Facebook is playing is a good thing. It would be nice to see companies push a little back.

[Viewer 2.5 Beta Now Available]

Do you think that Facebook is somehow accessing your profile via your own open browser window? That's not how it works.

That is exactly how it works. Because the "Like" button is loaded from Facebook's server, even just seeing the button tells Facebook "this browser just accessed this page". And if Facebook has put an ID cookie on your machine the last time you logged in there, the page view is directly connected to your Facebook profile. (The cookie can be read since the "Like" button is an iframe from Facebook's server, and hence not technically cross-site).

Of course, the best defense against this datamining is simply not using Facebook in the first place, but they still get page statistics, even if not directly keyed to your personal data.

ETA to point it out explicitly: This is the "Like" button on my profile page, running in an iframe, which essentially is a browser inside the browser:
https://www.facebook.com/plugins/like.php?href=https%3A%2F%2Fmy.secondlife.com%2Ftali.rosca&locale=en_US&layout=button_count&show_faces=false&width=90&action=like&font=arial&colorscheme=light&height=21

[Viewer 2.5 Beta Now Available]

I just want to point out that I have no problem with web profiles. Whether the bits travel over HTML or any other protocol is irrelevant.

Let us focus on the functionality and philosophies we want and do not want. Load time is certainly one of the things I care about; as is not being datamined by a corporation with a stated disregard for private choices, no matter which technology is used for it.

(Not being able to drop inventory on the profile grates a little on principle, but realistically, I find that I always need to write some information to go along with it, so dropping in the IM window is perfectly ok for me
That said, so far web profiles have cost me performance and one use case, and not given my anything, which does make me question the rationale behind the technology change).

[Viewer 2.5 Beta Now Available]

As a related note, remember that the "Like" button is a tracking device which feeds browsing behaviour to Facebook even if not clicked.

It is, to my knowledge, considered "Information we receive from third parties: Information from other websites", which allows Facebook (by their own policy claims) to use it for 180 days before anonymizing it!

While they will only use such personal information in ways described by their current privacy policy, EFF's timeline over Facebook policy provides a good overview of what we can expect that to mean.

The point is: People do not want to get pulled into this datamining operation, even if the "Like" button may have a fairly limited scope currently.

ETA to make this perfectly clear: The Like button is code running from Facebook's server, and as such has access to your Facebook profile. If you so much as look at a page with a Like button, Facebook considers that valid information about you (as in, your identified Facebook account) which they can use for whatever their current policies claim is acceptable use of private data for the next 180 days.
I'd imagine data about which SL avatars and groups you have looked at, correlated with your RL Facebook info, would be fairly valuable information for some people.

[Viewer 2.5 Beta Now Available]

All other opinions aside, the web profiles do objectively seem to be an order of magnitude slower to load than the old profiles.

It may be a justifiable tradeoff for some other functionality, though then we're back to whether waiting 8 seconds is worth a Facebook "Like" button, which seems to be the only added "benefit". Are there plans to extend the web profiles with further functionality, so the choice of a web platform is essentially a matter of easy updates?

[Viewer 2.5 Beta Now Available]

Just a comment to point out that when you see the profiles inworld, they have an extra button with most, if not all (I haven't done a one-to-one comparison) of the usual functionality, and likewise, the notes are also still there.

Hitting the my.secondlife.com/profile.name page from an external browser gives a somewhat crippled version of them.

[Viewer 2.5 Beta Now Available]

I don't know if it is a bug, or simply the new design choice, but the picks do not show any associated text. I'm somewhat surprised that nobody has apparently commented on this

Also, I'd like to have Picks above Groups, since I am far more likely to want to see people's picks than their groups.

[[VIDEO] Stop outfit conflicts, attach multiple objects to the same point!]

@Elite: I cannot help but notice that a lot of what you like being able to do with multiple attachment spots is exactly the sort of functionality third party viewers have built in, so you don't need to run scripted attachments for it.

[Technology Improvements for Q1 Including Raising Group Limit to 42]

@Darren: They are specifically moving the chat to a well-known, open source system developed by others over the last decade. (XMPP running on ejabberd).

-Apart from that, LL has never released any of the server code.

[Technology Improvements for Q1 Including Raising Group Limit to 42]

FJ, while I realize that it isn't a top priority in the chat project, I am curios:

With the use of standard protocol and server, are there any plans for allowing external acces, i.e. chatting between SL and a "normal" XMPP client?

[Technology Improvements for Q1 Including Raising Group Limit to 42]

Great to hear a status after the all-but-total radio silence the last quarter.

Something I've been wondering in relation to the compression on sim crossing: Do you have any statistics on how it impacts low-scripted avatars? Does the compression introduce extra overhead for them which is not offset by the savings?

[[VIDEO] Stop outfit conflicts, attach multiple objects to the same point!]

it's time to get with the program.

Perhaps LL should get with the program and and provide some of the features which have proven immensely popular in TPVs. Not having to give up useful tools would help the adoption immensely.

[[VIDEO] Stop outfit conflicts, attach multiple objects to the same point!]

Temp/local textures, build math, AO and object area search, just off the top of my head. I really miss the outfit shortcuts, though, and the multi-layers and attachments are also killer.

I agree that there is little point in staying on the LL 1.23, though.

[Mesh Import Open Beta Starts Today]

With rigging being very high on my list of interesting things for meshes, I'd really love some more information on that.

But just for starters, could we actually get access to the http://jira.secondlife.com/secure/attachment/38659/simplebot.dae mentioned in the wiki?

[Mesh Open Beta Begins on October 13th]

I can and do dole out the L$ on ADITI for testing purposes all the time. I'll make sure that every account on ADITI has enough 'moola' to test mesh when the time comes.

 

__Oskar

Will you do an inventory refresh while you're at it, or do we have to change password to trigger it?

I must say, meshes have far exceeded anything I ever dared hope for. The rigging in particular really blew me away. This is a gamechanger, and it will shake up things. Whether that is scary or exciting is a matter of perspective. Chalk me up on the excited side. This is a needed evolution.

[Saying Farewell to Avatars United]

SL certainly needs things like better group management and calendars. Not integrating those in SL itself, but having AU as a stand-alone "Facebook light" was a spectacular misfire. So for SL, getting AU out of the way and pulling people and functionality closer to the core (and letting Facebook do the facebook thing) certainly is the right thing to do, though it is of course not fun for those who used AU for other games.

[Check here if you want more options]

Again some valid points from Q, and a big nod for stepping up and explaining your position, whether everybody agree with the particulars or not.

Here are a couple of cents from me:

I completely disagree with this, and yes, I know saying that will make me some enemies. The only polling worth anything is true random sampling and that's both expensive and doesn't help with design. Voluntary polls and votes are basically worthless -- they're completely subject to advocacy and gaming.
Without a sample implementation to try out, most people (I didn't say everyone, so please don't accuse me of that.) don't know what they want. The average desired change is usually no change at all. In general, I think we want to try things out in some sort of "real" form, which is what Project Viewers are for.

Considering the kicking and screaming on on all sides about who knows what about the "true" use of the viewer, and some vocal parties declaring themselves the "true authority" on what "people" want, I agree that sampling the residents is a dangerous path, but on the flip side, it is arguably all the more important that we get some fairly objectice metrics, and if anybody can gather/provide them, it must be LL. But as you say, that is not a small task which can be done for every single idea being pitched.

One problem with the sample implementation style, though, is that (and sorry for bringing up history, but it is a relevant issue) LL has practically never, ever reverted an idea once it has reached the level of being publicly announced. So we have never had a "sample implementation"; at best merely an advance peek at how things will end up looking in the next official release.

TPVs can afford to try partial solutions and see what sticks because they usually address an advanced use case. They can ship buggy, incremental work because their customers know that's what to expect. Our official solutions need to be complete and suitable for all users, including newcomers. (Yes, it's acknowledged that we haven't always succeeded at this, but it is our goal).

At the same time, it is worth noting how people are willing to put up with all sorts of glitches and half-baked versions as ideas shake out, and people can see a good feature/idea forming.

Whether the Snowstorm project can get into such a groove and get people behind it, I do not know. The original Snowglobe project was billed pretty much exactly as this, too, and was, frankly, a miserable failure.

You have a big problem with the massive headstart some third-party viewers have; abandoning them to start playing around with the Snowstorm/Snowglobe project would be a pretty massive loss of functionality for many.

I am not entirely clear on the licensing for the Snowstorm-related code. Do you still need a release from third-party developers for the code to later be usable for dual licensensing?

The way I see it, you practically need to import (or recreate) some of the "killer features" from TPVs (AO, temp/local textures, radar, build math etc) before Snowglobe is a realistic option for people to start playing around with and use, to give feedback on. As is, it is merely some obscure offshoot which you can play with if you for some reason want to compile your own client; not a realistic option over/alongside the TPVs.

In other words, you have some catching up to do before Snowstorm - and in turn the official "non-quirky" viewer - can succeed, and I am not saying that as a slam against the project, but as an honest opinion on how to proceed.

[Check here if you want more options]

2. Go back to 1.23, add all the really kewl features (such as invisible skins and tattoo layers and the other goodies)... and simply re-arrange menus so they are more intutitive (I covered that in my previous message).  Add the really kewl features people like with Emerald and Imprudence and Hippo.  The code is already written... all you have to do is double-check it and plug it in.  Isn't that why you made this code open source in the first place?

Because LL uses a dual license, allowing them to sell the viewer for closed-source use, they cannot use the 3rd party patches unless the 3rd party explicitly hands over all rights to the code to LL, something most understandably have been reluctant to do.

[Check here if you want more options]

And more comments about grand and unlikely schemes, separating the UI from the engine, making the viewer modular, these are side issues.

The big question is why "we don't want to add options" is a reasonable response to a request that an option that previously existed, and that a large part of the user base (both gamers and chatters) depended on, can't be returned to Viewer 2. This is not simply a blithe request that some new functionality that never existed before be added as an option, but that a fundamental part of the user experience that has been maintained for years (and, previously, repaired when it had been broken) be retained.

Why is THIS PARTICULAR option the cause of so much angst from Linden Lab?

Strictly speaking, the blog post is not about that particular chat functionality, but about the design philosophy of the viewer more generally.

That said, if I understand this "trigger issue" correctly, in the new viewer, I'll have to explicitly enable the chat bar for every single line I want to write? -That would absolutely drive me insane, but, well... having no intention of using V2-as-is over my current third party viewer anyway, it is a non-issue for me in the first place, which in itself speaks volumes.

[Check here if you want more options]

I agree with Q's initial post. Shuffling all kinds of decisions off to some huge "Preference" page the user must go through to get what they want is a bad idea, and a sign of a bad design. (And we also need to differentiate between options and features in this discussion).

Taken alone, in context of software design, and out of context of Viewer 2 development, there's little to criticize.

However:

a) Allow entire user interfaces to be "plugged in". This requires a  major architectural change to the software. Although we've talked about  it, it's going to be a while yet before we get there.

Many people had many different ideas and hopes for features in Viewer 2. But I think the one thing everybody expected from it was exactly this.

b) Allow  options to be controlled close to the point of use. As I said above,  this can clutter the interface but can be effective.

Ironically, one of the major criticisms of Viewer 2 is removing exactly this sort of philosophy, doing away with dockable windows, which is a well-understood, unobtrusive way of giving the user choices at their fingertips in the interface itself; a sort of meta-interface you can use to adjust the interface. Instead, Viewer 2 specificaly shuffles such choices off in a preference tab, if giving them at all.

c) Make an interface that covers all use cases. This is the hardest of  all, requiring real understanding and design, but is usually the right  answer.

Again, the forced modality of Viewer 2 grates badly against "understanding the use cases".

So as I read your post (admittedly possibly with a bias), you indirectly explain why Viewer 2 was a failure on both the architectural and design front (despite some good features; I am not arguing that).

LL's stubborn insistance that "we'll like it once we "get it"" has a lot of people angry, and considering that we were literally (and condescendingly) told exactly so by Jack and Wallace in the last controversy over display names, it's not hard to see why your post will be read in that light.

And in the case of the viewer, considering how people flock to 3rd party viewers rather than Viewer 2, I think it is also safe to say that it is not just a matter of people bitching on principle about changes they haven't seen yet.