It's easy to design a mall, right?

Well, maybe. It's certainly easy to design one poorly, but not so easy to do well.

One place I have a store is redoing their mall. The new one is where the sim landing point will be set, and the users will, hopefully, shop a bit before heading into the sim; the sim owner is also hoping this will reduce lag in the main sim. Okkay, fine. I can deal with that.

Unfortunately, I was asleep for the opening land rush (which happened overnight US time), and wound up with a less desirable location than the one I currently occupy, right where the teleporter drops a new arrival into the current mall. This wouldn't be quite so bad except that the design of the new mall makes only a few spaces desirable, and leaves the rest with significant handicaps.

When I open up a store, I look for one where my products can easily be seen from where a new arrival comes in. The idea is to grab their attention right off the bat. There are usually several places in a mall that qualify, and I try hard to grab one. This particular mall seemed designed to minimize those spaces, however. Here's the basic design unit of the mall:

That's me standing on the landing point, using the standard camera view from behind. It's an island pod in four quadrants, with spaces around the outside wall. Four of these units are arranged in a square. Because of the layout, though, only the one island space is clearly visible, and all of the outside spaces are at least partially obscured. There are four spaces visible straight down the lanes between the islands. One of those, however, is where the wall will be removed when the mall is expanded at some point in the future, leaving only three, plus the four inward-facing island spaces, as desirable locations. Those were, of course, all gone by the time I got there.

From this picture, it looks like there's not as much of a problem for folks not in the 7 prime locations. That's because I derendered all of the vendors visible in this picture. The reality is much worse, because no limits were initially imposed on the folks inhabiting the islands. This one isn't too bad:

(All I did was move the camera around; I didn't move myself at all.) That vendor, at least, showed some restraint. (So to speak.) The real horror is this one:

That vendor essentially blocked out one entire corner of the mall, and management let them. When I complained, the manager told me she'd impose a 5-meter height limit on shops in the islands, and a 15-meter height limit on the ones along the wall. This misses the point, to me, though. Even that kind of height limit doesn't preserve the sight lines from a user just popping in to the shops behind the islands.

I wound up here, to the left of Chorazin Creations:

The two vendors in the island in front of my shop had kept to the low height of the walls, and my sign, at least, was visible over them. I'm not entirely happy with this location, but I don't think I'm going to be able to do better. I'm stuck in that mall for a while longer, since I'd (rather stupidly, it appears) prepaid my rent at the old mall for quite a while in advance.

I'm not a designer. I leave that to my good RL and SL friend Axi Kurmin (of, among other businesses, Urban Forge Virtuatecture). But if I can see problems with this design, I'm sure she can outline many more.

Final releases usually aren't

Sigh. By now, if you've been following the saga of Phoenix, you know that 725 was less than a total success. We put a lot of work and fixes into it, and pushed even harder to release 818 by Christmas.

It's better, but it's still got bugs. (Film at 11.)

The only program that's bug-free is one that's never used. Just as with any other human endeavor, no program is perfect. There are bugs left in Phoenix that need fixing, mostly in the areas of RLV, texture video memory management, and the new inventory system LL keeps trying to push out, AIS.

At this point, however, Phoenix is feature-frozen. It will get bug fixes, but no new features, at least officially. (I can't speak for Jess, but I expect that new features that can be dropped in without significant effort will be added - as long as they're added to Firestorm first.) All new feature development will happen in Firestorm, and only get backported to Phoenix on a time-available basis.

The difference between now and a couple of months ago, when I first said that we weren't feature-freezing Phoenix yet, is that the developers believe that the major features that can be added to Phoenix have been. In particular, display names and multi-attach are in and working about as well as they can be. We're also tired of chasing some persistent bugs that simply don't exist in the V2 codebase.

Even so, as we fix things, there will be more releases of Phoenix. We hate having a viewer out there with problems as much as the users hate having to deal with problems. This is a final release only in that new versions likely won't have significant feature additions. There will be bug fixes, at least until Firestorm reaches production release status. Once that happens, though, expect Phoenix to be finalized.

Release early, release often

One of open-source guru Eric Raymond's favorite sayings is "Release early, release often". This appeared originally in his seminal work The Cathedral and the Bazaar, which should be required reading for anyone doing open source development.

This has relevance to the current state of the Phoenix Viewer project. The release of 1.5.2.725 - what we're calling a release candidate, mainly in self-defense - was delayed by quite a bit of time relative to our previous schedule of releases. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. Part of the reason there is that the release was delayed for a while, waiting first on my fix of a nasty texture upload issue, and then the completion of the parcel Windlight settings feature.

Regardless of the reason, the end result was the same: we wound up having to do a lot of debugging, and releasing with bugs we'd rather have fixed.

The answer is in Eric's dictum. Releasing early and often both tends to compartmentalize the addition of features and the corresponding bugs, and also tends to make bug resolution easier and closer to the introduction of whatever caused the bug. On top of that, it also reduces the pressure to just push something out before it's really ready, by keeping users happy that features are being introduced and bugs fixed on an ongoing basis.

A case in point here is the support for Display Names. The original feature was added by a developer scratching his own itch. As I've said before, that's the norm in open source development. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. One user submitted a patch, after that version went out in beta test, to extend the reach into local chat windows - but we couldn't add it, at that point, because we were trying to lock it down tighter for the formal release of what became 725.

Then we had a couple of showstopper bug reports - including one that was submitted to us that we agreed to fix before the release, but that apparently didn't satisfy the user, who submitted an abuse report with Linden Lab over it! (I really, really hope I don't find out who that idiot is. He caused a lot of needless pain and agony.) Those delayed the release even further, and got in the way of proper beta testing as we quickly approached the deadline we'd publicly set. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release.

