Discussion: Main Content Layout Best Practices

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

Jacques Le Roux
Administrator
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" <[hidden email]>

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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

Adrian Crum
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" <[hidden email]>
>> 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 <[hidden email]> 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
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

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

> 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" <[hidden email]>
>>
>>> 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 <[hidden email]> 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
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

Jacques Le Roux
Administrator
In reply to this post by Adrian Crum-2
Hi Adrian,

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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

Jacques Le Roux
Administrator
In reply to this post by Bruno Busco
From: "Bruno Busco" <[hidden email]>
> 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 <[hidden email]>:
>
>> 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" <[hidden email]>
>>>
>>>> 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 <[hidden email]> 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
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

Adrian Crum-2
In reply to this post by Adrian Crum
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 <[hidden email]> wrote:

> From: Adrian Crum <[hidden email]>
> Subject: Re: Discussion: Main Content Layout Best Practices
> To: [hidden email]
> 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" <[hidden email]>
> >> 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
> <[hidden email]>:
> >>
> >>> I think what David is suggesting is something
> like this
> >>> http://www.wildbit.com/demos/modalbox/
> >>>
> >>> Regards
> >>> Anil Patel
> >>>
> >>>
> >>>
> >>> On May 23, 2008, at 1:57 PM, David E Jones
> wrote:
> >>>
> >>>
> >>>> I didn't say open a new window, I said
> either expand a hidden area or
> >>>> popup using JavaScript within the window
> (ie over top of the list
> >>>> behind
> >>>> it).
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On May 23, 2008, at 11:55 AM, Jacques Le
> Roux wrote:
> >>>>
> >>>>  IMHO, we should avoid to overuse popping
> as opening a new window is
> >>>> time
> >>>>> consuming (especially in Firefox).
> This is currently a major
> >>>>> inconvenience
> >>>>> for Lookups and Calendar for instance
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>> From: "David E Jones"
> <[hidden email]>
> >>>>>
> >>>>>>
> >>>>>> Since we're entering the world
> of using more javascript in the  
> >>>>>> browser,
> >>>>>> why not have the add form on the
> top but hidden by default  with
> >>>>>> and Add
> >>>>>> button of some sort that would
> cause the form to be  shown? We
> >>>>>> could even
> >>>>>> make it fancy and popup over top
> of the list form  and have it go
> >>>>>> away after
> >>>>>> submission with an update of the
> list behind  it... without any
> >>>>>> page loads
> >>>>>> even.
> >>>>>>
> >>>>>> -David
> >>>>>>
> >>>>>>
> >>>>>> On May 22, 2008, at 11:38 PM,
> Scott Gray wrote:
> >>>>>>
> >>>>>>  I would agree with that but
> personally I would prefer to see them on
> >>>>>>> completely different pages.
> If I wanted to be able to refer back to
> >>>>>>>  the
> >>>>>>> list while adding I would
> ctrl+click and then ctrl+tab to flick back
> >>>>>>>  and
> >>>>>>> forth, that's what makes
> tabbed browsers so handy.  One of the
> >>>>>>>  problems with
> >>>>>>> having them on the same page
> is that any errors after adding
> >>>>>>> would be
> >>>>>>> displayed before the list
> while the add form would be way down the
> >>>>>>>  bottom.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Scott
> >>>>>>>
> >>>>>>> 2008/5/23 David E Jones
> <[hidden email]>:
> >>>>>>>
> >>>>>>>
> >>>>>>>> On May 22, 2008, at 9:11
> AM, Adrian Crum wrote:
> >>>>>>>>
> >>>>>>>> 2) If a screen has a list
> and add form, what should be the order of
> >>>>>>>>  these
> >>>>>>>>
> >>>>>>>>> forms (I have seen in
> your recent work that add form should
> >>>>>>>>> come  on
> >>>>>>>>>> top
> >>>>>>>>>> and
> >>>>>>>>>> I completely
> >>>>>>>>>> agree with this).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> I believe the form
> should be on top of the list. Otherwise, as you
> >>>>>>>>>  add
> >>>>>>>>> items to the list, the
> form is scrolled off the bottom of the
> >>>>>>>>>  screen.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> The main question is: what
> is going to be used more? Will it be the
> >>>>>>>>  list or
> >>>>>>>> the add form?
> >>>>>>>>
> >>>>>>>> If in most cases it will
> be the list, and if you have to scroll  
> >>>>>>>> down
> >>>>>>>> every
> >>>>>>>> time to see it...
> that's a pain.
> >>>>>>>>
> >>>>>>>> -David
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >


     
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Main Content Layout Best Practices

