
Building the Google Photos Web UI - megaman821
https://medium.com/google-design/google-photos-45b714dfbed1
======
svat
Section 2 of the article, on Justified Layout, was a joy to read. As it says,
it's inspired by (adapted/simplified from) TeX's line-breaking algorithm,
described by Knuth and Plass ([http://www.eprg.org/G53DOC/pdfs/knuth-plass-
breaking.pdf](http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf)). The
paper is a _fantastic_ read. Even if you never use TeX, it's worth reading. (I
elaborated more on it here:
[https://tex.stackexchange.com/a/423578/48](https://tex.stackexchange.com/a/423578/48))

As reading the paper will make clear, it's really incredible how with very
simple primitives (boxes, glue and penalties), we can achieve so many
different kinds of layout. Sometimes when I'm struggling with CSS layout I
yearn for a layout model as simple as TeX's. (Though of course CSS has other
hard problems to solve like variable width and "simpler" users, and I guess
the most recent additions to CSS, like Flexbox and Grid typesetting, are some
small steps in the direction of approaching the power of TeX circa 1978.)

------
andybak
As someone who's grumbled at the semi-occasional glitch and lag in Google
Photos I feel bad reading this. It's a genuinely hard problem.

~~~
romwell
>As someone who's grumbled at the semi-occasional glitch and lag in Google
Photos I feel bad

Don't. They killed a good product, Picasa, which didn't have these problems
_because it didn 't need to solve them_.

There's no way Google Photos - or any cloud solution - will be an adequate
replacement to handle my 100GB+ library of JPEGs, RAW files, and videos, with
instant editing and access to all of it -- if only because it doesn't take a
second to pull 100GB of data from the net!

Not everything needs to be cloud-based -- but not according to Google's
vision. Picasa still does a fine job for me, but I have to preserve my copy of
the installer because Google wouldn't want me to have it any more.

~~~
joshuamorton
It appears you didn't really read the article. There's no need to pull 100gb
of data.

And 100gb is comparatively small for a photo and video library. The article
mentions testing with 250k photos, which would be well over 100gb (2-3 times
that at minimum, significantly more if RAW and high res).

~~~
romwell
>It appears you didn't really read the article. There's no need to pull 100gb
of data.

I read the article, paying special attention to section 4, aptly titled "Smoke
and Mirrors".

There's always a need to pull in as much data as the user wants to actually
interact with.

No matter what tricks you pull, you'd still need about 1s to pull in a 10MB
photo over a 100mbps connection at full speed, and most people don't have
that. Reading data off a disk is an order (or two, with an SSD) of magnitude
faster.

And sometimes, I just want to flip through the library and look at _a lot_ of
photos without having to wait seconds for each one to load.

Sure, the layout algorithms are still important, and that's what a lot of the
article is about. But all king's horses and all king's men can't make the
latency of a javascript UI with a network backend comparable to a compiled
program interacting with a disk.

Thank you, but smoke and mirrors aren't for everyone. Google Photos fulfills
an obvious need, but it's not a Picasa replacement.

~~~
pjmlp
I went back to use the filesystem as I was used to do before.

Editing via Paint.NET and exporting to the Web via jAlbum.

Requiring a G+ account didn't help to gain my love.

~~~
igouy
1) Folders date-labelled when the files were moved from camera to computer
20180712 and files date & sequence labelled 20180712-005.ARW
20180712-005-1.tif as variants are created

2) Edit mostly via RawTherapee (with special help from MS ICE & photoFXlab
masks & Silver Efex Pro)

3) Distribute & Share with Google Photos (jpgs down-sized below 16MP) [upload
with web browswer interface avoids all the confusion around auto backup and
deletes]

------
londons_explore
I'd like to see even more responsiveness in the photo grid. I think these
ideas are good, but could be taken further.

For example, while scrubbing fast, I shouldn't ever see blank grey tiles.

My scroll bar has say 1000 pixels of vertical height. That means there are
only 1000 positions I can scrub fast to. They should preload all those
positions in the form of a video with 1000 frames and then display the correct
frame of the video as the initial low res render.

They could alternatively preload them in the form of a CSS/html grid with
about 500 bytes per position, or 8 bytes per image. That should at least let
them get vague gradients and approximate colours for the content of the
thumbnails.

------
chendragon
I suspect some of this has changed at some point, right around when they
switched to material design. Scrolling became laggy on some machines and the
page would often become unresponsive. When Google Photos first came out it was
wonderfully responsive but I have since switched away.

------
ishikawa
This is by far my favorite Google product. I always wondered how they could do
the scroll so fast. But for me the loading time is slow. I can scroll fast but
I get into a blank area for a long time. The scroll should also work, on
Android at least, when you do a search.

------
kachurovskiy
Unrelated feature request: use photo resolution that matches the TV resolution
on Chromecast.

Currently 26MP photos casted on a 4k TV (with Chromecast built in) look awful.

------
Jyaif
Regarding the scrolling, any decent mobile developer can write a 60fps (and
even 120fps with the new iPads) scrolling gallery with billions of photos, but
with the web it's still a hard problem 20+ years in. This is pathetic.

~~~
lern_too_spel
With multiple aspect ratios and justified layout? Prove it. Neither the Apple
Photos app nor Google Photos app can do this. If you're cropping everything
into fixed aspect ratios, it's trivial on all platforms with existing
libraries.

