Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #4087 > unrolled thread

know its ipad

Back to article view | Back to comp.lang.javascript

Contents

  know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-12 14:35 +1000
    Re: know its ipad "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-07-12 09:04 +0100
      Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-12 21:19 +1000
        Re: know its ipad 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> - 2011-07-12 13:09 +0100
          Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-13 07:35 +1000
            Re: know its ipad 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> - 2011-07-13 01:00 +0100
              Re: know its ipad 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> - 2011-07-13 01:14 +0100
              Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-13 15:57 +1000
                Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-12 23:29 -0700
                  Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-12 23:31 -0700
                    Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-13 17:25 +1000
                      Re: know its ipad Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-13 12:53 +0200
                      Re: know its ipad David Mark <dmark.cinsoft@gmail.com> - 2011-10-09 18:35 -0700
                        Re: know its ipad dhtml <dhtmlkitchen@gmail.com> - 2011-10-09 22:39 -0700
                          Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-10-10 17:42 +1100
                            Re: know its ipad David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 21:40 -0700
                          Re: know its ipad David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 21:38 -0700
                  Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-13 04:20 -0700
                    Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-13 04:34 -0700
                      Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-13 04:58 -0700
                        Re: know its ipad 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> - 2011-07-13 13:50 +0100
                          Re: know its ipad dhtml <dhtmlkitchen@gmail.com> - 2011-07-13 11:02 -0700
                            Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-13 11:59 -0700
                              Re: know its ipad 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> - 2011-07-13 21:32 +0100
                                Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-13 14:28 -0700
                                  Re: know its ipad 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> - 2011-07-13 23:46 +0100
                                    Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-14 10:01 +1000
                                  Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-13 16:51 -0700
                                    Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-14 02:04 -0700
                                      Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-14 15:11 -0700
                                        Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-14 21:54 -0700
                                          Re: know its ipad Yoda <jorgechamorro@mac.com> - 2011-07-15 03:14 -0700
                                          Re: know its ipad Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-15 13:06 +0100
                                            Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-15 08:14 -0700
                                              Re: know its ipad Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-15 20:00 +0100
                                                Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-15 12:12 -0700
                                                  Re: know its ipad Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-16 01:14 +0100
                                                    Re: know its ipad Jorge <jorge%jorgechamorro.com@gtempaccount.com> - 2011-07-16 08:56 -0700
                                                      Re: know its ipad Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-16 23:07 +0100
                                                        Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-17 16:40 -0700
                                                          Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-18 11:33 +1000
                                                            Re: know its ipad RobG <rgqld@iinet.net.au> - 2011-07-17 19:54 -0700
                                                              Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-18 02:19 -0700
                                                            Re: know its ipad Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-18 21:41 +0200
                                                              Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-19 07:13 +1000
                                                            Re: know its ipad Dr J R Stockton <reply1129@merlyn.demon.co.uk> - 2011-07-19 20:18 +0100
                                        Re: know its ipad Arno Welzel <usenet@arnowelzel.de> - 2011-07-17 10:34 +0200
                                          Re: know its ipad David Mark <dmark.cinsoft@gmail.com> - 2011-10-09 19:02 -0700
                                            Re: know its ipad Arno Welzel <usenet@arnowelzel.de> - 2011-10-10 13:49 +0200
                                              Re: know its ipad David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 21:56 -0700
                                Re: know its ipad dhtml <dhtmlkitchen@gmail.com> - 2011-07-15 09:56 -0700
                                Re: know its ipad David Mark <dmark.cinsoft@gmail.com> - 2011-10-09 18:48 -0700
                Re: know its ipad Arno Welzel <usenet@arnowelzel.de> - 2011-07-13 11:57 +0200
                Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-13 04:13 -0700
          Re: know its ipad Dr J R Stockton <reply1128@merlyn.demon.co.uk> - 2011-07-13 18:19 +0100
            Re: know its ipad "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-07-14 08:12 +0000
        Re: know its ipad Richard Cornford <Richard@litotes.demon.co.uk> - 2011-07-13 08:05 -0700
          Re: know its ipad Andrew Poulos <ap_prog@hotmail.com> - 2011-07-14 08:34 +1000
    Re: know its ipad Elegie <elegie@anonymous.invalid> - 2011-07-12 10:13 +0200
    Re: know its ipad Ry Nohryb <jorge@jorgechamorro.com> - 2011-07-12 04:19 -0700
    Re: know its ipad Bjoern Hoehrmann <bjoern@hoehrmann.de> - 2011-07-12 13:24 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#4258

