Adjust Zoom/Width/Height of Device (wrapper/iframe)

[Brent Lintner <br...@gmail.com>]

Hey All,

I have a feature I am working on, where you can adjust the browser zoom of
the device UI (that wraps the iFrame), as well as the app html itself
(iFrame). However, not all browsers support it and it will not be perfect.
Additionally, you could also adjust the device width/height/padding, and
device pixel ratio (for what it is worth). This would be persisted client
side (per domain, as usual), and overwrite what is originally defined in
the device JS file.

The main inspirational use case that caused me to do this was:

Say I have two laptops, my Macbook Pro 15" (no retina), and my ASUS Zenbook
13". When I load a device, say the Nexus 4, I want to have it look as close
as possible (in sizing/zoom) as the content on my real device (however it
is rendered). However, at default zoom on my Macbook, it needs like a 70%
zoom to look like it does on my Zenbook (where the UI is quite close to
what is rendered on my real device).

Also, by having the ability to custom adjust the device data (and persist
it), I think this will allow a wide variety of different scenarios for a
web app to be handled by users without them having to request changes to
the device file (although that is still encouraged when it is generally
applicable). An example of two different scenarios would be: say I am
testing my app on Chrome, vs a Cordova app. There is more padding in Chrome
because of the address bar. By being able to adjust the padding, I can
change it back and forth when I need to. This is something that was
previously sort of attempted to be addressed via device JS files, but it
never was used fully due to the different possible scenarios that could
occur.

Lastly, I do realize that some sort of feature to support those various
scenarios in device files (in general) would be awesome, but until that can
be figured out, I think giving users the ability to adjust these themselves
will alleviate any frustration at the device being "stuck" on what its
default data (as well only being able to adjust browser zoom document wide,
i.e. "ctrl +/-").

Am I making sense? :-) Thoughts?

-- 
Brent

Re: Adjust Zoom/Width/Height of Device (wrapper/iframe)

[Gord Tanner <gt...@gmail.com>]

+1 for the custom device idea.

I really like that option and vote that we add it to Ripple.

Would be awesome for the users to add in devices that we don't officially
support yet.


On Fri, Mar 8, 2013 at 2:24 PM, Horn, Julian C <ju...@intel.com>wrote:

