A New Type.lol - A type foundry index—and more!

MarkJohnson · March 4

@Nick Shinn Done. If you ever change your mind you can let me know or re-submit. Best of luck to you and your endeavors.

Ray Larabie · March 5

@MarkJohnson I mentioned earlier that automation doesn’t really work for Wikidata, though to be fair that might just have been my experience. I spent about a week trying different approaches to automate entries and mostly ended up wandering down dead ends.

That said, if you can get batch submissions working reliably, there’s no real reason you couldn’t transform your data into the required format and push it through. If you’re planning to experiment with that, it’s worth starting sooner rather than later; there’s a bit of a waiting period involved before you can run larger batches, and having an established Wikimedia account helps.

One practical tip: AI tends to explain how these tools worked in the past, not necessarily how they behave now. It’s better to look for recent, real-world examples of working submissions and follow those.

MarkJohnson · March 5

Good call. Question for you on that @Ray Larabie, have you tried using playwright for any of your exploration? That was my fall back idea in my mind this morning if there's no API or connection I can make myself. But again, I've not really gotten through what's possible there. I can't imagine it will be wildly fast and immediate, but...maybe possible through that if nothing else?

Ray Larabie · March 5

No, I didn't use playwright, I was using Quickstatements. There are structural fragilities to say the least. Cryptic failures, opaque limbo, and from my guess, a thin wrapper over a brittle backend. And pile on some mid-job token expiries, and mysterious timeouts!

I couldn't even get it to successfully upload more than a couple of entries.

Johannes Neumeier · March 13

MarkJohnson said:

Then you will sell this platform to Monotype or some such corporate investor.
This is completely antithetical to the purpose of type.lol. While I understand the concern, I run a foundry and don't sell through any other resellers despite the potential to make more literal money, but with far worse terms, conditions, and financial incentive.

Could you (regularly) make a database dump of your foundry/font data available with a CC/open source license?

I don't agree with @Nick Shinn, but I also don't disagree. The only way to dissuade the critisim of this data eventually vanishing (into the abyss, or into the corporate behemoth) is if the data isn't yours alone.

Nick Shinn · March 13

That was my point, Johannes.
Good intentions are worthless in the long run, if one is creating instrumentality that subsequently enables unwanted, unintended outcomes.

MarkJohnson · March 16

@Johannes Neumeier Yeah, for sure. Open data aligns with what I'm trying to do ultimately, I just want to be safe about it and be careful and intentional with what is shared.

On one hand I've created a resource to find information out about foundries, designers, and typefaces which has so far gotten relatively positive feedback despite imperfect data currently. On the other hand some folks don't want their info openly shared if it's not accurate—which not all of it is yet, nor would I imagine it to be accurate in perpetuity.

Like, even in this thread, does @Nick Shinn want his data public or not? Who should be able to edit data about him, his type, his foundry? Only Nick? Who gives that management permission? Right now by having it on type.lol, at least everyone can point at me and say, "I hate you Mark, specifically you—for this data being inaccurate." I can live with that.

I would hate to just open it all up to produce even less accountability or responsibility to making a good end product. So I'm thinking about what the right version of this looks like. What data should be open? Under what license? With what governance? Not opposed, just want to do it right.

John Hudson · March 17

Thinking aloud:

If foundries want accurate information on aggregated sites, maybe there should be an openly defined data format for information that foundries would maintain themselves and that would live on their web server? This would not only ensure that information is accurate and kept up-to-date—or, rather, as accurate as the foundry makes it and keeps it—, it would also provide a means to opt in/out of at least some aggregate sites that might choose to only list foundries that provide data in this format.

Typedesigner · March 17

@MarkJohnson On my website https://typedesigner.de you can browse my font families and see the available licensing options and pricing for each typeface if you would like to list them in your directory.

MarkJohnson · March 19

@John Hudson Interesting idea! I think the intent is right and totally makes sense. Foundries should have agency over how their data appears on aggregated sites.

I think the main challenge is on the mechanism. A new data format that foundries maintain themselves has a rough adoption curve. I worry that asking people maintaining a separate JSON/XML file alongside their website or core focus is just creating one more thing to go stale.

The idea of a foundry maintainable abstract source of data that can't go stale would be ideal, but I don't know how likely it would be to be adopted or usable.

I think one version of this idea skips the file and works with what foundries already maintain: their website. The pattern would be:

Automated extraction: A service crawls the foundry's site and pulls structured metadata (typefaces, pricing, licensing, credits, classifications, etc).
Foundry admin access: The foundry claims their listing, verifies ownership, and gets an admin panel to review and correct anything the automation got wrong.
Open API: The corrected, foundry-approved data is available via a public API that any aggregator can use.

This keeps the maintenance burden near zero for foundries (they're already updating their websites when they release new faces), gives them editorial control over the structured data, and solves the distribution problem instead of every aggregator scraping independently and getting different things wrong, there's one canonical source that the foundry has blessed.

Type.lol is already doing steps 1 and 2. The open API piece is something I've been thinking about and just want to get right. Would be curious whether that method addresses your idea in a useful enough way.

Another approach I've thought about, but I think would be also challenging for adoption would be to basically create a javascript snippet on your site that's basically a beacon for this open data service to monitor, and when the website is updated, calls out to the open data service to scrape/update automatically.

Most of the issues I see generally are around:

Adoption
Maintaining the data
Governance (Who controls what? What is true? Who determines that? How do you do that without an account...I think you need one at the end of the day.)

I still think the Wikidata idea that @Ray Larabie suggested makes a lot of sense and I'm still looking into that.

MarkJohnson · March 19

@Typedesigner I added you and enriched the info there: https://type.lol/f/sergej-lebedev

If you create an account and claim your profile, you'll be able to manage your foundry and designer entities there

Typedesigner · March 19

MarkJohnson said:

@Typedesigner I added you and enriched the info there: https://type.lol/f/sergej-lebedev

If you create an account and claim your profile, you'll be able to manage your foundry and designer entities there

@MarkJohnson ,
embedding my full website in an iframe is not safe and can cause security and privacy issues. I have blocked it, so it won’t display on external sites. Thanks for understanding.

A New Type.lol - A type foundry index—and more!

Comments

Categories