Load image thumbnail in sidebar - Discussion

[7malikk]

Currently, the images are all fetched from archive.org and displayed in the sidebar as seen below:

In reference to issue #998 and task 1 of my proposal.

I proposed steps to begin to address this issue:

• A limit/cap should be set to represent a "huge image collection", for example upon user submission of a link, the response being the images, if greater than say 250, should be displayed in a grid format (4 or 5 columns, less on tablet).
• When the user hovers (long press on a tablet) over an image, it pops up within a visible width and the image name (refer to the proposal for a graphic display) or the thumbnail has the name of the image attached to it for easy identification, instead of the hover?? (just a thought)

[7malikk]

Hey there @jywarren @cesswairimu @TildaDares @PeculiarE

What are your thoughts on this feature?
I'd like us to discuss

• the areas it cuts across, though, from the skimming I've done, it could be easily contained
• possible issues that could arise? I was brainstorming with @segun-codes, taking into consideration that not all images would come with a thumbnail format as @PeculiarE once said, so we thought to add a cracked file icon in such cases. here is a sample:
  
  it'll be a lot smaller of course, and it will have the image name attached, giving off the notion that it does not have a thumbnail file but can still be placed on the map. (is this overkill?)

I'd appreciate your thoughts

Also had a thought to add an event listener to the image itself, instead of the place on map button, when the user hovers over an image or a thumbnail, a tooltip pops up and reads place on map.
Just some thoughts.

Note, this task is consistent with task distribution @segun-codes and I agreed upon and listed it on the Trello board, many thanks!

[jywarren]

Hi, I think this is a good project to take up next. You might try opening a really big archive.org collection to see "how bad it is" when it tries to load a lot of images.

