«

Hi:

Is there any way using Javascript to force Safari for mobile
devices to display scroll bars beside a table when vertical content
overflows ?

(I have a 613-row table that is agonizing to vertically scroll using the
one-finger swiping method)

(btw, I posted this wrongly in the authoring.html group earlier )

Thanks,

--
Mel Smith

Mel Smith wrote on 22 dec 2011 in comp.lang.javascript:

> (I have a 613-row table that is agonizing to vertically scroll using the
> one-finger swiping method)

613??

Better think of a more friendly alternative for any browser.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

"Evertjan." <> wrote in message
news:Xns9FC3CECB6351Eeejj99@194.109.133.133...
> Mel Smith wrote on 22 dec 2011 in comp.lang.javascript:
>
>> (I have a 613-row table that is agonizing to vertically scroll using the
>> one-finger swiping method)
>
> 613??
>
> Better think of a more friendly alternative for any browser.


Well, I have 613 Homes in my Senior's Park, and a line for each home (7
columns), so it works perfectly with a scroll bar, and a few search fields
and sorting methods based on Denis McMahon's Javascript methods for sorting.

So, when a user wishes to got to the bottom (or top) of the table (based
on 1 of 4 different sorting columns/methods), a quick slide of the scroll
bar is easy.

But, with no Scroll bar, you can wear out your finger *and* patience !

-Mel

Mel Smith wrote on 22 dec 2011 in comp.lang.javascript:

>
> "Evertjan." <> wrote in message
> news:Xns9FC3CECB6351Eeejj99@194.109.133.133...
>> Mel Smith wrote on 22 dec 2011 in comp.lang.javascript:
>>
>>> (I have a 613-row table that is agonizing to vertically scroll using
>>> the one-finger swiping method)
>>
>> 613??
>>
>> Better think of a more friendly alternative for any browser.
>
>
> Well, I have 613 Homes in my Senior's Park, and a line for each
> home (7 columns), so it works perfectly with a scroll bar


To view 7 fields on a line is not an easy way to view a record.
HTML gives much easier viewable ways of formatting a record.

Why not give the viewer choices of diaplay?

> and a few search
> fields and sorting methods based on Denis McMahon's Javascript methods
> for sorting.

"it works perfectly"?

Your Q shows it does not.

A list of 613 lines can better, IMHO, be devided in smaaler groups, by
first letter or by adress or by age, according to the wishes of the
viewer. Serverside SQL search is perfect for the job.

> So, when a user wishes to got to the bottom (or top) of the table
> (based on 1 of 4 different sorting columns/methods),
> a quick slide of the scroll bar is easy.

Only in certain browsers perhaps, as your Q shows.

But why should a user want to go to the top or the bottom,
there are much more informative ways to show a selection.

> But, with no Scroll bar, you can wear out your finger *and*
> patience !

Quite, that is also an argument not to use scrolling lists of such
length, there are better ways to show a selection.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan said:

>
> To view 7 fields on a line is not an easy way to view a record.
> HTML gives much easier viewable ways of formatting a record.
>
> Why not give the viewer choices of diaplay?
>
>> and a few search
>> fields and sorting methods based on Denis McMahon's Javascript methods
>> for sorting.
>
> "it works perfectly"?
>
> Your Q shows it does not.
>
> A list of 613 lines can better, IMHO, be devided in smaaler groups, by
> first letter or by adress or by age, according to the wishes of the
> viewer. Serverside SQL search is perfect for the job.
>
>> So, when a user wishes to got to the bottom (or top) of the table
>> (based on 1 of 4 different sorting columns/methods),
>> a quick slide of the scroll bar is easy.
>
> Only in certain browsers perhaps, as your Q shows.

*Certain Browsers * ???

I've tested my table on Safari (for PC's), Chrome, FireFox, Opera, IE 7
and 9. All have scroll bars.

