Hi Pierre,
> 1. For the record: the ability to create a new style is one of the items
> of the list of styles.
Yes, that's the intention.
> 2. I understand that we will defer the option of sorting conditions.
> However I disagree with the proposition "the Add button Appended to the last condition".
> - It adds the risks and constraints mentioned
> - It does not allow to insert a condition. The user has to delete and recreate all of
> the following to insert a new one.
>
> My proposal (with your mockup) would be to have an Add button (left to Remove button)
> for each condition. These two buttons would be located below the preview area.
> - Click Add to add a condition after the selected one.
> - Insert becomes possible
> - Defer the sorting feature is less penalizing
We never had sorting, so at least that's not a regression.
I know it's a somewhat basic feature to leave out, but here's hoping
that there will be someone to implements the basics for nice drag-drop
stuff within the whole app (i. e. a reliable animation framework to
show status changes; and of course drag and drop if that's not already
in place).
The problem with an Add button inside every condition is one of UI
hierarchy. All current buttons within the condition field act directly
upon the condition, but Add would not.
Also, I don't believe there should be so much need to add conditions
at arbitrary places in the list, so, no, I don't feel like adding
that...
> - No risk of hidden button
The button is designed this way, so the newcomer instantly knows where
to click to add a condition (ease the learning curve). It comes with a
few drawbacks, but I also described on the wiki how the major ones can
be mitigated.
> 3. It is crucial to know what cell is the current one when defining a "formula"
> condition. "Area" should include "Current Cell". Space is not an issue here
> (ability to hide the area)
Oh, sorry I forgot about Regina's and your criticism... I'll update
the mockup to include "Origin Cell" (which seemed to be the most
fitting name to me, but please do comment!) in the next minutes.
> 4. My proposal mockup was a first attempt in the discussion. It included the ability
> to disable (not delete) a condition. While this may be useful, especially for testing,
> this would require changes since this property is not currently available.
> I propose not to retain this proposal.
Okay, this matches up with what I thought. :)
Astron.
--
Unsubscribe instructions: E-mail to
[hidden email]
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/Posting guidelines + more:
http://wiki.documentfoundation.org/NetiquetteList archive:
http://listarchives.libreoffice.org/global/design/All messages sent to this list will be publicly archived and cannot be deleted
Locked
