ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <gtan...@gmail.com>
Subject Re: Adjust Zoom/Width/Height of Device (wrapper/iframe)
Date Fri, 08 Mar 2013 20:16:21 GMT
+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 <julian.c.horn@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message