Jump to content

Testing on other grids


Samara Kasshiki
 Share

You are about to reply to a thread that has been inactive for 4138 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

So Aditi seems to have some major issues with the mesh uploader. Sometimes it works quickly and perfectly, other times you never get the upload button. Same files, same avatar, all different sandbox sims. SO, my question is -- is it practical to upload on another grid and count that as a viable test? Like opensim (haven't been there in years though). Would be good if they would fix this.

When I contact support and they send a note to aditi it gets fixed (for awhile). But it definitely hampers your workflow. So any suggestions would be appreciated.

This doesn't seem to be a "ME" issue as tech support agreed my connection was great, I even tried the official viewer with the exact same results. AND, like I said, once reported I could upload on both grids for many many hours yesterday. Late last eve it stopped again (for me anyway) and this morning no luck either.

I have read other posts here so know I am not alone, but would be good if this could get fixed --

 

Link to comment
Share on other sites

It frustrates me to the point that I just stopped making meshes. It's not really my area of expertise, so I'm just concentrating on things that do work. After spending hours, upon hours of work on a mesh, and then not being able to upload it. I've just given up. It makes life alot less stressful. Of course, there are very few areas that don't have bugs in SL. The sad part is that LL doesn't seem to care. Heck, LL can't even fix the simple spread hand problem that has gone on since the beginning. It's seems that if something kind of works, then that is OK with LL.

Uploading a mesh on another grid can only prove that there is nothing wrong with the dae file. Beyond that, there is no other benefit in doing so.

Link to comment
Share on other sites

I'm not sure what your definition of "test" might be in this context, but I can tell you that every incarnation of OpenSim is slightly different.  Some OpenSim grids work really well, some run like molasses in winter.  It all depends on whose grid it is, and how they have it set up.

I can also tell you that I've never had much luck in reliably uploading mesh models to any OpenSim grid.  Until recent posts on the subject, I'd thought the problem was with OpenSim itself, but now I'm more inclined to believe it's an issue with Firestorm.  I haven't thoroughly tested, though, so take that with a grain of salt.

Maybe I'm just lucky, but I've never had any trouble to speak of, in uploading mesh models to SL with the official viewer.  Even among those who do have trouble, the consensus seems to be that the LL viewer does it more reliably than Firestorm does.

I realize that may be little comfort if you're having as much trouble as you say, with both.  I wish I had a better answer for you.

Link to comment
Share on other sites

On 2 occasions in the past few days I have had people come up to me on the beta grid asking why I could upload mesh ok but they could not. In both instances they were using Firestorm, and in both instances they switched to V3 and were able to upload. I don't know which viewers you have tried but definitely try the Linden Viewer. I can only think of a handful of instances over the past year where I have not been able to upload mesh successfully and I think most of those instances were down to packet loss on my connection which my ISP has now fixed.

Link to comment
Share on other sites


Medhue Simoni wrote:

It frustrates me to the point that I just stopped making meshes.

Sorry to hear that, Medhue.  You'd made some nice things, as I recall.

 


Medhue Simoni wrote:

Of course, there are very few areas that don't have bugs in SL.

Very true.  As I so often find myself saying, "Scotch Tape and Band-Aids, my friend, Scotch Tape and Band-Aids."

In fairness, it's gotten a lot better in recent years, but still the amount of bugs in SL is rather staggaring.  Knowing as much as I do about SL's history, I understand why there are so many, but still, it's hard not to be frustrated by them.

 


Medhue Simoni wrote:

The sad part is that LL doesn't seem to care.

Don't mistake not being physically able to solve difficult problems quickly with not caring.  I've met a lot of Lindens in my day, I've spent time at the San Francisco offices, and I have yet to encounter a single Linden who is not deeply passionate about SL, and intensely committed to making it as good as it can possibly be.  They're good people, who work hard, and do incredibly challenging things, every day.

The biggest problem is that design decisions made nearly a decade ago prevent easy fixes for the majority of problems.  What seem on the surface like simple problems that should be easily solvable are usually amazingly complex, interconnected messes, under the hood.  Tug at one string and twenty five more start to unravel.

To do it right, the whole thing really should be rewritten, from scratch.  But do that, and there goes ten years worth of existing content, existing economy, and existing community.  If it were up to me, I'd say just say drop the hammer, and start over again with a better system.  But luckily for everyone who's invested in the current system, it's not up to me in any way.

 

 


Medhue Simoni wrote:

Heck, LL can't even fix the simple spread hand problem that has gone on since the beginning.

I'm not sure what "hand problem" you're referring to, in particular.  I assume it's got something to do with the avatar's hands?

If that's the case, here's what I can tell you that might help shed some light on the issue, whatever it might be.  From what I've been told by certain LL insiders who shall remain nameless, and from what we all can plainly see just by looking at the avatar model, the person who originally said to them, "Hey guys, I can make a customizable human avatar model for you," was nowhere near as up to the task as he purported to be.  He made some design decisions that are downright baffling, including, but far from limited to, the decision not to put bones in the hands.  For some reason I cannot possibly fathom, he opted to go with morphs for the various hand positions, instead of skeletal animations. 

This causes no end of problems.  It's the reason you can't put a ring on a finger, and have it stay on when the finger moves.  It's the reason you can't create custom hand poses and hand animations.  It's the reason the avatar can't even do so much as hold a broomstick convincingly.  It's a big part of the reason the mesh clothing deformer project has been so challenging, and is still not complete.  The list goes on and on.  It was one of the worst design decisions in the history of design decisions.

Fast forward ten years to the present, and what's done is long since done.  The only way to solve all these problems would be to replace the avatar with a better one (which I'm all in favor of).  But again, if that were done, there goes a decade worth of existing content, not to mention the difficulties involved in trying to yank the existing avatar out of the system.  From what I've been told, the avatar is pretty deeply intrenched into the heart of the whole thing (which in itself doesn't seem to have been a sensible design decision, either).

