Discussion: Main Content Layout Best Practices

[Adrian Crum]

I think we need to develop some layout best practices for the main
content area. There seems to be some lack of direction or a lack of
consistency in that area of the UI. It may be due to new contributors
and committers coming on board who aren't aware of the existing "de
facto" layout practices.

For instance, there seems to be an overabundance of screenlets being
used. Also, "Create New" buttons aren't placed in the layout in a
consistent way.

Many of the screens in OFBiz follow a certain pattern, so they lend
themselves well to screen decorators. The Find screen decorator
(https://issues.apache.org/jira/browse/OFBIZ-1635) is a good example. We
could do the same thing with other types of screens.

I think it would be a good thing to get a discussion going. Let's share
our experiences with UIs, pros and cons of different approaches, share
screenshots, etc. Then we can condense it all into a UI Best Practices
guide for the Wiki.

What do you think?

-Adrian

[Tim Ruppert]

Giving people good input and best practices always increases the  
likelihood of turning out more easily understood code.!

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On May 21, 2008, at 10:23 AM, Adrian Crum wrote:

> I think we need to develop some layout best practices for the main  
> content area. There seems to be some lack of direction or a lack of  
> consistency in that area of the UI. It may be due to new  
> contributors and committers coming on board who aren't aware of the  
> existing "de facto" layout practices.
>
> For instance, there seems to be an overabundance of screenlets being  
> used. Also, "Create New" buttons aren't placed in the layout in a  
> consistent way.
>
> Many of the screens in OFBiz follow a certain pattern, so they lend  
> themselves well to screen decorators. The Find screen decorator (https://issues.apache.org/jira/browse/OFBIZ-1635 
> ) is a good example. We could do the same thing with other types of  
> screens.
>
> I think it would be a good thing to get a discussion going. Let's  
> share our experiences with UIs, pros and cons of different  
> approaches, share screenshots, etc. Then we can condense it all into  
> a UI Best Practices guide for the Wiki.
>
> What do you think?
>
> -Adrian

[Jacques Le Roux]

This sounds like a good start

Jacques

From: "Adrian Crum" <[hidden email]>

>I think we need to develop some layout best practices for the main
> content area. There seems to be some lack of direction or a lack of
> consistency in that area of the UI. It may be due to new contributors
> and committers coming on board who aren't aware of the existing "de
> facto" layout practices.
>
> For instance, there seems to be an overabundance of screenlets being
> used. Also, "Create New" buttons aren't placed in the layout in a
> consistent way.
>
> Many of the screens in OFBiz follow a certain pattern, so they lend
> themselves well to screen decorators. The Find screen decorator
> (https://issues.apache.org/jira/browse/OFBIZ-1635) is a good example. We
> could do the same thing with other types of screens.
>
> I think it would be a good thing to get a discussion going. Let's share
> our experiences with UIs, pros and cons of different approaches, share
> screenshots, etc. Then we can condense it all into a UI Best Practices
> guide for the Wiki.
>
> What do you think?
>
> -Adrian
>

[Vikas Mayur-2]

Thanks Adrian for your recent work and concerns over moving on to use best
practices and new features especially in things that has been added newly to
the project. I am not a expert in this but still want to clarify few things.

1) What is the best way to show navigation options in a list form. Either
<screenlet> should be used or not.
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).

BTW, I have tried to use <screenlet> widget instead of <container> in
screens for sfa component but the results are weird. The screenlet bar comes
out bigger in size. I will try to find out the cause but would appreciate
help on this as well.

Thank You,
Vikas


On Wed, May 21, 2008 at 9:53 PM, Adrian Crum <[hidden email]> wrote:

> I think we need to develop some layout best practices for the main content
> area. There seems to be some lack of direction or a lack of consistency in
> that area of the UI. It may be due to new contributors and committers coming
> on board who aren't aware of the existing "de facto" layout practices.
>
> For instance, there seems to be an overabundance of screenlets being used.
> Also, "Create New" buttons aren't placed in the layout in a consistent way.
>
> Many of the screens in OFBiz follow a certain pattern, so they lend
> themselves well to screen decorators. The Find screen decorator (
> https://issues.apache.org/jira/browse/OFBIZ-1635) is a good example. We
> could do the same thing with other types of screens.
>
> I think it would be a good thing to get a discussion going. Let's share our
> experiences with UIs, pros and cons of different approaches, share
> screenshots, etc. Then we can condense it all into a UI Best Practices guide
> for the Wiki.
>
> What do you think?
>
> -Adrian
>

[Adrian Crum]

Vikas Mayur wrote:
> 1) What is the best way to show navigation options in a list form. Either
> <screenlet> should be used or not.