> Hi Brent,
>
> Here at Intel we have a couple of Ripple derivatives that we have
> incorporated into various toolkits. We did implement something similar to
> what you suggested, although we did it in a somewhat more straightforward
> way. I can pass on our experience, for what it's worth.
>
> First, we added a slider to the Devices panel that allows you to zoom the
> device frame between 20% and 150% of its nominal size. We don't persist the
> zoom setting. We found two use cases for this control.
>
> 1) If the simulated device is too large to fit on the screen, then you can
> shrink it to make it fit.
> 2) You can attempt to match the physical size of the simulated device.
> This is achieved by setting the zoom control to something like the ratio of
> the effective dpi values for the host monitor and the simulated device.
>
> For example, an iPhone 4 is 2x3 inches, and its dimensions in physical
> pixels is 640x960 pixels @ 320 dpi.  The operating system scales this at
> 2:1, so the display environment looks like 320x480 in density-independent
> or "css" pixels. So the nominal density after scaling is 160 dpi. If the
> dpi of your monitor is 100 dpi, then you have to set the zoom to 62.5%
> (100/160) to get the simulation frame to be 2x3 inches.  By the way, if
> anyone knows how to detect the dpi value for the monitor in software I
> would love to hear what it is.
>
> Scaling always causes distortion and text can become pretty hard to read.
> Still, if you want to know whether a push button is too small to hit with
> your finger, you can answer that kind of question by zooming to actual size.
>
> We also investigated the possibility of allowing the user to create a
> "custom" device, where the user enters all the device parameters. Here I
> think there are usability issues because users are liable to type in the
> advertised dimensions of a device, which are typically quoted in physical
> pixels (e.g. 640x960 for an iPhone4), and that's not what you want. Still,
> it does allow the savvy user to work around the fact that Ripple doesn't
> know about your favorite device (yet).
>
>     Julian
>
> -----Original Message-----
> From: Brent Lintner [mailto:brent.lintner@gmail.com]
> Sent: Friday, March 08, 2013 12:36 PM
> To: dev@ripple.incubator.apache.org
> Subject: Adjust Zoom/Width/Height of Device (wrapper/iframe)
>
> Hey All,
>
> I have a feature I am working on, where you can adjust the browser zoom of
> the device UI (that wraps the iFrame), as well as the app html itself
> (iFrame). However, not all browsers support it and it will not be perfect.
> Additionally, you could also adjust the device width/height/padding, and
> device pixel ratio (for what it is worth). This would be persisted client
> side (per domain, as usual), and overwrite what is originally defined in
> the device JS file.
>
> The main inspirational use case that caused me to do this was:
>
> Say I have two laptops, my Macbook Pro 15" (no retina), and my ASUS
> Zenbook 13". When I load a device, say the Nexus 4, I want to have it look
> as close as possible (in sizing/zoom) as the content on my real device
> (however it is rendered). However, at default zoom on my Macbook, it needs
> like a 70% zoom to look like it does on my Zenbook (where the UI is quite
> close to what is rendered on my real device).
>
> Also, by having the ability to custom adjust the device data (and persist
> it), I think this will allow a wide variety of different scenarios for a
> web app to be handled by users without them having to request changes to
> the device file (although that is still encouraged when it is generally
> applicable). An example of two different scenarios would be: say I am
> testing my app on Chrome, vs a Cordova app. There is more padding in Chrome
> because of the address bar. By being able to adjust the padding, I can
> change it back and forth when I need to. This is something that was
> previously sort of attempted to be addressed via device JS files, but it
> never was used fully due to the different possible scenarios that could
> occur.
>
> Lastly, I do realize that some sort of feature to support those various
> scenarios in device files (in general) would be awesome, but until that can
> be figured out, I think giving users the ability to adjust these themselves
> will alleviate any frustration at the device being "stuck" on what its
> default data (as well only being able to adjust browser zoom document wide,
> i.e. "ctrl +/-").
>
> Am I making sense? :-) Thoughts?
>
> --
> Brent
>

RE: Adjust Zoom/Width/Height of Device (wrapper/iframe)

["Horn, Julian C" <ju...@intel.com>]

Hi Brent,

I zoomed the <section> whose id is device-container.

    Julian

-----Original Message-----
From: Brent Lintner [mailto:brent.lintner@gmail.com] 
Sent: Wednesday, March 13, 2013 3:14 PM
To: dev@ripple.incubator.apache.org
Subject: Re: Adjust Zoom/Width/Height of Device (wrapper/iframe)

Hey Julian,

Thanks a lot for mentioning your experience with this feature, and things you did or did not do when implementing it- much appreciated. :-) I plan to take all of that into account when I _do_ get around to doing this feature.
Although.. any chance something like that could be contributed back (and save me some time)? ;-D

Also, when you said zoom the device frame, did you mean just zoom the content that wraps the iFrame? Or does it zoom that, as well as the iFrame's actual document? Currently, I have it setup so you can zoom either (although it is not perfect..).

+1 - I also like the idea of a user being able to add a unsupported 
+device,
and additionally being able to easily contribute it to the project.

On Fri, Mar 8, 2013 at 2:24 PM, Horn, Julian C <ju...@intel.com>wrote:

> Hi Brent,
>
> Here at Intel we have a couple of Ripple derivatives that we have 
> incorporated into various toolkits. We did implement something similar 
> to what you suggested, although we did it in a somewhat more 
> straightforward way. I can pass on our experience, for what it's worth.
>
> First, we added a slider to the Devices panel that allows you to zoom 
> the device frame between 20% and 150% of its nominal size. We don't 
> persist the zoom setting. We found two use cases for this control.
>
> 1) If the simulated device is too large to fit on the screen, then you 
> can shrink it to make it fit.
> 2) You can attempt to match the physical size of the simulated device.
> This is achieved by setting the zoom control to something like the 
> ratio of the effective dpi values for the host monitor and the simulated device.
>
> For example, an iPhone 4 is 2x3 inches, and its dimensions in physical 
> pixels is 640x960 pixels @ 320 dpi.  The operating system scales this 
> at 2:1, so the display environment looks like 320x480 in 
> density-independent or "css" pixels. So the nominal density after 
> scaling is 160 dpi. If the dpi of your monitor is 100 dpi, then you 
> have to set the zoom to 62.5%
> (100/160) to get the simulation frame to be 2x3 inches.  By the way, 
> if anyone knows how to detect the dpi value for the monitor in 
> software I would love to hear what it is.
>
> Scaling always causes distortion and text can become pretty hard to read.
> Still, if you want to know whether a push button is too small to hit 
> with your finger, you can answer that kind of question by zooming to actual size.
>
> We also investigated the possibility of allowing the user to create a 
> "custom" device, where the user enters all the device parameters. Here 
> I think there are usability issues because users are liable to type in 
> the advertised dimensions of a device, which are typically quoted in 
> physical pixels (e.g. 640x960 for an iPhone4), and that's not what you 
> want. Still, it does allow the savvy user to work around the fact that 
> Ripple doesn't know about your favorite device (yet).
>
>     Julian
>
> -----Original Message-----
> From: Brent Lintner [mailto:brent.lintner@gmail.com]
> Sent: Friday, March 08, 2013 12:36 PM
> To: dev@ripple.incubator.apache.org
> Subject: Adjust Zoom/Width/Height of Device (wrapper/iframe)
>
> Hey All,
>
> I have a feature I am working on, where you can adjust the browser 
> zoom of the device UI (that wraps the iFrame), as well as the app html 
> itself (iFrame). However, not all browsers support it and it will not be perfect.
> Additionally, you could also adjust the device width/height/padding, 
> and device pixel ratio (for what it is worth). This would be persisted 
> client side (per domain, as usual), and overwrite what is originally 
> defined in the device JS file.
>
> The main inspirational use case that caused me to do this was:
>
> Say I have two laptops, my Macbook Pro 15" (no retina), and my ASUS 
> Zenbook 13". When I load a device, say the Nexus 4, I want to have it 
> look as close as possible (in sizing/zoom) as the content on my real 
> device (however it is rendered). However, at default zoom on my 
> Macbook, it needs like a 70% zoom to look like it does on my Zenbook 
> (where the UI is quite close to what is rendered on my real device).
>
> Also, by having the ability to custom adjust the device data (and 
> persist it), I think this will allow a wide variety of different 
> scenarios for a web app to be handled by users without them having to 
> request changes to the device file (although that is still encouraged 
> when it is generally applicable). An example of two different 
> scenarios would be: say I am testing my app on Chrome, vs a Cordova 
> app. There is more padding in Chrome because of the address bar. By 
> being able to adjust the padding, I can change it back and forth when 
> I need to. This is something that was previously sort of attempted to 
> be addressed via device JS files, but it never was used fully due to 
> the different possible scenarios that could occur.
>
> Lastly, I do realize that some sort of feature to support those 
> various scenarios in device files (in general) would be awesome, but 
> until that can be figured out, I think giving users the ability to 
> adjust these themselves will alleviate any frustration at the device 
> being "stuck" on what its default data (as well only being able to 
> adjust browser zoom document wide, i.e. "ctrl +/-").
>
> Am I making sense? :-) Thoughts?
>
> --
> Brent
>



--
Brent

Re: Adjust Zoom/Width/Height of Device (wrapper/iframe)

[Brent Lintner <br...@gmail.com>]

Hey Julian,

Thanks a lot for mentioning your experience with this feature, and things
you did or did not do when implementing it- much appreciated. :-) I plan to
take all of that into account when I _do_ get around to doing this feature.
Although.. any chance something like that could be contributed back (and
save me some time)? ;-D

Also, when you said zoom the device frame, did you mean just zoom the
content that wraps the iFrame? Or does it zoom that, as well as the
iFrame's actual document? Currently, I have it setup so you can zoom either
(although it is not perfect..).