A lot of people, including me, have proposed adding a new avatar, while leaving the old one in place, as a legacy option.  Sooner or later, I'm sure that that will happen.  I have no idea when, though.  It could be tomorrow, next year, or another ten years from now.  Here's hoping we won't have to wait too much longer.

As for any bugs associated with the existing avatar, I wouldn't count on any of them being fixed.  Again, this isn't because LL doesn't care.  It's because most of them just aren't fixable (at least, not without ripping the whole system apart).

 

How's that for a messed up, totally not what anyone wants to hear, FUBAR of an answer?  Well, it's a messed up, totally not what anyone should have to deal with, FUBAR of a situation.  Did I mention Scotch Tape and Band-Aids?

Link to comment
Share on other sites

I agree it really is frustrating, but now that I have "beaten down" Blender *wink* I actually enjoy working in it.

 

I HAVE FOUND that doing a live chat asking for the server to be rebooted or the stack cleared or whatever they need to do DOES seem to get things going in an hour or so. And they stay up for awhile. Hence I have pinned "live chat" to my browser toolbar LOL.

Link to comment
Share on other sites

Thanks. I wish (sort of) that the official viewer would fix the issue but that doesn't seem to be MY issue. No packet loss (tech supported tested). When it works it works instantly and well. Other times (long periods) it just doens't work. Might try the Linden viewer again I guess when it sticks again, but my brief episode with NO appearance of the upload button has me thinking that it will not help.   Thanks all.

Link to comment
Share on other sites

The hand spread problem has to do with hand morphs sticking and then defaulting to spread hand when changing the hand morph. Recently, the jira has had some action, but again we sit waiting, and waiting, and waiting. https://jira.secondlife.com/browse/STORM-1899

I do not mean that any individual Linden doesn't care, only that LL as a whole doesn't care. This is not a debatable statement really. If they did care, irreguardless of the difficulties, the issues would be fixed. We can debate as to why these issues aren't fixed. Of course, the system is complex and, as you said, many things overlap and cause other issues, but this is really only a time issue. If a company is not willing to invest the time, then nothing will be done. Personally, as some1 that sells products in SL, I find it inexcusable to allow bugs related to content creation to go on for this long, and inexcusable to not make them a top priority. In animation, we also have an even more important bug that basically breaks every looping animation, but too many think the workaround is sufficient, despite the fact that it doesn't realy fix the issue, and it will continue to worsen.


The issue with uploading meshes is another inexcusable issue. We didn't have this issue when we were all beta testing it. During beta testing, we could also resize the preview window, then 1 day, all of a sudden we can't resize the mesh upload window. I brought this up at the user group meeting and Nyx told me to write a jira about it. Guess where that issue is? I bring this up to demonstrate the screwed up process that goes on at the Lab. Who in their right mind would think doing away with a resizable mesh upload window is a good thing? It truely boggles the mind, and we can only assume that management is horrible. Just the fact that I was told to write a jira shows how LL's mindset on the whole process is messed up. I don't work for them, I'm the customer just trying to point out a problem. Not just an average customer too, but 1 that not only generates money for LL, but also pays them hundreds of dollars a month.