The other thought I had was - what if we have it fail gracefully -- i.e. we just search for thumbnails, and if there are no matches, we just show the full image. Although it could cause trouble (we'll find out how much trouble in the above testing of a big gallery), that way if there are some images without, the whole experience still fundamentally works even though you have to wait longer for them to load. This is complexity but if the complexity fails we're essentially reverting back to how it was, in terms of UX. What do you think?

The tooltip sounds interesting, but it might not work well on mobile devices. Sometimes we can shorten the text on a button by moving some longer explanation to a tooltip though. What about the button saying "place" or showing an icon, but the tooltip says "place image on map" or something?

[7malikk]

Alright, @jywarren, that sounds good, I would test it out with a collection with a lot of images.

That's a good one @jywarren, so if i run a match for thumbnails and there aren't any or not all have one, we default to the full image. I will test this out and see where it leads. It sounds quite interesting.

Very true, mobile would be a hassle for the tooltip. Yea the shortening sounds good, but where do we intend to implement it? on mobile? or on all screens? or when we're loading a lot of images?

[jywarren]

I think if we add a tooltip, we could shorten the button text for all devices. Thanks!

On Wed, Dec 14, 2022 at 12:12 PM Malik ***@***.***> wrote: Alright, @jywarren <https://github.com/jywarren>, that sounds good, I would test it out with a collection with a lot of images. That's a good one @jywarren <https://github.com/jywarren>, so if i run a match for thumbnails and there aren't any or not all have one, we default to the full image. I will test this out and see where it leads. It sounds quite interesting. Very true, mobile would be a hassle for the tooltip. Yea the shortening sounds good, but where do we intend to implement it? on mobile? or on all screens? or when we're loading a lot of images? — Reply to this email directly, view it on GitHub <#1295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF6J6QFJRS7VQBPAE4K2LWNH5XNANCNFSM6AAAAAAS6KPPUA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Okay, but for the sake of user experience I think the tooltip should read 'click button to place on map' or any alternative that's quite suggestive. I'd like to think that mental model suggests that a tooltip saying 'place on map' (especially on bigger screens - laptop, desktop etc.) upon hovering over an image means the user should drag and drop the image on the tile.

[7malikk]

Alright @jywarren
Will do
Thank you!

[7malikk]

Hello @jywarren, I've encountered some issues as regards this feature.

Description 1

Firstly, I wanted to kick off with the cap/limit, which entails that once the images gotten from the response are above a certain amount --say 100, the program defaults to using thumbnails. I placed the code snippet below in the renderImages function found here;

if (imageCount > 100) {
  // execute thumbnail render
} else {
  // execute image render
}

Issue 1

The ImageCount variable is updated here after each image is rendered from my study, so it does not suffice as a condition in my snippet above. I believe it was set up this way for a reason as after examining the response, I noticed not all the files are in jpegs/pngs formats so using response.data.files.length was not an option.

Description 2 / Issue 2

While testing out the thumbnails, I noticed that when I placed the thumbnail images on the map, they were pixelated.

Proposed solution to Issue 2

We could render the images as is from the response, and only change the image size to say 65 x 65, here is a sample of what I
have accomplished and what I am implying:

From my observation, it takes a lot longer to place an image from a large collection on the map and also to fetch it from archive.org

Final thoughts

I would like your thoughts on my progress so far and a way to address issue 1, maybe a substitute for imageCount ?

[7malikk]

@segun-codes you could also check this out and let me know what you think.

As for issue #1, I'm not sure I understand the problem clearly, but if what you mean is that because not all files returned from IA have format png or jpeg, variable imageCount will therefore have inaccurate value, then why don't you increment imageCount in the function where fetch operation is done and not inside renderImage(). Then you make the said variable available for use in the conditional check statement above.

You can re-clarify, if my understanding is faulty, many thanks!

[segun-codes]

Hi, I think this is a good project to take up next. You might try opening a really big archive.org collection to see "how bad it is" when it tries to load a lot of images.

The other thought I had was - what if we have it fail gracefully -- i.e. we just search for thumbnails, and if there are no matches, we just show the full image. Although it could cause trouble (we'll find out how much trouble in the above testing of a big gallery), that way if there are some images without, the whole experience still fundamentally works even though you have to wait longer for them to load. This is complexity but if the complexity fails we're essentially reverting back to how it was, in terms of UX. What do you think?

The tooltip sounds interesting, but it might not work well on mobile devices. Sometimes we can shorten the text on a button by moving some longer explanation to a tooltip though. What about the button saying "place" or showing an icon, but the tooltip says "place image on map" or something?

@jywarren, @7malikk... you know I'm wondering why will a user have need to fetch 100images (and having to wait) in one fell swoop when there's only so much images the user can distort/knit per time. If IA API provides a way to fetch in batches, say 20images per fetch cycle from a folder containing 100images, we could improve user experience this way. Just thinking aloud.

[7malikk]

Hi, I think this is a good project to take up next. You might try opening a really big archive.org collection to see "how bad it is" when it tries to load a lot of images.
The other thought I had was - what if we have it fail gracefully -- i.e. we just search for thumbnails, and if there are no matches, we just show the full image. Although it could cause trouble (we'll find out how much trouble in the above testing of a big gallery), that way if there are some images without, the whole experience still fundamentally works even though you have to wait longer for them to load. This is complexity but if the complexity fails we're essentially reverting back to how it was, in terms of UX. What do you think?
The tooltip sounds interesting, but it might not work well on mobile devices. Sometimes we can shorten the text on a button by moving some longer explanation to a tooltip though. What about the button saying "place" or showing an icon, but the tooltip says "place image on map" or something?

@jywarren, @7malikk... you know I'm wondering why will a user have need to fetch 100images (and having to wait) in one fell swoop when there's only so much images the user can distort/knit per time. If IA API provides a way to fetch in batches, say 20images per fetch cycle from a folder containing 100images, we could improve user experience this way. Just thinking aloud.

I like the idea, i wonder what @jywarren thinks, do we go this route or do you have something else in mind?

[7malikk]

Hi, I think this is a good project to take up next. You might try opening a really big archive.org collection to see "how bad it is" when it tries to load a lot of images.
The other thought I had was - what if we have it fail gracefully -- i.e. we just search for thumbnails, and if there are no matches, we just show the full image. Although it could cause trouble (we'll find out how much trouble in the above testing of a big gallery), that way if there are some images without, the whole experience still fundamentally works even though you have to wait longer for them to load. This is complexity but if the complexity fails we're essentially reverting back to how it was, in terms of UX. What do you think?
The tooltip sounds interesting, but it might not work well on mobile devices. Sometimes we can shorten the text on a button by moving some longer explanation to a tooltip though. What about the button saying "place" or showing an icon, but the tooltip says "place image on map" or something?

@jywarren, @7malikk... you know I'm wondering why will a user have need to fetch 100images (and having to wait) in one fell swoop when there's only so much images the user can distort/knit per time. If IA API provides a way to fetch in batches, say 20images per fetch cycle from a folder containing 100images, we could improve user experience this way. Just thinking aloud.

I like the idea, i wonder what @jywarren thinks, do we go this route or do you have something else in mind?

[segun-codes]

Hi, I think this is a good project to take up next. You might try opening a really big archive.org collection to see "how bad it is" when it tries to load a lot of images.
The other thought I had was - what if we have it fail gracefully -- i.e. we just search for thumbnails, and if there are no matches, we just show the full image. Although it could cause trouble (we'll find out how much trouble in the above testing of a big gallery), that way if there are some images without, the whole experience still fundamentally works even though you have to wait longer for them to load. This is complexity but if the complexity fails we're essentially reverting back to how it was, in terms of UX. What do you think?
The tooltip sounds interesting, but it might not work well on mobile devices. Sometimes we can shorten the text on a button by moving some longer explanation to a tooltip though. What about the button saying "place" or showing an icon, but the tooltip says "place image on map" or something?

@jywarren, @7malikk... you know I'm wondering why will a user have need to fetch 100images (and having to wait) in one fell swoop when there's only so much images the user can distort/knit per time. If IA API provides a way to fetch in batches, say 20images per fetch cycle from a folder containing 100images, we could improve user experience this way. Just thinking aloud.

I like the idea, i wonder what @jywarren thinks, do we go this route or do you have something else in mind?

Okay...

[jywarren]

What about doing "pagination" (i.e. batches of 100 images) only on the client side, not via requesting fewer images from IA? So, we fetch all items in JSON, but only display 100 at a time?

For counting, maybe we need to pre-process (scan through) all images to count thumbnails vs. non-thumbnails? That can give us things like total count.

Regarding pixellation, are you using the original image when placing, instead of the thumbnail it's associated with? Each thumbnail has an "original" counterpart, right?

Thanks!!

[segun-codes]

I like your idea for issue #2. However, implementation such as resizing the image in normal size just before displaying it on the sidebar is worth thinking about. This way, you persist the only the normal size in storage and avoid creating two storages (in the program) for scaled-down size and normal size. I just hope this thought isn't bent somewhere.

[7malikk]

What about doing "pagination" (i.e. batches of 100 images) only on the client side, not via requesting fewer images from IA? So, we fetch all items in JSON, but only display 100 at a time?

For counting, maybe we need to pre-process (scan through) all images to count thumbnails vs. non-thumbnails? That can give us things like total count.

Regarding pixellation, are you using the original image when placing, instead of the thumbnail it's associated with? Each thumbnail has an "original" counterpart, right?

Thanks!!

Client-side pagination is a great idea, considering UI, what are your thoughts as regards say button placements?

Pre-processing, that didn't cross my mind, I'll note that down, Thank you!

Correct, I must've used the thumbnail as I executed the rendered image placement function alongside my filter for thumbnails. Noted

Thanks a lot @jywarren

[jywarren]

Hmm, interesting. Yes, I mean we kind of managed to avoid storing more info about the image because we just used the displayed image in HTML itself to transfer the URL to Leaflet:

Leaflet.DistortableImage/examples/js/archive.js

Lines 122 to 128 in 208ed4c

	document.addEventListener('click', (event) => {
	if (event.target.classList.contains('place-button')) {
	const imageURL = event.target.previousElementSibling.src;
	const image = L.distortableImageOverlay(imageURL);
	map.imgGroup.addLayer(image);
	}
	});

We could:

1. begin storing an associative array of objects recording thumbnail vs. original for each image, maybe keyed to URL... or,
2. add an additional attribute, like data-original-image="url/to/example.jpg" to the element, so the two are stored together. We could then check if there's an original attribute in the code excerpt above, when we receive the click on the Place button.

What do you think?

Regarding pagination... I'm not sure. Maybe we need the image list to scroll by itself so that the top of the sidebar remains visible... and then we can show something like gmail?

But perhaps we should move this whole pagination discussion to its own issue so we don't fill up this comment thread. Would that be OK?

[7malikk]

I like your idea for issue #2. However, implementation such as resizing the image in normal size just before displaying it on the sidebar is worth thinking about. This way, you persist the only the normal size in storage and avoid creating two storages (in the program) for scaled-down size and normal size. I just hope this thought isn't bent somewhere.

Thanks for your feedback on this, from my current implementation, it is as you say, a single size is created and when placed on the tile layer, it takes its actual size. I believe we're on the same page, but I would give it some thought and maybe call on you for more insight @segun-codes

[7malikk]

We could:

1. begin storing an associative array of objects recording thumbnail vs. original for each image, maybe keyed to URL... or,
2. add an additional attribute, like data-original-image="url/to/example.jpg" to the element, so the two are stored together. We could then check if there's an original attribute in the code excerpt above, when we receive the click on the Place button.

What do you think?

Regarding pagination... I'm not sure. Maybe we need the image list to scroll by itself so that the top of the sidebar remains visible... and then we can show something like gmail?

But perhaps we should move this whole pagination discussion to its own issue so we don't fill up this comment thread. Would that be OK?

Alright @jywarren

• okay we first store originals and the thumbnails in an array of objects, with the URL as key, like so?:

const images = [
{
 "original": "url/to/example.jpg",
 "thumbnail": "url/to/example_thumb.jpg"
}]

• I'm not sure I fully understand the second point, could you please clarify?

Alright, I will create a separate issue regarding that and ping you, we can also have more discussions on it.

[jywarren]

In 2) I meant instead extending the idea of storing the second url in the same html element by adding a custom attribute. Custom attributes I believe are supposed to start with data-______. Make sense? It's kind of nice not to manage a separate array as @segun-codes pointed out.

[7malikk]

In 2) I meant instead extending the idea of storing the second url in the same html element by adding a custom attribute. Custom attributes I believe are supposed to start with data-______. Make sense? It's kind of nice not to manage a separate array as @segun-codes pointed out.

@jywarren Alright, I believe I understand what you mean here. Thank you!

[segun-codes]

I like your idea for issue #2. However, implementation such as resizing the image in normal size just before displaying it on the sidebar is worth thinking about. This way, you persist the only the normal size in storage and avoid creating two storages (in the program) for scaled-down size and normal size. I just hope this thought isn't bent somewhere.

Thanks for your feedback on this, from my current implementation, it is as you say, a single size is created and when placed on the tile layer, it takes its actual size. I believe we're on the same page, but I would give it some thought and maybe call on you for more insight @segun-codes

Okay.