Pushing Pixels

Indeed, this is a poor example specifically because House of Cards makes heavy use of digital backlot.

> Steve: We have a visual effects supervisor on the show who’s been working with Fincher for around 20 years. Let’s say we’re shooting on stage, and out the window we want to see the Washington monument, we’ll shoot green screen out of the set window. Then we’ll coordinate with the VFX department, telling them that we need to add a certain image out the window, and then we will go back-and-forth on how much expense it will require and how best to accomplish it.

> We actually do a fair amount of digital work in post on the show. All the driving in the show, anything inside the vehicle is done on stage, in a room that is a big three-sided green screen space. The car does not move, the actors are in the car, and the cameras are set up around them. We have very long strips of LED monitors hung above the car. We had a camera crew go to Washington, D.C. to drive around and shoot plates for what you see outside when you’re driving. And that is fed into the LED screens above the car. So as the scene is progressing, the LED screens are synched up to emit interactive light to match the light conditions you see in the scenery you’re driving past (that will be added in post). All the reflections on the car windows, the window frames and door jambs is being shot while we’re shooting the actors in the car. Then in post the green screens are replaced with the synced up driving plates,…

See http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html for a detailed exploration of precisely the issue with icons and real-life examples of how smaller versions are actually different images (eg a large 3d image with drop shadows gets gradually flattened to a simplified 2d version).

One thing you can do for patching SVG is to have multiple versions of images/shapes and use CSS rules to select just the most appropriate one to show depending on a class you add to some root or parent item - hiding the other until needed.
I haven't tested this, but wonder if the browser would be smart enough to prioritise loading of the different images depending on the visibility.

Otherwise you could generate those parts of the SVG as required, and use the load event to only swap the display to the more appropriate version of an image once loaded.. hence as you zoom the display, you first get the "core" image/shapes etc simply scaled by the browser, and then as background images are loaded, these scaled versions are replaced by more appropriate versions.

This would match the way that zooming works with tiles in apps like Google maps - when you first zoom in you simply get the base tile images scaled by the browser, and then replaced by the more detailed versions as they're loaded.

It's in the carousel on that page, but here's an interview with Timothy Peel, who did those for The Expanse and also Mr. Robot. They talk about it a bit:

https://www.pushing-pixels.org/2016/01/21/a-window-into-another-world-interview-with-timothy-peel.html

I think they'd rather bring you into the world by showing the UI and interactions while also showing the actors. With a opaque device, we know they're using it, but we don't get to see any detail about it. And a camera angle behind the actor that shows the UI can be awkward. So I think it's really just a compromise to be able to show the UIs, interaction, and the actors from the front at the same time.

I wouldn't ever use one for privacy, and I think the only realistic way transparent devices would be useful is if they tint the glass so it's maybe 50% opaque.

One thing I wish I had discovered earlier is that some devs from Google released the sources for a "Google I/O" app for the last two years, and that reading that code teaches you a lot of how to design a good app.

The Google I/O app uses (and sometimes introduces) many useful patterns in UI design and Architecture design. It scales to all kind of screen sizes, hardware configurations and platform versions.

Here is a link to a resource page for the Android Developer Lab in Paris. You can find links to Google I/O 2011 and two other examples there.

https://sites.google.com/site/androiddevlabs2011/code-lab-paris

Oh, and also: http://www.pushing-pixels.org/

I have to concede that I do prefer the longer abbreviations, especially nowadays when most editors have auto-completion, although of course there are limits. A healthy balance between (0) and (1). This also reminds me of those ridiculously long class names (2).

(0) my_structured_query_language_connect()
(1) SHFILEOPSTRUCTW [0]
(2) InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter [1]

[0] https://news.ycombinator.com/item?id=20018562

[1] https://www.pushing-pixels.org/2007/11/07/and-the-longest-jre-class-name-is.html

Vectors are not a panacea.

http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html

(Among other articles about this topic).

Having said that, I still wish they were better supported in modern OSes as a hybrid solution because while they start to fall apart at small sizes they do handle the scaling in the other direction (which is what this topic is mostly about here anyway) well, certainly better than just upsampling a bitmap icon.