Jacques Le Roux
Administrator
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" <[hidden email]>

> 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 <[hidden email]> wrote:
>
>> From: Adrian Crum <[hidden email]>
>> Subject: Re: Discussion: Main Content Layout Best Practices
>> To: [hidden email]
>> 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" <[hidden email]>
>> >> 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
>> <[hidden email]>:
>> >>
>> >>> I think what David is suggesting is something
>> like this
>> >>> http://www.wildbit.com/demos/modalbox/
>> >>>
>> >>> Regards
>> >>> Anil Patel
>> >>>
>> >>>
>> >>>
>> >>> On May 23, 2008, at 1:57 PM, David E Jones
>> wrote:
>> >>>
>> >>>
>> >>>> I didn't say open a new window, I said
>> either expand a hidden area or
>> >>>> popup using JavaScript within the window
>> (ie over top of the list
>> >>>> behind
>> >>>> it).
>> >>>>
>> >>>> -David
>> >>>>
>> >>>>
>> >>>> On May 23, 2008, at 11:55 AM, Jacques Le
>> Roux wrote:
>> >>>>
>> >>>>  IMHO, we should avoid to overuse popping
>> as opening a new window is
>> >>>> time
>> >>>>> consuming (especially in Firefox).
>> This is currently a major
>> >>>>> inconvenience
>> >>>>> for Lookups and Calendar for instance
>> >>>>>
>> >>>>> Jacques
>> >>>>>
>> >>>>> From: "David E Jones"
>> <[hidden email]>
>> >>>>>
>> >>>>>>
>> >>>>>> Since we're entering the world
>> of using more javascript in the
>> >>>>>> browser,
>> >>>>>> why not have the add form on the
>> top but hidden by default  with
>> >>>>>> and Add
>> >>>>>> button of some sort that would
>> cause the form to be  shown? We
>> >>>>>> could even
>> >>>>>> make it fancy and popup over top
>> of the list form  and have it go
>> >>>>>> away after
>> >>>>>> submission with an update of the
>> list behind  it... without any
>> >>>>>> page loads
>> >>>>>> even.
>> >>>>>>
>> >>>>>> -David
>> >>>>>>
>> >>>>>>
>> >>>>>> On May 22, 2008, at 11:38 PM,
>> Scott Gray wrote:
>> >>>>>>
>> >>>>>>  I would agree with that but
>> personally I would prefer to see them on
>> >>>>>>> completely different pages.
>> If I wanted to be able to refer back to
>> >>>>>>>  the
>> >>>>>>> list while adding I would
>> ctrl+click and then ctrl+tab to flick back
>> >>>>>>>  and
>> >>>>>>> forth, that's what makes
>> tabbed browsers so handy.  One of the
>> >>>>>>>  problems with
>> >>>>>>> having them on the same page
>> is that any errors after adding
>> >>>>>>> would be
>> >>>>>>> displayed before the list
>> while the add form would be way down the
>> >>>>>>>  bottom.
>> >>>>>>>
>> >>>>>>> Regards
>> >>>>>>> Scott
>> >>>>>>>
>> >>>>>>> 2008/5/23 David E Jones
>> <[hidden email]>:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On May 22, 2008, at 9:11
>> AM, Adrian Crum wrote:
>> >>>>>>>>
>> >>>>>>>> 2) If a screen has a list
>> and add form, what should be the order of
>> >>>>>>>>  these
>> >>>>>>>>
>> >>>>>>>>> forms (I have seen in
>> your recent work that add form should
>> >>>>>>>>> come  on
>> >>>>>>>>>> top
>> >>>>>>>>>> and
>> >>>>>>>>>> I completely
>> >>>>>>>>>> agree with this).
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>> I believe the form
>> should be on top of the list. Otherwise, as you
>> >>>>>>>>>  add
>> >>>>>>>>> items to the list, the
>> form is scrolled off the bottom of the
>> >>>>>>>>>  screen.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> The main question is: what
>> is going to be used more? Will it be the
>> >>>>>>>>  list or
>> >>>>>>>> the add form?
>> >>>>>>>>
>> >>>>>>>> If in most cases it will
>> be the list, and if you have to scroll
>> >>>>>>>> down
>> >>>>>>>> every
>> >>>>>>>> time to see it...
>> that's a pain.
>> >>>>>>>>
>> >>>>>>>> -David
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>
>
>
>

123