Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

This sounds like a good start

Jacques

From: "Adrian Crum" <ad...@hlmksw.com>
>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
>

Re: Discussion: Main Content Layout Best Practices

[Tim Ruppert <ti...@hotwaxmedia.com>]

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

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@hlmksw.com>
> 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
> 

Re: Discussion: Main Content Layout Best Practices

[Vikas Mayur <vi...@gmail.com>]

Thanks Adrian - on these topics.
comments inline.

On Thu, May 22, 2008 at 8:41 PM, Adrian Crum <ad...@hlmksw.com> 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
>

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@yahoo.com>
> Jacques Le Roux <ja...@les7arts.com> wrote: Ha ok, sorry I missed the relation between "add form on the top but hidden " 
> and "We could even make it fancy and popup over top"
>
> In this case I will vote for with my 2 hands and I will even hope that we could use such techniques to create an hidden calendar 
> and
> show it when needed. If we do it during lauching it's not very sensible since launching takes time anyway and after it would be
> great to see it popping quickly.
>
> I was thinking we can have an ajax-powered date control that has dropdowns for year, month, and day.

Yes why not, but my main concern was about the time to load the popup windows.

Jacques

> -Adrian

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@yahoo.com>]

Jacques Le Roux <ja...@les7arts.com> wrote: Ha ok, sorry I missed the relation between "add form on the top but hidden " and "We could even make it fancy and popup over top"

In this case I will vote for with my 2 hands and I will even hope that we could use such techniques to create an hidden calendar and 
show it when needed. If we do it during lauching it's not very sensible since launching takes time anyway and after it would be 
great to see it popping quickly.

I was thinking we can have an ajax-powered date control that has dropdowns for year, month, and day.

-Adrian

       

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

Ha ok, sorry I missed the relation between "add form on the top but hidden " and "We could even make it fancy and popup over top"

In this case I will vote for with my 2 hands and I will even hope that we could use such techniques to create an hidden calendar and 
show it when needed. If we do it during lauching it's not very sensible since launching takes time anyway and after it would be 
great to see it popping quickly.

Thanks

Jacques

From: "Anil Patel" <an...@hotwaxmedia.com>
>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" <jo...@hotwaxmedia.com>
>>>>
>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>
>>
>
> 

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

Hi Adrian,

From: "Adrian Crum" <ad...@yahoo.com>
> In the UI work I've done, I have tried to keep accessibility an important priority. One of the things I like about having a
> scalable UI is that sight impaired people can crank up their browser's default font to see it better. The simplified markup is
> great for screen readers. Keeping OFBiz accessible to the blind is one reason why I want the screen widgets to output plain HTML
> in addition to all the new, fancy Ajax stuff.
>
> I agree we're doing pretty well. The only thing we're missing is a "Skip Menus" button at the top of the screen.

I began to work on this using the solution described in the chapter 8 of Jeffrey Zeldman's "Designing With Web Standards, 2nd
edition" (I also added a link to this valuable book from the Wiki Books page).
I commited the work in progress in rev. 662598
It should work but I was unable to test it in the limited time I gave to this feature tonight (accesskey is a nightmare).

