ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Horn, Julian C" <>
Subject RE: Adjust Zoom/Width/Height of Device (wrapper/iframe)
Date Fri, 08 Mar 2013 19:24:34 GMT
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).


-----Original Message-----
From: Brent Lintner [] 
Sent: Friday, March 08, 2013 12:36 PM
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?

View raw message