Re: Discussion: Main Content Layout Best Practices

[Jacques Le Roux]

From: "Bruno Busco" <[EMAIL PROTECTED]>

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 <[EMAIL PROTECTED]>:

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" <[EMAIL PROTECTED]>

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 <[EMAIL PROTECTED]> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>