[Design] [cosmo] [proposal] Detail View

[Adam Christian]

 From the UI QA standpoint I really don't feel that one design is  
going to be any different than the other in terms of total testing  
time. Either way I will be writing all of the automated test, spend  
time working with mde on getting hooks for all the different pieces  
in javascript and manually testing everything that isn't possible to  
automate, so I really don't know of any reason that QA time would be  
any different.

 From our point of view, doing it right the first time is more  
efficient. If we are talking about doing this UI later, that means we  
have to write all the tests, do all the manual testing, then go back  
and do it all again if we decide to make these changes later.  
Granted, we can make hooks for the basic pieces that don't need to  
change, but for every new element on the UI, we have to write a test  
to manipulate and verify results and that is very specific to the  
pieces of the DOM.

mde, mikeal, am I missing anything in there?

Adam

On May 7, 2007, at 4:28 PM, Pieter Hartsook wrote:

> I want to agree with Katie. I think that from a public view of our
> project, getting something that works shipped by mid-July (read that
> as before OSCON) is more important than tweaking the UI. So if
> adopting the new UI adds additional risk of slippage I would vote for
> the less risky choice.
>
> But, if the risk is about the same and the development and QA time is
> about the same, I would encourage us to explore the web-centric UI.
> Maybe because we would be using standard collapse/expand panels the
> risk to get something that fits in a standard browser-size window
> could be less than porting the Chandler desktop design.
>
> Even if the new UI turns out to be riskier and we decide not to do
> this for 0.7, again I would agree with Katie that we should plan to
> try this implementation post 0.7 and not let this decision create
> inertia that  blocks future exploration.
>
> So, bottom line -- I like the idea of the new UI, I think we should do
> it, but only do it for 0.7 if risk to slippage is not greater than the
> existing desktop UI.
>
> Pieter
>
> On 5/7/07, Katie Capps Parlante <capps at osafoundation.org> wrote:
>> A couple of thoughts from a strategic perspective:
>>
>> 1. The design looks promising. In general, we shouldn't be  
>> shackled by
>> desktop constraints when thinking about designs for the Hub UI.
>>
>> 2. Getting the release out is most important. The cosmo schedule has
>> slipped -- the 0.7 timeframe is very tight. Risking the schedule  
>> further
>>   is not a good thing. A new design introduces schedule risk, even if
>> the implementation is the same, as a new design will likely require
>> further discussion and decision making.
>>
>> Getting something out is most important.
>>
>> FWIW, if we don't pursue this design now, I think it is worth  
>> pursuing
>> it for a 0.8 release. At the end of the day, the dashboard design is
>> going to be hobbled in 0.7, because we thought it was most  
>> important to
>> get *some* first version of it up, with the correct infrastructure
>> behind it. This doesn't mean we are stuck with every detail in the  
>> first
>> pass forever. I hope to see us experiment with dashboard and detail
>> features post-preview.
>>
>> Cheers,
>> Katie
>>
>> Priscilla Chung wrote:
>> > This coming week Matthew is going to re-implement  the details  
>> view of
>> > the web UI in order to support stamping for dashboard. He  
>> informed me
>> > that he will have to start from clean slate.  From my  
>> understanding, the
>> > amount of time to implement a layout identical to the desktop  
>> and time
>> > to implement a proposal are about the same.
>> >
>> > So we took this opportunity to look at the event details on the  
>> desktop
>> > and see if there are ways to address some of the known issues.  
>> How to
>> > make it behave more like a web application. Come up with more  
>> visually
>> > acceptable solutions to incorporate all the form elements  
>> without losing
>> > the 'Save' and 'Remove' button on smaller screen sizes.
>> >
>> > ****Note: Please review the questions below before commenting on  
>> the
>> > design proposal.****
>> >
>> > We came up with a proposal which is a slight departure from the  
>> current
>> > desktop layout of the detail view:
>> > http://wiki.osafoundation.org/Projects/ 
>> CosmoZeroDotSevenSpec#CurrentMockUp
>> >
>> > **The reasons for coming up with a new proposal for detail view  
>> are the
>> > following:**
>> > + The current layout which is adapted to the desktop app is not  
>> well
>> > suited to web conventions.
>> > + This layout better scales to handle small screen sizes and/or
>> > additional types of stamps.
>> > + Right now we have only three stamps, but there is no more  
>> space on the
>> > horizontal 'mark up bar'. The proposed layout scales for addition
>> > stamps, including other ideas such as annotations for read-only
>> > collections, per a previous discussion on the design
>> > list: http://lists.osafoundation.org/pipermail/design/2007-May/ 
>> 007059.html
>> > ).
>> > + The visual relationship strengthens the visual grouping and
>> > association for the address, task and event stamp and their  
>> associated
>> > capabilities.
>> > + The Casual Collaborator target user, is someone who does not  
>> use the
>> > desktop every day and may need more guidance in understanding the
>> > concept of the the address, task and event stamp.
>> > + It's not going to take more time to build than implementing  
>> the layout
>> > similar to the desktop.
>> > + The current layout which is adapted to the desktop is very  
>> tight—the
>> > web app may have problems with different fonts and font size.
>> >
>> >  From the very beginning Mimi and I agreed to keep the two  
>> applications
>> > consistent, but only **where it makes sense**. This proposal is not
>> > intending to create a unique web UI for the sake of it. We felt  
>> the web
>> > app is a good way to try ideas out, where the desktop app lacked in
>> > experimentation because it would longer and be prone to more bugs.
>> >
>> > **The reason not to move forward with a new proposal for the  
>> detail view:**
>> > + Discussion on the design list may impact schedule.
>> > + If this proposal distracts from /'//the purpose of preview'/,  it
>> > makes sense to postpone this discussion till post preview.
>> > + It's not identical to the desktop app and might cause problems  
>> with
>> > some users, primarily desktop users who are used to using the  
>> desktop.
>> > For preview, the target user for the web UI are Casual  
>> Collaborator and
>> > not the 'Consultative desktop users'.
>> >
>> > It's fine if we decide to move forward and mimic the layout on the
>> > desktop, as long we're aware of the known issues. Trying  
>> something new
>> > may fix some issues however it will also create other issues. If  
>> our
>> > concern is schedule, doing something new may not necessarily cause
>> > risk—though I lean on Ted/Matthew to confirm this.
>> >
>> > Usability risk is unknown at this point because we don't have users
>> > testing the proposed layout vs. the desktop layout, but  
>> implementing two
>> > different layouts offers us the opportunity to test and learn  
>> from our
>> > users. I understand completely if the team as a whole does not  
>> want to
>> > take a chance on this because there are a lot of risk factors  
>> already.
>> >
>> > **Questions:**
>> > Forgive my bluntness, but it seems like time is against our  
>> side, so
>> > before commenting on the proposal, I'd first like to ask:
>> > + Is this proposal distracting everyone from /'purpose of  
>> preview'/?
>> > + If so, then we should consider tabling this discussion till post
>> > preview—where it belongs?
>> > *
>> > *
>> > -Priscilla
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design