New Portraits of Children card for Ephemera

[jrbuck99]

I don’t find this exact card in Ephemera, though there are similar ones.

It’s essentially the same card as girl in pink dress and hat stands holding a basket of flowers in front of a large screen - TuckDB Ephemera but with “New Year” instead of “Christmas” in the greeting. It also belongs to Artistic Series 2307 and is the same size.

From a purely descriptive standpoint, I would have said that the card design/image is the same, only the caption is different. However, with your new Ephemera structure, it seems like you’ll have to give it a different item “title” to differentiate the URLs. I can’t say I’m a fan of that approach, but then since I’m not a Tuck collector, I’m not really your target audience. I really thought the previous item numbering scheme worked fine.

And, as far as cards using essentially the same design, young girl carrying a basket of flowers - TuckDB Ephemera, from Series 2376, also seems like it should have the same descriptors (or title) but, of course, doesn’t. I can’t help but feeling that as the Ephemera DB grows, this sort of fragmentation will only increase. Oh, and for Series 2376, I believe child in winter coat and hat stands with doll - TuckDB Ephemera should also be in the same set as the Series 2376 girl in pink, but they’re currently split up.

[justintanner]

@jrbuck99 thanks for that feedback. Are you referering to the end of the url:

items/girl-in-pink-dress-and-hat-stands-holding-a-basket-of-flowers-in-front-of-a-large-screen

Or the Set title

portraits of children (2307)

as the confusing part?

[jrbuck99]

@justintanner The item title, which has now replaced your item number at the end of the URL.

I don’t know if I’d call it confusing so much as an invitation to inconsistency. Now you’re using the item title as a unique identifier, but, since most Ephemera items don’t really have titles, the item “title” is actually a description of the item’s image or design. However, since multiple cards use the same basic image, in order to have a unique identifier, you have to come up with different descriptions for cards that look essentially the same, except perhaps for the caption or greeting, which is generally given in the item comment.

So, now you have “…items/2082” becoming “…items/girl-in-pink-dress-and-hat-stands-holding-a-basket-of-flowers-in-front-of-a-large-screen” and “…items/547” becoming “…items/young-girl-carrying-a-basket-of-flowers”. They’re basically the same design, but from different series. Continuing to use unique item numbers in the URL would have allowed you to (eventually) provide a more consistent item title/description for these similar cards, which I would hope would be a long term goal for the site. Now, you have my newly uploaded card with, again, the same design, but which will require yet another unique item title to accommodate your new structure. It wouldn’t surprise me if there are other cards out there with that same design that have yet to be reported.

So, all in all, it just seems to me that you’re putting yourself in a position that will make it more difficult in the long run for you to associate similar cards based on their descriptions, something that I think would be of interest to at least some Tuck collectors. Again, though, not being a Tuck collector myself, it’s just my opinion!

[justintanner]

@jrbuck99 Interesting, yes many of the slugs (urls with words like “girl-in-pink-dress…”) start the same, just like many items in the DB (postcards and ephemera) have the same or very similar titles.

Are the slugs worse on the eyes than the old database primary index (internal number) that was there before?

My decision to use slugs was to help search engines find the page and rank it. Internally we still use a database primary ID.

Slugs will automatically find a unique name no matter what. Code works like:

1. Try the title as the slug
2. Try the title + any other text on the item (can be set title, or even comment)
3. Repeat until it’s unique

[justintanner]

@jrbuck99 Also I decided to add you images to existing card and update the comment.

[jrbuck99]

@justintanner I don’t know that “worse on the eyes” is a real big consideration, although I’d say that the trend these days for many web sites (not just TuckDB) to use those “slugs” in the URL certainly make those URLs look downright cluttered and unwieldy. I definitely wouldn’t want to try to type one in to get to a web page! I guess that technique qualifies as a “best practice” in web design these days, though I’m not a fan.

It used to be that including a web page’s key words in Meta tags, which a site’s visitors would never see, could supposedly accomplish for search engines what you’re saying that the slugs are now intended to do. Has that technique been deprecated? When I built my first web site (now long gone) in 1996, Google wasn’t even born yet, and when I built the Arbuckle trade card site in 1999, it was barely in diapers. The leading search engines were ones like Alta Vista, HotBot and Lycos, I think. And it was the actual text in the web pages that seemed to matter most.