Jacques
PS : Actually I wondered about accesskey, I finally found in http://www.wats.ca/show.php?contentid=32 : <<even these keys would be
inaccessible to users not using a North American Standard (QWERTY) keyboard>>, clearly not efficient :(
Some works done tough : http://www.wats.ca/show.php?contentid=43

> -Adrian
>
> Jacques Le Roux <ja...@les7arts.com> wrote: From: "Jacques Le Roux"
>> From: "Bruno Busco"
>
>> [...]
>>> Another point that I would bring into this discussion (hoping not being OT)
>>> is the possibility for the user to easily use the page with the keyboard
>>> only and still be able to switch between search fields panel and the data
>>> table to refine the search.
>>> I have noticed that many end-users that use non-web based application go
>>> very fast in data entry with the keyboard only and this, in my opinion,
>>> should be considered in the OFBiz interface desing.
>>
>> Yes, I agree this is a very pertinent remark (we could even think more about the 15% of the population which is more or less
>> disabled, and sadly underemployed from this cause. In France for instance there are laws for decades about that but still a lot
>> of
>> enterprises which prefer to pay taxes than to employ handicapped persons...)
>
> Mmm... That saids, I though one hour ago that it's should be a huge task for an ERP UI... Then I dowloaded Webbie
> http://www.webbie.org.uk/ and NVDA  http://www.nvda-project.org/download.html (awesome for a free tool). Sorry these softwares are
> designed for Windows but I guess the same exists on Linux
>
> And you know what ? I think OFBIz is not doing too bad. Of course we could do better by adding means to skip some parts of the
> screens, but it's really not too bad.
>
> Ok, I let my screen open and I did not close my eyes. But I'm pretty sure OFBiz is not so hard to use for a blind person with some
> experience with computer and web tools designed for blinds (and of course some guidances for OFBiz at start too, I remember now my
> 1st steps in OFBIz). Good news isn'it ?
>
> Of course this is seen from a non blind person and I can't guarantee it's realistic... Maybe in some decades, centuries ?
>
> Jacques
>
>
>> Jacques
>>
>>> Thanks,
>>> -Bruno
>>>
>>> 2008/6/1 Adrian Crum :
>>>
>>>> I know the two subjects were mixed in some replies. I understand what you
>>>> mean though. ;-)
>>>>
>>>> -Adrian
>>>>
>>>> Scott Gray  wrote: I was for separating create forms
>>>> and search/result forms, I was not
>>>> suggesting that we should separate the search forms themselves.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2008/6/1 Jacques Le Roux :
>>>>
>>>> > I finally agree with most too (I mean I agree with Adrian's proposition
>>>> and
>>>> > Andrew's here). Having them on 2 screen was a Scott's
>>>> > proposition that I agreed with because of the flexibility given by modern
>>>> > browsers and their integrated tabs capabilities. But I can
>>>> > imagine that some people, especially end users, would not like to use
>>>> tabs
>>>> > or even a modern browser (though they should to use
>>>> > both). Then it's obviously not easier to use...
>>>> >
>>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>>> default
>>>> > when there are results. If we would really want to have
>>>> > something like that, whe should at least have an indicator to let know
>>>> the
>>>> > user that the list is not empty.
>>>> >
>>>> > Just my opinion, and BTW having a consensual standard usage will be
>>>> great.
>>>> > I agree with the idea that we really need to standardise our ways of
>>>> doing
>>>> > things, even if there are only a few places still needing it in OFBiz ERP
>>>> > (thanks to widgets for instance)
>>>> >
>>>> > Jacques
>>>> >
>>>> > From: "Andrew Zeneski"
>>>> >
>>>> >  I can agree with most except list results and the form should be
>>>>  rendered
>>>> >> as one screen. This is to make usage easier when the
>>>> >> user  wants to change the search parameters. Having the form collapsed
>>>> by
>>>> >>  default when there are results is good.
>>>> >>
>>>> >>
>>>> >> Andrew
>>>> >>
>>>> >>
>>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>>> >>
>>>> >>  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"
>>>> >>>>
>>>> >>>>> 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 :
>>>> >>>>>
>>>> >>>>>  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"
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>>> 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 :
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>  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
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Bruno Busco" <br...@gmail.com>
> Yes, I think that the Skip Menu is something that could be useful even to
> people not impaired but particulary "affetionated" to the keyboard and to
> DOS applications.

Some work done, but in its state (which does not seem to have a chance to change) accesskey is a quasi deadlock :(

> 
> One more thing to consider in the layout best practice is the hiding of
> every menu command that is not available due to the actual user permission.
> We have had a thread about this in this ML and I think we should put it in
> this best practice list also.

+1

Jacques

> -Bruno
> 
> 
> 
> 2008/6/2 Adrian Crum <ad...@hlmksw.com>:
> 
>> The basic idea is to have a Skip Menu button very early in the page, so
>> that sight impaired users can tab to that button, hit Enter, and jump over
>> all of the main and sub navigation to go directly to the main content.
>>
>> By the way, when you are testing OFBiz's accessibility, you don't have to
>> close your eyes - just turn your monitor off and hide your mouse. ;-)
>>
>>
>> -Adrian
>>
>> Jacques Le Roux wrote:
>>
>>> Adrian,
>>>
>>> This is great, I would like to have a look at the Skip Menu button, hope I
>>> will find time (I'm willing to do too much things at the same time these
>>> last times and I do just a few of them)
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum" <ad...@yahoo.com>
>>>
>>>> In the UI work I've done, I have tried to keep accessibility an important
>>>> priority. One of the things I like about having a scalable UI is that sight
>>>> impaired people can crank up their browser's default font to see it better.
>>>> The simplified markup is great for screen readers. Keeping OFBiz accessible
>>>> to the blind is one reason why I want the screen widgets to output plain
>>>> HTML in addition to all the new, fancy Ajax stuff.
>>>>
>>>> I agree we're doing pretty well. The only thing we're missing is a "Skip
>>>> Menus" button at the top of the screen.
>>>>
>>>> -Adrian
>>>>
>>>> Jacques Le Roux <ja...@les7arts.com> wrote: From: "Jacques Le
>>>> Roux"
>>>>
>>>>> From: "Bruno Busco"
>>>>>
>>>>
>>>>  [...]
>>>>>
>>>>>> Another point that I would bring into this discussion (hoping not being
>>>>>> OT)
>>>>>> is the possibility for the user to easily use the page with the
>>>>>> keyboard
>>>>>> only and still be able to switch between search fields panel and the
>>>>>> data
>>>>>> table to refine the search.
>>>>>> I have noticed that many end-users that use non-web based application
>>>>>> go
>>>>>> very fast in data entry with the keyboard only and this, in my opinion,
>>>>>> should be considered in the OFBiz interface desing.
>>>>>>
>>>>>
>>>>> Yes, I agree this is a very pertinent remark (we could even think more
>>>>> about the 15% of the population which is more or less
>>>>> disabled, and sadly underemployed from this cause. In France for
>>>>> instance there are laws for decades about that but still a lot of
>>>>> enterprises which prefer to pay taxes than to employ handicapped
>>>>> persons...)
>>>>>
>>>>
>>>> Mmm... That saids, I though one hour ago that it's should be a huge task
>>>> for an ERP UI... Then I dowloaded Webbie
>>>> http://www.webbie.org.uk/ and NVDA
>>>> http://www.nvda-project.org/download.html (awesome for a free tool).
>>>> Sorry these softwares are
>>>> designed for Windows but I guess the same exists on Linux
>>>>
>>>> And you know what ? I think OFBIz is not doing too bad. Of course we
>>>> could do better by adding means to skip some parts of the
>>>> screens, but it's really not too bad.
>>>>
>>>> Ok, I let my screen open and I did not close my eyes. But I'm pretty sure
>>>> OFBiz is not so hard to use for a blind person with some
>>>> experience with computer and web tools designed for blinds (and of course
>>>> some guidances for OFBiz at start too, I remember now my
>>>> 1st steps in OFBIz). Good news isn'it ?
>>>>
>>>> Of course this is seen from a non blind person and I can't guarantee it's
>>>> realistic... Maybe in some decades, centuries ?
>>>>
>>>> Jacques
>>>>
>>>>
>>>>  Jacques
>>>>>
>>>>>  Thanks,
>>>>>> -Bruno
>>>>>>
>>>>>> 2008/6/1 Adrian Crum :
>>>>>>
>>>>>>  I know the two subjects were mixed in some replies. I understand what
>>>>>>> you
>>>>>>> mean though. ;-)
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> Scott Gray  wrote: I was for separating create forms
>>>>>>> and search/result forms, I was not
>>>>>>> suggesting that we should separate the search forms themselves.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> 2008/6/1 Jacques Le Roux :
>>>>>>>
>>>>>>> > I finally agree with most too (I mean I agree with Adrian's
>>>>>>> proposition
>>>>>>> and
>>>>>>> > Andrew's here). Having them on 2 screen was a Scott's
>>>>>>> > proposition that I agreed with because of the flexibility given by
>>>>>>> modern
>>>>>>> > browsers and their integrated tabs capabilities. But I can
>>>>>>> > imagine that some people, especially end users, would not like to
>>>>>>> use
>>>>>>> tabs
>>>>>>> > or even a modern browser (though they should to use
>>>>>>> > both). Then it's obviously not easier to use...
>>>>>>> >
>>>>>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>>>>>> default
>>>>>>> > when there are results. If we would really want to have
>>>>>>> > something like that, whe should at least have an indicator to let
>>>>>>> know
>>>>>>> the
>>>>>>> > user that the list is not empty.
>>>>>>> >
>>>>>>> > Just my opinion, and BTW having a consensual standard usage will be
>>>>>>> great.
>>>>>>> > I agree with the idea that we really need to standardise our ways of
>>>>>>> doing
>>>>>>> > things, even if there are only a few places still needing it in
>>>>>>> OFBiz ERP
>>>>>>> > (thanks to widgets for instance)
>>>>>>> >
>>>>>>> > Jacques
>>>>>>> >
>>>>>>> > From: "Andrew Zeneski"
>>>>>>> >
>>>>>>> >  I can agree with most except list results and the form should be
>>>>>>>  rendered
>>>>>>> >> as one screen. This is to make usage easier when the
>>>>>>> >> user  wants to change the search parameters. Having the form
>>>>>>> collapsed
>>>>>>> by
>>>>>>> >>  default when there are results is good.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Andrew
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>>>>>> >>
>>>>>>> >>  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"
>>>>>>> >>>>
>>>>>>> >>>>> 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 :
>>>>>>> >>>>>
>>>>>>> >>>>>  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"
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>>> 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 :
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>>  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
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>

Re: Discussion: Main Content Layout Best Practices

[Bruno Busco <br...@gmail.com>]

Yes, I think that the Skip Menu is something that could be useful even to
people not impaired but particulary "affetionated" to the keyboard and to
DOS applications.

One more thing to consider in the layout best practice is the hiding of
every menu command that is not available due to the actual user permission.
We have had a thread about this in this ML and I think we should put it in
this best practice list also.

-Bruno



2008/6/2 Adrian Crum <ad...@hlmksw.com>:

> The basic idea is to have a Skip Menu button very early in the page, so
> that sight impaired users can tab to that button, hit Enter, and jump over
> all of the main and sub navigation to go directly to the main content.
>
> By the way, when you are testing OFBiz's accessibility, you don't have to
> close your eyes - just turn your monitor off and hide your mouse. ;-)
>
>
> -Adrian
>
> Jacques Le Roux wrote:
>
>> Adrian,
>>
>> This is great, I would like to have a look at the Skip Menu button, hope I
>> will find time (I'm willing to do too much things at the same time these
>> last times and I do just a few of them)
>>
>> Thanks
>>
>> Jacques
>>
>> From: "Adrian Crum" <ad...@yahoo.com>
>>
>>> In the UI work I've done, I have tried to keep accessibility an important
>>> priority. One of the things I like about having a scalable UI is that sight
>>> impaired people can crank up their browser's default font to see it better.
>>> The simplified markup is great for screen readers. Keeping OFBiz accessible
>>> to the blind is one reason why I want the screen widgets to output plain
>>> HTML in addition to all the new, fancy Ajax stuff.
>>>
>>> I agree we're doing pretty well. The only thing we're missing is a "Skip
>>> Menus" button at the top of the screen.
>>>
>>> -Adrian
>>>
>>> Jacques Le Roux <ja...@les7arts.com> wrote: From: "Jacques Le
>>> Roux"
>>>
>>>> From: "Bruno Busco"
>>>>
>>>
>>>  [...]
>>>>
>>>>> Another point that I would bring into this discussion (hoping not being
>>>>> OT)
>>>>> is the possibility for the user to easily use the page with the
>>>>> keyboard
>>>>> only and still be able to switch between search fields panel and the
>>>>> data
>>>>> table to refine the search.
>>>>> I have noticed that many end-users that use non-web based application
>>>>> go
>>>>> very fast in data entry with the keyboard only and this, in my opinion,
>>>>> should be considered in the OFBiz interface desing.
>>>>>
>>>>
>>>> Yes, I agree this is a very pertinent remark (we could even think more
>>>> about the 15% of the population which is more or less
>>>> disabled, and sadly underemployed from this cause. In France for
>>>> instance there are laws for decades about that but still a lot of
>>>> enterprises which prefer to pay taxes than to employ handicapped
>>>> persons...)
>>>>
>>>
>>> Mmm... That saids, I though one hour ago that it's should be a huge task
>>> for an ERP UI... Then I dowloaded Webbie
>>> http://www.webbie.org.uk/ and NVDA
>>> http://www.nvda-project.org/download.html (awesome for a free tool).
>>> Sorry these softwares are
>>> designed for Windows but I guess the same exists on Linux
>>>
>>> And you know what ? I think OFBIz is not doing too bad. Of course we
>>> could do better by adding means to skip some parts of the
>>> screens, but it's really not too bad.
>>>
>>> Ok, I let my screen open and I did not close my eyes. But I'm pretty sure
>>> OFBiz is not so hard to use for a blind person with some
>>> experience with computer and web tools designed for blinds (and of course
>>> some guidances for OFBiz at start too, I remember now my
>>> 1st steps in OFBIz). Good news isn'it ?
>>>
>>> Of course this is seen from a non blind person and I can't guarantee it's
>>> realistic... Maybe in some decades, centuries ?
>>>
>>> Jacques
>>>
>>>
>>>  Jacques
>>>>
>>>>  Thanks,
>>>>> -Bruno
>>>>>
>>>>> 2008/6/1 Adrian Crum :
>>>>>
>>>>>  I know the two subjects were mixed in some replies. I understand what
>>>>>> you
>>>>>> mean though. ;-)
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> Scott Gray  wrote: I was for separating create forms
>>>>>> and search/result forms, I was not
>>>>>> suggesting that we should separate the search forms themselves.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> 2008/6/1 Jacques Le Roux :
>>>>>>
>>>>>> > I finally agree with most too (I mean I agree with Adrian's
>>>>>> proposition
>>>>>> and
>>>>>> > Andrew's here). Having them on 2 screen was a Scott's
>>>>>> > proposition that I agreed with because of the flexibility given by
>>>>>> modern
>>>>>> > browsers and their integrated tabs capabilities. But I can
>>>>>> > imagine that some people, especially end users, would not like to
>>>>>> use
>>>>>> tabs
>>>>>> > or even a modern browser (though they should to use
>>>>>> > both). Then it's obviously not easier to use...
>>>>>> >
>>>>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>>>>> default
>>>>>> > when there are results. If we would really want to have
>>>>>> > something like that, whe should at least have an indicator to let
>>>>>> know
>>>>>> the
>>>>>> > user that the list is not empty.
>>>>>> >
>>>>>> > Just my opinion, and BTW having a consensual standard usage will be
>>>>>> great.
>>>>>> > I agree with the idea that we really need to standardise our ways of
>>>>>> doing
>>>>>> > things, even if there are only a few places still needing it in
>>>>>> OFBiz ERP
>>>>>> > (thanks to widgets for instance)
>>>>>> >
>>>>>> > Jacques
>>>>>> >
>>>>>> > From: "Andrew Zeneski"
>>>>>> >
>>>>>> >  I can agree with most except list results and the form should be
>>>>>>  rendered
>>>>>> >> as one screen. This is to make usage easier when the
>>>>>> >> user  wants to change the search parameters. Having the form
>>>>>> collapsed
>>>>>> by
>>>>>> >>  default when there are results is good.
>>>>>> >>
>>>>>> >>
>>>>>> >> Andrew
>>>>>> >>
>>>>>> >>
>>>>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>>>>> >>
>>>>>> >>  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"
>>>>>> >>>>
>>>>>> >>>>> 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 :
>>>>>> >>>>>
>>>>>> >>>>>  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"
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>> 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 :
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>  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
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

The basic idea is to have a Skip Menu button very early in the page, so 
that sight impaired users can tab to that button, hit Enter, and jump 
over all of the main and sub navigation to go directly to the main content.

By the way, when you are testing OFBiz's accessibility, you don't have 
to close your eyes - just turn your monitor off and hide your mouse. ;-)

