Jonathan, I have no disrespect at all for Nyx. And yes, it's highly appreciated that he asks us for input instead of just implementing it.
Still, if nothing in his original design is going to be changed then the effect is almost the same; except if this list is convinced that his original design is indeed the best. Apparently that stands or falls with having time (money) to do anything beyond what he already planned to do, and therefore explaining that is the only way to make the list understand this. Hence my question. Not because I think he is wrong, but because I want to know (and understand): Why not implement the extra requests from this list and then release the whole feature three months later? Imho it IS better to delay the feature and release a really well-thought-out new feature that will really work for a long time, than to be 3 months sooner and have people feel frustrated about little shortcomings for the next 3 years. Specifically to Jonathan: I'm sure this is a misunderstanding in the way my post came across. I appologise for that. It's sometimes hard to come accross correctly in written emails (I'm not even good at it in RL). On Fri, Mar 26, 2010 at 02:52:39PM -0500, Jonathan Irvin wrote: > > On Fri, Mar 26, 2010 at 06:56, Carlo Wood <ca...@alinoe.com> wrote: > > It bothers me a bit that we (you) would choose to go > for an implementation that is not the best or the > ideal one, ONLY because you want to push out a new > feature "in time". > > > Carlo, it pains me to see you have this attitude towards the > Lindens...especially those who are in here trying to communicate with us. > ***Linden Labs has limited resources*** They can't just magically allocate > time > and money to a feature that would be awesome because you think so. They have > time and money constraints. > > > Personally, I'd first design how I'd want it to look > from the user point of view (what most of the discussion > from the community is about) without taking into account > coding arguments. And once we have that, I'd just > implement it, no matter the costs or time needed. > That is what coders do: they implement what is requested. > > > This is a blind perspective to have. Coding constraints come into play > because > coding takes time and when you are on a payroll with a budget, time = money. > You have to sacrifice the really awesome feature that will take a while for > the > ones that are easy, but have an ok benefit. > > The Lindens aren't tools, my friend. Perhaps showing more respect for them > will give you respect in return by getting us new features. And, keep in > mind, > this is an OpenSource forum. If you have an idea, make it happen and pitch it > to us. Code it yourself and post it to the open forum. The lindens have > enough on their plate as it is which is why they went the opensource route to > begin with...having the assistance of the community make a better product. > > > Thus, since for almost everything we said so far your > argument is: we can't do that within the given timeframe; > can you defend, or at least make acceptable and understandable > that "a" new feature has to be added in 3 months, even if > that new feauture is a bit inferior compared to what > that UI could have looked like? > > > Again, show some respect here. The lindens have a lot on their plate and are > wanting you to make a business case for this. They need to know a feasible, > tangible way they can impliment feature ABC while not over taxing their > resources. Also, this feature needs to be used by the whole and not a small > percentage of users. > > > Changing it AGAIN in the near future (ie, 6 months later) > is probably not going to happen for several reasons :/ > So, not doing it right now has almost the same implications > as deciding to never do it. I'd really like to understand > why that is the best thing to do. > > Thanks for discussing this with us, > Carlo Wood <ca...@alinoe.com> > > PS With regards to the UI design. > I like the concept of "click wear" inserts the wearable > in a default place, after which you can reorder it. > And where this inserting means "at the top of a folder > that one of the currently existing wearable categories". > It just makes sense. > > But, in the end the goal should be that wearer can > determine the order of every texture layer, or at > least to a great extend, including: > - Tucking in jackets or not (jacket <-> pants ordering) > (my proposal was to add a pseudo jacket, below or > above which other jackets are below or above the pants). > - Wearing shirts over jackets (jacket <-> shirt ordering) > (proposal was to be able to dump a jacket in the 'shirt' > folder if one wishes). > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > > In conclusion, have a little more common courtesy. The fact that the Lindens > are participating as often as they are and engaging in good conversation > should > be something you shouldn't take for granted. > > > Think good business. > -- Carlo Wood <ca...@alinoe.com> _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