Link to comment
Share on other sites


Medhue Simoni wrote:

I do not mean that any individual Linden doesn't care, only that LL as a whole doesn't care. This is not a debatable statement really. If they did care, irreguardless of the difficulties, the issues would be fixed. We can debate as to why these issues aren't fixed. Of course, the system is complex and, as you said, many things overlap and cause other issues, but this is really only a time issue. If a company is not willing to invest the time, then nothing will be done. 

A truer statement has never been made on these forums.

Link to comment
Share on other sites


Medhue Simoni wrote:

The hand spread problem has to do with hand morphs sticking and then defaulting to spread hand when changing the hand morph. Recently, the jira has had some action, but again we sit waiting, and waiting, and waiting.

Thanks for explaining.  I don't often create animations for SL, so I wasn't aware of this particular issue.  I can see how it would be really frustrating.

 


Medhue Simoni wrote:

I do not mean that any individual Linden doesn't care, only that LL as a whole doesn't care. This is not a debatable statement really.

Sorry, but that doesn't make sense.  The company, like every company on Earth, is made up of people.  If the individual people care, then the company cares, by definition.

And of course it's a debatable statement.  I just debated it. :)

Again, don't confuse the amount of time it takes to solve difficult problems with the degree to which the people working on those problems care about solving them.  If things are difficult, they're difficult.  No amount of complaining ever magically makes anything easier to fix.

 


Medhue Simoni wrote:

If they did care, irreguardless of the difficulties, the issues would be fixed.

Sorry again, but this statement is also nonsensical.  Simply caring about an issue doesn't make it get solved.  There's no such thing as a magic care wand, that somehow makes problems go away.  Nobody goes, "OK, I'm caring a whole lot right now.  Someone wave that wand.  This problem is going to disappear in 3, 2, 1, and it's gone!  Wow, caring really does the trick!"  You know as well as I do, that's just not how it works.

Look, I get that you're frustrated, and probably blowing off steam, but it's important to assess the situation realistically.  If you want to debate their level of ability to solve any given problem, that would be fair game.  But don't say they don't care.  I know for a fact that they do.

 


Medhue Simoni wrote:

Of course, the system is complex and, as you said, many things overlap and cause other issues, but this is really only a time issue. If a company is not willing to invest the time, then nothing will be done.


I'd submit that there are far more dimensions to it than just time alone.  As I said before, some of the problems that exist would require a complete reworking of the underlying architecture of the system, from the ground up.  That's not just a question of time.  It's also a question of whether or not it's worth doing away with the existing system, and the years and years of content that it contains.  Tell me, would you be willing to start over again from scratch tomorrow, if it meant the system would work perfectly thereafter?

Some would answer yes to that question.  I know I certainly would.  A lot of people would not, though.  Are their opinions less worthy of consideration?

 

Since you brought up time, though, let's focus on that for a moment.  I would argue strongly that investing the time is precisely what they've been doing.  It's just the amount of time required is more than you'd like.

Think about the logic here.  You can't very well accuse them of moving too slowly, and simultaneously accuse them of not investing time.  Clearly, if problems that require a lot of work to solve are taking a long time to solve, then they ARE investing the time, by definition.

It is a fact that as time has gone by, more and more of SL's problems have gotten solved.  There are literally thousands of bugs that have been squashed, in the last couple of years alone.  But obviously, there still remain thousands more, and none of us can help but be frustrated by that.  It's a screwed up system, which should have been designed differently, right from the start.  But it is what it is, and I firmly believe they're doing the best job anybody could do, to make it as well as it can.

I know it's easier to **bleep** about it than to be willing to accept that.  I get it, I really do.  But I prefer to remain a pragmatist.  I'd much rather assess the situation honestly, than waste my emotional reserves on things that are beyond my control.

 

 


Medhue Simoni wrote:

Personally, as some1 that sells products in SL, I find it inexcusable to allow bugs related to content creation to go on for this long, and inexcusable to not make them a top priority.


"Inexcusable" is a strong word, but I must admit I'm hard pressed to think of a better one.  I do agree with you that it's ridiculous that so many bugs exist, particularly in the content creation arena.  I cannot agree, however, with this notion that the bugs have been "allowed" to go on. 

There are lots of reasons why bugs linger.  Sometimes, they're just really time-consuming to work on, as we've been discussing.  Other times, there are dependencies in place which mean a particular bug physically cannot be fixed until other bugs have also been fixed.  Still other times, the symptom of a bug is well known, but the cause is elusive.  And sometimes, a bug simply cannot be fixed at all, without redesigning the entire system, a we've also discussed.

