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: lazarus@miraclec.com
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>>

Reply via email to