On Dec 13, 2007 12:52 AM, Davor Cubranic <[EMAIL PROTECTED]> wrote: > On Tuesday 11 December 2007 03:39:31 hank williams wrote: > > The design is not that complex to fix. In web applications, companies > > are iterating daily and fixing stuff until they get it right. This > > process should not wait till 2.0. The world moves too fast. > > OK, call it 1.1 then. It can start right after the 1.0 release, but I > don't think the dashboard redesign was being mentioned in the 1.0 > release goals that Sheila posted last week. My point was that if the > current design of the Dashboard confuses and puts off new users, and it > cannot be fixed before 1.0, then perhaps Chandler is better off without > a Dashboard in 1.0. > > At any rate, I don't think your comment about changing the > design "daily" holds up very well on the desktop where users have to > download and install the app and, potentially, migrate their data. I > think the Chandler team has worked really hard to get down to six-week > milestone release cycle.
I am not suggesting they can do what web guys do. I am suggesting that that is *the competitive environment*, and it makes the issue of fixing critical issues important. The fact that your competition has the capacity for instant iteration is a serious issue and makes responsiveness key. It's not that nothing happens in between -- > there are continuous builds available for download and (weekly?) > checkpoints -- but those are not fully tested, and I'd be curious to > see how many non-OSAF users actually download and use those. It's more > realistic that the Dashboard redesign would happen over a series of > milestone dot-releases in early- to mid-2008, if that's what OSAF > chooses to put the focus on in post-1.0. (And which improvements I'd be > very happy to see, BTW.) > Chandler has been gestating for 6 + years. I would agree that 6 weeks to fix something is not a problem. My concern is that from Mimi's tone, she really *doesnt believe* there is a problem. These are things that will be fixed at "some point in the future" that are actually easy to fix if one decided they are important. Instead she believes that some good user training, demos, support etc will fix the problem and help us "find the pony" in chandler. Hank _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