As you well pointed out, all of these things require significant investments of time.  The flip side of that is if we all know that solutions take time, then we have to be willing to invest exactly as much patience as those amounts of time require.  Again, we can't say, "We demand you take the time to fix _____," and "We want that same _____ fixed immediately," in the same breath.  That's not how the universe works.

As for what is or isn't a top priority, we have no way of knowing that, from the outside.  It's easy to assume that high-priority projects get done right away, and lower priority ones get done later, but if you think about how the actual development process works, that's hardly ever the case.  Like every company, they're always working on more than one thing at a time.  If the fixing Bug A requires six months of work, and fixing Bug B only requires six days of work, of course B is going to be fixed way faster than A.  That doesn't mean A isn't a higher priority.  A could very well be the primary focus of the company for the entire six-month period.  But the mere fact that it's highest priority doesn't change the immutable fact that the process of fixing it takes six months of work, no matter what.  Likewise, B might be the very lowest priority of all projects the company is working on, but because it happens not to require a ton of time, it gets done quickly.  Not every single person in the company can work on A, after all, even if A is the highest possible priority.

It's only when two projects happen to take equal amounts of time that priority dictates which one gets finished first.  And it's pretty rare that any two projects are so equal.

 


Medhue Simoni wrote:

In animation, we also have an even more important bug that basically breaks every looping animation, but too many think the workaround is sufficient, despite the fact that it doesn't realy fix the issue, and it will continue to worsen.


I can't comment on that one, I'm afraid, since I don't know anything about it.  Once again, I can certainly see how it would be really frustrating. 

 


Medhue Simoni wrote:

The issue with uploading meshes is another inexcusable issue. We didn't have this issue when we were all beta testing it.


True, but the beta environment is not the release environment. Both the server code and the viewer code have evolved significantly since then.

That's not to say I don't agree with you that there's no good excuse for it, of course.  I just don't think "It wasn't like this in beta" is particularly telling about anything.

 


Medhue Simoni wrote:

During beta testing, we could also resize the preview window, then 1 day, all of a sudden we can't resize the mesh upload window...  Who in their right mind would think doing away with a resizable mesh upload window is a good thing?


I very much doubt anyone thinks it's a good thing.  Most likely, it's something that got inadvertently broken somewhere along the line, in one of the updates.  Do you have any evidence that it was a deliberate change?

That's not to say that allowing something like that to break is excusable.  As I said, if you want to question their competence level when it comes to certain things (like quality control), that's totally fair.  But to just assume that a change for the worse was someone's deliberate doing, without any direct evidence, is wrong.  If you do have such evidence, it would of course change my tune on this particular topic, so by all means, present it.

 


Medhue Simoni wrote:

I brought this up at the user group meeting and Nyx told me to write a jira about it. Guess where that issue is?

...Just the fact that I was told to write a jira shows how LL's mindset on the whole process is messed up. I don't work for them, I'm the customer just trying to point out a problem. Not just an average customer too, but 1 that not only generates money for LL, but also pays them hundreds of dollars a month.


So, they've provided you with a means of documenting your troubles with the system, and communicating same directly to them, and you think that's a bad thing?

What would you suggest, in lieu of the JIRA?  Do you really think just mentioning things at group meetings is a better way to go?  Seriously, as someone who's so financially invested in SL as you are, what do you think would be the very best way to document and communicate your problems to LL?

 

For what it's worth, LL is hardly the only company uses JIRA for bug reporting and tracking.  It's quite common.  Thousands of companies use it, in fact.  Software makers that use it include Adobe, Autodesk, Microsoft, Intuit, Cisco, Dolby Labs, eBay, and hundreds of others.  Game companies that use it include Blizzard, Nintendo, Rockstar Games, Sega, just to name a few.   If you want a complete listing, check out http://www.atlassian.com/company/customers.

Is there something in particular you don't like about the system?

Link to comment
Share on other sites

I'm not going to go back and forth with you on opinions.

My issue with LL's jira system is that it seems like just a game of pass the buck. IMHO, many jira seem to be waiting for a resident to take it upon themselves to dig thru the code and fix the problem. Just look at how many of the LL jiras are fixed inside other viewers and LL has to goto those people to get the issue fixed in the main viewer. Jiras languish until some resident makes a big deal about it or submits a fix properly. If the fix is not submitted "properly", then expect it to be ignored. I've never seen a jira system that relies so much on the community to do all the work. Nyx understood the resizable window issue, and could have easily written his own jira about it, and not wasted more of my time. I suspect that telling residents to write jiras is simply a way to pass the buck. The jira then goes into the void, never to be seen again. IMO, if LL cared, they would put the proper amount of staff on the jiras to get things fixed in a reasonable amount of time. To even imply that I, or some of us have not been extremly patient with LL, is utterly ridiculous. Most of the major bugs are 5+ years old now.

 