-Adrian

Jacques Le Roux wrote:
> Adrian,
> 
> This is great, I would like to have a look at the Skip Menu button, hope 
> I will find time (I'm willing to do too much things at the same time 
> these last times and I do just a few of them)
> 
> Thanks
> 
> Jacques
> 
> From: "Adrian Crum" <ad...@yahoo.com>
>> In the UI work I've done, I have tried to keep accessibility an 
>> important priority. One of the things I like about having a scalable 
>> UI is that sight impaired people can crank up their browser's default 
>> font to see it better. The simplified markup is great for screen 
>> readers. Keeping OFBiz accessible to the blind is one reason why I 
>> want the screen widgets to output plain HTML in addition to all the 
>> new, fancy Ajax stuff.
>>
>> I agree we're doing pretty well. The only thing we're missing is a 
>> "Skip Menus" button at the top of the screen.
>>
>> -Adrian
>>
>> Jacques Le Roux <ja...@les7arts.com> wrote: From: "Jacques 
>> Le Roux"
>>> From: "Bruno Busco"
>>
>>> [...]
>>>> Another point that I would bring into this discussion (hoping not 
>>>> being OT)
>>>> is the possibility for the user to easily use the page with the 
>>>> keyboard
>>>> only and still be able to switch between search fields panel and the 
>>>> data
>>>> table to refine the search.
>>>> I have noticed that many end-users that use non-web based 
>>>> application go
>>>> very fast in data entry with the keyboard only and this, in my opinion,
>>>> should be considered in the OFBiz interface desing.
>>>
>>> Yes, I agree this is a very pertinent remark (we could even think 
>>> more about the 15% of the population which is more or less
>>> disabled, and sadly underemployed from this cause. In France for 
>>> instance there are laws for decades about that but still a lot of
>>> enterprises which prefer to pay taxes than to employ handicapped 
>>> persons...)
>>
>> Mmm... That saids, I though one hour ago that it's should be a huge 
>> task for an ERP UI... Then I dowloaded Webbie
>> http://www.webbie.org.uk/ and NVDA  
>> http://www.nvda-project.org/download.html (awesome for a free tool). 
>> Sorry these softwares are
>> designed for Windows but I guess the same exists on Linux
>>
>> And you know what ? I think OFBIz is not doing too bad. Of course we 
>> could do better by adding means to skip some parts of the
>> screens, but it's really not too bad.
>>
>> Ok, I let my screen open and I did not close my eyes. But I'm pretty 
>> sure OFBiz is not so hard to use for a blind person with some
>> experience with computer and web tools designed for blinds (and of 
>> course some guidances for OFBiz at start too, I remember now my
>> 1st steps in OFBIz). Good news isn'it ?
>>
>> Of course this is seen from a non blind person and I can't guarantee 
>> it's realistic... Maybe in some decades, centuries ?
>>
>> Jacques
>>
>>
>>> Jacques
>>>
>>>> Thanks,
>>>> -Bruno
>>>>
>>>> 2008/6/1 Adrian Crum :
>>>>
>>>>> I know the two subjects were mixed in some replies. I understand 
>>>>> what you
>>>>> mean though. ;-)
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Scott Gray  wrote: I was for separating create forms
>>>>> and search/result forms, I was not
>>>>> suggesting that we should separate the search forms themselves.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> 2008/6/1 Jacques Le Roux :
>>>>>
>>>>> > I finally agree with most too (I mean I agree with Adrian's 
>>>>> proposition
>>>>> and
>>>>> > Andrew's here). Having them on 2 screen was a Scott's
>>>>> > proposition that I agreed with because of the flexibility given 
>>>>> by modern
>>>>> > browsers and their integrated tabs capabilities. But I can
>>>>> > imagine that some people, especially end users, would not like to 
>>>>> use
>>>>> tabs
>>>>> > or even a modern browser (though they should to use
>>>>> > both). Then it's obviously not easier to use...
>>>>> >
>>>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>>>> default
>>>>> > when there are results. If we would really want to have
>>>>> > something like that, whe should at least have an indicator to let 
>>>>> know
>>>>> the
>>>>> > user that the list is not empty.
>>>>> >
>>>>> > Just my opinion, and BTW having a consensual standard usage will be
>>>>> great.
>>>>> > I agree with the idea that we really need to standardise our ways of
>>>>> doing
>>>>> > things, even if there are only a few places still needing it in 
>>>>> OFBiz ERP
>>>>> > (thanks to widgets for instance)
>>>>> >
>>>>> > Jacques
>>>>> >
>>>>> > From: "Andrew Zeneski"
>>>>> >
>>>>> >  I can agree with most except list results and the form should be
>>>>>  rendered
>>>>> >> as one screen. This is to make usage easier when the
>>>>> >> user  wants to change the search parameters. Having the form 
>>>>> collapsed
>>>>> by
>>>>> >>  default when there are results is good.
>>>>> >>
>>>>> >>
>>>>> >> Andrew
>>>>> >>
>>>>> >>
>>>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>>>> >>
>>>>> >>  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"
>>>>> >>>>
>>>>> >>>>> 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 :
>>>>> >>>>>
>>>>> >>>>>  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"
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>>> 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 :
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>  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
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>>
> 
> 

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

Adrian,

This is great, I would like to have a look at the Skip Menu button, hope I will find time (I'm willing to do too much things at the 
same time these last times and I do just a few of them)

Thanks

Jacques

From: "Adrian Crum" <ad...@yahoo.com>
> In the UI work I've done, I have tried to keep accessibility an important priority. One of the things I like about having a 
> scalable UI is that sight impaired people can crank up their browser's default font to see it better. The simplified markup is 
> great for screen readers. Keeping OFBiz accessible to the blind is one reason why I want the screen widgets to output plain HTML 
> in addition to all the new, fancy Ajax stuff.
>
> I agree we're doing pretty well. The only thing we're missing is a "Skip Menus" button at the top of the screen.
>
> -Adrian
>
> Jacques Le Roux <ja...@les7arts.com> wrote: From: "Jacques Le Roux"
>> From: "Bruno Busco"
>
>> [...]
>>> Another point that I would bring into this discussion (hoping not being OT)
>>> is the possibility for the user to easily use the page with the keyboard
>>> only and still be able to switch between search fields panel and the data
>>> table to refine the search.
>>> I have noticed that many end-users that use non-web based application go
>>> very fast in data entry with the keyboard only and this, in my opinion,
>>> should be considered in the OFBiz interface desing.
>>
>> Yes, I agree this is a very pertinent remark (we could even think more about the 15% of the population which is more or less
>> disabled, and sadly underemployed from this cause. In France for instance there are laws for decades about that but still a lot 
>> of
>> enterprises which prefer to pay taxes than to employ handicapped persons...)
>
> Mmm... That saids, I though one hour ago that it's should be a huge task for an ERP UI... Then I dowloaded Webbie
> http://www.webbie.org.uk/ and NVDA  http://www.nvda-project.org/download.html (awesome for a free tool). Sorry these softwares are
> designed for Windows but I guess the same exists on Linux
>
> And you know what ? I think OFBIz is not doing too bad. Of course we could do better by adding means to skip some parts of the
> screens, but it's really not too bad.
>
> Ok, I let my screen open and I did not close my eyes. But I'm pretty sure OFBiz is not so hard to use for a blind person with some
> experience with computer and web tools designed for blinds (and of course some guidances for OFBiz at start too, I remember now my
> 1st steps in OFBIz). Good news isn'it ?
>
> Of course this is seen from a non blind person and I can't guarantee it's realistic... Maybe in some decades, centuries ?
>
> Jacques
>
>
>> Jacques
>>
>>> Thanks,
>>> -Bruno
>>>
>>> 2008/6/1 Adrian Crum :
>>>
>>>> I know the two subjects were mixed in some replies. I understand what you
>>>> mean though. ;-)
>>>>
>>>> -Adrian
>>>>
>>>> Scott Gray  wrote: I was for separating create forms
>>>> and search/result forms, I was not
>>>> suggesting that we should separate the search forms themselves.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2008/6/1 Jacques Le Roux :
>>>>
>>>> > I finally agree with most too (I mean I agree with Adrian's proposition
>>>> and
>>>> > Andrew's here). Having them on 2 screen was a Scott's
>>>> > proposition that I agreed with because of the flexibility given by modern
>>>> > browsers and their integrated tabs capabilities. But I can
>>>> > imagine that some people, especially end users, would not like to use
>>>> tabs
>>>> > or even a modern browser (though they should to use
>>>> > both). Then it's obviously not easier to use...
>>>> >
>>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>>> default
>>>> > when there are results. If we would really want to have
>>>> > something like that, whe should at least have an indicator to let know
>>>> the
>>>> > user that the list is not empty.
>>>> >
>>>> > Just my opinion, and BTW having a consensual standard usage will be
>>>> great.
>>>> > I agree with the idea that we really need to standardise our ways of
>>>> doing
>>>> > things, even if there are only a few places still needing it in OFBiz ERP
>>>> > (thanks to widgets for instance)
>>>> >
>>>> > Jacques
>>>> >
>>>> > From: "Andrew Zeneski"
>>>> >
>>>> >  I can agree with most except list results and the form should be
>>>>  rendered
>>>> >> as one screen. This is to make usage easier when the
>>>> >> user  wants to change the search parameters. Having the form collapsed
>>>> by
>>>> >>  default when there are results is good.
>>>> >>
>>>> >>
>>>> >> Andrew
>>>> >>
>>>> >>
>>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>>> >>
>>>> >>  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"
>>>> >>>>
>>>> >>>>> 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 :
>>>> >>>>>
>>>> >>>>>  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"
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>>> 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 :
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>  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
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
> 

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@yahoo.com>]

