[Design] Re: implementation ideas for "sections"

[Mimi Yin]

[Replying to this thread on the design list to propose some design  
alternatives and revisit the issue from a workflow and use case  
perspective.]

+ Showing and hiding sections
+ Arbitrary number of sections
+ Also perhaps, arbitrarily defined sections (ie. One section is  
defined around a triage status and another section is defined around  
a person, a third section is defined around a Project. Triage status:  
NOW items, @Joline items, Project: Juno account items )

Another potentially cheaper way to address this problem would be to  
have the user "check-off" collections in the sidebar which would in  
turn create 3 "sections" in the summary pane or 3 separate summary  
panes, 1 pane for each collection "checked" off.

+ Sidebar collections are already user-definable
+ Part of the virtuality plan is to allow users to define sidebar  
collections around more specific attributes (ie. Status, People,  
Projects, Context, etc).
+ We could implement explicitly ordering collections in the sidebar  
as a way to provide users with easy access to the collections they  
look at most often (move to the top of the collection list).
+ Would minimize vertical scrolling in the summary pane to find  
sections.

I'd like to propose doing a short use case exploration as a way to  
guide some of these feature decisions (please reply with your own  
scenarios):

When is it useful to have sections?
+ Facilitates DnD filing of items into different lists
+ Allows you to view more than one list at a time

What are some examples of such lists?
+ Project lists
+ @People agenda lists
+ Status lists

What are some scenarios:
+ Amit is having a one-on-one meeting with Jeremiah. Amit needs to  
draw up both the @Jeremiah agenda he's put together for his one-on- 
one meetings with Jeremiah as well as be able to view the Project  
lists in order to review the status of various projects that Jeremiah  
is working on. At the some time, Amit needs to be able to see his own  
list of "NOW" items to figure out how much additional work he can  
take on and what a reasonable turnaround time might be.

Mimi

On Jan 30, 2006, at 1:18 PM, Mitchell Kapor wrote:

> Since I think we agree in the general case we want to be able to  
> handle an arbitrary number of sections, the question which Alec  
> raises of whether the header stays visible if the section scrolls  
> out of view is very relevant.  My opinion is that we shouldn't keep  
> the header on the screen if its section would otherwise be offscreen.
>
> I also think that managing screen real estate when you have a lot  
> of sections is generally a tricky issue.  One idea is to have three  
> states, not two, for every section.  open, closed, and hidden.   
> Hidden sections take up 0 rows.  OK, so you ask how do you know  
> that they are there at all.  Easy.  You put some sort of mark along  
> side of either the section above or below.  Clicking on it or  
> whatever reveals it.  Hovering over the mark could show names of  
> hidden sections.  I've always wanted this in my outline editor.
>
> On whether every section should have the same columns, I am  
> inclined to say yes.
>
>
> On Jan 27, 2006, at 3:01 PM, Alec Flett wrote:
>
>> So John, Jeffrey, and I have been discussing some suggestions for  
>> how we might implement "sections" as Mimi has described them.
>>
>> The basic ideas I've pulled out of the design sessions are:
>> 1) There are initially 3 sections, one for each of "now", "later",  
>> and "done"
>> 2) We might allow other arbitrary groupings depending on other  
>> attributes - i.e. by subject, by 'who', etc
>> 3) The sections have headers and are collapsible
>> 4) There is one giant scrollbar to scroll the whole display,  
>> rather than scrollbars per-section - so that, for instance, you  
>> could scroll the "later" section right out of view.
>>
>> There are some open issues, that both influence, and depend on  
>> design decisions:
>> 1) When a section is scrolled out of view, does the section header  
>> stay in view? (seems like yes, we'd like it to stay in view if at  
>> all possible, but I'm not 100% sure.. that would probably be very  
>> nice for just 3 sections, but really bad for more than 5-6)
>> 2) Where does the header for the columns live - above all the  
>> sections/data or one header per section? (seems like ideally just  
>> one header)
>>
>> There are a few possibilities on the table right now:
>> 1) Have a bunch of grids, and use a 3rd-party widget to collapse  
>> the sections. In the background, keep the grid columns aligned.  
>> The grids would all live together on the same wx.Panel, which  
>> would scroll in some fashion.
>> There are some details to this implementation which would need  
>> further clarification:
>>   a) How do we actually size each grid widget on screen? As we  
>> scroll, do we tell each grid widget to get smaller and larger, but  
>> suppress the per-grid scrollbars? John thought this was  
>> unnecessary, that we could just tell the grid to be exactly the  
>> right height to fit the number of rows in the section, and that  
>> the grid wouldn't try to draw the rows that weren't on screen. I  
>> thought that the grid would still be allocating data structures  
>> just to maintain its own geometry, but we weren't sure if that was  
>> actually true or not.
>>   b) would that make it hard to allow section headers to remain on  
>> screen, since you'd essentially have to move them within the Panel  
>> so that they were always in a visible part of the Panel. And if  
>> that's the case, wouldn't they overlap with the grid? We'd have to  
>> hide the grid I guess, especially since wx doesn't like  
>> overlapping child windows.
>>   c) It would be easy to do a unified header widget, since it  
>> would live outside of any of the grids, and would just make sure  
>> all the grids stayed in sync.
>>   d) if we started sectioning on another attribute, there would be  
>> a lot of tear down and rebuilding of grids - but maybe that's ok
>>
>> 2) Use the grid as it stands now, but delineate certain rows as  
>> section header rows. The grid scrolls as normal, but when drawing  
>> a row of data, we would essentially be offsetting the grid row by  
>> the number of headers above that row. i.e. If we drew a "now"  
>> header at row 0 in the grid, then the data would start at row 1.  
>> If the "later" header was at row 33, we'd display the 32nd item in  
>> the collection at row 34 because the "now" and "later" headers  
>> were above this. Issues around this:
>>    a) where do we do this translation from data row -> grid row  
>> and vice versa? Seems like wxTableData (or a derivative) is a good  
>> candidate
>>    b) how do we draw sections headers? It seems possible to put a  
>> widget in a particular cell, but is there a way to indicate to the  
>> grid drawing code that you want a cell to span multiple columns?  
>> i.e. it would be nice if we could just put a "section header  
>> widget" in the first cell of the section header row, and draw all  
>> the way across the grid
>>    c) We'd just use the normal grid header, which is ugly - so  
>> we'd have to figure out a way to integrate davids' ColHeader  
>> widget into the grid. This would be a nice thing to give back to  
>> the wx community, as we think they want this anyway.
>>    d) section collapsing and keeping section headers on screen  
>> would be pretty easy - just a modification to the wxTableData data/ 
>> grid row mapping.
>>
>> I personally prefer 2) - I think its more likely to lead to a  
>> cleaner design in the long run, plus be easier to implement in the  
>> short run. The one thing I am worried about is 2b) but I'm pretty  
>> sure we can come up with some workarounds even if we can't make  
>> cells span all columns.
>>
>> Alec
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev