This is a pretty generic question, but I hope it will be helpful. Under what conditions might it be possible to do a fairly quick to release version and then iterate the feature behavior towards something more sophisticated, without breaking things?
Best regards, Joel On 3/26/10, Carlo Wood <ca...@alinoe.com> wrote: > 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 > -- Sent from my mobile device Contact: Mobile: 508-728-2323 EMail: joel.fo...@gmail.com Skype: joel.foner Follow: http://www.twitter.com/joelfoner http://joelfoner.com CV: http://joelfoner.com/about http://www.linkedin.com/in/joelfoner _______________________________________________ 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
