On Wed, Sep 7, 2016 at 12:06 AM, Jürgen Spitzmüller <sp...@lyx.org> wrote:
> > As I wrote, I think it is important that the dialogs work on all > current screens, and in general, I think 800x600 is still a good > maximum for dialogs. > That's a fair opinion. Do you know whether there are plans to bring any remaining dialogs >800x600 into compliance with this soft limit? If so, do you know what approaches are planned? Consistency will help adoption of design elements like the tabs in the citation dialog. > As to scrollbars, I don't think this is a good idea. This is not usable > without the mouse (and I doubt it can be elegantly done with Qt). > Scrollbars are traditionally mouse driven; however, for someone who prefers the keyboard the arrow keys or page up / page down can be used (thus only limiting Vim zealots like myself without yet more exotic key bindings). Tab can be used to navigate between fields. Again admitting ignorance, but it seems like the QScrollArea could be used. Going further, perhaps the scrollbars can wrapped in a conditional that queries the user's resolution on launch to see if they are even needed (if the screen resolution is larger than the dialog, don't draw them but embed the layouts that would traditional lay within them directly into the dialog). > When I did the redesign, I really tried several options. It was _not_ > possible to design a dialog of the proper size without using a > pane/tabbar or toolbox. I selected the latter, since it is the most > space-saving option and it does not introduce any extra-clicks. > Sounds good, I appreciate your diligence and willingness to share your approach. I'm just hoping to offer user perspectives and options that might feel "more natural" for the uninitiated yet still be serviceable and unintrusive to all. Of course any redesign is annoying since you have to get used to the > new UI, but we have to make the dialogs work for everybody. > Understood. I'm still curious what fraction of LyX users have such resolution limitations. Some interesting desktop web browser statistics here: http://www.w3schools.com/browsers/browsers_display.asp. > Any points I missed? > What are your thoughts on relabeling to Find Citation and introducing an F-based keyboard solution? This is a redesign (which as you note is annoying); however, using "F" for "Find" is a more common design element than "S" for "Search" vice "Save". > (Note that I am not talking about the shortcut to open the search dialog) Because it does not work for me (or I don't know how to properly use it), what is Alt-S supposed to do? In closing, for your consideration and not requiring a response, Thank you for the continued discussion on this. Please don't get me wrong: I truly value the work that you and the other developers do (I hope to join you and contribute in some small ways once my studies have finished). However, I've stood by silently until now but am compelled by Maria's initiation of the discussion. I have introduced LyX to numerous (cross-platform and savvy) new users and this is one of the functional elements that commonly, once explained, gets the response "but why?" I suppose the main line of thought that I've heard is "why does Formatting look like a header with fields below it and there are no fields for text entry below the Search Citation header" not realizing it is in fact a clickable design element. Once explained and the fields shown, the question is "why is that hidden by default?" because, in my experience, most users are not writing documents on a small resolution display and thus don't likely expect such space-saving measures. I do not want to diminish your efforts or discard your work, but this strikes me as a potential case where the needs/expectations of the many users may outweigh the needs of a the few (who can still be accommodated). It is also somewhat a slippery slope. Netbooks drove the change. What happens if LyX is ported to a device with a more limited screen in terms of size / resolution? To aid the current design, perhaps it is more sensible to have both Search and Formatting initially collapsed to (a) instigate inquisitive behavior that will lead to a click, (b) will then provide the user a session-wide persistent open version of his/her preferred portion, and (c) I believe by your logic, introduce no additional clicks. Perhaps easier: include in the label "(click to open)" when collapsed.