[Chandler-dev] [Proposal] Web UI Work Q

[Brian Kirsch]

Hi Travis,
Can the Dojo 1.0 work be divided among developers (me, you, jeffrey)  
to speed up the integration process
and thus get to the goals below faster?

-Brian


On Feb 13, 2008, at 1:07 PM, Travis Vachon wrote:

> Hi Mimi
>
>>
>> I. REDUCING # OF CONCEPTS DESKTOP USERS NEEDS TO UNDERSTAND TO  
>> START SHARING
>> + Remove OOTB Hub collection
>> - This is confusing Desktop users who have a different set of OOTB  
>> collections and end up seeing the Hub OOTB collection when they  
>> set up their Hub account on the Desktop. Grace thought that the  
>> OOTB Hub collection contained all the stuff she was putting into  
>> her Chandler Desktop Dashboard collection (which she never  
>> published) and couldn't understand why she wasn't seeing items in  
>> the Dashboard collection in her OOTB Hub collection and vice versa.
>
> I'd be pretty concerned about how confusing this would be for stand  
> alone users. That said, this would probably be Randy work and I  
> don't plan on blocking it, so I'm just -0.
>
>>
>> + Automatically generate 2 tickets (View and Edit and View-only)  
>> when users create new Hub collections - https:// 
>> bugzilla.osafoundation.org/show_bug.cgi?id=10261
>
> Sounds fine, though I remember vague worries from Jared about  
> security here, I'd rather do something along the lines of adding a  
> little bit of code and web ui that says "share this collection." In  
> the new security model this will just mean giving them a link to  
> the collection without a ticket, and we could add an option that  
> would make the client generate a ticket if they want to share read/ 
> write.
>
>>
>> + Fix Collection Details Dialog to distinguish between Subscribing  
>> and Sharing (see mock-up 1)
>> - List out URLs for the all the different ways to subscribe + link  
>> to instructions on wiki page (I will re-factor instructions Travis  
>> pulled together)
>> - List out ticketed URLs for sharing with others
>> - Option to download
>> - Move 'Save' button for saving a name change to the bottom of the  
>> dialog
>> - Move Delete button to bottom of the dialog
>
> I agree that this dialog is confusing. In particular I'd really  
> like to see the sharing instructions sanitized. Moving the save and  
> delete buttons around may or may not be trivial, so I'd want an  
> upper limit of maybe a couple hours spent on that, since I don't  
> see how they particularly enhance sharing.
>
>>
>> II. IMPROVEMENTS TO THE TICKETED VIEW (see mock-up 2)
>> + Add 2 pixel divider underneath 'ADD TO MY ACCOUNT'
>> + Move 'Subscribe' and Download options to the sidebar below
>> + Add 'Share' option
>
> Again, moving these pieces may not be trivial (I suspect from  
> working in them last time that they aren't) so I really think we  
> should have strict time limits.
>
>> + Clicking on any of the links in the sidebar for subscribing /  
>> sharing pop-sup a 'ticketed' version of the Collection Details Dialog
>> - Collection name is not editable
>> - URLs should be different for subscribing I imagine
>> - Only 1 ticketed URL, whichever one the user used to access the  
>> ticketed view (Ideally, if you received a 'View and Edit' ticket,  
>> you should have access to the 'View-only' ticket as well, but  
>> that's a nice-to-have.)
>
> This is basically along the same lines as (I), in that most of  
> these changes are focused on cleaning up the "get sharing  
> instructions/information" process.
>
> I think perhaps a better idea would be to come up with a new dialog  
> that is specifically focused on giving users information about how  
> to share and subscribe to collections. This will let us really  
> emphasize the "sharing" idea in the web ui and leave us some room  
> for making the save/delete buttons a little prettier in the  
> collection info dialog. To minimize development time the dialog  
> should be pretty much the same in "ticket collection" and "regular  
> collection" mode, though minor things like number of ticketed links  
> and "share link" ui could of course be different. This will make  
> development faster and minimize the amount of futzing we need to do  
> with the current ui.
>
> Pursuing this strategy would probably take 2-3 days of dev and  
> testing, while making all of the changes you suggest would probably  
> look more like a week at least.
>
>>
>> III. MAKING WEB UI MORE USEFUL FOR STANDALONE USERS AND REMOTE  
>> DESKTOP USERS (see mock-up 1)
>> + Sort Triage Status by 'TriageStatusChangedDate' so that newly  
>> created items appear at the top of the list, right now they  
>> disappear to the bottom of the NOW items.
>
> I have no idea how hard this would be, so I'd estimate 2 days at  
> least.
>
>>
>> + Making the Notes field Usable
>> - Remove 'Addressing' and 'Task' stamp from DV, give space over to  
>> Notes field
>
> This is probably 2 days of work and testing.
>
>> - (Optional) 4. Add 'Star' stamp to markup bar.
>> - (Optional) 5. Swap task stamp icon for start stamp in the table  
>> column header.
>
> I'm afraid I don't understand what the star stamp is doing here. If  
> it's literally just stamping something as a task it probably  
> wouldn't be too bad 2 days of work and testing.
>>
>> IV. SETTING EXPECTATIONS
>> I need to come up with explanatory text for the account  
>> confirmation page and log-in page that highlights what you can do  
>> with the web UI. (I need to think about this more.)
>>
>> V. VISUAL CLEAN-UP + MARKETING
>> + Change 'selected highlight color' to match link color: #0066ff
>>
>> + Move New collection Link to top of Sidebar
>> + Move divider to top of Sidebar, make it 2 pixels (#CCCCCC)
>> + Add 2 pixel divider under 'ADD TO MY ACCOUNT' in ticketed view  
>> (#CCCCCC)
>
> These bits should be mostly trivial, but all together will probably  
> be 1-2 days of work and testing. Depending on how complicated the  
> changes to the login and account confirmation page are it could  
> easily be an extra 1-2 days.
>
> So all total we're looking at 2 weeks of work for this spruce up. I  
> think that devoting 2 weeks of work to a spruce up within the next  
> 3-4 months sounds pretty reasonable and could possibly even be  
> broken up somewhat to make it even more palatable, with a couple  
> caveats:
>
> - I'm -1 on doing any work on this before the dojo 1.0 work has  
> landed unless there is overwhelming opposition to that sentiment.
> - I'd like to get a couple of the new widgets into full scale  
> deployment before we start this work. We can theorize all we want  
> about what the pain points in the application will be once we've  
> deployed the widgets but we're bound to be surprised. I suspect at  
> least one of these items will seem less important and at least one  
> new task will seem much more important once we've gotten a couple  
> widgets deployed. Assuming the dojo 1.0 work does finish up in 4  
> weeks and adding 2 weeks to get a couple widgets into production  
> that puts this spruce-up work at the beginning of April. That  
> sounds just about right to me (spring cleaning!).
>
> -Travis
>
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20080213/419ba891/attachment.htm