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.*
_______________________________________________ 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
