Up until now we've gotten away with using the state.json file in the root of buckets. This is an unsustainable design: we won't get away with this for much longer.

I'd like to switch to SQLite for this stuff. We want stricter schemas, validation, and migrations if we're actually going to put pxl to use in a production setting and handle upgrades across versions. I also have some nice ideas about resumable uploads

The Left/Right hotkeys, which navigate through an album, conflict with the Chrome/Firefox shortcuts for Back/Forward: Alt+Left/Right. Using the browser hotkeys currently makes you go two photos back/forward.

It would be nice if the browser hotkeys retain their regular functionality: the same as the Left/Right hotkeys.

• Year
• Board year
• Committee

For https://photos.svsticky.nl/, we use DigitalOcean Spaces with its CDN enabled. However, the CDN uses a different URL format than the one currently supported by pxl: https://<space>.<region>.cdn.digitaloceanspaces.com/.

Also, DO recently added the feature of using custom subdomains when using the CDN, which also changes the URL format.

Therefore it would be nice if pxl can support custom URL formats, since DO Spaces without its CDN doesn't seem to be very performant for small files (the lack of HTTP/2, even with CDN, also doesn't help).

Currently, we don't set any Cache-Control headers, so browsers fetch all resources all the time. We should change this to Cache-Control: must-revalidate. That causes Chrome to actually check for expiration with If-Modified-Since and If-None-Match

The S3 API may reject requests with a custom error (503 Slow Down) when a rate
limit has been reached. Boto automatically retries these requests, this does
not always work. Example traceback:

Traceback (most recent call last):
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/boto3/s3/transfer.py", line 279, in upload_file
    future.result()
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/s3transfer/futures.py", line 73, in result
    return self._coordinator.result()
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/s3transfer/futures.py", line 233, in result
    raise self._exception
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/s3transfer/tasks.py", line 126, in __call__
    return self._execute_main(kwargs)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/s3transfer/tasks.py", line 150, in _execute_main
    return_value = self._main(**kwargs)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/s3transfer/upload.py", line 692, in _main
    client.put_object(Bucket=bucket, Key=key, Body=body, **extra_args)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/botocore/client.py", line 320, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/botocore/client.py", line 623, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (SlowDown) when calling the PutObject operation (reached max retries: 4): Please reduce your request rate.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "main.py", line 6, in <module>
    cli.main()
  File "/home/username/pxl/pxl/cli.py", line 224, in main
    cli()
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/username/pxl/pxl/cli.py", line 127, in upload_cmd
    image = upload.public_image_with_size(client, entry)
  File "/home/username/pxl/pxl/upload.py", line 102, in public_image_with_size
    public_image(client, local_filename, object_name)
  File "/home/username/pxl/pxl/upload.py", line 124, in public_image
    Key=object_name,
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/boto3/s3/inject.py", line 131, in upload_file
    extra_args=ExtraArgs, callback=Callback)
  File "/home/username/.local/share/virtualenvs/pxl-IyaRoL09/lib/python3.7/site-packages/boto3/s3/transfer.py", line 287, in upload_file
    filename, '/'.join([bucket, key]), e))
boto3.exceptions.S3UploadFailedError: Failed to upload /tmp/photofile.jpeg to the-bucket-name/abcdef12-3456-7890-abcd-ef1234567890_w_1600.jpg: An error occurred (SlowDown) when calling the PutObject operation (reached max retries: 4): Please reduce your request rate.

Some sort of backoff handling would probably be useful. I found
https://pypi.org/project/backoff/, which would probably work.

In Firefox, on 100% zoom, not all album thumbnails are shown on the homepage. On my resolution (2560x1440), I see 25, which increases when zooming out.

On Chrome all thumbnails are all shown. (Although some rows are of a different size.)

There's a special callback for the oauth integration that logs the user out. we should at a link to it. (I'm not sure if it's a POST handler or not)

• Committee
• Board year
• ?

The current setup is done through the pxl init command, but there are a few things we can improve about its UX:

• The init command SHOULD verify the configuration settings before saving them to a file.
• The init command MAY offer to create the given bucket if it doesn't exist yet (after user confirmation)

@Riscky asked us to package pxl releases as Ubuntu .debs so that the less technically inclined board members don't have to wrestle with Pipenv.

We need HTML templates and the corresponding CSS for:

• The index. This is a list of all the albums.
• An album. This is a list of all images.
• Individual images. This is a detail view.

Requirements/constraints we already thought of:

• Within the index, order of albums is important.
• Albums should have a title, visible in the template.
• Within an album, order of photos isn't too important.
• Individual images should have a download button

Plus all the other standard stuff like reasonable HTML.

On iOS, the buttons in a photo's detail view are overlapping. Example (from Firefox, but all iOS browsers use the same rendering engine):

In multiple places (eg. uploading and deleting a picture) the .jpg extension is hardcoded.

We currently just use print(), but we probably should send error/diagnostic messages to stderr instead of stdout. We can use the click.echo() util for this.

It would be nice if pxl could have a pxl deploy command so people don't need to worry about manually writing deploy scripts.

People might want photos to be taken down if they are in them by accident or find them otherwise harassing. There should be a button which requests takedown of a photo. This can be simple: like a mailto link with a prefilled template which goes out to a predefined email address.

pls fix ;(

In addition to the left/right buttons, swiping would be nice on mobile.

In a previous version pxl had a nonfunctional report button per photo.
We should add this back and add the functionality needed to report and remove individual pictures (#74).

An often requested feature is an option to download the original photo. Flickr currently requires people to be signed in.

After #4 is merged we need to remember uploads in the state file and store that file on S3. We do need to think about if we want to support concurrent uploads. I have a feeling this shouldn't be too difficult if we're a bit careful.

Let's start with a simple lockfile, though.

(We could also code the happy path, but let's do concurrent operations right at the start. Fixing this stuff later is difficult because building on invalid assumptions about concurrency is difficult to fix later.)

Look up albums with ease

• Name
• Committee?
• ?

After #6, we can generate index files with the content from the state file. Then, we have a reasonable MVP

It would be great if you could download an entire album, instead individual pictures.

The shadow for the album title doesn't go down entirely. This causes an ugly line under each album with the original color. See the image below for an example.

Currently, the original links don't actually cause the file to be downloaded. We can fix this by setting the Content-Disposition: attachment header.

Thanks @tomwassenberg for suggesting!

The app currently crashes on building an empty album

This is probably because URL bar doesn't count as vw in chrome

Maybe as an extension to the 'edit' cli option.

We need to find a way that all pictures align perfectly beautiful in a grid. Especially vertical pictures stand out too much

Tweak some media queries to fix

It might be useful to offer some way of reordering albums and allowing a user to edit them, to prevent mistakes like "Respberry Pi" from being for eternity.

We might want to add a nice looking 404 page so people can configure their webserver to point to that instead of serve an ugly default page.

I saw @tomwassenberg try the escape button to go back to the album view from an individual photo. This is a bit of progressive enhancement that we should support for people that do have JS enabled.

Some text in the current theme isn't too easily readable. We should test the contrast of all text under some accessibility guidelines and improve the colors accordingly

Using https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

This drastically improves initial load times of albums. and also reduces bandwidth on mobile phones.

I implemented an POC that progressively enhances a page with this in such a way
that the page works the same with javascript enabled or disabled. Just when JS is enabled, the page loads faster

POC:

img.lazy {
  display: hidden;
}

document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    lazyImages.forEach(function(lazyImage) {
      lazyImage.src = lazyImage.dataset.src;
      lazyImage.classList.remove("lazy");
    });
  }
});

    <a href="/baco-preski-borrel-2017/" class="album">
      <img data-src="https://lol"
           alt="BaCo PreSki Borrel 2017" class="lazy album-cover">
      <noscript><img src="https://lol"
                     alt="BaCo PreSki Borrel 2017" class="album-cover"></noscript>
      <h2 class="album-title">BaCo PreSki Borrel 2017</h2>
    </a>

It would be easier to upload albums if a folder of albums could be uploaded in one command, assuming the subfolders are aptly named.

@Ckef talked about a bug (in private chat) where the CLI crashes. From the stacktrace I saw, my hunch is that this happens when uploading an image without EXIF data.

Opening this as a placeholder/potential bug.

We don't set the page titles properly. We need to set them.

Candidate pieces of info:

• Album name
• Photo num (instead of uuid)
• Brand - svsticky
• "Generated with pxl"

First round of feedback indicated that a slideshow in the pictures page would be a great addition

Stuff like exact date/time, location and a bunch of other things. We don't need it for anything, so we shouldn't store it.