In any event, the point I’m trying to make is that if cards look basically identical, it seems to me that they should have the same descriptor(s), whether it’s in the title or some other field. That way, if a search result, whether external or internal, turns up one of those “girl in pink dress” cards it should turn up both, even if they’re in different sets, as these two are. But if one is found as “girl-in-pink-dress-and-hat-stands-holding-a-basket-of-flowers-in-front-of-a-large-screen”, that doesn’t particularly help finding “young-girl-carrying-a-basket-of-flowers”. The only commonality between the two is “a-basket-of-flowers”. If I were just coming to the Ephemera site for the first time, trying to see if there were any Tuck cards using the same design as the corresponding Arbuckle card, it seems highly unlikely that I’d find both using the obvious key words.

Now, I realize that the inconsistency in the item titles for those two cards probably already existed. There appear to be many other pairs or groups of look-alike cards in Ephemera with a similar issue. It’s just that by making that title part of the URL, you’re basically locking in that inconsistency and likely preventing any future effort to institute common descriptors between or among them, which I hope would be a long term goal. You won’t be able to make changes to the item titles without the effect rippling into the item’s URL, thus affecting any user bookmarks or external links to those cards.

[justintanner]

@jrbuck99 interesting, yeah the slugs are not amazing for Postcards or Ephemera.

The meta tags are there as well, getting a site to pass SEO is a long checklist of stuff. When I designed TuckDB 10 years ago, I decided against slugs, this time I decided to check every SEO checkbox.

As for changes, that’s okay because the item contains a full history of every past slug, so changes won’t be a big deal. The history also includes the legacy /items/123 urls as well.

I’m worried the that slugs simply too long and they are kinda unwieldily.

You got me thinking, maybe this scheme will work better:

/items/123-item-title-but-cutoff-at-a-reasonable-limit

That would solve most of the problems and doesn’t look too bad.

What do you think?

[jrbuck99]

@justintanner I suppose the question that comes to my mind, irrespective of whether or not slugs are unwieldy or unsightly, is whether they really buy you that much at all in terms of SEO. What audience are you trying to reach with a perhaps marginally higher ranking that you aren’t already reaching?

I tend to think of search engine rankings as being primarily useful for commercial, or at least monetized, sites that are in competition with other similar businesses. If I were operating a store selling green feathered gizmos, I’d certainly want my store to rank right up there with any of my competitors’ stores when a potential customer went searching specifically for a green feathered gizmo. But what other sites do you see TuckDB competing with for search traffic, and who are the potential visitors you think you might gain with a higher ranking?

It seems to me that most current collectors of Raphael Tuck cards and such would already have found your site over the past 10 years. Are you trying to reach someone who’s curious about a Tuck card they just found in Grandma’s attic, and who goes to Google to find out something about it? If so, what search terms do you think they’re likely to use to find such a card.

Currently, simply entering “Raphael Tuck” already brings up TuckDB Postcards as the third Google result. Search for “Raphael Tuck card” and you come in second, right behind Wikipedia. It’s hard for me to see how an increased search ranking would gain you very much. Now, I suppose if they searched for “Raphael Tuck card girl in pink dress”, improved SEO might make a marginal difference, but is someone likely to be that verbose initially. My expectation would be that they’d start with something simpler in their external search and then refine it in an internal search once they reached your site. I know that’s the way I’d do it, but perhaps that’s just me!

For a site that’s basically image driven, I would think that one tweak you might consider would be the use of alternate text (alt=“girl in pink dress”) with each card image. These days, Google tends to present a selection of images at or near the top of the first search results page. I’m inclined to think that if somebody did enter more verbose terms in Google, trying to find a specific card, that they might very well try looking at those image results first, and perhaps associating alternate text with an image would help raise that image’s visibility. If there’s no alternate text, I believe Google just picks up nearby text in the associated web page and uses that instead.

Anyway, it’s good to know that, if you do stick with slugs, that any future changes to item titles and such will still chain back to previous URLs. Each of the images from TuckDB that I’ve added to my own Arbuckle site is paired with a link to that card on TuckDB and, since I don’t update a page unless I’m adding a new image to it, as it is many of my links are already a generation or two behind relative to your current domain names!

