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

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

Change UI layout

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

Contents

  Change UI layout Andrew Poulos <ap_prog@hotmail.com> - 2014-07-02 15:39 +1000
    Re: Change UI layout danca <cyberdanny@tiscalinet.it> - 2014-07-02 10:05 +0200
      Re: Change UI layout Andrew Poulos <ap_prog@hotmail.com> - 2014-07-02 23:27 +1000
        Re: Change UI layout Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-02 15:58 +0200
          Re: Change UI layout Andrew Poulos <ap_prog@hotmail.com> - 2014-07-03 11:36 +1000
            Re: Change UI layout Andrew Poulos <ap_prog@hotmail.com> - 2014-07-03 18:20 +1000
              Re: Change UI layout Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-03 11:42 +0200
            Re: Change UI layout Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-03 10:38 +0200
      Re: Change UI layout Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-07-03 21:51 +0100
        Re: Change UI layout danca <cyberdanny@tiscalinet.it> - 2014-07-04 15:09 +0200
        Re: Change UI layout Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-07-05 16:10 +0100
    Re: Change UI layout Joao Rodrigues <groups_jr-1@yahoo.com> - 2014-07-05 12:58 -0300
      Re: Change UI layout Christoph Michael Becker <cmbecker69@arcor.de> - 2014-07-05 19:31 +0200
        Re: Change UI layout Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-06 23:34 +0200

#25184 — Change UI layout

I have a design that displays well on a desktop monitor. When the design 
is viewed on a "small" screen such as a mobile phone the layout fails in 
that its unreadable (you need to zoom in and scroll about to read the 
content).

My idea for a solution is to dynamically strip the 
nice-to-have/non-essential elements and so give more room to the "real" 
content. Working under the assumption that accurately deciding if a 
screen is small will be problematic I'm thinking that the way forward is 
to put a checkbox on the home page with a checkbox that reads "Mobile".

If the user checks the box the nice-to have elements are removed.

Is this appropriate?

Andrew Poulos

[toc] | [next] | [standalone]

#25186

Il 02/07/2014 08:04, Stefan Ram ha scritto:
> Andrew Poulos <ap_prog@hotmail.com> writes:
>> Is this appropriate?
>
>    The usual approach today is called »Responsive Design«.
>
>    It usually is done with CSS. You use CSS to adapt the
>    page to the screen, like:
>
> @media screen and (max-width:750px) and (min-width:500px)
> { a { width: 50%; }}
> @media screen and (min-width:750px)
> { a { width: 25%; white-space: nowrap; }}
>
>    . Only when CSS alone is not sufficient, one uses JavaScript
>    (»Progressive Enhancement«), along the lines of:
>
> if( window.matchMedia( 'only screen and (max-device-width: 450px)' ).matches )
> ...
> else if
> ( window.matchMedia( 'only screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation: portrait)' ).matches )...
>
>    .
>
I tried a similar approach but it does not seems to be a satisfying 
solution to me.
My Android smartphone declares an horizontal resolution of 940 pixels, 
but obviously a standard page is unreadable on the tiny screen, so I 
actually detect the user agent and automatically redirect the mobile 
devices to a dedicated page, instead of rely on the screen resolution.
An explicit button seems to be the rational choice, however. The iPad is 
identified as a mobile device but the screen is wide enough to display 
standard pages.
Dan

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

#25190

On 2/07/2014 6:05 PM, danca wrote:
> Il 02/07/2014 08:04, Stefan Ram ha scritto:
>> Andrew Poulos <ap_prog@hotmail.com> writes:
>>> Is this appropriate?
>>
>>    The usual approach today is called »Responsive Design«.
>>
>>    It usually is done with CSS. You use CSS to adapt the
>>    page to the screen, like:
>>
>> @media screen and (max-width:750px) and (min-width:500px)
>> { a { width: 50%; }}
>> @media screen and (min-width:750px)
>> { a { width: 25%; white-space: nowrap; }}
>>
>>    . Only when CSS alone is not sufficient, one uses JavaScript
>>    (»Progressive Enhancement«), along the lines of:
>>
>> if( window.matchMedia( 'only screen and (max-device-width: 450px)'
>> ).matches )
>> ...
>> else if
>> ( window.matchMedia( 'only screen and (min-device-width: 481px) and
>> (max-device-width: 1024px) and (orientation: portrait)' ).matches )...
>>
>>    .
>>
> I tried a similar approach but it does not seems to be a satisfying
> solution to me.
> My Android smartphone declares an horizontal resolution of 940 pixels,
> but obviously a standard page is unreadable on the tiny screen, so I
> actually detect the user agent and automatically redirect the mobile
> devices to a dedicated page, instead of rely on the screen resolution.
> An explicit button seems to be the rational choice, however. The iPad is
> identified as a mobile device but the screen is wide enough to display
> standard pages.

I just tested my 3 year old android phone running Chrome and innerWidth 
returns 980 with the phone in landscape mode so I'm leaning towards a 
button as well.

Andrew Poulos

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

#25191

Andrew Poulos wrote:

> On 2/07/2014 6:05 PM, danca wrote:
>> My Android smartphone declares an horizontal resolution of 940 pixels,
>> but obviously a standard page is unreadable on the tiny screen, so I
>> actually detect the user agent and automatically redirect the mobile
>> devices to a dedicated page, instead of rely on the screen resolution.

Bad idea.

>> An explicit button seems to be the rational choice, however. The iPad is
>> identified as a mobile device but the screen is wide enough to display
>> standard pages.
> 
> I just tested my 3 year old android phone running Chrome and innerWidth
> returns 980 with the phone in landscape mode so I'm leaning towards a
> button as well.

There *are* 980px in landscape mode.  Both "detecting" the user agent and 
redirecting, and a button, are wrong, user-unfriendly approaches.  Instead, 
the layout must be so that it does not force zoom-out, i.e. it must not be 
too wide.

The relevance of this thread to this newsgroup approaches 0.  Please find a 
newsgroup where it is on-topic.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25193

On 2/07/2014 11:58 PM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 2/07/2014 6:05 PM, danca wrote:
>>> My Android smartphone declares an horizontal resolution of 940 pixels,
>>> but obviously a standard page is unreadable on the tiny screen, so I
>>> actually detect the user agent and automatically redirect the mobile
>>> devices to a dedicated page, instead of rely on the screen resolution.
>
> Bad idea.
>
>>> An explicit button seems to be the rational choice, however. The iPad is
>>> identified as a mobile device but the screen is wide enough to display
>>> standard pages.
>>
>> I just tested my 3 year old android phone running Chrome and innerWidth
>> returns 980 with the phone in landscape mode so I'm leaning towards a
>> button as well.
>
> There *are* 980px in landscape mode.  Both "detecting" the user agent and

Actually I should've said 980px in portrait mode.

> redirecting, and a button, are wrong, user-unfriendly approaches.  Instead,
> the layout must be so that it does not force zoom-out, i.e. it must not be
> too wide.

Ok. Google found some browser sniffing that was laughing hundreds, if 
not thousands, of characters long.

> The relevance of this thread to this newsgroup approaches 0.  Please find a
> newsgroup where it is on-topic.

Not really. I'm now leaning towards a solution that uses HTML, CSS and 
checking window.matchMedia onload to change the layout appropriately.

Andrew Poulos

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

#25195

On 3/07/2014 11:36 AM, Andrew Poulos wrote:
> On 2/07/2014 11:58 PM, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>
>>> On 2/07/2014 6:05 PM, danca wrote:
>>>> My Android smartphone declares an horizontal resolution of 940 pixels,
>>>> but obviously a standard page is unreadable on the tiny screen, so I
>>>> actually detect the user agent and automatically redirect the mobile
>>>> devices to a dedicated page, instead of rely on the screen resolution.
>>
>> Bad idea.
>>
>>>> An explicit button seems to be the rational choice, however. The
>>>> iPad is
>>>> identified as a mobile device but the screen is wide enough to display
>>>> standard pages.
>>>
>>> I just tested my 3 year old android phone running Chrome and innerWidth
>>> returns 980 with the phone in landscape mode so I'm leaning towards a
>>> button as well.
>>
>> There *are* 980px in landscape mode.  Both "detecting" the user agent and
>
> Actually I should've said 980px in portrait mode.
>
>> redirecting, and a button, are wrong, user-unfriendly approaches.
>> Instead,
>> the layout must be so that it does not force zoom-out, i.e. it must
>> not be
>> too wide.
>
> Ok. Google found some browser sniffing that was laughing hundreds, if
> not thousands, of characters long.
>
>> The relevance of this thread to this newsgroup approaches 0.  Please
>> find a
>> newsgroup where it is on-topic.

PE was right. I "solved" my issue by using CSS media queries (and no js 
at all).

Andrew Poulos

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

#25197

Andrew Poulos wrote:

> On 3/07/2014 11:36 AM, Andrew Poulos wrote:
>> On 2/07/2014 11:58 PM, Thomas 'PointedEars' Lahn wrote:
>>> Andrew Poulos wrote:
>>>> I just tested my 3 year old android phone running Chrome and innerWidth
>>>> returns 980 with the phone in landscape mode so I'm leaning towards a
>>>> button as well.
>>> There *are* 980px in landscape mode.  Both "detecting" the user agent
>>> and
>>
>> Actually I should've said 980px in portrait mode.

Me too.

>>> redirecting, and a button, are wrong, user-unfriendly approaches.
>>> Instead, the layout must be so that it does not force zoom-out, i.e. it
>>> must not be too wide.
>> […]
>>> The relevance of this thread to this newsgroup approaches 0.  Please
>>> find a newsgroup where it is on-topic.
> 
> PE was right. I "solved" my issue by using CSS media queries (and no js
> at all).

Since I was at least partially wrong [1], how exactly did you solve it?

F'up2 ciwa.stylesheets


[1] <news:1851843.LhWb2JNgvM@PointedEars.de>
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25196

[X-Post ciwa.html, ciwa.stylesheets, comp.lang.javascript;
 F'up2 comp.infosystems.www.authoring.html]

Andrew Poulos wrote in <news:comp.infosystems.www.authoring.stylesheets>:

> So I'd hoave to get the DPI and then the screen size to work out the
> physical size of the screen to decide whether that's "small" and then
> change the page's styles accordingly.

Maybe the best solution is neither HTTP, nor CSS or scripting.  I thought 
that it would suffice to set “max-width” or “width” CSS properties, and I 
found older recommendations for @viewport rules on the Web.

But what really worked for me is this “meta” element I found when I emulated 
“HTC Sensation, Evo 3D” (since I own an HTC Sensation) in Chromium 34 on 
<https://twitter.com/>, which redirected me to <http://mobile.twitter.com/>:

<meta name="viewport" id="viewport" content="width=device-width, initial-
scale=1.0, maximum-scale=1.0, user-scalable=0">

In particular

<meta name="viewport" content="width=device-width, initial-scale=1.0">

appears to be working fine for the language selection on my Web site, 
<http://PointedEars.de/>. (I still have to do something about the background 
when content is zoomed, though.)

It would appear that non-mobile browsers ignore this element, so you can 
always include it, and you may not need an extra mobile version in simple 
cases like this.

(It did not work so well for “Home” because it prevented the horizontally 
arranged "links", that I put there particularly for mobile “Features”, from 
being accessible.  And fixed widths like “540px”, unstead of “device-width”, 
prevent the zoom in the built-in Android browser.  So I am not using it 
there for the time being.  Also, setting the viewport width this way may 
trigger @media queries for the screen unintentionally; that happened to me 
as well.)
 
> Then I'd need a bunch of different devices to test on which given
>    <http://cartoonized.net/cellphone-screen-resolution.php>
> will not be easy or even possible.

Please do not play stupid.

<http://www.catb.org/~esr/faqs/smart-questions.html#intro>


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#25200

In comp.lang.javascript message <lp0egh$jhi$1@dont-email.me>, Wed, 2 Jul
2014 10:05:36, danca <cyberdanny@tiscalinet.it> posted:


>My Android smartphone declares an horizontal resolution of 940 pixels,
>but obviously a standard page is unreadable on the tiny screen, so I
>actually detect the user agent and automatically redirect the mobile
>devices to a dedicated page, instead of rely on the screen resolution.
>An explicit button seems to be the rational choice, however. The iPad
>is identified as a mobile device but the screen is wide enough to
>display standard pages.


Do not use just "a" button, if you can do better.  Offer choices such as
(but better name,) Vast, Big, Ordinary, Small, Tiny, Auto-Detect
(default).  That way, those for whom it works can use the default, and
those for whom it does not have choices available, and if they can do no
better they can revert to default.  Consider whether it is wide to make
the choice sticky, so that it holds between successive visits.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

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

#25204

Il 03/07/2014 22:51, Dr J R Stockton ha scritto:
> In comp.lang.javascript message <lp0egh$jhi$1@dont-email.me>, Wed, 2 Jul
> 2014 10:05:36, danca <cyberdanny@tiscalinet.it> posted:
>
>
>> My Android smartphone declares an horizontal resolution of 940 pixels,
>> but obviously a standard page is unreadable on the tiny screen, so I
>> actually detect the user agent and automatically redirect the mobile
>> devices to a dedicated page, instead of rely on the screen resolution.
>> An explicit button seems to be the rational choice, however. The iPad
>> is identified as a mobile device but the screen is wide enough to
>> display standard pages.
>
>
> Do not use just "a" button, if you can do better.  Offer choices such as
> (but better name,) Vast, Big, Ordinary, Small, Tiny, Auto-Detect
> (default).  That way, those for whom it works can use the default, and
> those for whom it does not have choices available, and if they can do no
> better they can revert to default.  Consider whether it is wide to make
> the choice sticky, so that it holds between successive visits.
>
Actually I have two home pages for "wide-screen" devices (one of them 
with the auto-detection script), and one for mobile devices.
Upon landing in the homepage, the script could redirect visitors to the 
"mobile" homepage. Here a button allows to go back to the home (the 
second one, without the script). This way I don't use cookies and allow 
for visitors to decide if to stay in the "small-screen" subsystem or go 
back to the standard page. I will however think about your suggestions, 
and will explore further what css can do. I surely don't want to change 
a bit of my standard page to accomodate it for mobile devices.
What I am really waiting for, is user's feedback, then I'll see what to 
do! ;-)
Dan

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

#25229

In comp.lang.javascript message <button-20140704010305@ram.dialup.fu-
berlin.de>, Thu, 3 Jul 2014 23:06:46, Stefan Ram <ram@zedat.fu-
berlin.de> posted:

>Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> writes:
>>Do not use just "a" button, if you can do better.  Offer choices such as
>>(but better name,) Vast, Big, Ordinary, Small, Tiny, Auto-Detect
>>(default).  That way, those for whom it works can use the default, and
>
>  Does ›Big‹ mean, I will see a big font, or a big part of the
>  page, that is, a small font? I'm supposed to play a quiz,
>  before I can see the page? Just get me outta here!


My "such as (but better name)" indicates that I am conveying the general
idea but leaving the details to my readers.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

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

#25205

On 07/02/2014 02:39 AM, Andrew Poulos wrote:
> I have a design that displays well on a desktop monitor. When the design
> is viewed on a "small" screen such as a mobile phone the layout fails in
> that its unreadable (you need to zoom in and scroll about to read the
> content).
>
> My idea for a solution is to dynamically strip the
> nice-to-have/non-essential elements and so give more room to the "real"
> content. Working under the assumption that accurately deciding if a
> screen is small will be problematic I'm thinking that the way forward is
> to put a checkbox on the home page with a checkbox that reads "Mobile".
>
> If the user checks the box the nice-to have elements are removed.
>
> Is this appropriate?

As Stefan Ram pointed out, it seems that "Responsive Design" is the way 
to go nowadays, as more and more people are using smartphones everyday. 
But, depending on the site / web application's audience, responsive and 
adaptive design won't suffice. I think that's why some sites are using 
server-side combined with client-side JavaScript to detect specific devices.

I've found out some sites using WURFL.js and Modernizer together.


-- 
Joao Rodrigues

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

#25208

Joao Rodrigues wrote:

> As Stefan Ram pointed out, it seems that "Responsive Design" is the way
> to go nowadays, as more and more people are using smartphones everyday.

Don't forget that there are other devices, such as smart TVs, which
could benefit from responsive design.

> But, depending on the site / web application's audience, responsive and
> adaptive design won't suffice. I think that's why some sites are using
> server-side combined with client-side JavaScript to detect specific
> devices.
> 
> I've found out some sites using WURFL.js and Modernizer together.

I didn't know about WURFL.js before; thanks for the pointer.

However, when will "they" ever learn that not all browsers have
"JavaScript" execution available, let alone enabled.

-- 
Christoph M. Becker

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

#25253

[X-Post comp.infosystems.www.authoring.misc, comp.lang.javascript;
 F'up2 ciwa.misc]

Christoph Michael Becker wrote in comp.lang.javascript:

> Joao Rodrigues wrote:
>> As Stefan Ram pointed out, it seems that "Responsive Design" is the way
>> to go nowadays, as more and more people are using smartphones everyday.
> 
> Don't forget that there are other devices, such as smart TVs, which
> could benefit from responsive design.

*Everyone* benefits from Responsive Web Design.  It does not matter how a 
comparably small or comparably large or otherwise uncommonly-sized viewport 
came about; it is there.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

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

csiph-web