[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Re: mdgrid and enabling/disabling axis

From: Vadim Zeitlin
Subject: [lmi] Re: mdgrid and enabling/disabling axis
Date: Wed, 11 Jan 2006 22:52:15 +0100


 I'm continuing this private discussion we had with Eugene on the mailing
list as I think it may be interesting to the others -- and I also hope you
may help to find the best answers to the questions below.

ET> (1). Allow a user to add/remove axis (dimension) to/from a product domain
ET> Data: We should probably add a flag for every axis used in mdgrid that
ET> indicates whether the axis participates in a product domain (product value
ET> being dependant or not on the axis value). It implies that the underlying
ET> MultiDimGridTable have to support enableing/disableing of a particular axis
ET> in a product domain. Maybe those flags (mentioned in the sentence above)
ET> should be put inside MultiDimGridTableAny and not into the MultiDimGrid).

 I agree. Indeed, the information about whether the values depend on/vary
along the axis must be passed to the table -- it may be important for it.

ET> UI: At that point there are two approaches discussed.
ET> First one with checkboxes near every axis that control directly those flags
ET> from above.
ET> Second one with the additional 'Invariant' (invariant is inappropriate here,
ET> because it means that something (product for example) does not depend on the
ET> axis, and its not the axis that is invariant -- better 'unapplicable')
ET> option in drop-down axis value lists.
ET> Question: how should we address the merging problem? When user marks axis as
ET> unapplicable (disables it from product domain) and there are different
ET> values of product for different values of that dimension, which value should
ET> editor choose? A good example is a product that depends only on Gender that
ET> has, say value of 5 for 'Male' and 10 for 'Female', imagine that user
ET> disables that Gender dimension from the product -- what value should it have
ET> after -- 5 or 10 (or even NULL)?

 Excellent question... I don't think there is a single best solution for
all situations so I believe we should provide some flexibility here. For
example, my first idea was to check if the values for all genders were
really the same -- but while this would probably work well in this case,
it might be not the best thing to do if there are a lot of values. So,
again, IMHO this should be configurable. I see 2 ways to do it:

- supposing we have some MDGridTable::ExcludeAxis(axis) (as per above), we
  should delegate the decision to it, e.g. it could return true/false to
  allow/forbid disabling this axis

- ask the user what to do

Does anyone see anything better?

ET> (2). Allow a programmer to control the set of axis available (for adding
ET> into a product domain) to a user for a given product
ET> Data: nothing to be done probably as we have already stated the set of
ET> dimensions to vary the product value upon in the MultiDimGrid constructor.
ET> UI: it should be addressed along with 1_UI.
ET> Question: could we imagine the below UI:
ET> /-----------------\
ET> |  X axis: Strike |
ET> |  Y axis: Gender |
ET> |                 |
ET> |x Strike: -----  |
ET> |x Gender: -----  |
ET> |x Option: value? |
ET> |-----------------|
ET> |  Maturity  +add |
ET> |  Smoking   +add |
ET> \-----------------/

 Sorry, what are the "+add"? I thought we'd just have just unchecked
checkboxes near the unused axis?

ET> Or another one:
ET> /-----------------------------\
ET> |      X axis: Strike         |
ET> |      Y axis: Gender         |
ET> |                             |
ET> |      Strike: -----          |
ET> |      Gender: -----          |
ET> |      Option: value?         |
ET> |-------------------^^close^^-|
ET> | /--------\     /----------\ |
ET> | | Strike | =>x | Maturity | |
ET> | | Gender |     | Smoking  | |
ET> | | Option | +<= |          | |
ET> | \--------/     \----------/ |
ET> \-----------------------------/
ET> The ^^close^^ could be a button that shows/hides the bottom part (plays the
ET> role of that global checkbox).I hope its pretty self-explanatory.

 I think this one would take too much screen estate. But it's still an
idea to consider...

ET> (3). Prevent user from accidentally adding or removing an axis(dimension)
ET> from a product domain
ET> Data: nothing to be done, because its a UI-only feature.
ET> UI: Two approaches were discussed:
ET> First one with a sort of a modal dialog (from the legacy editor approach)
ET> that allows to select the applicable axis for the product value domain.
ET> Second one with a global checkbox (or button) freezing enabling/disabling of
ET> axis (or removing that 'Unapplicable' option from drop-down value lists for
ET> applicable dimensions and disable unapplicable axis drop-down lists)

 To be honest, more I think about it, less sure I become how useful this
feature is. Even if you accidentally check the "use this axis" checkbox or
select a value different from "N/A", it's not really a problem to uncheck
it back or to select "N/A", is it? Maybe we could start without it and ask
the users how do they feel with this UI and add this extra protection only
if it is deemed necessary by them?

ET> (4). Read-only mode in the mdgrid widget
ET> Data: Probably a flag or a boolean function in MultiDimGridTable that
ET> controls whether we can alter product value domain. And another parameter to
ET> MultiDimGrid indicate whether we are in read only mode.

 If we have MultiDimGridTable::IsReadOnly(), we probably don't need
anything else in the grid, do we?

ET> UI: if read-only mode then don't show UI features concerning 1

 Notice that for this we'd need to be able to detect whether the values
depend or not on the given axis... So maybe we finally need a function to
do this in MultiDimGridTable -- and it could be also used to check if the
user can disable this axis (see second half of point (1) above).

ET> and disable editing in the wxGrid table showing read/only product
ET> values.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]