[justintanner]

I’m missing a few alt tags, and i’ll keep an eye out for them, thanks for the reminder.

I thought along the same lines as you back when I designed TuckDB, why bother with SEO for a non-profit, but now that I’m looking to generalize this for www.collectionpub.com, some collectors may want SEO. My thoughts were do an SEO audit once and then it’s set for all sites.

Aside from Google, Bing, ByteDance, indexing my sites as they are doing non-stop. I think my new scheme:

/items/123-young-girl-carrying-basket

vs

/items/123

Is more information, its helpful on it own, to answer the question, what page is that?

[jrbuck99]

@justintanner Ah, I didn’t realize that CollectionPub was being spawned by TuckDB. I had assumed it was just a new tool that you were using to rebuild the site. There are almost always compromises necessary to go from a task-specific tool to a more generic one.

I suppose, then, I should mention what appears to be a browser-specific issue that I’ve run into with the new platform. In your old system, search results or category browses that included a large number of items were displayed in multiple pages with a fixed number of items on each page. Your new system seems to attempt to display them in one neverending page that repeatedly loads more items when page scrolling nears the bottom of the page. That appears to work fine in Google Chrome although, frankly, if I’m trying to work my way through a few thousand items, I much prefer discrete, fixed-quantity pages. What I’ve found though, is that in my primary browser of choice, Pale Moon, and even in Firefox, my second choice, the loading of additional items seems to hang after the first 25 items. That little spinning wheel just keeps endlessly circling. Essentially, the same thing happens when trying to display the category tags, but not until after the first 30 tags in that situation. So, it seems like whatever you’re doing to load those extra items is handled differently in Firefox (with Pale Moon just being a Firefox fork) than in Chrome. I haven’t tried it in Edge, that being pretty much at the bottom of my browser choices.

[justintanner]

@jrbuck99 wow, thanks for the bug report.

What OS are you using, windows 10, 11?

And what version of FF are you on?

On mac both Pale Moon and Firefox are working, atm.

[justintanner]

But that spinner should have a fallback, thats not working, obviously.

[jrbuck99]

Okay, I found the root of the problem, although the lack of fault tolerance still exists and probably should still be addressed.

I have a long-standing aversion to the acceptance of cookies and only add exceptions to my settings on a site-by-site basis when absolutely necessary. It seems you’ve now started requiring cookies for certain functionality in Ephemera (and Postcards, too, I assume). Some time back I had added an exception to allow cookies for tuckdb.org in order to log into the forum, but had never seen a need to do the same for tuckdbephemera.org. Adding that exception seems to clear up the problem, as long as I go back and reload the front page first.

Another question did arise while testing out that solution, though. By having pages that keep adding items as scrolling nears the bottom, it makes it somewhat difficult to get to the links at the bottom of the page. Once I found that the continuous loading was working now, I tried to get to the forum link and found that I had to jump ahead of the loading to get to the bottom, and then act fast before those links got pushed out of view!

[justintanner]

Interesting, so toggling on cookies made it work, that’s a bit weird, as that bit of JavaScript shouldn’t have much todo with cookies. I’ll double check the cookie settings, they should only be used for owners login to their collection, nothing else. I went outta my way to make these sites, tracker-free and cookie-free, because they don’t have ads.

Infinite scroll definitely has some drawbacks as you mentioned the footer pages are hard to get to, I originally jammed all the footer pages into the top right “hamburger” button, but it was a bit too much in one dropdown. I’ll have to think of something else.

I’ll consider making regular pagination an option, in the meantime the list view is currently using regular pagination, no infinite scroll.

If you see anything else weird let me know.

[jrbuck99]

Yeah, it’s definitely a cookie issue. I just went back and ran through what I’d call a full cycle trial. I started with my cookie exception list set to accept tuckdbephemera.org, went to the Ephemera front page, selected the Christmas tag, then scrolled down, and down, and down. Worked fine. I then got completely out of Ephemera, deleted the exception from my settings and repeated the above sequence. The scrolling stops after the first 25 items. Once again, I exited Ephemera, re-added the exception, and it all worked just fine. So,definitely the cookie. There appears to be only one, “_collection_pub_session”, with typical gobblydegook content.