+1 - I also like the idea of a user being able to add a unsupported device,
and additionally being able to easily contribute it to the project.

On Fri, Mar 8, 2013 at 2:24 PM, Horn, Julian C <ju...@intel.com>wrote:

> Hi Brent,
>
> Here at Intel we have a couple of Ripple derivatives that we have
> incorporated into various toolkits. We did implement something similar to
> what you suggested, although we did it in a somewhat more straightforward
> way. I can pass on our experience, for what it's worth.
>
> First, we added a slider to the Devices panel that allows you to zoom the
> device frame between 20% and 150% of its nominal size. We don't persist the
> zoom setting. We found two use cases for this control.
>
> 1) If the simulated device is too large to fit on the screen, then you can
> shrink it to make it fit.
> 2) You can attempt to match the physical size of the simulated device.
> This is achieved by setting the zoom control to something like the ratio of
> the effective dpi values for the host monitor and the simulated device.
>
> For example, an iPhone 4 is 2x3 inches, and its dimensions in physical
> pixels is 640x960 pixels @ 320 dpi.  The operating system scales this at
> 2:1, so the display environment looks like 320x480 in density-independent
> or "css" pixels. So the nominal density after scaling is 160 dpi. If the
> dpi of your monitor is 100 dpi, then you have to set the zoom to 62.5%
> (100/160) to get the simulation frame to be 2x3 inches.  By the way, if
> anyone knows how to detect the dpi value for the monitor in software I
> would love to hear what it is.
>
> Scaling always causes distortion and text can become pretty hard to read.
> Still, if you want to know whether a push button is too small to hit with
> your finger, you can answer that kind of question by zooming to actual size.
>
> We also investigated the possibility of allowing the user to create a
> "custom" device, where the user enters all the device parameters. Here I
> think there are usability issues because users are liable to type in the
> advertised dimensions of a device, which are typically quoted in physical
> pixels (e.g. 640x960 for an iPhone4), and that's not what you want. Still,
> it does allow the savvy user to work around the fact that Ripple doesn't
> know about your favorite device (yet).
>
>     Julian
>
> -----Original Message-----
> From: Brent Lintner [mailto:brent.lintner@gmail.com]
> Sent: Friday, March 08, 2013 12:36 PM
> To: dev@ripple.incubator.apache.org
> Subject: Adjust Zoom/Width/Height of Device (wrapper/iframe)
>
> Hey All,
>
> I have a feature I am working on, where you can adjust the browser zoom of
> the device UI (that wraps the iFrame), as well as the app html itself
> (iFrame). However, not all browsers support it and it will not be perfect.
> Additionally, you could also adjust the device width/height/padding, and
> device pixel ratio (for what it is worth). This would be persisted client
> side (per domain, as usual), and overwrite what is originally defined in
> the device JS file.
>
> The main inspirational use case that caused me to do this was:
>
> Say I have two laptops, my Macbook Pro 15" (no retina), and my ASUS
> Zenbook 13". When I load a device, say the Nexus 4, I want to have it look
> as close as possible (in sizing/zoom) as the content on my real device
> (however it is rendered). However, at default zoom on my Macbook, it needs
> like a 70% zoom to look like it does on my Zenbook (where the UI is quite
> close to what is rendered on my real device).
>
> Also, by having the ability to custom adjust the device data (and persist
> it), I think this will allow a wide variety of different scenarios for a
> web app to be handled by users without them having to request changes to
> the device file (although that is still encouraged when it is generally
> applicable). An example of two different scenarios would be: say I am
> testing my app on Chrome, vs a Cordova app. There is more padding in Chrome
> because of the address bar. By being able to adjust the padding, I can
> change it back and forth when I need to. This is something that was
> previously sort of attempted to be addressed via device JS files, but it
> never was used fully due to the different possible scenarios that could
> occur.
>
> Lastly, I do realize that some sort of feature to support those various
> scenarios in device files (in general) would be awesome, but until that can
> be figured out, I think giving users the ability to adjust these themselves
> will alleviate any frustration at the device being "stuck" on what its
> default data (as well only being able to adjust browser zoom document wide,
> i.e. "ctrl +/-").
>
> Am I making sense? :-) Thoughts?
>
> --
> Brent
>



