<html><head></head><body>Hi Astron, thanks for the input ... most of your remarks can be explained and I'll do that this evening. At the hackfest and the conference, Markus was so kind to explain a lot of constraints we have here. Nevertheless, if you have a mockup, I'n happy to see fresh input (please have a look at. The wiki page first, some design goals are explained there). Now, I am approaching my day job ... Have a nice day! Cheers, Christoph -- Sent via mobile... <div class="gmail_quote"> Astron <heinzlesspam@googlemail.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">Hi. I am probably sometimes out of my depth here, so bear with me if I propose unreasonable things. I had never used this feature until tonight. > The main idea is now, that there is no difference between the currently > selected element in the table above and the entries below. Example: If > the user clicks on an element and starts changing the name, then this > name will be changed "live" in the table above as well. Same for range > options or the expression. So far, I like this. Still, a core point I would like to question about the current mock-ups is that there are a Define Names and a Manage Names dialogue. IMHO, there must be clever way of combining these. I'll try to think about an own mock-up. > Some more core behavior: > * If the user wants to add a new name from the Manage Names > dialog, then we now go to the "Add Names" dialog (that makes > adding new names really clear). > * If the user changes a name / expression in the Manage Names > dialog and this entry is invalid ... Can we restrict the characters that can be entered to the valid ones? Pressing an invalid key could simply result in nothing, except for maybe a slightly annoying beep (and non-modal information). > * The user should be always able to exit the current change with > ESC (restores last entry before the started to edit the field). Yes. And the change should be revertible with an Undo button (is that what the "Back" button is for?). > * If the user selects more than one entry, then ... > * we deactivate the text fields (maybe even the Scope &g t; field) > * Paste (or Insert, no terminology decision yet) inserts > all selected items. I hope I understand this correctly: it inserts the selected range names into the currently selected cell in a format like "Cappuccino;Chocolate;Cookies"? Then, I see two problems: # "Paste" shouldn't overwrite text when the current cell was double-click/F2-edited before opening the Manage Names dialogue (otherwise formulas might be deleted). Is that workable? # How is it possible to handle inserting multiple range names correctly? Some format work in certain formulas and when using certain ranges, some don't, i. e. neither "Cappuccino+Chocolate+Cookies" nor "Cappuccino;Chocolate;Cookies" is possible in all cases. Is clever guessing based on existing formulas possible here? > * We could get rid of the "Modify" button -&g t; improves the number > and meaning of the buttons Good. In the current interface it is used confusingly (not that there isn't precedent for this in other LibO dialogues – colour options, I am looking at you!). > * Since we need to "reserve" space for the "Information Text" > above the edit entries, we now can explain the user that he > might also use formula expressions (if he adds a named range). > For the rest, I strongly suggest to keep the common naming (for > Calc and Excel users). Cool. But about the mock-up wherein two items are selected: you may beg to differ, but I don't find "2 range names selected" to be very useful information. I think this one could go. > * Once we do have non-modal messages, the Information Text line > isn't needed anymore. Same info will be provid ed via message > balloons (or similar). I find the majority of balloons to be aesthetically rather less pleasing and will fiercely defend the humble yellow-coloured information bar against attacks such as your own. :) > A final note: Please be aware that this is something new to > LibreOffice ... we currently don't have such a dialog concept, although > I find it very promising. What do you think? Like it. Regards, Astron. <hr /> Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise">http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise</a> </pre></blockquote></div></body></html>