Hey Astron, > Sorry for the extremely long wait. I am not sure if my mockups live up > to any expectations that might have built up, but here we go... > I've just updated: > https://wiki.documentfoundation.org/File:Mockup-conditionalformatting.png > Take a look. In the following, I will use (n) to refer to the part of > the mockup I am referring to. > > So, what's changed? > > * I've integrated drag/drop sortability as well as sorting via buttons > in a hopefully not too intrusive way.
Will need to investigate if this is possible in the way as you suggested it but will try to implement this idea. > * It can't be seen in the mock-up, but it would be good, if condition > sorting via drag/drop had similarly nice animations as the slide > sorter in Impress. Can't promise that. Might be too much work to integrate that for such a small feature. > > * The Add button has wandered into the position where Condition n+1 > sits, so it is now integrated in the conditions list box. This is to > make it more obvious that one can add more conditions when there's > only one set by default. That will indeed make it harder to add > conditions once the initial space in the conditions list box is filled > up. We might be able to mitigate that problem by moving the whole > Condition n+1 field with the Add button permanently to the end of the > list so it doesn't scroll when the rest of the list scrolls. (I hope I > described that clear enough, although I fear I did not. Please ask.) > * It's still not possible to add conditions in an arbitrary place in > the list. I consider that a design decision. > > * When a condition is not selected, there's only a summary, as can be > seen for Condition 1 in (2). This is similar to how Excel 2010 > displays conditions in its condition manager. > * One important difference to Excel is that this design does not allow > sort conditions that apply to different ranges. This is important > mostly because ranges can overlap, so conditions from different ranges > can conflict. I think, the sane choice is to try to apply conditions > for the largest range first and and those for the smallest range last > – although that doesn't remedy the whole problem. However, the UI of a > document-wide conditional formatting editing dialogue would probably > have been worse than Excel's, so I tried to avoid that. I'm not sure if we support overlapping conditional formats but if not this should be a feature that we can add. > > * There's an expander labelled Area, to edit the range of a set of > conditions after they were created. It is not expanded by default, the > expanded view can be seen in (2), though. > * Note that the range is also part of the title bar of condition > window (at least in my mock-ups), it should be updated accordingly if > the information is edited in the window. > > * There's a completely new manager window. This is supposed to help > with two things: > 1 find the conditions/ranges that were set without lots of try and error > 2 delete all conditions for a range > * You may debate how useful the First Condition is in recognising a > whole set of conditions. Other ideas very welcome. > I don't see that much use in the Conditional Format Manager. Excel uses a totally different concept and treats each conditional format entry as one entry in the manager while we would a set of conditional formats treat as one entry. But I have no strong opinion about that. Astron, I would propose that we take some minutes in Hamburg and discuss this together. Regards; Markus _______________________________________________ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise