Adrian, David, All,
Configurable, good idea !
I think we could agree without a vote for a configurable option with a OOTB default not launching a find request. I really believe
that DB stress is a good argument (searching all while you will, in much case, need less).
On some live DB it can be really stressing. For instance think about a huge list of clients with a number of backend operators and
the main screen being a find Parties. I know a case where, when searching for a client, we had to restrict to use only the PartyId
or using both first and last names. No need to say that servers were strong enough.
Anyway there are much more point to discuss about UI and this one is only
minor, sorry for digression :o)
But if necessary why not a new vote for the default ?
Jacques
From: "Adrian Crum" <[EMAIL PROTECTED]>
Bump.
If you check the replies to this, there were a handful of +1s.
If the decision is to not have Find screen results displayed initially, that's fine. I just need to know what the majority
prefers.
By the way, there is a possibility to make this configurable - so that it isn't
an all or nothing situation.
-Adrian
--- On Fri, 5/30/08, Adrian Crum <[EMAIL PROTECTED]> wrote:
From: Adrian Crum <[EMAIL PROTECTED]>
Subject: Re: Discussion: Main Content Layout Best Practices
To: dev@ofbiz.apache.org
Date: Friday, May 30, 2008, 11:16 AM
Getting back to this...
Here are the layout best practices discussed so far:
"In the case where items are being added to a list, it
is preferable to
have the item data entry screen and the item list on
separate screens.
If the two functions are incorporated into one screen, then
the item
data entry screen should be above the item list. In
addition, the item
data entry screen should be collapsible and initially
collapsed."
"If a Find Item screen has a form for search options,
the search options
form should be above the list of items found. The list of
items found
should display all items initially - giving the user the
ability to
narrow the results via the search options form."
Can we agree on these?
-Adrian
Jacques Le Roux wrote:
> From: "Scott Gray" <[EMAIL PROTECTED]>
>> It looks nice but if we did that the user would
lose the ability to refer
>> back to the list while entering data, I would
prefer an
>> expand/collapse form
>> if we are going to keep them on the same page.
>
> Yes I agree, but I really like the idea for the
calendar (I can't
> propose it for lookups are they are too much to be
loaded when lauching
> and the probability of use is far more low, but maybe
one day, when
> machines will be more powerful :D
>
> Jacques
>
>> Regards
>> Scott
>>
>> 2008/5/24 Anil Patel
<[EMAIL PROTECTED]>:
>>
>>> I think what David is suggesting is something
like this
>>> http://www.wildbit.com/demos/modalbox/
>>>
>>> Regards
>>> Anil Patel
>>>
>>>
>>>
>>> On May 23, 2008, at 1:57 PM, David E Jones
wrote:
>>>
>>>
>>>> I didn't say open a new window, I said
either expand a hidden area or
>>>> popup using JavaScript within the window
(ie over top of the list
>>>> behind
>>>> it).
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 23, 2008, at 11:55 AM, Jacques Le
Roux wrote:
>>>>
>>>> IMHO, we should avoid to overuse popping
as opening a new window is
>>>> time
>>>>> consuming (especially in Firefox).
This is currently a major
>>>>> inconvenience
>>>>> for Lookups and Calendar for instance
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "David E Jones"
<[EMAIL PROTECTED]>
>>>>>
>>>>>>
>>>>>> Since we're entering the world
of using more javascript in the
>>>>>> browser,
>>>>>> why not have the add form on the
top but hidden by default with
>>>>>> and Add
>>>>>> button of some sort that would
cause the form to be shown? We
>>>>>> could even
>>>>>> make it fancy and popup over top
of the list form and have it go
>>>>>> away after
>>>>>> submission with an update of the
list behind it... without any
>>>>>> page loads
>>>>>> even.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On May 22, 2008, at 11:38 PM,
Scott Gray wrote:
>>>>>>
>>>>>> I would agree with that but
personally I would prefer to see them on
>>>>>>> completely different pages.
If I wanted to be able to refer back to
>>>>>>> the
>>>>>>> list while adding I would
ctrl+click and then ctrl+tab to flick back
>>>>>>> and
>>>>>>> forth, that's what makes
tabbed browsers so handy. One of the
>>>>>>> problems with
>>>>>>> having them on the same page
is that any errors after adding
>>>>>>> would be
>>>>>>> displayed before the list
while the add form would be way down the
>>>>>>> bottom.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> 2008/5/23 David E Jones
<[EMAIL PROTECTED]>:
>>>>>>>
>>>>>>>
>>>>>>>> On May 22, 2008, at 9:11
AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>> 2) If a screen has a list
and add form, what should be the order of
>>>>>>>> these
>>>>>>>>
>>>>>>>>> forms (I have seen in
your recent work that add form should
>>>>>>>>> come on
>>>>>>>>>> top
>>>>>>>>>> and
>>>>>>>>>> I completely
>>>>>>>>>> agree with this).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I believe the form
should be on top of the list. Otherwise, as you
>>>>>>>>> add
>>>>>>>>> items to the list, the
form is scrolled off the bottom of the
>>>>>>>>> screen.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The main question is: what
is going to be used more? Will it be the
>>>>>>>> list or
>>>>>>>> the add form?
>>>>>>>>
>>>>>>>> If in most cases it will
be the list, and if you have to scroll
>>>>>>>> down
>>>>>>>> every
>>>>>>>> time to see it...
that's a pain.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>
>
>