In my opinion (and others can chime in with theirs - that's the intent
of this thread) screenlets should be used ONLY to separate sections of a
screen that have different and distinct functions. The order entry and
party profile screens are good examples of breaking up a complicated
screen using screenlets.

In the Fixed Asset area in the Accounting component, there are a lot of
screens that have a list of items and a data entry form to add an item
to the list. I updated the UI on those screens to remove the screenlets
that contained the list, because a list (or table) is visually distinct
from the rest of the screen - it doesn't need the help of a screenlet.

As far as navigation options are concerned, I'm not sure what you mean.
If you mean the pagination menu, then the one supplied by the form
widget should be fine.

I gave the screenlet widget the ability to put the pagination menu in
its title bar, but I'm beginning to change my view on that. I'm starting
to think that the screenlet title bar should contain only the title and
(optionally) the expand/collapse control. Here's why - some screens have
things in the title bar that are hard to notice. Like the order entry
process - where the Continue button is in a title bar. That's the last
place I would look for a Continue button - nearly everyone puts that
sort of thing at the bottom of the screen.

Putting the pagination menu in the title bar is a bad idea because it's
inconsistent. The user may be used to seeing the pagination menu
rendered by the form widget, then they come across a screen where it has
been moved to the screenlet title bar. That might be a cause of confusion.

I would really like to hear other opinions on the screenlet title bar
contents. Right now my opinion is "less is more."

> 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.

> BTW, I have tried to use <screenlet> widget instead of <container> in
> screens for sfa component but the results are weird. The screenlet bar comes
> out bigger in size. I will try to find out the cause but would appreciate
> help on this as well.

Give me a link and I'll take a look at it.

-Adrian

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> Vikas Mayur wrote:
>> 1) What is the best way to show navigation options in a list form. Either
>> <screenlet> should be used or not.
>
> In my opinion (and others can chime in with theirs - that's the intent of this thread) screenlets should be used ONLY to separate
> sections of a screen that have different and distinct functions. The order entry and party profile screens are good examples of
> breaking up a complicated screen using screenlets.

This makes sense indeed, and is sufficiently simple to be remembered by everyone for a long time

> In the Fixed Asset area in the Accounting component, there are a lot of screens that have a list of items and a data entry form to
> add an item to the list. I updated the UI on those screens to remove the screenlets that contained the list, because a list (or
> table) is visually distinct from the rest of the screen - it doesn't need the help of a screenlet.

It's always better with an example :o)

> As far as navigation options are concerned, I'm not sure what you mean. If you mean the pagination menu, then the one supplied by
> the form widget should be fine.
>
> I gave the screenlet widget the ability to put the pagination menu in its title bar, but I'm beginning to change my view on that.
> I'm starting to think that the screenlet title bar should contain only the title and (optionally) the expand/collapse control.
> Here's why - some screens have things in the title bar that are hard to notice. Like the order entry process - where the Continue
> button is in a title bar. That's the last place I would look for a Continue button - nearly everyone puts that sort of thing at
> the bottom of the screen.

Yes, that's true but you get quickly used to it... This is only a convention, even if we all know that shared conventions and
constraints help a lot...

> Putting the pagination menu in the title bar is a bad idea because it's inconsistent. The user may be used to seeing the
> pagination menu rendered by the form widget, then they come across a screen where it has been moved to the screenlet title bar.
> That might be a cause of confusion.
>
> I would really like to hear other opinions on the screenlet title bar contents. Right now my opinion is "less is more."

Yes I agree, "simple is beautiful". But we should keep what is already in the title bar (like the unconventional buttons) unless we
want to do an UI wide brainstorm ...

My 2 cents so far

Jacques

>> 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.
>
>> BTW, I have tried to use <screenlet> widget instead of <container> in
>> screens for sfa component but the results are weird. The screenlet bar comes
>> out bigger in size. I will try to find out the cause but would appreciate
>> help on this as well.
>
> Give me a link and I'll take a look at it.
>
> -Adrian
>

[Adrian Crum]

Jacques Le Roux wrote:

>> I would really like to hear other opinions on the screenlet title bar
>> contents. Right now my opinion is "less is more."
>
> Yes I agree, "simple is beautiful". But we should keep what is already
> in the title bar (like the unconventional buttons) unless we want to do
> an UI wide brainstorm ...
>
> My 2 cents so far
>
> Jacques

Once the best practices are finalized, we don't have to go out and
change everything at once. We can do it like we did the updated styles -
fix them as you come across them.

-Adrian

[David E Jones]

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

[Scott Gray]

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 <[hidden email]>:

>
> 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
>
>

[Vikas Mayur-2]

Thanks Adrian - on these topics.
comments inline.

On Thu, May 22, 2008 at 8:41 PM, Adrian Crum <[hidden email]> wrote:

Vikas Mayur wrote:

1) What is the best way to show navigation options in a list form. Either
<screenlet> should be used or not.