-- 
Brent

RE: Adjust Zoom/Width/Height of Device (wrapper/iframe)

["Horn, Julian C" <ju...@intel.com>]

Hi Brent,

Here at Intel we have a couple of Ripple derivatives that we have incorporated into various toolkits. We did implement something similar to what you suggested, although we did it in a somewhat more straightforward way. I can pass on our experience, for what it's worth.

First, we added a slider to the Devices panel that allows you to zoom the device frame between 20% and 150% of its nominal size. We don't persist the zoom setting. We found two use cases for this control.

1) If the simulated device is too large to fit on the screen, then you can shrink it to make it fit.
2) You can attempt to match the physical size of the simulated device. This is achieved by setting the zoom control to something like the ratio of the effective dpi values for the host monitor and the simulated device.

For example, an iPhone 4 is 2x3 inches, and its dimensions in physical pixels is 640x960 pixels @ 320 dpi.  The operating system scales this at 2:1, so the display environment looks like 320x480 in density-independent or "css" pixels. So the nominal density after scaling is 160 dpi. If the dpi of your monitor is 100 dpi, then you have to set the zoom to 62.5% (100/160) to get the simulation frame to be 2x3 inches.  By the way, if anyone knows how to detect the dpi value for the monitor in software I would love to hear what it is.

Scaling always causes distortion and text can become pretty hard to read. Still, if you want to know whether a push button is too small to hit with your finger, you can answer that kind of question by zooming to actual size.

We also investigated the possibility of allowing the user to create a "custom" device, where the user enters all the device parameters. Here I think there are usability issues because users are liable to type in the advertised dimensions of a device, which are typically quoted in physical pixels (e.g. 640x960 for an iPhone4), and that's not what you want. Still, it does allow the savvy user to work around the fact that Ripple doesn't know about your favorite device (yet).

    Julian

-----Original Message-----
From: Brent Lintner [mailto:brent.lintner@gmail.com] 
Sent: Friday, March 08, 2013 12:36 PM
To: dev@ripple.incubator.apache.org
Subject: Adjust Zoom/Width/Height of Device (wrapper/iframe)

Hey All,

I have a feature I am working on, where you can adjust the browser zoom of the device UI (that wraps the iFrame), as well as the app html itself (iFrame). However, not all browsers support it and it will not be perfect.
Additionally, you could also adjust the device width/height/padding, and device pixel ratio (for what it is worth). This would be persisted client side (per domain, as usual), and overwrite what is originally defined in the device JS file.

The main inspirational use case that caused me to do this was:

Say I have two laptops, my Macbook Pro 15" (no retina), and my ASUS Zenbook 13". When I load a device, say the Nexus 4, I want to have it look as close as possible (in sizing/zoom) as the content on my real device (however it is rendered). However, at default zoom on my Macbook, it needs like a 70% zoom to look like it does on my Zenbook (where the UI is quite close to what is rendered on my real device).

Also, by having the ability to custom adjust the device data (and persist it), I think this will allow a wide variety of different scenarios for a web app to be handled by users without them having to request changes to the device file (although that is still encouraged when it is generally applicable). An example of two different scenarios would be: say I am testing my app on Chrome, vs a Cordova app. There is more padding in Chrome because of the address bar. By being able to adjust the padding, I can change it back and forth when I need to. This is something that was previously sort of attempted to be addressed via device JS files, but it never was used fully due to the different possible scenarios that could occur.

Lastly, I do realize that some sort of feature to support those various scenarios in device files (in general) would be awesome, but until that can be figured out, I think giving users the ability to adjust these themselves will alleviate any frustration at the device being "stuck" on what its default data (as well only being able to adjust browser zoom document wide, i.e. "ctrl +/-").

Am I making sense? :-) Thoughts?

--
Brent