In the UI work I've done, I have tried to keep accessibility an important priority. One of the things I like about having a scalable UI is that sight impaired people can crank up their browser's default font to see it better. The simplified markup is great for screen readers. Keeping OFBiz accessible to the blind is one reason why I want the screen widgets to output plain HTML in addition to all the new, fancy Ajax stuff.

I agree we're doing pretty well. The only thing we're missing is a "Skip Menus" button at the top of the screen.

-Adrian

Jacques Le Roux <ja...@les7arts.com> wrote: From: "Jacques Le Roux" 
> From: "Bruno Busco" 

> [...]
>> Another point that I would bring into this discussion (hoping not being OT)
>> is the possibility for the user to easily use the page with the keyboard
>> only and still be able to switch between search fields panel and the data
>> table to refine the search.
>> I have noticed that many end-users that use non-web based application go
>> very fast in data entry with the keyboard only and this, in my opinion,
>> should be considered in the OFBiz interface desing.
>
> Yes, I agree this is a very pertinent remark (we could even think more about the 15% of the population which is more or less
> disabled, and sadly underemployed from this cause. In France for instance there are laws for decades about that but still a lot of
> enterprises which prefer to pay taxes than to employ handicapped persons...)

Mmm... That saids, I though one hour ago that it's should be a huge task for an ERP UI... Then I dowloaded Webbie 
http://www.webbie.org.uk/ and NVDA  http://www.nvda-project.org/download.html (awesome for a free tool). Sorry these softwares are 
designed for Windows but I guess the same exists on Linux

And you know what ? I think OFBIz is not doing too bad. Of course we could do better by adding means to skip some parts of the 
screens, but it's really not too bad.

 Ok, I let my screen open and I did not close my eyes. But I'm pretty sure OFBiz is not so hard to use for a blind person with some 
experience with computer and web tools designed for blinds (and of course some guidances for OFBiz at start too, I remember now my 
1st steps in OFBIz). Good news isn'it ?

Of course this is seen from a non blind person and I can't guarantee it's realistic... Maybe in some decades, centuries ?

Jacques


> Jacques
>
>> Thanks,
>> -Bruno
>>
>> 2008/6/1 Adrian Crum :
>>
>>> I know the two subjects were mixed in some replies. I understand what you
>>> mean though. ;-)
>>>
>>> -Adrian
>>>
>>> Scott Gray  wrote: I was for separating create forms
>>> and search/result forms, I was not
>>> suggesting that we should separate the search forms themselves.
>>>
>>> Regards
>>> Scott
>>>
>>> 2008/6/1 Jacques Le Roux :
>>>
>>> > I finally agree with most too (I mean I agree with Adrian's proposition
>>> and
>>> > Andrew's here). Having them on 2 screen was a Scott's
>>> > proposition that I agreed with because of the flexibility given by modern
>>> > browsers and their integrated tabs capabilities. But I can
>>> > imagine that some people, especially end users, would not like to use
>>> tabs
>>> > or even a modern browser (though they should to use
>>> > both). Then it's obviously not easier to use...
>>> >
>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>> default
>>> > when there are results. If we would really want to have
>>> > something like that, whe should at least have an indicator to let know
>>> the
>>> > user that the list is not empty.
>>> >
>>> > Just my opinion, and BTW having a consensual standard usage will be
>>> great.
>>> > I agree with the idea that we really need to standardise our ways of
>>> doing
>>> > things, even if there are only a few places still needing it in OFBiz ERP
>>> > (thanks to widgets for instance)
>>> >
>>> > Jacques
>>> >
>>> > From: "Andrew Zeneski"
>>> >
>>> >  I can agree with most except list results and the form should be
>>>  rendered
>>> >> as one screen. This is to make usage easier when the
>>> >> user  wants to change the search parameters. Having the form collapsed
>>> by
>>> >>  default when there are results is good.
>>> >>
>>> >>
>>> >> Andrew
>>> >>
>>> >>
>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>> >>
>>> >>  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"
>>> >>>>
>>> >>>>> 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 :
>>> >>>>>
>>> >>>>>  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"
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>> 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 :
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>  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
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>
>>> >
>>>
>>>
>>>
>>>
>>
>



       

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Bruno Busco" <br...@gmail.com>
> [...]
>> Another point that I would bring into this discussion (hoping not being OT)
>> is the possibility for the user to easily use the page with the keyboard
>> only and still be able to switch between search fields panel and the data
>> table to refine the search.
>> I have noticed that many end-users that use non-web based application go
>> very fast in data entry with the keyboard only and this, in my opinion,
>> should be considered in the OFBiz interface desing.
>
> Yes, I agree this is a very pertinent remark (we could even think more about the 15% of the population which is more or less
> disabled, and sadly underemployed from this cause. In France for instance there are laws for decades about that but still a lot of
> enterprises which prefer to pay taxes than to employ handicapped persons...)

Mmm... That saids, I though one hour ago that it's should be a huge task for an ERP UI... Then I dowloaded Webbie 
http://www.webbie.org.uk/ and NVDA  http://www.nvda-project.org/download.html (awesome for a free tool). Sorry these softwares are 
designed for Windows but I guess the same exists on Linux

And you know what ? I think OFBIz is not doing too bad. Of course we could do better by adding means to skip some parts of the 
screens, but it's really not too bad.

 Ok, I let my screen open and I did not close my eyes. But I'm pretty sure OFBiz is not so hard to use for a blind person with some 
experience with computer and web tools designed for blinds (and of course some guidances for OFBiz at start too, I remember now my 
1st steps in OFBIz). Good news isn'it ?

Of course this is seen from a non blind person and I can't guarantee it's realistic... Maybe in some decades, centuries ?

Jacques


> Jacques
>
>> Thanks,
>> -Bruno
>>
>> 2008/6/1 Adrian Crum <ad...@yahoo.com>:
>>
>>> I know the two subjects were mixed in some replies. I understand what you
>>> mean though. ;-)
>>>
>>> -Adrian
>>>
>>> Scott Gray <le...@gmail.com> wrote: I was for separating create forms
>>> and search/result forms, I was not
>>> suggesting that we should separate the search forms themselves.
>>>
>>> Regards
>>> Scott
>>>
>>> 2008/6/1 Jacques Le Roux :
>>>
>>> > I finally agree with most too (I mean I agree with Adrian's proposition
>>> and
>>> > Andrew's here). Having them on 2 screen was a Scott's
>>> > proposition that I agreed with because of the flexibility given by modern
>>> > browsers and their integrated tabs capabilities. But I can
>>> > imagine that some people, especially end users, would not like to use
>>> tabs
>>> > or even a modern browser (though they should to use
>>> > both). Then it's obviously not easier to use...
>>> >
>>> > Just one point : I'm not sure it's good to have forms collapsed by
>>> default
>>> > when there are results. If we would really want to have
>>> > something like that, whe should at least have an indicator to let know
>>> the
>>> > user that the list is not empty.
>>> >
>>> > Just my opinion, and BTW having a consensual standard usage will be
>>> great.
>>> > I agree with the idea that we really need to standardise our ways of
>>> doing
>>> > things, even if there are only a few places still needing it in OFBiz ERP
>>> > (thanks to widgets for instance)
>>> >
>>> > Jacques
>>> >
>>> > From: "Andrew Zeneski"
>>> >
>>> >  I can agree with most except list results and the form should be
>>>  rendered
>>> >> as one screen. This is to make usage easier when the
>>> >> user  wants to change the search parameters. Having the form collapsed
>>> by
>>> >>  default when there are results is good.
>>> >>
>>> >>
>>> >> Andrew
>>> >>
>>> >>
>>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>> >>
>>> >>  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"
>>> >>>>
>>> >>>>> 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 :
>>> >>>>>
>>> >>>>>  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"
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>> 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 :
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>  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
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>
>>> >
>>>
>>>
>>>
>>>
>>
>

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Bruno Busco" <br...@gmail.com>
[...]
> Another point that I would bring into this discussion (hoping not being OT)
> is the possibility for the user to easily use the page with the keyboard
> only and still be able to switch between search fields panel and the data
> table to refine the search.
> I have noticed that many end-users that use non-web based application go
> very fast in data entry with the keyboard only and this, in my opinion,
> should be considered in the OFBiz interface desing.

Yes, I agree this is a very pertinent remark (we could even think more about the 15% of the population which is more or less 
disabled, and sadly underemployed from this cause. In France for instance there are laws for decades about that but still a lot of 
enterprises which prefer to pay taxes than to employ handicapped persons...)

Jacques

> Thanks,
> -Bruno
>
> 2008/6/1 Adrian Crum <ad...@yahoo.com>:
>
>> I know the two subjects were mixed in some replies. I understand what you
>> mean though. ;-)
>>
>> -Adrian
>>
>> Scott Gray <le...@gmail.com> wrote: I was for separating create forms
>> and search/result forms, I was not
>> suggesting that we should separate the search forms themselves.
>>
>> Regards
>> Scott
>>
>> 2008/6/1 Jacques Le Roux :
>>
>> > I finally agree with most too (I mean I agree with Adrian's proposition
>> and
>> > Andrew's here). Having them on 2 screen was a Scott's
>> > proposition that I agreed with because of the flexibility given by modern
>> > browsers and their integrated tabs capabilities. But I can
>> > imagine that some people, especially end users, would not like to use
>> tabs
>> > or even a modern browser (though they should to use
>> > both). Then it's obviously not easier to use...
>> >
>> > Just one point : I'm not sure it's good to have forms collapsed by
>> default
>> > when there are results. If we would really want to have
>> > something like that, whe should at least have an indicator to let know
>> the
>> > user that the list is not empty.
>> >
>> > Just my opinion, and BTW having a consensual standard usage will be
>> great.
>> > I agree with the idea that we really need to standardise our ways of
>> doing
>> > things, even if there are only a few places still needing it in OFBiz ERP
>> > (thanks to widgets for instance)
>> >
>> > Jacques
>> >
>> > From: "Andrew Zeneski"
>> >
>> >  I can agree with most except list results and the form should be
>>  rendered
>> >> as one screen. This is to make usage easier when the
>> >> user  wants to change the search parameters. Having the form collapsed
>> by
>> >>  default when there are results is good.
>> >>
>> >>
>> >> Andrew
>> >>
>> >>
>> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>> >>
>> >>  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"
>> >>>>
>> >>>>> 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 :
>> >>>>>
>> >>>>>  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"
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> 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 :
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>  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
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>
>> >
>>
>>
>>
>>
> 

Re: Discussion: Main Content Layout Best Practices

[Bruno Busco <br...@gmail.com>]

I agree with both points summarized by Adrian.

Since we were also speaking about the screenlet header and what control
should be visible there, I would like to remind
https://issues.apache.org/jira/browse/OFBIZ-1750 where there was a proposal
of having a little icon on the screenlet title bar offering contextual help.
Since the screenlet is supposed to be used to split the page content into
several conceptual aggregated information may be these information could be
linked as a whole to a single help page.
Having a best practice to put the help link would be fine.

Another point that I would bring into this discussion (hoping not being OT)
is the possibility for the user to easily use the page with the keyboard
only and still be able to switch between search fields panel and the data
table to refine the search.
I have noticed that many end-users that use non-web based application go
very fast in data entry with the keyboard only and this, in my opinion,
should be considered in the OFBiz interface desing.

Thanks,
-Bruno

2008/6/1 Adrian Crum <ad...@yahoo.com>:

> I know the two subjects were mixed in some replies. I understand what you
> mean though. ;-)
>
> -Adrian
>
> Scott Gray <le...@gmail.com> wrote: I was for separating create forms
> and search/result forms, I was not
> suggesting that we should separate the search forms themselves.
>
> Regards
> Scott
>
> 2008/6/1 Jacques Le Roux :
>
> > I finally agree with most too (I mean I agree with Adrian's proposition
> and
> > Andrew's here). Having them on 2 screen was a Scott's
> > proposition that I agreed with because of the flexibility given by modern
> > browsers and their integrated tabs capabilities. But I can
> > imagine that some people, especially end users, would not like to use
> tabs
> > or even a modern browser (though they should to use
> > both). Then it's obviously not easier to use...
> >
> > Just one point : I'm not sure it's good to have forms collapsed by
> default
> > when there are results. If we would really want to have
> > something like that, whe should at least have an indicator to let know
> the
> > user that the list is not empty.
> >
> > Just my opinion, and BTW having a consensual standard usage will be
> great.
> > I agree with the idea that we really need to standardise our ways of
> doing
> > things, even if there are only a few places still needing it in OFBiz ERP
> > (thanks to widgets for instance)
> >
> > Jacques
> >
> > From: "Andrew Zeneski"
> >
> >  I can agree with most except list results and the form should be
>  rendered
> >> as one screen. This is to make usage easier when the
> >> user  wants to change the search parameters. Having the form collapsed
> by
> >>  default when there are results is good.
> >>
> >>
> >> Andrew
> >>
> >>
> >> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
> >>
> >>  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"
> >>>>
> >>>>> 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 :
> >>>>>
> >>>>>  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"
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 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 :
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>  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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>
> >
>
>
>
>

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@yahoo.com>]

