[Design] [cosmo] [proposal] Detail View

[Mikeal Rogers]

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/design/attachments/20070507/10bd5182/PGP.pgp