Hi team, Yes, the all issues I've previously said are focusing on next things: - reduce the number of items (the rarely used items should be cleanup or removed or merged) - make all consistent (means when you go to one dialog and learn it, the all other similar dialogs should be the same) - reduce the number of clicks, steps to learn: make wide used template dialog (easy to learn), add inside only what 90% use. So less options, will means less headache, less bugs, and a cleaner ui. - exception: even seems probably strange, at least I am going to preffer one dialog that offers less options like: for compiler options a list of 4 items: Debug (default), Release, Normal and Custom and at Custom should be the "Compiler options", even you will have more dialogs to look at, but you will not always change the compiler options
By merging one dialog (like Project->New... to be a part of: File->New...->Other... dialog) respect the rule by: - less menu items (the project menu have less options) - it is consistent (is the single one UI), if you want to customize to have in File->New...->Project (when is wanted that) will open the same dialog as is in File->New->Other... (look that right now one have a tree, and other have a list) - it has the same number of clicks but reduce the number of them if you will have a New...->Other button on toolbar (is hard to add many toolbar buttons on it) - Merging that search dialogs will reduce to minimum the search section(1st section) make it consistent (2nd section) by merging. Reducing the click number is hard to manage, but at least will keep it the same. I'm not sure which is the best design, that is at least one purposed one to simplify. P.S. I am not wanting to think on Lazarus to be a Delphi Clone UI. Will never match it and worse, it will never make it better. Like Wine VS Windows, good to be there, but when you'll think what tool to use, if you have money you will use Delphi (or take a free Delphi) because you have no reason to keep a worse tool. Most of my purposed designs are how other tools/UIs solves that problem like: Eclipse, MonoDevelop, KDevelop, OpenOffice. Why not something purely original? Is hard to make it perfect but is easier to take best opensource inovation and to put it inside Lazarus when regarding UI. Ciprian -----Original Message----- From: Mattias Gaertner [mailto:[EMAIL PROTECTED] Sent: D 28.10.2007 02:30 To: [email protected] Subject: Re: [lazarus] Usability issues - search On Sun, 28 Oct 2007 01:59:07 +0300 "Ciprian Mustiata" <[EMAIL PROTECTED]> wrote: > On Fri, 26 Oct 2007 14:42:35 +0300 > "Ciprian Mustiata" <[EMAIL PROTECTED]> wrote: > > > - file->search or replace (excluding incremental search) are to > > heavy Unify them in the same dialog and if the replace/search (like > > is in: Find in Files dialog) work differently on different > > criteria: by project, by folder, etc. they may be put in multiple > > tabs > > I'm not sure how multiple tabs are more usable here. Can you give more > details? > > Instead all Search, replace, Find in files options, in my point of > view should be only one dialog: Search with two tabs: > - Search (in current file) > - Search All (all files) > They should keep the form of Find in Files dialog (which have both > roles, for search and replace) > > Find All will create a list of all results in all files, and Find > will create the results in the current file (nothing new here) and > will be put in a list (like Find in Files). The F3 (Find Next/Replace > Next), and Shift+F3 (Find previous) will to in that list one item up > and down. On that way to be the things the search will reduce to less > options: Search, Incremental Search, Go to Line. The dialog that > users should learn is very simple (because will do all steps and you > have to learn it only once) and will be consistent against all > searchings. Incremental Search and Go To Line are very simple dialogs > and have nothing to change. Do I understand this right: You want that the normal Find dialog should put its result into the search result view, instead of jumping to the result? And you want that Find and Find-in-Files should be merged, so that you can no longer use Find-in-Files for global navigation and Find for local navigation? I personally would not like that. But if someone really wants this feature, then provide a patch that adds an option to the env opts dlg, so users can switch between those both behaviors. Mattias _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
<<winmail.dat>>