I know the two subjects were mixed in some replies. I understand what you mean though. ;-)

-Adrian

Scott Gray <le...@gmail.com> wrote: I was for separating create forms and search/result forms, I was not
suggesting that we should separate the search forms themselves.

Regards
Scott

2008/6/1 Jacques Le Roux :

> I finally agree with most too (I mean I agree with Adrian's proposition and
> Andrew's here). Having them on 2 screen was a Scott's
> proposition that I agreed with because of the flexibility given by modern
> browsers and their integrated tabs capabilities. But I can
> imagine that some people, especially end users, would not like to use tabs
> or even a modern browser (though they should to use
> both). Then it's obviously not easier to use...
>
> Just one point : I'm not sure it's good to have forms collapsed by default
> when there are results. If we would really want to have
> something like that, whe should at least have an indicator to let know the
> user that the list is not empty.
>
> Just my opinion, and BTW having a consensual standard usage will be great.
> I agree with the idea that we really need to standardise our ways of doing
> things, even if there are only a few places still needing it in OFBiz ERP
> (thanks to widgets for instance)
>
> Jacques
>
> From: "Andrew Zeneski" 
>
>  I can agree with most except list results and the form should be  rendered
>> as one screen. This is to make usage easier when the
>> user  wants to change the search parameters. Having the form collapsed by
>>  default when there are results is good.
>>
>>
>> Andrew
>>
>>
>> On May 30, 2008, at 12:16 PM, Adrian Crum  wrote:
>>
>>  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" 
>>>>
>>>>> 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 :
>>>>>
>>>>>  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" 
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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 :
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>


       

Re: Discussion: Main Content Layout Best Practices

[Scott Gray <le...@gmail.com>]

I was for separating create forms and search/result forms, I was not
suggesting that we should separate the search forms themselves.

Regards
Scott

2008/6/1 Jacques Le Roux <ja...@les7arts.com>:

> I finally agree with most too (I mean I agree with Adrian's proposition and
> Andrew's here). Having them on 2 screen was a Scott's
> proposition that I agreed with because of the flexibility given by modern
> browsers and their integrated tabs capabilities. But I can
> imagine that some people, especially end users, would not like to use tabs
> or even a modern browser (though they should to use
> both). Then it's obviously not easier to use...
>
> Just one point : I'm not sure it's good to have forms collapsed by default
> when there are results. If we would really want to have
> something like that, whe should at least have an indicator to let know the
> user that the list is not empty.
>
> Just my opinion, and BTW having a consensual standard usage will be great.
> I agree with the idea that we really need to standardise our ways of doing
> things, even if there are only a few places still needing it in OFBiz ERP
> (thanks to widgets for instance)
>
> Jacques
>
> From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>
>  I can agree with most except list results and the form should be  rendered
>> as one screen. This is to make usage easier when the
>> user  wants to change the search parameters. Having the form collapsed by
>>  default when there are results is good.
>>
>>
>> Andrew
>>
>>
>> On May 30, 2008, at 12:16 PM, Adrian Crum <ad...@hlmksw.com> wrote:
>>
>>  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" <le...@gmail.com>
>>>>
>>>>> 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 <an...@hotwaxmedia.com>:
>>>>>
>>>>>  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" <jo...@hotwaxmedia.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>

Re: Discussion: Main Content Layout Best Practices

[David E Jones <jo...@hotwaxmedia.com>]

On May 31, 2008, at 10:03 AM, Jacques Le Roux wrote:

> Just one point : I'm not sure it's good to have forms collapsed by  
> default when there are results. If we would really want to have
> something like that, whe should at least have an indicator to let  
> know the user that the list is not empty.

The form that would be collapsed by default is the one with the search  
fields, not the results. The reason is that with a lot of search  
fields the results get pushed pretty far down the page and it is  
difficult to effectively review them.

On May 31, 2008, at 12:11 PM, Daniel Martínez wrote:

> I prefer search form showed by default (which does not mean that it  
> cannot be collapsed by means of some button). It informs the user  
> which are the filters for the results he's viewing.
>
> I.e. when using google, the search form is always visible. Maybe I  
> forgot which were the terms I was looking for. No worry, they are  
> here with my results ;)

Yes, but on google there is only one search field, and on many of  
these forms there can be over a dozen.

It might be interesting to have a super-small summary of the search  
constraints used for the results, like we do in the ecommerce product  
search.

-David

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

I finally agree with most too (I mean I agree with Adrian's proposition and Andrew's here). Having them on 2 screen was a Scott's
proposition that I agreed with because of the flexibility given by modern browsers and their integrated tabs capabilities. But I can
imagine that some people, especially end users, would not like to use tabs or even a modern browser (though they should to use
both). Then it's obviously not easier to use...

Just one point : I'm not sure it's good to have forms collapsed by default when there are results. If we would really want to have
something like that, whe should at least have an indicator to let know the user that the list is not empty.

Just my opinion, and BTW having a consensual standard usage will be great. I agree with the idea that we really need to standardise 
our ways of doing things, even if there are only a few places still needing it in OFBiz ERP (thanks to widgets for instance)

Jacques

From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>I can agree with most except list results and the form should be  rendered as one screen. This is to make usage easier when the
>user  wants to change the search parameters. Having the form collapsed by  default when there are results is good.
>
>
> Andrew
>
>
> On May 30, 2008, at 12:16 PM, Adrian Crum <ad...@hlmksw.com> wrote:
>
>> 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" <le...@gmail.com>
>>>> 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 <an...@hotwaxmedia.com>:
>>>>
>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>
>>>>>>>>
>>>>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>

Re: Discussion: Main Content Layout Best Practices

[Daniel Martínez <da...@paradisosistemas.es>]

I prefer search form showed by default (which does not mean that it 
cannot be collapsed by means of some button). It informs the user which 
are the filters for the results he's viewing.

I.e. when using google, the search form is always visible. Maybe I 
forgot which were the terms I was looking for. No worry, they are here 
with my results ;)
--
Daniel Martínez

