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). 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)
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.)
>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.
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).
>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.
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]
I've got 30GB+ of photos/videos in my Google Photos (unclear count due to Pixel free upload). I launch Google Photos, I see the most recent photos. I scrub down to 2011, there's the photos in 2011. It doesn't try to load the entire library in one go.
You shouldn't. I wish all these apps had a dumb basic mode (like gmail html mode) that would just show the photos in a static fashion so it's not a pain to browse on low end mobile. The article is interesting, but just like onedrive photo galleries, these UI are often slow to scroll in and even reset randomly so when you're in the middle of a 100 photo gallery and it happens it's a bit frustrating.
Remember the old picasa UI? it just showed the photos, that's it, nothing fancy, on complicated calculations in js...
Also off topic ... but medium UI is getting worse and worse, on a laptop, fixed heading + fixed message on the bottom (that can't be dismissed), really? not much real estate left for the actual content. And don't get me started on the pictures that take 10 seconds to load, because of "lazy loading" bound to the scroll position...
Oh, how Google would want you to forget it. It still runs circles around anything that came to replace it, while running on a decade-old machine managing 100GB+ of photos in mixed formats.
I must be the only one on HN who despised the old picasa UI. I've been making more and more use of Google Photos because of how easy to use it is.
Maybe these statements should be qualified. I'm an average user in terms of photos: I take them sometimes, usually from my phone, I don't like having lots of duplicates in various devices and I don't care to manage all the backups by myself; I just don't want to lose them.
I'm not a professional photographer and it feels like there's a world of difference in terms of what UI one might want if they are. Kinda like as a professional developer I don't care for my text editor's ability to print pages, I want it to syntax highlight.
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.
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.
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.
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.
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.
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.)