Link to comment
Share on other sites

I obviously can't speak for Nyx, or anyone else, and I certainly wasn't privy to the conversation you describe.  However, I fail to see how his simply asking a person who raised an issue during a meeting to take the next logical step of submitting a formal bug report about it constitutes his not caring. My interpretation would be the exact opposite.  If he didn't care, he wouldn't have asked for the report at all.

This notion that if he truly cared he'd have created the JIRA himself is a bit silly, don't you think?  Anybody could just as easily turn your statement around to say that if YOU truly cared about the issue, then YOU would follow the formal procedure to put it on the company's radar.  For all you know, he might simply have had too much on his plate that day to be able to get to it quickly, so he asked you to do it because he didn't want it to have to wait, and because he trusted that because it was so obviously important to you, you could be counted on to follow through. 

If that's indeed what happened, then it's a textbook example of healthy delegation.  It's exactly the kind of thing I do, when I have a busy work schedule.  It happens all the time that a client calls me up, and says "We really need _______.  It's super important to us."  If I'm way too busy to give the issue the attention it deserves at that day, I will say to the client, "Sounds great.  I'd be more than happy to work up a strategy to take care of that for you.  Do me a favor; put all the details in an E-mail, and send it to me as soon as you can, so I don't forget anything we've discussed."  To my knowledge, nobody's ever had a problem with that. 

Usually, the client will follow through, and send the E-mail.  If they don't, all I can do is assume it wasn't really as important to them as they made it out to be, and I just keep going with my existing work.  Either way, the fact that I made the request for the E-mail demonstrates that I care.

Obviously, I'm just speculating on Nyx's actual reasoning when I assume it's similar to what mine would be in his place.  I have no way of knowing exactly what was said by him or you, nor do I know what was going on in either of your minds at the time.  Mainly, I'm just trying to point out that there are alternate explanations besides "They don't care."

 

The fact is countless thousands of JIRAs have been submitted over the years.  Many of those issues have been fixed, many are still waiting to be fixed, and some won't be fixed for a multitude of possible reasons.  This is all to be expected.

Your implication that every JIRA just "falls into the void" is just not accurate.  You're right that some of them sit idle until someoene makes a big deal about it, but that's part of the point of the system.  If a particular issue shows to be really important to the community, they'll do what they can to bump it up the priority list, if possible.  The intent in this regard is perfectly reasonable, even if the execution is debatable.

You're also right that some issues get fixed by the open source community before they make it to the official viewer.  That's the nature of open source software, as I'm sure you know.  There's not a whole lot of meaning to be assigned to it, in and of itself.  It's just what happens with every single open source project there is.

Take Blender, for example.  A great many of its features and bug fixes have originated with its user community, rather than directly from within the Blender Foundation itself.  Its COLLADA exporter was messed up for a long time, for example, and only got fixed when a group of Blender users, who were also SL users, took it upon themselves to do it, in order to better be able to use Blender with SL.  Would you accuse the Blender Foundation of having "passed the buck"?

 

I do understand that my arguments may be falling on deaf ears, if you've already made up your mind that you want to be upset about this.  Perceived attempts at dismantling your reasons to be upset might not be met with the most open of arms.  But as I said, I'd just rather be pragmatic than expend emotional reserves on things like this.  As I've said many times now, I'm as frustrated as anyone when it comes to the amount and nature of bugs in SL.  But I'd rather try to channel that frustration into something healthier than just accusing hard working people of being uncaring.  We can agree to disagree on that, if you prefer.

Link to comment
Share on other sites

I prefer the LL viewer for uploading meshes. Perhaps it is my set up, but Firestorm doesn't let me set the various options for Physics Analyze (method, quality and smooth), and Simplify (method, passes). They show either Default or nothing and I am unable to change those settings.

I will say that the error messages one can get while uploading a mesh file that has problems are cryptic. They do not offer a lot of meaning for the average user who is new to mesh creation.

Link to comment
Share on other sites

