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:[email protected]]
Sent: Friday, March 08, 2013 12:36 PM
To: [email protected]
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