The answer is to release much more often. No, I'm not advocating public betas. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results.

What of Firestorm? We're faced here with two conflicting demands: a group of users who want it, and a group of users who will only use it if it's been sufficiently de-sucked. The fear is that waiting long enough to satisfy the latter will cause the former to go off to something else, while satisfying the former runs the risk of the latter trying it, saying "This is just like Viewer 2! This sucks!" and never trying again.

I would argue that we should err, once again, on the side of releasing early and often. We should also make it plain to the latter camp that Firestorm is very much a work in progress, and that nothing is nailed down until the users are happy - so, like the weather in Houston, if you don't like it, just wait 10 minutes and it'll change. That has two benefits: it gets us people actually finding bugs, which is the true power of doing open source development, and it shows the user base in a concrete manner that we are indeed listening to their concerns and working to fix them.

Will we irritate people? Yeah. I think we're going to do that any way we cut it, and that this approach will cause the least total irritation in the user community of anything we might do.

De-sucking Viewer 2

With the impending release of the next version of Phoenix, the team is beginning to turn its attention to Firestorm, our version of Viewer 2. We're just beginning the process, and there's a lot of work to do. Even so, there's already been significant de-sucking done, as this screenshot will show.

The biggest overall complaint is that Viewer 2 wastes immense amounts of screen space, between the sidebar and the separate IM and local chat floaters and the UI design that puts huge borders everywhere for no apparent or good reason. As that screenshot shows, we've already gotten local chat docked into the IM window, with vertical tabs, as in Phoenix, and a separate inventory floater like the one in version 1. That screenshot is already very reminiscent of the way I lay out Phoenix's user window.

This is very preliminary. We haven't really devoted much thought or design effort to Firestorm, as yet, and so any or all of that can change. We also have a lengthy list of features to examine, adapt, and port to the new codebase. The whole developer community uses Phoenix's feature set above and beyond that of the base viewer. To be sure, we all use different parts of it, but if there's a feature in Phoenix, there's a member of the team that uses and knows it.

We're not going to put out a viewer we won't use ourselves.

In addition, the members of the development team have a wide range of experience within SL, and the folks we know have an even wider range. For example, I personally know one of the biggest vendors of clothing in SL. As far as I'm concerned, Firestorm isn't ready for prime time unless he can get his job done as easily as he does today, with the minimum of learning curve to surmount. (He doesn't have time to spend learning another way of working. He's too busy creating.) The same goes for folks in many other realms of SL.

No, Firestorm isn't going to happen overnight. There's too much to de-suck, for too many people. I don't expect even an alpha version to be available to the testers for quite some time. I can promise this, though: When it does come out, it'll be worth the wait.

"It's the official viewer; get used to it!"

