Like Katie, I certainly don't think we should be constrained by the desktop and prevented from exploring alternatives for the Hub UI.That being said, it seems to me like we are getting into a debate about the design details which clearly demonstrates what we are worried about. As much as we would like to be able to take this design as is and assume there are no issues and no discussions to be had, we have seen many times before that when you go to implement something, this stuff just surfaces. These things take time to resolve and bandwidth for discussions that isn't going into something else. My view is purely from a risks and schedule perspective. We could very well move forward with a new design and resolve any issues really quickly but this is unknown. Sure, the desktop detail view design doesn't translate perfectly to the web but we know what those problems are and we can just choose to live with them for now.Remember it's Preview not 1.0. It's about getting something out there even if we realize there are problems and limitations. We have certainly compromised in many areas of the design, not just the detail view. There is nothing to say that we won't revisit many UI issues on BOTH the desktop and web post-Preview. I believe this is part of what we are trying to accomplish with getting out an initial version in the first place.
mde has stated that, as is, the dev time is very low and will result in something that ( according to all the feedback we've seen so far ) a better UI. So we're talking about perceived risk in two plans.
Why is there an assumption that copying the chandler detail and implementing "as is" is low risk. We've already said that there are risks in that design and solving those issues is harder following a UI based exactly on chandler desktop. So both designs have risks for development, and one design makes usability suffer greatly on low resolution.
I'd also like to note that mde's test where the non-collapsing detail view barely fit on 1280x1024 is when the browser is at default size, the browser is not the desktop client and is usually resized in some way and we are currently fixing the calendar UI for different window sizes within a certain range.
With more room to work in the detail view we have a small reduction in risk. Can anyone please elaborate on the design risk in a new UI that fits the same components and semantics as the existing chandler UI in a manor better fitting a webui. I'm racking my brain trying to figure out what all the issues are and I honestly can't think of more than a few minor problems.
Yes, this is only the first iteration of the UI and there will be more, but I don't think myself or the developers are seeing anyones reasoning for not going for this better UI now and I think we would all appreciate a little bit of elaboration from PPD. We've tried very hard to voice our concerns in the small window we have before EOD and would like to know that our time hasn't been wasted.
I'd also like to say that one UI has to room for "iteration" and the other is essentially throw away code after 0.7 which I think is what is making some of us a little more adamant about this right now.
-Mikeal
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