On 18/07/2011 9:40 AM, RobG wrote:
> On Jul 17, 8:07 am, Ben Bacarisse<ben.use...@bsb.me.uk>  wrote:
>> Jorge<jorge%jorgechamorro....@gtempaccount.com>  writes:
>>> On 16 jul, 02:14, Ben Bacarisse<ben.use...@bsb.me.uk>  wrote:
>>
>>>> It was a fail for two reasons: (1) The separation was not done properly in
>>>> that the desktop version kept reverting to the iPad version on a link
>>>> clink.  (2) Doing it well means getting both sites right and that was
>>>> not done.
>>
>>> Well separated because m.thenextweb.com is a totally different thing
>>> than thenextweb.com. Whether the actual pages work or not, has nothing
>>> to do with it.
>>
>> Agreed.  The flaw in the separation is not related to the fact that one
>> version of the site does not work.  Of course, it could be that what I
>> see as failed separation is deliberate -- I can't be sure what the
>> intent was.
>>
>> The bottom line for me is that I can't see what is it that is being
>> touted as good about this site?  It seems to be broken for people
>> visiting with certain devices, and that can't be considered a success
>> can it?  I was not weighing into the argument about whether serving
>> device-specific content is the right thing to do, I was commenting on
>> what appeared to be a suggestion of how to do it well.
>
> It may well be that had they not divided their resources, they might
> have been able to produce one good site rather than two awful ones
> (though I think there is also an iPod Touch version too).
>
> In any case, the fact that people make different versions of a site
> does not, of itself, make it a good idea. And where different versions
> are indicated (or at least, different UIs) to meet user requirements,
> it does not seem appropriate to force a particular version of a site
> onto a user because of the device they happen to be using, even if you
> can determine that reliably.

I've worked at companies where they've tried to retrofit assistive 
elements to a web site to make it "fully" accessible. The work was many 
times what it took to build the non-accessible site and placed a 
cognitive load on the users that relied on assistive technologies so 
large that the site was basically unusable for them.

In my opinion a smarter thing to do would've been to have designed a new 
web site with the user that requires assistive technologies as the 
primary user. Yes, it would've meant maintaining the "same" content in 
two different places but *all* users would've had a web site that best 
suited them.

Moving the logic on, this would mean a desktop version, an accessible 
desktop version, a mobile version, and an accessible mobile version. 
Four versions of the same web site!

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#4260

On Jul 18, 11:33 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
[...]
> I've worked at companies where they've tried to retrofit assistive
> elements to a web site to make it "fully" accessible. The work was many
> times what it took to build the non-accessible site and placed a
> cognitive load on the users that relied on assistive technologies so
> large that the site was basically unusable for them.
>
> In my opinion a smarter thing to do would've been to have designed a new
> web site with the user that requires assistive technologies as the
> primary user. Yes, it would've meant maintaining the "same" content in
> two different places but *all* users would've had a web site that best
> suited them.
>
> Moving the logic on, this would mean a desktop version, an accessible
> desktop version, a mobile version, and an accessible mobile version.
> Four versions of the same web site!

It is a business decision as to how to meet user requirements based on
the costs and benefits of proposed solutions. If the chosen solution
requires the development different UIs, then fine.

But the issue here is how to make the versions available. It doesn't
make sense to me to limit access based on sniffing particular devices,
when there are so many other variables in the decision of which UI to
use and where the range of devices accessing the site may be way
beyond what was envisaged.

It goes back to the fundamentals of why browser sniffing was a bad
idea. It's still a bad idea for all the same reasons, the two main
ones being that you can't necessarily determine a user's requirements
based on the device they are using, nor can you determine reliablly
*every* device that might access the site.

If different versions are available, let the user decide which one
they want.


--
Rob

[toc] | [prev] | [next] | [standalone]

#4270

X-No-Archive: Yes

On Jul 18, 4:54 am, RobG <rg...@iinet.net.au> wrote:
>
> But the issue here is how to make the versions available. It doesn't
> make sense to me to limit access based on sniffing particular devices,

"Limit access" ? No. Serve the best page for his device, yes.

> when there are so many other variables in the decision of which UI to
> use and where the range of devices accessing the site may be way
> beyond what was envisaged.
>
> It goes back to the fundamentals of why browser sniffing was a bad
> idea. It's still a bad idea for all the same reasons,

I disagree, it's simply the faster/easier/better way to detect an iOS
device.

> the two main
> ones being that you can't necessarily determine a user's requirements
> based on the device they are using,

Of course you can once you know, say, that it's an iPhone and not a
shitty netbook.

> nor can you determine reliablly
> *every* device that might access the site.

Nothing is perfect.

The tens (or hundreds) of inferences and dead js code/styles/markup
you want to put and serve in a single file just for the sake of mixing
it up all is a much worse idea yet.
--
Jorge.

[toc] | [prev] | [next] | [standalone]

#4303

Andrew Poulos wrote:

> RobG wrote:
>> In any case, the fact that people make different versions of a site
>> does not, of itself, make it a good idea. And where different versions
>> are indicated (or at least, different UIs) to meet user requirements,
>> it does not seem appropriate to force a particular version of a site
>> onto a user because of the device they happen to be using, even if you
>> can determine that reliably.
> 
> I've worked at companies where they've tried to retrofit assistive
> elements to a web site to make it "fully" accessible. The work was many
> times what it took to build the non-accessible site and placed a
> cognitive load on the users that relied on assistive technologies so
> large that the site was basically unusable for them.
> 
> In my opinion a smarter thing to do would've been to have designed a new
> web site with the user that requires assistive technologies as the
> primary user.

ACK

> Yes, it would've meant maintaining the "same" content in two different
> places but *all* users would've had a web site that best suited them.
> 
> Moving the logic on, this would mean a desktop version, an accessible
> desktop version, a mobile version, and an accessible mobile version.
> Four versions of the same web site!

No.  I'm afraid you do not really know what you are talking about, but Web 
authoring is off-topic here anyway.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#4311

On 19/07/2011 5:41 AM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> RobG wrote:
>>> In any case, the fact that people make different versions of a site
>>> does not, of itself, make it a good idea. And where different versions
>>> are indicated (or at least, different UIs) to meet user requirements,
>>> it does not seem appropriate to force a particular version of a site
>>> onto a user because of the device they happen to be using, even if you
>>> can determine that reliably.
>>
>> I've worked at companies where they've tried to retrofit assistive
>> elements to a web site to make it "fully" accessible. The work was many
>> times what it took to build the non-accessible site and placed a
>> cognitive load on the users that relied on assistive technologies so
>> large that the site was basically unusable for them.
>>
>> In my opinion a smarter thing to do would've been to have designed a new
>> web site with the user that requires assistive technologies as the
>> primary user.
>
> ACK
>
>> Yes, it would've meant maintaining the "same" content in two different
>> places but *all* users would've had a web site that best suited them.
>>
>> Moving the logic on, this would mean a desktop version, an accessible
>> desktop version, a mobile version, and an accessible mobile version.
>> Four versions of the same web site!
>
> No.  I'm afraid you do not really know what you are talking about, but Web
> authoring is off-topic here anyway.

Its alright, don't be afraid.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#4345

In comp.lang.javascript message <-MOdneCk57L9EL7TnZ2dnUVZ_t2dnZ2d@westne
t.com.au>, Mon, 18 Jul 2011 11:33:12, Andrew Poulos
<ap_prog@hotmail.com> posted:

>
>In my opinion a smarter thing to do would've been to have designed a
>new web site with the user that requires assistive technologies as the
>primary user. Yes, it would've meant maintaining the "same" content in
>two different places but *all* users would've had a web site that best
>suited them.
>
>Moving the logic on, this would mean a desktop version, an accessible
>desktop version, a mobile version, and an accessible mobile version.
>Four versions of the same web site!


If the content is maintained in more than one place, then the different
versions will diverge, unless much care is taken.

Maintain the shared visible content in a single location, with each part
being annotated to show which goes where in which (one or more) of the
reader-facing versions.  Each part has a list of IDs.

Have a program which reads that file, and uses it to load the visible
content into the skeletons of the versions, using the IDs.

Fundamentally, that's a database-type solution, but not needing formal
database software.

If authoring in Windows, the program could well be in WSH JavaScript.

If tools other than what qualify a person to write here are lacking, it
_could_ all be done in browser JavaScript apart from one final
copy'n'paste per version.  An HTA may not need that.