Dude, where did I say Nyx didn't care? I appreciate your help, but you really should reread what I've said, cause you are constantly making assumptions that I did not imply. I was talking about a policy, whether an implied policy or a real policy. A policy of LL's, not Nyx's. All the Lindens would have done something similar. I'm just saying that it shouldn't be assumed that the resident should be writing LL's jira. Why? Because I've seen it dozens of times now, that the next step is a Linden in the jira asking for clarification, which expends even more time for the creator of the jira to reply, and this goes on and on. If a Linden understands an new issue, they should be writing the jira and passing on all the needed info to whomever may be working on it. Insisting that the customers make a jira for every issue found is just adding steps to a process that is already far too ridiculous. When a customer writes a jira, it is often nonsensical to some1 not familiar with the issue. Many times there is a language barrier, and sometimes not a foreign language barrier but a technical language barrier. I deal with customers on a daily basis, and to understand their issues, you have to have a conversation with them. In the situation that I brought up, the conversation was already had. Making me write the jira started the process over again.

Plus, I don't think you understand what the definition of a customer is. The customer doesn't work for the company. We don't have to follow any policy and are only engaging in an attempt to help the company. If you expect the customer to jump through your companies hoops, you will be let down almost every single time. When 1 of my customers comes to me and tells me about a problem, I appreciate the heads up and certainly not going to ask them to expend any more time or energy on making sure the problem is fixed. If they want something new or something changed that is not broken or part of the actual product, than that is a whole other situation. As I understand it, when I'm the customer, my job in the process is to enjoy the product and pay when I find the service valuable enough. It's not my responsibility to help make the product or service better, that is extra that I do for free, which is outside the bounds of a customer's responsibilities.

Link to comment
Share on other sites

If I misinterpreted your meaning about Nyx in particular, that's something we can certainly discuss.  I'm not sure how that one misunderstanding constitutes "constantly making assumptions", though.  Let's not exaggerate. 

Also, I'm sure you'd agree, that when your words do get misinterpreted, it's really not helpful to say to someone, "You should read."  At best, that implies some rather inaccurate assumptions of your own, and at worst, it's a snide remark, intended to irritate the other person.  Either way, it's unproductive.

Let's be factually accurate.  I DID read what you wrote, as I'm sure you already know.  If I hadn't, I would never have been able to reply to it at all.  The fact that your intended meaning was distorted, whether through my fault or yours, doesn't mean I did not read.  To corect the situatuin, all you would have had to say was, "Hey, that's not actually what I meant.  Let me explain," and all would have been fine.

Further, it's not productive to tell someone they don't understand what a customer is.  Having been in business for 19 years, I can assure you, I do. 

No one ever said or implied that the customers work for the company, that they have any responsibilities equivalent to those who do, or that they're obligated to follow any particular policy.  However, when a customer knows that a company has certain policies in place regarding communication of issues that are important to that customer, it only makes sense that the customer adhere to those policies, if he or she wants the issues addressed.

 

This might make you laugh, but I first learned this lesson about 20 years ago, when I was working at Subway.  During the lunch and dinner rushes, with two of us working, we used to do around 240 subs an hour. That's 120 each, meaning each sub had to be made in no more than 30 seconds, including the time it takes to let the customer state what they want on it.  If left to their own devices, any and every customer would drag the process out, picking one ingredient at a time, slowing things from 30 seconds to as much as 10 minutes.  To avoid that, we very deliberately structured the way the customer had to communicate with us.  They were not allowed to pick one ingredient at a time.  No matter what they started to say, we would (politely) cut them off, by asking pointed questions, so that the process would work our way, not theirs.  20 years later, I can still hear the process i my head.  The order was extremely specific:  "Half or whole?  White or wheat?  Cheese?  Onion, lettuce, tomato?  Pickles, peppers, olives?  Oil, vinegar, mayo?" and the sub was done, in under 30 seconds. 

