Re: Why are navigational element are not static when scrolling long pages?

[Ferdinand Soethe <sa...@soethe.net>]

My point:

Making use of the only purpose we came up with for the current
mechanism (being able to have menus longer than the page) will create
an extremely user-unfriedly page because opening a menu item at the
bottom of such a menu

- requires the user to
  scroll the page (not really menu-like and a drag to do)

- and will scroll the tab bar out of sight if he does

So to get an idea of the content of a complete site (by browsing menus
and tabs) requires constant change between clicking and scrolling
action.

Conclusion:

I see this as a very strong reason to change the default in pelt so
that header and menu remain in place when you scroll content (and make
the current setting an option).

In a second step enhance the menueing system so support column breaks
or perhaps even break automatically when the number of items doesn't
fit on the screen.

--
Ferdinand Soethe

Re: Why are navigational element are not static when scrolling long pages?

[Ross Gardler <rg...@apache.org>]

Ferdinand Soethe wrote:
> My point:
> 
> Making use of the only purpose we came up with for the current
> mechanism (being able to have menus longer than the page) will create
> an extremely user-unfriedly page because opening a menu item at the
> bottom of such a menu
> 
> - requires the user to
>   scroll the page (not really menu-like and a drag to do)
> 
> - and will scroll the tab bar out of sight if he does
> 
> So to get an idea of the content of a complete site (by browsing menus
> and tabs) requires constant change between clicking and scrolling
> action.
> 
> Conclusion:
> 
> I see this as a very strong reason to change the default in pelt so
> that header and menu remain in place when you scroll content (and make
> the current setting an option).

Such a change will have to be taken to a vote since it will affect a 
great many users when they upgrade. However, adding a configuration 
option allowing it to be turned on would not need a vote. But a vote 
would be meaningless unless someone finds a solution that is cross 
browser compatible.

I'd suggest finding the solution, adding it as a configuration option 
and then, if you still want to, take it to a vote to make it the default.

> In a second step enhance the menueing system so support column breaks
> or perhaps even break automatically when the number of items doesn't
> fit on the screen.

Again, if you find a way of doing this in a cross-browser compatible way 
I'd be all for it. Sounds hard to me though.

Ross

Re: Why are navigational element are not static when scrolling long pages?

[Ferdinand Soethe <sa...@soethe.net>]

Ross Gardler wrote:

RG> I'd suggest finding the solution, adding it as a configuration option
RG> and then, if you still want to, take it to a vote to make it the default.

Sounds good to me since such a change would only make sense if we
get it to work properly. Implementing it as an option will give us
a chance to test and show it and win people over.

(Or - more likely - I'll find out that the sceptics where right about
this.)


--
Ferdinand Soethe

Re: Why are navigational element are not static when scrolling long pages?

[Ross Gardler <rg...@apache.org>]

Ferdinand Soethe wrote:
> My point:
> 
> Making use of the only purpose we came up with for the current
> mechanism (being able to have menus longer than the page) will create
> an extremely user-unfriedly page because opening a menu item at the
> bottom of such a menu
> 
> - requires the user to
>   scroll the page (not really menu-like and a drag to do)
> 
> - and will scroll the tab bar out of sight if he does
> 
> So to get an idea of the content of a complete site (by browsing menus
> and tabs) requires constant change between clicking and scrolling
> action.
> 
> Conclusion:
> 
> I see this as a very strong reason to change the default in pelt so
> that header and menu remain in place when you scroll content (and make
> the current setting an option).

Such a change will have to be taken to a vote since it will affect a 
great many users when they upgrade. However, adding a configuration 
option allowing it to be turned on would not need a vote. But a vote 
would be meaningless unless someone finds a solution that is cross 
browser compatible.

I'd suggest finding the solution, adding it as a configuration option 
and then, if you still want to, take it to a vote to make it the default.

> In a second step enhance the menueing system so support column breaks
> or perhaps even break automatically when the number of items doesn't
> fit on the screen.

Again, if you find a way of doing this in a cross-browser compatible way 
I'd be all for it. Sounds tough to me though.

Ross