It appears, too, that there are at least a couple other minor effects when the cookie is blocked. On the front page, card images do not appear under the “Featured” header, just white space. Also, on the item results page, the boxes at the top for Sorts and Filters both show “0”, whereas when the cookie is enabled, and the scrolling works, those boxes show “5 Sorts” and “1 Filters”. Perhaps that info will help you zero in on the problem. Good luck!

[justintanner]

@jrbuck99 got got bottom of that bug, you were right the cookies turned off broke scrolling and a whole lot more.

Sites should now work fine with cookies off.
Also fixed those alt tags and images kinda looking crumby while loading in FF.

Thanks again for the bug reports, let me know if find anything else.

[jrbuck99]

Yep, @justintanner, that does seem to fix those problems. I still don’t really care for that infinite scrolling concept, but maybe that’s just the old fogey in me! However, if I want to browse through a large category (“tag”) or a search returns many hundreds, or thousands, of items, I’d rather not have to scroll forever on a single page just to see them all.

I did take a look at the List view, which I actually hadn’t even noticed before, but those thumbnail images are just too small for me to get a sense of what the cards look like, and it’s those visuals that I go by to see if a card I’m looking for is already in the DB.

I did also find a curious anomaly in that List view, and it seems to be browser dependent, so it may just be an issue of how the various browsers implement horizontal scrolling for a table. In Pale Moon (32.4.0), I get an initial page that looks like this:

However, when I scroll to the right, there are no other columns, just white space as far as the eye can see. In Firefox (102.15.0esr), I initially get:

Notice that there’s no horizontal scroll bar. However, if I increase or decrease the window width even by just a pixel or two, the scroll bar appears and everything scrolls fine. All the other columns appear to the right. At first I thought it was just a flukey quirk having to do with the precise window width I happened to start with for Firefox, but further trials with wider or narrower windows showed that it didn’t matter. It doesn’t seem to be a cookie issue, either, as toggling the setting between accept and block didn’t matter. (However, I did notice that if I allowed cookies for the site, it still stores one.)

Here’s a much wider starting window, with the same quirk:

Again, increasing or decreasing the width by just a pixel causes the horizontal scroll bar to appear and function properly.

Oh, and Google Chrome doesn’t seem to have the issue at all. Really weird, I’d say!

[jrbuck99]

@justintanner Just out of curiousity, I decided to take a look at the Error Console in both Pale Moon and Firefox to see if anything was being flagged on initial entry to the List view page. Pale Moon offers the following:

Timestamp: 9/9/2023 3:18:16 PM
Warning: Relative positioning of table rows and row groups is now supported. This site may need to be updated because it may depend on this feature having no effect.
Source File: https://assets.tuckdbephemera.org/assets/application-c504518bc5ef8710639b5598d220d41c91e94eee233d0aa95a94bb087dcbfbbe.js
Line: 56

Firefox says pretty much the same thing:

Relative positioning of table rows and row groups is now supported. This site may need to be updated because it may depend on this feature having no effect. application-c504518bc5ef8710639b5598d220d41c91e94eee233d0aa95a94bb087dcbfbbe.js:56:85794

Now, I haven’t a clue as to whether or not any of that is meaningful, but I just thought I’d pass it along.

[justintanner]

@jrbuck99 wow thanks again, I’ve got the scrolling working in Pale Moon, give it a try when you get a chance, as for the warning, I’ll keep an eye on it, I’m not taking any action ATM.

If you see anything else let me know.

[jrbuck99]

Okay, @justintanner. I just tried it again and what I found is that the behavior in Pale Moon is now the same as Firefox, in that initial entry to List view does not display a horizontal scroll bar. However, once I force the scroll bar to appear by tinkering with the window width, I can see that all the columns off to the right are now present.

I did find, though, that in addition to conjuring up the horizontal scroll bar by changing the width of the window, I can also get it to appear by clicking on one of the links in the page and then using the browser’s back button to return to the List view page. It appears as if there needs to be a forced window resize or refresh event after the table is loaded before it realizes the horizontal scroll bar is necessary.