Andrew Zeneski escribió:
> I can agree with most except list results and the form should be 
> rendered as one screen. This is to make usage easier when the user 
> wants to change the search parameters. Having the form collapsed by 
> default when there are results is good.
>
>
> Andrew
>
>
> On May 30, 2008, at 12:16 PM, Adrian Crum <ad...@hlmksw.com> wrote:
>
>> 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" <le...@gmail.com>
>>>> 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 <an...@hotwaxmedia.com>:
>>>>
>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>
>>>>>>>>
>>>>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>

Re: Discussion: Main Content Layout Best Practices

[Andrew Zeneski <an...@hotwaxmedia.com>]

I can agree with most except list results and the form should be  
rendered as one screen. This is to make usage easier when the user  
wants to change the search parameters. Having the form collapsed by  
default when there are results is good.


Andrew


On May 30, 2008, at 12:16 PM, Adrian Crum <ad...@hlmksw.com> wrote:

> 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" <le...@gmail.com>
>>> 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 <an...@hotwaxmedia.com>:
>>>
>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>
>>>>>>>
>>>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>

Re: Discussion: Main Content Layout Best Practices

[Daniel Martínez <da...@paradisosistemas.es>]

+1
(to both)
--
Daniel

Adrian Crum escribió:
> 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" <le...@gmail.com>
>>> 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 <an...@hotwaxmedia.com>:
>>>
>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>
>>>>>>>
>>>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

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" <ad...@yahoo.com>
> 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 <ad...@hlmksw.com> wrote:
>
>> From: Adrian Crum <ad...@hlmksw.com>
>> 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" <le...@gmail.com>
>> >> 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
>> <an...@hotwaxmedia.com>:
>> >>
>> >>> 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"
>> <jo...@hotwaxmedia.com>
>> >>>>>
>> >>>>>>
>> >>>>>> 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
>> <jo...@hotwaxmedia.com>:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> 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
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>
>
>
> 

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@yahoo.com>]

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 <ad...@hlmksw.com> wrote:

> From: Adrian Crum <ad...@hlmksw.com>
> 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" <le...@gmail.com>
> >> 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
> <an...@hotwaxmedia.com>:
> >>
> >>> 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"
> <jo...@hotwaxmedia.com>
> >>>>>
> >>>>>>
> >>>>>> 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
> <jo...@hotwaxmedia.com>:
> >>>>>>>
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> > 
> >


      

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

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" <le...@gmail.com>
>> 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 <an...@hotwaxmedia.com>:
>>
>>> 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" <jo...@hotwaxmedia.com>
>>>>>
>>>>>>
>>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>
> 
> 

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Scott Gray" <le...@gmail.com>
> 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 <an...@hotwaxmedia.com>:
>
>> 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" <jo...@hotwaxmedia.com>
>>>>
>>>>>
>>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>
> 

Re: Discussion: Main Content Layout Best Practices

[Scott Gray <le...@gmail.com>]

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.

Regards
Scott

2008/5/24 Anil Patel <an...@hotwaxmedia.com>:

> 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" <jo...@hotwaxmedia.com>
>>>
>>>>
>>>> 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 <jo...@hotwaxmedia.com>:
>>>>>
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>

Re: Discussion: Main Content Layout Best Practices

[Anil Patel <an...@hotwaxmedia.com>]

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" <jo...@hotwaxmedia.com>
>>>
>>> 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 <jo...@hotwaxmedia.com>:
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>
>

Re: Discussion: Main Content Layout Best Practices

[David E Jones <jo...@hotwaxmedia.com>]

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" <jo...@hotwaxmedia.com>
>>
>> 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 <jo...@hotwaxmedia.com>:
>>>
>>>>
>>>> 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
>>>>
>>>>
>

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

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" <jo...@hotwaxmedia.com>
>
> 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 <jo...@hotwaxmedia.com>:
>>
>>>
>>> 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
>>>
>>>
> 

Re: Discussion: Main Content Layout Best Practices

[David E Jones <jo...@hotwaxmedia.com>]

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 <jo...@hotwaxmedia.com>:
>
>>
>> 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
>>
>>

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

> About the +/- button, having it on the right-hand side seems
> counterintuitive to me, I would rather see it on the left.  Or better yet, I
> love how in gmail I can click anywhere along the title of a message and have
> it expand/collapse.

Yes, we may have even both, like in Windows (and in Gnome as well at least, maybe it even comes from Mac at beginning) : you can 
dlb-click to maxi-minimize or use the button at the right (note then that having them at right is not counterintuitive to everybody, 
conventions... ;o)

Jacques

> Scott
>
> 2008/5/24 Jacques Le Roux <ja...@les7arts.com>:
>
>>
>> 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.
>>
>>
> 

Re: Discussion: Main Content Layout Best Practices

[Scott Gray <le...@gmail.com>]

About the +/- button, having it on the right-hand side seems
counterintuitive to me, I would rather see it on the left.  Or better yet, I
love how in gmail I can click anywhere along the title of a message and have
it expand/collapse.

Scott

2008/5/24 Jacques Le Roux <ja...@les7arts.com>:

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

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Vikas Mayur" <vi...@gmail.com>
>> On Fri, May 23, 2008 at 8:30 PM, Adrian Crum <ad...@hlmksw.com> 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

I found the link, nothing great in it http://www.nabble.com/forum/Permalink.jtp?root=8474257&post=8487874&page=y

> Jacques

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

From: "Vikas Mayur" <vi...@gmail.com>
> On Fri, May 23, 2008 at 8:30 PM, Adrian Crum <ad...@hlmksw.com> 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
>>>
>>>
> 

Re: Discussion: Main Content Layout Best Practices

[Vikas Mayur <vi...@gmail.com>]

On Fri, May 23, 2008 at 8:30 PM, Adrian Crum <ad...@hlmksw.com> 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
>>
>>

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

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
> 

Re: Discussion: Main Content Layout Best Practices

[Vikas Mayur <vi...@gmail.com>]

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

Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux <ja...@les7arts.com>]

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

Jacques

From: "Scott Gray" <le...@gmail.com>
>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 <jo...@hotwaxmedia.com>:
> 
>>
>> 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
>>
>>
>

Re: Discussion: Main Content Layout Best Practices

[Scott Gray <le...@gmail.com>]

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 <jo...@hotwaxmedia.com>:

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

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

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.

Re: Discussion: Main Content Layout Best Practices

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Discussion: Main Content Layout Best Practices

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Discussion: Main Content Layout Best Practices

[Vikas Mayur <vi...@gmail.com>]

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 <ad...@hlmksw.com> 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
>