In my opinion (and others can chime in with theirs - that's the intent of this thread) screenlets should be used ONLY to separate sections of a screen that have different and distinct functions. The order entry and party profile screens are good examples of breaking up a complicated screen using screenlets.

In the Fixed Asset area in the Accounting component, there are a lot of screens that have a list of items and a data entry form to add an item to the list. I updated the UI on those screens to remove the screenlets that contained the list, because a list (or table) is visually distinct from the rest of the screen - it doesn't need the help of a screenlet.

As far as navigation options are concerned, I'm not sure what you mean. If you mean the pagination menu, then the one supplied by the form widget should be fine.

Yes - I was talking about pagination menu. Sorry for not to be very clear.

 

I gave the screenlet widget the ability to put the pagination menu in its title bar, but I'm beginning to change my view on that. I'm starting to think that the screenlet title bar should contain only the title and (optionally) the expand/collapse control. Here's why - some screens have things in the title bar that are hard to notice. Like the order entry process - where the Continue button is in a title bar. That's the last place I would look for a Continue button - nearly everyone puts that sort of thing at the bottom of the screen.

Putting the pagination menu in the title bar is a bad idea because it's inconsistent. The user may be used to seeing the pagination menu rendered by the form widget, then they come across a screen where it has been moved to the screenlet title bar. That might be a cause of confusion.

I would really like to hear other opinions on the screenlet title bar contents. Right now my opinion is "less is more."

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.

BTW, I have tried to use <screenlet> widget instead of <container> in
screens for sfa component but the results are weird. The screenlet bar comes
out bigger in size. I will try to find out the cause but would appreciate
help on this as well.

Give me a link and I'll take a look at it.

I do not have any changes committed which you can look in trunk, but yes you can certainly test with the attached patch.
Please visit the link https://localhost:8443/sfa/control/CreateContact after that and notice the size of screenlet title bar.


Thank You,
Vikas

-Adrian

[Jacques Le Roux]

I agree with Scott, it has always surprised me to have both on the same page

Jacques

From: "Scott Gray" <[hidden email]>

>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 <[hidden email]>:
>
>>
>> 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
>>
>>
>

[Vikas Mayur-2]

I also see few difference in find functionality:

1) When a user click on tab button - find button or any other option like
facilities under Facility, projects under Project, In my opinion the
result(s) should be shown by
    default as is done in projects. It is upon user choice to use search
options or not.
    See the difference between
https://localhost:8443/projectmgr/control/FindProject and
https://localhost:8443/accounting/control/findPayments or
    https://localhost:8443/partymgr/control/findparty
2) Naming convention of button in search form (Find or Search). I think Find
button is used in new work.
3) Making all forms to adhere to one convention so that we can do the
necessary cleanups, like for example in find party screen to just have a
Find / Search button in
    instead of Lookup Party and Show all records

   Thoughts please.


Vikas

[Adrian Crum]

So, you are saying the list should contain all records when the page is
first displayed, and then it can be refined by the user if needed. Is
that correct?

-Adrian

Vikas Mayur wrote:

> I also see few difference in find functionality:
>
> 1) When a user click on tab button - find button or any other option like
> facilities under Facility, projects under Project, In my opinion the
> result(s) should be shown by
>     default as is done in projects. It is upon user choice to use search
> options or not.
>     See the difference between
> https://localhost:8443/projectmgr/control/FindProject and
> https://localhost:8443/accounting/control/findPayments or
>     https://localhost:8443/partymgr/control/findparty
> 2) Naming convention of button in search form (Find or Search). I think Find
> button is used in new work.
> 3) Making all forms to adhere to one convention so that we can do the
> necessary cleanups, like for example in find party screen to just have a
> Find / Search button in
>     instead of Lookup Party and Show all records
>
>    Thoughts please.
>
>
> Vikas
>

[Adrian Crum]

David E Jones wrote:

>
> 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

That's why the data entry screen is collapsible.

[Vikas Mayur-2]

On Fri, May 23, 2008 at 8:30 PM, Adrian Crum <[hidden email]> wrote:

> So, you are saying the list should contain all records when the page is
> first displayed, and then it can be refined by the user if needed. Is that
> correct?
>

Yes -  that is correct indeed. But again this is just my thoughts and would
like to hear from you (others) whether it is something doable (if this could
be part of standard convention(s)).

Vikas

> -Adrian
>
>
> Vikas Mayur wrote:
>
>> I also see few difference in find functionality:
>>
>> 1) When a user click on tab button - find button or any other option like
>> facilities under Facility, projects under Project, In my opinion the
>> result(s) should be shown by
>>    default as is done in projects. It is upon user choice to use search
>> options or not.
>>    See the difference between
>> https://localhost:8443/projectmgr/control/FindProject and
>> https://localhost:8443/accounting/control/findPayments or
>>    https://localhost:8443/partymgr/control/findparty
>> 2) Naming convention of button in search form (Find or Search). I think
>> Find
>> button is used in new work.
>> 3) Making all forms to adhere to one convention so that we can do the
>> necessary cleanups, like for example in find party screen to just have a
>> Find / Search button in
>>    instead of Lookup Party and Show all records
>>
>>   Thoughts please.
>>
>>
>> Vikas
>>
>>

[David E Jones]

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 <[hidden email]>:
>
>>
>> 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
>>
>>

[Jacques Le Roux]

From: "Vikas Mayur" <[hidden email]>

> On Fri, May 23, 2008 at 8:30 PM, Adrian Crum <[hidden email]> wrote:
>
>> So, you are saying the list should contain all records when the page is
>> first displayed, and then it can be refined by the user if needed. Is that
>> correct?
>>
>
> Yes -  that is correct indeed. But again this is just my thoughts and would
> like to hear from you (others) whether it is something doable (if this could
> be part of standard convention(s)).

Why not as long as the list is shown with a reasonable default length

1) About the "+" "-" button, I did not notice them until I really searched for it (after I saw a remark about them in ML I guess).
It's a good idea and a good replacement for the double pages proposed by Scott. But then they should be *much more* visible.

2) Find as the button name is fine to me.

3) +1

BTW I remember having suggested some changes months (or years?) ago. I will try to find my propositions

Jacques

> Vikas
>
>
>> -Adrian
>>
>>
>> Vikas Mayur wrote:
>>
>>> I also see few difference in find functionality:
>>>
>>> 1) When a user click on tab button - find button or any other option like
>>> facilities under Facility, projects under Project, In my opinion the
>>> result(s) should be shown by
>>>    default as is done in projects. It is upon user choice to use search
>>> options or not.
>>>    See the difference between
>>> https://localhost:8443/projectmgr/control/FindProject and
>>> https://localhost:8443/accounting/control/findPayments or
>>>    https://localhost:8443/partymgr/control/findparty
>>> 2) Naming convention of button in search form (Find or Search). I think
>>> Find
>>> button is used in new work.
>>> 3) Making all forms to adhere to one convention so that we can do the
>>> necessary cleanups, like for example in find party screen to just have a
>>> Find / Search button in
>>>    instead of Lookup Party and Show all records
>>>
>>>   Thoughts please.
>>>
>>>
>>> Vikas
>>>
>>>
>

[Jacques Le Roux]

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" <[hidden email]>

>
> 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 <[hidden email]>:
>>
>>>
>>> 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
>>>
>>>
>

[David E Jones]

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" <[hidden email]>
>>
>> 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 <[hidden email]>:
>>>
>>>>
>>>> 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
>>>>
>>>>
>

[Anil Patel-3]

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" <[hidden email]>
>>>
>>> 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 <[hidden email]>:
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>
>