-- 
 (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk  BP7, Delphi 3 & 2006.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
   <http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
   NOT <http://support.codegear.com/newsgroups/>: news:borland.* Guidelines

[toc] | [prev] | [next] | [standalone]

#4243

Am 2011-07-15 00:11, schrieb Ry Nohryb:

> On Jul 14, 11:04 am, Ry Nohryb <jo...@jorgechamorro.com> wrote:
>> On Jul 14, 1:51 am, RobG <rg...@iinet.net.au> wrote:
>>
>>> (...)
>>> It really is quite simple. Try the following site:
>>
>>> <URL:http://www.seabreeze.com.au/graphs/qld2.asp>
>>> (...)
>>> That site was designed before touch devices were widely available
>>> (perhaps before they were available at all), yet maintains its
>>> functionality on various devices.
>>
>> Agreed, yes indeed, that's a page designed for a desktop that (barely)
>> functions on an iPhone, but it's far away from the best possible
>> experience for mobile users.
> 
> To see what I mean, go, for example, to <http://thenextweb.com> with a
> desktop browser, and then with an iPad.

A good example for a really bad design. Of course you must provide an
alternative version for mobile devices in this case.

The "desktop" version uses a fixed page width wich will not fit to 1024
pixels horizontally. It makes sense to limit the width of text, but the
layout should still allow smaller screens too.

The "desktop" version consist of dozens of single CSS and JSON files and
about 2.4 MB of data and thenextweb.com doesn't support compression.


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

[toc] | [prev] | [next] | [standalone]

#7160

On Sunday, July 17, 2011 4:34:33 AM UTC-4, Arno Welzel wrote:
> Am 2011-07-15 00:11, schrieb Ry Nohryb:
> 
> > On Jul 14, 11:04 am, Ry Nohryb <jo...@jorgechamorro.com> wrote:
> >> On Jul 14, 1:51 am, RobG <rg...@iinet.net.au> wrote:
> >>
> >>> (...)
> >>> It really is quite simple. Try the following site:
> >>
> >>> <URL:http://www.seabreeze.com.au/graphs/qld2.asp>
> >>> (...)
> >>> That site was designed before touch devices were widely available
> >>> (perhaps before they were available at all), yet maintains its
> >>> functionality on various devices.
> >>
> >> Agreed, yes indeed, that's a page designed for a desktop that (barely)
> >> functions on an iPhone, but it's far away from the best possible
> >> experience for mobile users.
> > 
> > To see what I mean, go, for example, to <http://thenextweb.com> with a
> > desktop browser, and then with an iPad.
> 
> A good example for a really bad design. Of course you must provide an
> alternative version for mobile devices in this case.

Not necessarily, though bad designs do sometimes require multiple sites for the same content.

> 
> The "desktop" version uses a fixed page width wich will not fit to 1024
> pixels horizontally. It makes sense to limit the width of text, but the
> layout should still allow smaller screens too.

Won't even fit at 1024x768 resolution with browser maximized? Guess the developer has a large monitor at high resolution and figured everybody else is just like them. :)

Though I don't care much for fixed-width layout designs, the ad agencies use them exclusively (as well as jQuery + plugins). That's just how they want them (and they don't write JS). So first two steps are to add media query/handheld CSS for a narrower (but usually still fixed) width and to remove jQuery scripts. The threshold width varies per layout. I usually test on the desktop with Chrome (using queries based on viewport rather than device width).

Unfortunately, the norm seems to be to throw the agency files up on the server as is and hope for the best.

> 
> The "desktop" version consist of dozens of single CSS and JSON files and
> about 2.4 MB of data and thenextweb.com doesn't support compression.

Can't fix that (other than the compression). Start again. :(

[toc] | [prev] | [next] | [standalone]

#7174

David Mark, 2011-10-10 04:02:

> On Sunday, July 17, 2011 4:34:33 AM UTC-4, Arno Welzel wrote:
>> Am 2011-07-15 00:11, schrieb Ry Nohryb:
>>
>>> On Jul 14, 11:04 am, Ry Nohryb <jo...@jorgechamorro.com> wrote:
>>>> On Jul 14, 1:51 am, RobG <rg...@iinet.net.au> wrote:
>>>>
>>>>> (...)
>>>>> It really is quite simple. Try the following site:
>>>>
>>>>> <URL:http://www.seabreeze.com.au/graphs/qld2.asp>
>>>>> (...)
>>>>> That site was designed before touch devices were widely available
>>>>> (perhaps before they were available at all), yet maintains its
>>>>> functionality on various devices.
>>>>
>>>> Agreed, yes indeed, that's a page designed for a desktop that (barely)
>>>> functions on an iPhone, but it's far away from the best possible
>>>> experience for mobile users.
>>>
>>> To see what I mean, go, for example, to <http://thenextweb.com> with a
>>> desktop browser, and then with an iPad.
>>
>> A good example for a really bad design. Of course you must provide an
>> alternative version for mobile devices in this case.
> 
> Not necessarily, though bad designs do sometimes require multiple sites for the same content.

Well - this is, how i define "bad" ;-) A good design should not require
different sites for different devices. Only for "extreme" cases - e.g.
display on the small screen of a mobile phone with just 240 x 320 or 320
x 480 pixels may need a "mobile" version. But an iPad ist way off these
limits - according to <http://www.apple.com/ipad/specs/> it offers 1024
x 768 pixels.

Well - designing elements to be handled easier with a touch interface
may be the point here - but then again it should not be assumed that
every touch device is iPad-like with a specific resolution. Android
exists as well and 800 x 480 is also a very common value.

[...]
>> The "desktop" version consist of dozens of single CSS and JSON files and
>> about 2.4 MB of data and thenextweb.com doesn't support compression.
> 
> Can't fix that (other than the compression). Start again. :(

Compression seems to work now - now just around 1 MB to load. Well...
still a lot, but better than nothing.


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

[toc] | [prev] | [next] | [standalone]

#7191

On Oct 10, 7:49 am, Arno Welzel <use...@arnowelzel.de> wrote:
> David Mark, 2011-10-10 04:02:
>
>
>
>
>
>
>
>
>
> > On Sunday, July 17, 2011 4:34:33 AM UTC-4, Arno Welzel wrote:
> >> Am 2011-07-15 00:11, schrieb Ry Nohryb:
>
> >>> On Jul 14, 11:04 am, Ry Nohryb <jo...@jorgechamorro.com> wrote:
> >>>> On Jul 14, 1:51 am, RobG <rg...@iinet.net.au> wrote:
>
> >>>>> (...)
> >>>>> It really is quite simple. Try the following site:
>
> >>>>> <URL:http://www.seabreeze.com.au/graphs/qld2.asp>
> >>>>> (...)
> >>>>> That site was designed before touch devices were widely available
> >>>>> (perhaps before they were available at all), yet maintains its
> >>>>> functionality on various devices.
>
> >>>> Agreed, yes indeed, that's a page designed for a desktop that (barely)
> >>>> functions on an iPhone, but it's far away from the best possible
> >>>> experience for mobile users.
>
> >>> To see what I mean, go, for example, to <http://thenextweb.com> with a
> >>> desktop browser, and then with aniPad.
>
> >> A good example for a really bad design. Of course you must provide an
> >> alternative version for mobile devices in this case.
>
> > Not necessarily, though bad designs do sometimes require multiple sites for the same content.
>
> Well - this is, how i define "bad" ;-) A good design should not require
> different sites for different devices. Only for "extreme" cases - e.g.
> display on the small screen of a mobile phone with just 240 x 320 or 320
> x 480 pixels may need a "mobile" version. But aniPadist way off these
> limits - according to <http://www.apple.com/ipad/specs/> it offers 1024
> x 768 pixels.
>
> Well - designing elements to be handled easier with a touch interface
> may be the point here - but then again it should not be assumed that
> every touch device isiPad-like with a specific resolution. Android
> exists as well and 800 x 480 is also a very common value.

Media queries + handheld style sheets have always worked for me (the
latter dating back many years). Narrower columns (or no columns), more
padding on buttons, etc.

>
> [...]
>
> >> The "desktop" version consist of dozens of single CSS and JSON files and
> >> about 2.4 MB of data and thenextweb.com doesn't support compression.
>
> > Can't fix that (other than the compression). Start again. :(
>
> Compression seems to work now - now just around 1 MB to load. Well...
> still a lot, but better than nothing.

Don't know what it is, but it sounds too huge to bother with. 1MB for
a Web page is ridiculous. Doesn't matter how fast the phones get
(issue is not just about download time), there will be other forms of
lesser agents to replace them as the LCD browsing experience. In other
words, if current trends continue, when wristwatch browsers (or
whatever) become popular, we'll see sites sprout third versions
optimized for wrist viewing. Then we'll see jQuery for watches, Sencha
Watch, etc. Developers need to break this cycle or the Web will become
less relevant each year. There's too much time being spent repeating
the same old mistakes. Ironic considering the emphasis placed on not
repeating ourselves.

The Next Web indeed. :) Wonder how much of that 1MB is appalling and
dated JS code.

[toc] | [prev] | [next] | [standalone]

#4217

On Jul 13, 1:32 pm, 123Jim <jnkjnjn...@uhnuhnunuhnuy.invalid> wrote:
> On 13/07/2011 19:59, Ry Nohryb wrote:
> .................................................................<SNIPPED>
>
>
>
> > The iPhone 4 has 2x the resolution of an iPhone 2G/3G/3GS, but no
> > sites have needed any modifications, so what ?
>
If a meta viewport is used with an absolute pixel value for a pre-
retina display, then a retina display will scale it up, using twice as
many pixels. That means that images get scaled up, too.

I have heard of sites targeted for iPhone prior to retina display
(retina came in iPhone 4) using small images. These small images got
zoomed, resulting in images having lower resolution in retina display
devices.


> > The point is: a small screen + no mouse ->  radically different user
> > interface + site/page layout + programming.
>
> I don't buy it ... a finger is pretty much like a mouse pointer .. only
> you can see better with a mouse pointer depending on how fat those
> fingers might be.
>
I don't buy it either. I've run into cases in iPhone that needed to be
addressed for the cross-browser site.

The most recent odd case I ran into was iPhone's JPEG EXIF rotation
header. The image looked rotated on the page in iPhone, yet in any
other browser, it was not rotated. I ended up using The Gimp to remove
the EXIF headers, resulting in the desired image at a fraction of the
size.

>
>
> > And a mobile device is battery powered: don't use setTimeout/
> > setInterval()s in tight loops, unless you want your page/site to drain
> > the phone's battery (as JQuery does).
>
> > So yes, programming (a web page/application) for a mobile/tablet is
> > very different than programming for a desktop.
> > --
>
> Are you suggesting iPad users surfing the web live in fear of stumbling
> on a website that uses wasteful power hungry Javascripts? .. It's a poor
> device if that is the case.

Try an older BlackBerry device w/BlackBerry browser -- that's bad.

Since around 2006 or so I have seen more sites that use a lot of very
inefficient javascript, such as using polling XHRs or using a popular
library resulting in a lot of unused code as well as a lot of long
chains of function calls. Such sites cause churn on MBP running FF5.
--
Garrett

[toc] | [prev] | [next] | [standalone]

#7159

On Wednesday, July 13, 2011 4:32:22 PM UTC-4, 123Jim wrote:
> On 13/07/2011 19:59, Ry Nohryb wrote:
> .................................................................<SNIPPED>
> >
> > The iPhone 4 has 2x the resolution of an iPhone 2G/3G/3GS, but no
> > sites have needed any modifications, so what ?
> >
> > The point is: a small screen + no mouse ->  radically different user
> > interface + site/page layout + programming.
> 
> I don't buy it ... a finger is pretty much like a mouse pointer .. only 
> you can see better with a mouse pointer depending on how fat those 
> fingers might be.

Correct and Jorge shouldn't be selling it; but some things never change.

> 
> >
> > And a mobile device is battery powered: don't use setTimeout/
> > setInterval()s in tight loops, unless you want your page/site to drain
> > the phone's battery (as JQuery does).
> >
> > So yes, programming (a web page/application) for a mobile/tablet is
> > very different than programming for a desktop.

Wrong.

> > --
> 
> Are you suggesting iPad users surfing the web live in fear of stumbling 
> on a website that uses wasteful power hungry Javascripts? .. It's a poor 
> device if that is the case.

He's just wrong, as usual. But I don't get your point about the wasteful scripts. Using the Web on an Android over 3G sucks (e.g. stalls, freezes, crashes) and JS abuse is certainly a big part of the problem.

Thank goodness for native apps; though those often freeze and crash too (especially the browsers), they are snappy when they work and leverage all of the device extras (e.g. multi-touch gestures) effortlessly.

Trying to make app-like Websites is just silly. Redirecting users to such alternate sites based on their UA string is ridiculous. The ultimate in futility is redirecting from one bloated jQuery (or whatever) site to one that uses XHR to load content and faux navigation (e.g. anything based on jQuery touch, mobile or whatever). See a lot of that these days. :(

[toc] | [prev] | [next] | [standalone]

#4134

Am 2011-07-13 07:57, schrieb Andrew Poulos:

> On 13/07/2011 10:00 AM, 123Jim wrote:
>> On 12/07/2011 22:35, Andrew Poulos wrote:
>>> On 12/07/2011 10:09 PM, 123Jim wrote:
>>>> On 12/07/2011 12:19, Andrew Poulos wrote:
>>>>> On 12/07/2011 6:04 PM, Richard Cornford wrote:
>>>>>> Andrew Poulos wrote:
>>>>>>> How can I know if a web page is running on an iPad without
>>>>>>> parsing navigator.platform (ie. without browser sniffing)?
>> ..............................
>>>>
>>>> Create your pages Using percentage for display width, limit it with
>>>> max-width in pixels, make your layout fluid if necessary. Use a strict
>>>
>>> That's one of the issues. What maximum pixel width: 1024, 980 or 768?
>>>
>>
>>
>> Take a look at the templates here:
>> http://www.cssliquid.com/
>>
>> Fluid design allows your page to look good and be functional with many
>> different screen resolutions.
> 
> Liquid design works well for text-based pages but what do you do with 
> images. Do you allow them to scale?

For my personal site I allow the images to scale by using a "max-width:
100%;" - e.g.:

<http://arnowelzel.de/wiki/en/fli4l/stats>
<http://arnowelzel.de/wiki/en/reviews/samsung_nc10>

This way, the images get scaled down, if the viewport is too small.



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

[toc] | [prev] | [next] | [standalone]

#4136

On Jul 13, 7:57 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
>
> Anyhow the issue is not the visual design on the pages but that I need
> to activate events like touch but only on devices where it makes sense.

It's not only touch events. iPads/iPhones require a totally different
site (in terms of page layout & programming) than desktop PCs with
mice, flash, resizeable windows, big screens, in-browser sound and
video, unlimited power supply, lots of memory, etc ...

The sooner you realize that, the better.

You'll want to branch asap: just use browser sniffing, or put a big
"iPad/iPod/iPhone/iOS/mobile version" button somewhere in the page,
and be prepared to serve a totally different thing.
--
Jorge.

[toc] | [prev] | [next] | [standalone]

#4152

In comp.lang.javascript message <ivhdh7$sq8$1@dont-email.me>, Tue, 12
Jul 2011 13:09:08, 123Jim <jnkjnjnini@uhnuhnunuhnuy.invalid> posted:


>>> Andrew Poulos wrote:
>>>> How can I know if a web page is running on an iPad without
>>>> parsing navigator.platform (ie. without browser sniffing)?

>Create your pages Using percentage for display width, limit it with
>max-width in pixels, make your layout fluid if nescesarry. Use a strict
>doctype to improve consistancy between different browsers.

That's not answering Andrew's question.  But those using that approach
might be interested in what <http://www.merlyn.demon.co.uk/www-use1.htm>
has to say about Zoom Text Only, and perhaps to comment on it.

However, the maximum width in px should not normally be hard-limited.
Consider wee Hamish MsSporran, who has a 2048*2560 screen, and whose
bat-eyed Grandpa McCaber wants to read the curling results on it.  But
he might know about Zoom.  But he might not know about Zoom Text Only.

In particular, some people do not seem to know that, while loaded IMG
elements have an internal size in pixels, and can be re-sized in px,
they can also with CSS be re-sized in em & ex, using computed values.


Andrew, you could perhaps without being too obtrusive include a set of
radio-buttons, setting made sticky with cookies, for the reader to
select device type.  Allowing a choice gives flexibility.

-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike v6.05  MIME.
  Web  <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
  Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
 No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[toc] | [prev] | [next] | [standalone]

#4157

Dr J R Stockton wrote on 13 jul 2011 in comp.lang.javascript:

> Andrew, you could perhaps without being too obtrusive include a set of
> radio-buttons, setting made sticky with cookies, for the reader to
> select device type.  Allowing a choice gives flexibility.
> 

Sticky cookies are a bad idea on touchscreens,
they make such a mess.

John, you might want to add this link to your new Date() page:

<http://www.grouprecipes.com/90262/sticky-date-cookies.html>

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

[toc] | [prev] | [next] | [standalone]

#4145

On Jul 12, 12:19 pm, Andrew Poulos wrote:
> On 12/07/2011 6:04 PM, Richard Cornford wrote:
>> Andrew Poulos wrote:
>>> How can I know if a web page is running on an iPad without
>>> parsing navigator.platform (ie. without browser sniffing)?
>
>> Start by understanding why you care. The reason for caring
>> will allow you to narrow in on which aspect of the difference
>> between 'running on an iPad' and 'not running on an iPad' is
>> actually relevant to you, and so the thing that should be the
>> subject of a pertinent test.
>
> Rather than have multiple "mini" branches (which have been working
> fine for years) like
>
> e = e || windows.event

Which has nothing to do with the environment being an iPad or not.

> I want to one branch to a separate block of code that I can
> code/test without having to simultaneously deal with whatever
> issues Android, Windows... etc may bring. So when the client
> says, "this needs to work on an iPad" I can be confident it
> does.

This is a code design/architecture issue. It sounds like you are
planning on going in a direction that (I and) many others have state
off in in the past, and recognised as a bad idea and abandoned
entirely. Trying to completely separate out the code for various
browsers multiples the writing/maintenance effort by the (now rigidly
fixed) number of browsers supported/tested (which is bad) while doing
very little to ease the effort needed for testing.

A hypothetical discussion of approaches to code architecture in
javascript/browser scripting is far too time consuming for me to
attempt at the moment. But in any event the concepts involved are
probably better expounded in the context of specific examples/
problems, which we don't have here.

> My clients "know" about web development and are expecting
> that development that includes the iPad and other mobile devices
> to be relatively straightforward when in fact I'm struggling. For
> example, why is it that:
>
> 1. Apple says the iPad screen resolution is 1024 x 768
>
> 2. designing as 980 x 660 appears to fit appropriately. The page
> has this meta element:
> <meta name="viewport" content="width=device-width">
>
> 3. window.innerWidth/Height returns 768 x 518

Saying 1024 x 768 sounds like a landscape orientation. Looking at
Apple's page on the subject of META elements (inevitably called META
Tags on that page) says:-

<URL: http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
>

| You do not need to set every viewport property. If only a subset of
| the properties are set, then Safari on iOS infers the other values.
| For example, if you set the scale to 1.0, Safari assumes the width
| is device-width in portrait and device-height in landscape
| orientation. Therefore, if you want the width to be 980 pixels and
| the initial scale to be 1.0, then set both of these properties.

- which makes it look like device-width always refers to the width
in prorate mode (768 pixels), and device-height the height in
portrait mode (1024 pixels). So it looks like your META element
is asking for a wewport width of 768 and getting it (and a
corresponding landscape mode height), and then possibly Safari
is then scaling that viewport to fit the available screen space.

Richard.

[toc] | [prev] | [next] | [standalone]

#4151

On 14/07/2011 1:05 AM, Richard Cornford wrote:
> On Jul 12, 12:19 pm, Andrew Poulos wrote:
>> On 12/07/2011 6:04 PM, Richard Cornford wrote:
>>> Andrew Poulos wrote:
>>>> How can I know if a web page is running on an iPad without
>>>> parsing navigator.platform (ie. without browser sniffing)?
>>
>>> Start by understanding why you care. The reason for caring
>>> will allow you to narrow in on which aspect of the difference
>>> between 'running on an iPad' and 'not running on an iPad' is
>>> actually relevant to you, and so the thing that should be the
>>> subject of a pertinent test.
>>
>> Rather than have multiple "mini" branches (which have been working
>> fine for years) like
>>
>> e = e || windows.event
>
> Which has nothing to do with the environment being an iPad or not.
>
>> I want to one branch to a separate block of code that I can
>> code/test without having to simultaneously deal with whatever
>> issues Android, Windows... etc may bring. So when the client
>> says, "this needs to work on an iPad" I can be confident it
>> does.
>
> This is a code design/architecture issue. It sounds like you are
> planning on going in a direction that (I and) many others have state
> off in in the past, and recognised as a bad idea and abandoned
> entirely. Trying to completely separate out the code for various
> browsers multiples the writing/maintenance effort by the (now rigidly
> fixed) number of browsers supported/tested (which is bad) while doing
> very little to ease the effort needed for testing.
>
> A hypothetical discussion of approaches to code architecture in
> javascript/browser scripting is far too time consuming for me to
> attempt at the moment. But in any event the concepts involved are
> probably better expounded in the context of specific examples/
> problems, which we don't have here.
>
>> My clients "know" about web development and are expecting
>> that development that includes the iPad and other mobile devices
>> to be relatively straightforward when in fact I'm struggling. For
>> example, why is it that:
>>
>> 1. Apple says the iPad screen resolution is 1024 x 768
>>
>> 2. designing as 980 x 660 appears to fit appropriately. The page
>> has this meta element:
>> <meta name="viewport" content="width=device-width">
>>
>> 3. window.innerWidth/Height returns 768 x 518
>
> Saying 1024 x 768 sounds like a landscape orientation. Looking at
> Apple's page on the subject of META elements (inevitably called META
> Tags on that page) says:-
>
> <URL: http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
>>
>
> | You do not need to set every viewport property. If only a subset of
> | the properties are set, then Safari on iOS infers the other values.
> | For example, if you set the scale to 1.0, Safari assumes the width
> | is device-width in portrait and device-height in landscape
> | orientation. Therefore, if you want the width to be 980 pixels and
> | the initial scale to be 1.0, then set both of these properties.
>
> - which makes it look like device-width always refers to the width
> in prorate mode (768 pixels), and device-height the height in
> portrait mode (1024 pixels). So it looks like your META element
> is asking for a viewport width of 768 and getting it (and a
> corresponding landscape mode height), and then possibly Safari
> is then scaling that viewport to fit the available screen space.

That's interesting I didn't realise that it might always refer to 
portrait mode.

Apple provides this bit of advice
<http://developer.apple.com/library/safari/#technotes/tn2010/tn2262/_index.html>
and unfortunately doesn't give much.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#4089

On 12/07/2011 06:35, Andrew Poulos wrote :

Hi Andrew,

> How can I know if a web page is running on an iPad without parsing
> navigator.platform (ie. without browser sniffing)?

There seems to be a logical issue here. You want to find an iPad, yet 
you do not want to look for it :)

Browser detection is simply a technique, in itself it is neither right 
nor wrong, only its usage can be. Historically, people would use browser 
detection because they wanted to make sure that the host would support 
the features they had to run; this, however, appeared to be unsafe 
(because browser detection is never 100% certain), inflexible (because 
new browsers' families and versions would spawn regularly) and awkward 
(because javascript allows to directly detect features). Yet, this does 
not mean you cannot have fair uses for browser detection.

More dangerous was browser-inference with feature-testing. We have seen 
people trying to identify the host by testing the host features. This 
made less sense than browser detection: if you can assert that a feature 
is available, why not just use it?

So, what do you want to do? If you have a specialized design for 
iPad-like devices, then I would recommend to simply add a link on the 
standard design page, to let the user select the specialized design if 
he/she wishes to. In addition, it is also acceptable to parse the user 
agent string and set this design as default if you find out the user 
agent is an iPad (and of course provide a link to the standard design 
page, in case the user wants it).

Regards,
Elegie.

[toc] | [prev] | [next] | [standalone]

#4093

On Jul 12, 6:35 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
> How can I know if a web page is running on an iPad without parsing
> navigator.platform (ie. without browser sniffing)?

You could ask the user :-)

Why don't you want to use navigator.platform but won't mind using
another (less straightforward) object/property/inference ?
--
Jorge.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web