corporate win--their requirements

[Gervase Markham]

Myk Melez wrote:
> Bradley Baetz wrote:
> But remember that user views intersect with product views, creating 
> potentially XxY formats.  I think we need a more sophisticated approach, 
> like perhaps product-specific and user-specific 

Group-specific, presumably...

> lists of fields to 
> display along, the union of which comprises the fields we want on the 
> form, along with some means of choosing from several different basic 
> layouts (maybe this can be made role-specific).

Or we make the layout more modular. E.g. email address fields vertically 
aligned here, with text fields here, and multi-selects in a horizontal 
row here, etc. etc.

But what about the query page? If you make custom fields 
product-specific, then each product will need its own query page, 
because otherwise the query page will be a superset of all possible 
fields, and a complete nightmare.

But then how do you do cross-product queries? A radical idea would be to 
make them impossible (although we could have an "add to this buglist" 
feature). This would significantly reduce complexity and page-download 
time once we have a third level.

>>> Third Level of Categorization (sub-component)
>>
>> If someone can come up with a UI, I'd prefer 'infinite level'. Since 
>> all components are unique ids anyway, if you kow the component, then 
>> you know the component's parent, and so on.
>>
> I thought so too at one point.  Now I'm not so sure, since the 
> implementation complexity of n-level systems increases greatly, while 
> the utility of fourth and subsequent levels drops at the same high rate.

I'm not convinced by the n-level system either. As Myk says, it would be 
very hard to find a use for more than three levels, and as bbaetz hints, 
the UI to define the relationships in an n-level system would get really 
hairy. And the implementation would be hard.

Gerv