I commented in a discussion elsewhere that I felt mesh wasn't going to take off because it wasn't going to appear in popular TPVs for months yet. That drew a reply basically saying Emerald was eeeeevil for putting out multiple attachments before LL did it, and all it did was make content creators' jobs more complicated, ending with "Plus last I checked, it's Linden Lab who decides the official stuff. Don't like it, don't log in."

The user under whose account that was posted - not the one doing the posting - asked people not to start a flamewar there, so I sent a private message asking him what his problem was. That drew this reply:

Ok, let me put it like this.

Back when Emerald had an update done, it caused major issues with our products. Soon people just began to state that our stuff was broken. The problem was that our stuff wasn't broken, the viewer just SUCKED!

It isn't MY job to make sure my fucking crap works for EVERY viewer! That is NOT my job and it isn't even listed in the TOS! Until it does state somewhere that it does, I am NOT going to fix my stuff for anyone's misfortune JUST because they are using a TPV! Don't like it, download 2.0 and shut it! This whole thing began to occur again when we started to distribute alpha layers. We made them optional, but people complained EVERY DAY about how they'd get harmless errors, but said that it was SOMEHOW preventing their product from working (which was bull crap!).

Bottom line is that I don't care what viewer is mostly used on the grid, and last I checked, since the Emerald fallout, some of them even began to use 2.0, some went to (of all things) (please get rid of this viewer if you can, it'd do us all a favor) (not kidding) (still reading?) Accent, Kirstens, or Phoenix. The other bottom line is that Linden Lab is the hosting service and the main creators. Everyone is whining and moaning about 2.0 and it's new interface all because people are lazy and don't want to learn how their buttons were just made vertical (with another button added). All in all, it's the official viewer; get used to it!

Now onward towards your Emerald dealing. Biggest wrong move ever! Emerald made their multi-attachment, but Linden lab asked them to remove it because they were planning to release the multi-attachment for premium users! It was swapped around to make it seem that Linden Lab was trying to stop Emerald and people threatened to leave, so Linden Lab stopped.

As for viewers that can't render Meshes, last I checked, Kirstens(S21) works pretty damn good on my machine. (Also, I'm a developer for god's sake! I know what the hell a mesh looks like when you don't have the ability to see them!)

To quickly summarize, it doesn't' MATTER who uses meshes or not! When people see how much higher quality they are compared to most other avatars, can't make it work, and ask why, they can't ask for a refund because the sale was legit and the product DOES work, it's just the moron is using a TPV that isn't up to date. That would never be my problem, and I don't care, because that is just how the damn real world works!

Hoo boy. Where to begin?

The overall thrust of this guy's argument is that we should take whatever LL chooses to give us. Step over that line, and we're nasty, eeeeevil folks who make everyone's lives harder. Never mind what the users want or don't want. Just eat your Brussels sprouts.

The fundamental thing this guy is forgetting is that we're here to serve the users, just as he is in his business. Everything that was added to Emerald, and now Phoenix, is there because users wanted it. Multi-attach is a case in point. Yes, Linden Lab finally added the feature, and got it right (and that, in itself, is an exception). The problem is that it took them six months to add it to a released viewer after Emerald had added it. This pattern repeats endlessly.

When LL does add a feature, they get it wrong more often than not, sometimes quite badly so. Display Names is just the latest notorious example. What users wanted was a way to change their existing account name, because their original choice, made before they understood what the name choice meant, sucked, because they were partnered, or for role-playing reasons. What we got, instead, was a way to impersonate someone else that didn't address what the users were asking for in the first place.

Of course, everybody knows Viewer 2 sucks. It's the poster child for what the user community thinks is wrong with LL. They tried to tell us what we wanted, instead of listening to us. The result is a classic disaster that has convinced a major part of the user community that LL fundamentally doesn't care about them. They're slowly de-sucking the user interface, but the users are voting with their feet: over twice as many users use viewer 1 based viewers as use V2-based viewers, and the current version of Phoenix is the most popular viewer on the grid by nearly a factor of 2 over any version of V2.

It's about what the users want, not about what LL tells the users to want. We're adults. We know what we want. Telling us to shut up and eat our Brussels sprouts is not going to go over well, be it from LL or a content creator who doesn't want to do the work needed to serve their users.