This might all sound trivial if you've never worked behind that counter before, but what we knew from experience was that if you fail to guide even a single customer through that process, the entire day's business can be destroyed.  We had it down to a science, and we were really good at it.  (Side note:  Subway's changed quite a bit since then, which I find really annoying, as someone who still eats there from time to time.  When I see some kid who doesn't know how to handle a crowd, allowing things to take forever and a day, it's all I can do not to jump over the counter and take over.)

Every once in a while, even though we were really polite in the way we steered customers through our process, someone would get upset about not being granted the freedom to slowly pick out ingredients, one by one.  I never did find a way to make those people happy.  Once they'd made up their mind they didn't like the process, that was that.  None of us were about to entertain the idea of abandoning our otherwise flawless system, though, just to try to accommodate those few people.  The reality is they probably would have found something else to get upset about, if not that.  Some people are just like that.

For every one of them, though, there was someone else who would be a 'model customer'.  Those people knew our system, and would actively help us help them.  I remember one guy, in particular.  He came in one evening, with his entire family, about ten people altogether.  At first, it was chaos, with children and elderly people, all shouting the various things they wanted.  It wasn't busy at the moment, so I let this go on for a couple of minutes, before the man and I exchanged looks, indicating that he knew that I knew exactly how to make this work, and that I had his blessing to set his family straight.  I looked each person square in the eye, and said, "Half or whole?  White or wheat?"  As each person answered, I laid their bread in front of them, forming a line, ten breads long.  Then I went down the line, asking each person in sequence, "What meats?"  Then I proceeded to, "Cheese" and went down the line again.  Then, "Oninon, lettuce, tomato?" down the line.  Then, "Picke's, perppers, olives?" down the line.  And finally, "Oil, vinegar, mayo?" down the line.  In less than five minutes total, everyone had their subs, and the whole family was happy.  The man the said, "Do you accept tips?" and handed me an extra twenty dollar bill.  Needless to say, he was thrilled to have had his family steered through our system.

 

I've never forgotten the lesson I learned that day, from that man.  So, in dealing with companies, I try, whenever possible, to be like him.  I try to work with the grain established by the people who do the jobs they do, day in and day out.  I can't pretend that that always works, of course, since not every person at every company is particularly good at what they do.  But in most cases, it's a winning strategy.

Clearly, LL believes in their JIRA system, the same we "sandwich artists" believed in our sub-making system, and the same way I currently believe in my "E-mail me what you need, and keep the phone conversations brief" system.  If they didn't think it worked for them, they wouldn't be using it.  While I 100% agree with you that in many cases, it's crucial to have a real conversation, that doesn't mean there's anything wrong a company representative also asking the customer to file a JIRA.  One doesn't preclude the other.  Quite the opposite, for best results, they often go hand in hand.

In most cases, live conversation alone, without the JIRA, would not make for an inefficient use of everyone's time.  Through the JIRA, there's bidirectional feedback on the status of the project, as well as capacity for input from many different sources, instead of just one customer. There would be no practical way to do all that if live conversation were the only tool being used.

You said you did have a conversation with Nyx, and that as a result of that conversation, he did understand the issue, right?  So, mission accomplished, on that front.  The fact that he also asked you to file a JIRA on it doesn't erase the conversation.  It only affirms it, and adds to it.

I don't know why you'd assume that it "starts the process over again".  My guess would be the reason Nyx wanted the JIRA filed was so that the ball could be put in motion, to assign someone to fix the problem.  JIRA isn't just a tool for communicating with customers, after all.  It's also an important internal organizational tool, within companies that use it. 

You say he could have filed it himself, which is technically true, but as I've already speculated, there are any number of potentially good reasons why he might have asked you to do it.  If you didn't want to do it, you could easily have replied, "I'd prefer not to deal with the JIRA system.  Any chance you could file it?"  It was a two-way conversation, after all, right?

If I were in his shoes, I probably would have said yes, but I also would have been loudly reluctant about it, to make it clear that it was  a one-time favor.  After all, I wouldn't want to plant the seed in anyone's mind of, "Want to bypass the system?  Call Nyx, and he'll do it for you."  Once people start to get that kind of idea about you, your phone rings off the hook, and you can't get any actual work done.  In every business, it is super important to steer people toward using the procedures that allow you to do your work properly.


Look, my purpose here isn't to defend LL.  I've been among the first to point out a great many of the bad decisions they've made over the years.  I'd just rather do it in a way that is productive, rather than angry sounding.  That's the way to get business done.

If you think that that constitutes "jumping through hoops", we're going to have to agree to disagree.  I can promise you, my customers don't see it that way when I ask them to submit information in the manner that works best for me, as I've already explained.  Most thank me for it, in fact. 

As for this notion that when they want something new it's a different situation than when they want something fixed, I couldn't disagree more.  Whichever one it is, the manner in which I need to approach it from my end is exactly the same, and the information I need from the customer is exactly the same.  Therefore, the manner in which I ask them to document the request is exactly the same. 

 

You said your 'job' as the customer is just to enjoy the product.  I don't think that that's a very complete assessment of the relationship between any customer, and any company.  Just like with any other relationship, when one party wants something from the other, the former needs to inform the latter that they want it.  If there's a particular tool in place to facilitate such things, then it only makes sense to use that tool.

As for whether or not it's your "responsibility to help make the product better," I would submit that it's a shared responsibility that we all have.  This is as true with SL as it is with every other product there is.  You can choose to be just a bystander, if that's all you want to be, or you can take a more active role toward positive change, for your own benefit. 

I'll share a quick story that may help illustrate the point.  Several months ago, I discovered some shortcomings with the latest version of particular Adobe product, which ended up causing some problems for my entire department in a feature film I was working on.  After trying unsuccessfully to resolve the issue on my own, I hopped on the Adobe forums to ask if anyone knew of a solution, before I go back to using an older version of the program.  No one actually did have a solution, but an Adobe employee noticed the post, and asked me to submit a formal report, which I was more than happy to do. Apparently, the company had been completely unaware of the issue, despite Adobe's stringent quality control.

That same employee also took things several steps further with me.  He asked me to submit my ideas for any and all changes that could make my job easier, and he invited me to participate in the company's closed testing group, so that the entire active development community (consisting of both Adobe employees and customers) could participate in discussion of my ideas.

While I regretfully haven't had as much time I would have liked to fully engage with the group, signs are positive that at least a few of the ideas I've submitted will be implemented.  For me, and presumably for everyone else who participates in the group, it's a really good feeling to know that I can help to shape the tools I use every day, so that they'll work a well as possible for me (and for everyone else who does the same things I do).

Assuming any of the changes I proposed actually do happen, I will benefit directly.  Therefore, my "responsibility to help make the product better" is a responsibility to myself, as a user of the product.  When the product gets better, my work gets done more easily, which means I make money more easily.  Yes, I'm helping the company, but my motivation for doing that is for me.  What helps the company helps me.

 

As you are someone who's deeply invested in SL, someone who's running a business in it, I would have thought your motivations for helping LL would be just as selfish (for lack of a better term) as mine are for helping Adobe.  I'm among the most generous and selfless people you'd ever meet, and even I know that when I talk to companies whose products I use, the reason I'm doing it is ultimately so that my own life will get better. 

You're right that you're certainly under no obligation to help LL or anyone else, including yourself.  If you'd rather not participate in this sort of thing, you absolutely don't have to.  But if you're smart, you will, and I know you're smart.  We're all in this together.

Link to comment
Share on other sites

First let me say that we agree on many things that have been brought up. In my last post, I said you should REREAD, not read, as of course I knew you read it. I said constantly, because you have made assumptions numerous times in this conversation, and I didn't feel the need to correct you. The Nyx assumption was too eroneous for me not to correct. Possibly you read too fast. I have no idea. Possibly, you have your mind set on how I think about this issue and don't want my actual words to get in the way. I can only guess as to why.

As for writing jiras, I have done so every time LL has asked, and a few have actually been handled in a way that I find appropriate. I've also wrote jiras for other programs. I've helped with numerous bugs on numerous programs, all of which got addressed, except on LL's jiras. You are definitely right that it is a selfish act which also helps others. In some cases, I wouldn't even be able to do the things that make me money if the problem was not fixed. I've also had my own jiras for bugs on large complicated projects, none of which I allowed others to write them, except 1 beta tester that was intimately involved.

Sure, in some cases, I direct the customer through a process, but in these cases, we aren't dealing with defects. Providing a customized service and dealing with defects are 2 completely different areas. For defects, you can't really guide the customer through it. You have to listen first, then figure out all the different possibilities, and then asked the right questions or do the right tests.

In the case of the resizable mesh upload window, I knew that there was a brief window from which I had to bring this up to LL and they'd actually do something about it. When Nyx asked me to write the jira, I pretty much knew that nothing would be done, but I wrote the jira anyways. Briefly after posting, it's status was changed to NEED MORE INFO. More info on what? Today, this jira is 1 year old and is Awaiting Review. No person is assigned to work on it. Any1 want to bet that 1 year from today it will still not be fixed or implemented? Really, any1? I'll take any bets.

Link to comment
Share on other sites

You may be right that I read a little too fast, in a few places.  I honestly thought the word you'd used was "read", not "reread".  Those two little letters change the meaning of the whole sentence.  I will apologize, and chalk it up to the fact that my sleep schedule has been kind of screwy lately.

 

In any case, yes, it seems we do agree on a lot of things, but also disagree on several key points.  That seems to be the case whenever you and I cross paths, which is probably why we tend to have such lengthy and interesting conversations. :)

At this point, I think we've probably both said what we needed to say on this topic.  If you've got anything more to add, I'm happy to read it (more carefully, I promise), and reply.  If you don't, I think we can put it to rest, as nothing is coming to mind right now for me to add, myself.  Thoughts?

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4138 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...