I have an iPad 2, and it is the only one of my tested group that does
not have scroll bars (altho I would assume that other mobile devices may not
have the scroll bars either).




>
> But why should a user want to go to the top or the bottom,
> there are much more informative ways to show a selection.
>
>> But, with no Scroll bar, you can wear out your finger *and*
>> patience !
>
> Quite, that is also an argument not to use scrolling lists of such
> length, there are better ways to show a selection.
>

*of such length* ?!?

You may (or may not) be interested in taking a look at the first page of
my www.frostdelay.com site. THe table on the 1st page has in excess of
*5000* lines and approx 5 columns. This is what I could call 'lengthy'.

The current table I'm working on has 613 rows - a pipsqueak by
comparison. Both of these tables are managed from my CGI server (which is a
C-based executable with a complete and extensive database backend (see
www.whosaway.com) )

Anyway, thanks for the response. My users are very happy with my tables
(thanks to the help from Denis McMahon).

-Mel

Mel Smith wrote on 22 dec 2011 in comp.lang.javascript:

> Evertjan said:
>
>>
>> To view 7 fields on a line is not an easy way to view a record.
>> HTML gives much easier viewable ways of formatting a record.
>>
>> Why not give the viewer choices of diaplay?
>>
>>> and a few search
>>> fields and sorting methods based on Denis McMahon's Javascript
>>> methods for sorting.
>>
>> "it works perfectly"?
>>
>> Your Q shows it does not.
>>
>> A list of 613 lines can better, IMHO, be devided in smaaler groups,
>> by first letter or by adress or by age, according to the wishes of
>> the viewer. Serverside SQL search is perfect for the job.
>>
>>> So, when a user wishes to got to the bottom (or top) of the table
>>> (based on 1 of 4 different sorting columns/methods),
>>> a quick slide of the scroll bar is easy.
>>
>> Only in certain browsers perhaps, as your Q shows.
>
> *Certain Browsers * ???
>
> I've tested my table on Safari (for PC's), Chrome, FireFox, Opera,
> IE 7
> and 9. All have scroll bars.
>
> I have an iPad 2, and it is the only one of my tested group that
> does
> not have scroll bars (altho I would assume that other mobile devices
> may not have the scroll bars either).

But your Q shows you are not happy with only "Safari (for PC's), Chrome,
FireFox, Opera, IE 7 and 9"

So you should listen to yourslef, arguing that some important browsers do
not apply.


>> But why should a user want to go to the top or the bottom,
>> there are much more informative ways to show a selection.
>>
>>> But, with no Scroll bar, you can wear out your finger *and*
>>> patience !
>>
>> Quite, that is also an argument not to use scrolling lists of such
>> length, there are better ways to show a selection.
>>
>
> *of such length* ?!?
>
> You may (or may not) be interested in taking a look at the first
> page of
> my www.frostdelay.com site. THe table on the 1st page has in excess of
> *5000* lines and approx 5 columns. This is what I could call
> 'lengthy'.

I think that you do not give your users optimal posssibilties.

> The current table I'm working on has 613 rows - a pipsqueak by
> comparison. Both of these tables are managed from my CGI server
> (which is a C-based executable with a complete and extensive database
> backend (see www.whosaway.com) )

Any serverside coding can deliver subsets via SQL.

> Anyway, thanks for the response. My users are very happy with my
> tables
> (thanks to the help from Denis McMahon).

I do not understand why the help of Denis McMahon makes your users happy.

The fact that your users are happy can also mean that they are easily
happy, because they do not know html and coding can give much better
readability and subset query selection than the terrible excel-like
layout you probably give them.

It is the task of the programmer [you!?] to make use of the best
possiblities display and selection technique offers, as imho, that is not
doubling Excel with lists od 613 rows, even though this is just the exact
number of commandmants in Jewish law.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Mel Smith, 2011-12-22 22:55:

> Evertjan said:
>
[...]
>> Quite, that is also an argument not to use scrolling lists of such
>> length, there are better ways to show a selection.
>>
>
> *of such length* ?!?

If you assume 60 lines per page on a printout this would be 10(!) pages
or information.

You don't call this a long list?

> You may (or may not) be interested in taking a look at the first page of
> my www.frostdelay.com site. THe table on the 1st page has in excess of
> *5000* lines and approx 5 columns. This is what I could call 'lengthy'.

So what? Because there are more examples of bad presentation of
information this makes your over 600 line long list better?

> The current table I'm working on has 613 rows - a pipsqueak by
> comparison. Both of these tables are managed from my CGI server (which is a
> C-based executable with a complete and extensive database backend (see
> www.whosaway.com) )
>
> Anyway, thanks for the response. My users are very happy with my tables
> (thanks to the help from Denis McMahon).

If your users are happy with those tables anyway - what's your problem?

But *if* you want to find a better way to present 613 lines of
information you *should* consider better ways than just putting 613
lines into a single block.

For example: You could use JavaScript to calculate how much lines fit in
the viewport (without the space for the navigation, header etc.) and
create a pagewise navigation. The navigation sould be kept visible in
the viewport and it would be very helpful to have more than just numbers
- maybe the first letter of the primary sort field.

This way a user could get to *any* point of the data with *one* click
(or tap) and without moving a scrollbar around or swiping on the display.

If you extend this by event handlers to handle the up/down keys to allow
navigating using the keyboard, it would be even more comfortable.




--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

Evertjan, Andrew, and Arno:

Thanks for your comments and Merry Christmas to y'all.

Happy 'Tabling' too !

--
Mel Smith

In comp.lang.javascript message <>, Thu,
22 Dec 2011 11:19:41, Mel Smith <> posted:

> Is there any way using Javascript to force Safari for mobile
>devices to display scroll bars beside a table when vertical content
>overflows ?
>
> (I have a 613-row table that is agonizing to vertically scroll using the
>one-finger swiping method)

If space permits, you could show buttons to move up/down by, say, +/-100
& +-10 lines, which may well be less painful.

If searching through a list of names, you could also shift by +-1 place
in the first letter (max +-13, if it rolls A-Z Z-A, then +-1 in the
second letter. It might or might not help to skip absent combinations
(few names begin Qg, for example).

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

Dr J R Stockton wrote on 23 dec 2011 in comp.lang.javascript:

> In comp.lang.javascript message <>,
> Thu, 22 Dec 2011 11:19:41, Mel Smith <>
> posted:
>
>> Is there any way using Javascript to force Safari for mobile
>>devices to display scroll bars beside a table when vertical content
>>overflows ?
>>
>> (I have a 613-row table that is agonizing to vertically scroll
>> using the
>>one-finger swiping method)
>
> If space permits, you could show buttons to move up/down by, say,
> +/-100 & +-10 lines, which may well be less painful.
>
> If searching through a list of names, you could also shift by +-1
> place in the first letter (max +-13, if it rolls A-Z Z-A, then +-1 in
> the second letter. It might or might not help to skip absent
> combinations (few names begin Qg, for example).

This is only true if you think the user just wants to scan visually
though the "list", like a paper phone-book we once used long ago,
and which excel-lovers still want to implement.

Scripting, imho serverside, can and should do better.

Methinks the user also or primarily wants to view a single entry or a
subgroup of entries with a common feature, like street-address or
agegroup or last-name.

So give the user some selective options on the individual fields or even
on a combination of fields or perhaps a substring on any field.

The programmer should not just ask what the user wants, but offer him or
her solutions never dreamed of and perferably monitor what of those
solutions are in fact used. The programmer should act upon the monitoring
by removing the not used ones or making them more logical to the users
mind.

If the returned subset is small enough, a list is not even a nice way of
showing the results. multiline blocks could be much better readable, if
they fit in one pageview without scrolling.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)