I'm not in the market for a new avatar - I'm quite happy with the AnthroXtacy tigress I wear - but if I was, I wouldn't buy from this guy anyway, if I knew who he was inworld. I deal with businesses that serve their customers, not dictate to them.

How easy is it to be evil?

Very easy. I got a notecard advertising a product to find out whether any user is online or not, by way of a chat command, for a mere L$150. I thought about it a while, and then used code snippets from the LL wiki to whip up a script.

The code to do the job is 129 lines of LSL, about half of them comments, and I didn't try hard to write compact code. (When I write programs, I come at them knowing that I'll have to come back and answer the question "Why the precise hell did you do it that way?!" in five years or so. When you look at it that way, clear and concise beats efficient but impenetrable every time.) The only magic here is in getting the key from the avatar name, and that I lifted straight from the LSL wiki.

There's a tiny but very loudly vocal minority of folks who claim that this code is evil, and that the Phoenix Viewer is evil for providing an equivalent function right in the profile display. Their ire at the Phoenix team is misdirected. If they don't think that this kind of thing is appropriate, then they need to convince LL to change the behavior of LSL. There's a JIRA to do just that, SVC-4823. It's only gotten 14 votes as I write this. Maybe, just maybe, the number of users who really care about this is a lot smaller than the loudmouthed kooks think.

In the meantime, I refuse to sit still while people call me evil for doing something that's both explicitly allowed by LL and done in many ways by many other people. This script is no more evil than a pistol is evil. It's the user, not the tool, that is good or evil; a tool simply is.

Here's the offending code, after the jump:

Pushing to release

The Phoenix Viewer team is pushing hard to get a beta of the next release out. We've been working on bug fixes and ironing out a few features where they haven't interfered with getting the release more stable.

This release is intended to be the last one before we turn our attention to Firestorm and de-sucking the Viewer 2 user interface. As such, we're trying hard to get as much into it as we can. One of the biggest feature additions is Display Name support. It's not as extensive as the one in Viewer 2; in particular, it doesn't put the DN in chat or IM texts, or on your friends list, but it does show it in tags and profile views and object ownership and things like that.

The guy who implemented this is our QA lead, Wolfspirit Magic. He's earned a developer tag for it. This is a classic case of an open source developer scratching their own itch, but it turned out to be prescient when LL released DN gridwide a week or so ago and then, a couple of days ago, flipped the switch and changed registrations to a single username instead of the old Firstname Lastname system.

There's some confusion about how to use a new-style username with existing viewers. If your viewer has a Firstname Lastname login window, you need to put your username in the Firstname field, and the word "resident" in Lastname. This will be true of Phoenix in the next release. We decided not to change the login window at this stage of the development cycle. It would have caused too many changes to the login manager, and especially the part that maintains saved logins.

We've gotten requests to add things, as well, even pretty recently. An example was a request that came in just yesterday to add the OpenSim LightShare feature to Phoenix. I sympathize with the submitter who says that not having it will hinder Phoenix's adoption among OpenSim users. He may well be right. However, that's a feature that, again, will take more time to code, integrate, and test than we have available before the beta is cut.

I keep mentioning the time available. It's short: we're planning to cut the beta version Sunday evening, let the beta team pound on it for a week, and if everything goes well - not at all guaranteed - then release Thanksgiving weekend. We haven't released a new version since 373, almost a month ago, and that's getting to be just too long. I believe in the bit of open source wisdom that says the best release policy is "release early and often"; that's not quite as practical when your userbase is measured in the hundreds of thousands, but is still sound advice.

The big change people will notice in the next version is multi-attachments. Henri Beauchamp's patch was imported, and extensively worked on to improve and extend its function. The old secondary attachment points are being deprecated, as well. If you have attachments on secondary points, Phoenix will migrate them to the corresponding primary point and attempt to put them in the same place on your avatar. You may need to do some minor tweaking, but should only have to do it once. The good news is that Phoenix will still display secondary attachments on other avatars correctly. The new system is also compatible with the one used in Viewer 2.

This is planned to be the last major release of Phoenix. Once it's out, we'll start in on Firestorm in earnest. Phoenix may get bugfixes, especially for high-impact bugs, but new features probably won't be added unless they're both crucial to continuing to use SL and straightforward to implement and test. We know that the V2 codebase is the future, and it's time to make it usable for folks who tried Viewer 2 and found it sucked.