Transcription of Ouro Audio Log #1

Hi everyone, I'm going to try a little something new here, this is just a voice memo, but instead of a video vlog this week, I'm just going to do audio.

I'm out here on a walk right now, the sun is out, it's beautiful. I just wanted to share some of the new stuff going on on the platform, what we've been working on, where we're going, and all that.

I'll probably turn this into a post, so I'll use some of the platform functionality. I'll save this as an audio file, pass it to a Hermes route - one that can create transcriptions and then if I end up rambling, we can summarize it or extract some valuable stuff out of it.

Trying this out, it's a new way of creating content, we'll see how it goes.

The biggest priority and focus the last couple weeks has been on SEO and organic discovery of content on the platform. This initially started with a new URL structure for all the assets and the core resources on the platform.

Originally, I had it really structured in the four elements, so earth, you had your datasets, water, you had your services and routes, air, you had your posts and conversations.

I think that was a lot of unnecessary structure and it made URLs for things really long. So it would be like /app/dataset/a-really-long-UUID to signify the dataset. Yeah, it was ugly, I really didn't like sharing those links around because it was just so long.

The other thing is you had no idea what you were getting when you got that link. So I learned a little bit more about SEO, I learned that the URL actually kind of does matter a little bit in terms of how search engines might rank some piece of content. It's also just better for like shareability and understandability and discoverability.

When you get a link now, you know what kind of asset it is, you know the author of it and you know the general idea because you have the title in the URL now.

Some of the changes so far: get away with that whole hierarchy and now at the root level, and we also got rid of like the /app, so it used to be we had like our marketing and blog and documentation, kind of at the root level, so like /docs, /content, /whatever. And then that was separated all from like /app, which would then signify that you were in the app and you were able to do stuff there, so you needed to be signed in past that point. And then because we still, like from the beginning we knew we wanted to have public and monetized assets discoverable, we had /public/elements/earth, whatever, etc. And so that was kind of like a public version of one of the assets that you might find at /app/whatever. That was kind of ugly, unmaintainable, so we've really cleaned that up.

And so now, there's this common trend that you see nowadays where the distinction between what is the app and what is marketing material and what is kind of like the external and the public facing part of the website, that distinction is shrinking quite a bit. And so now we don't have any sort of idea of /app or /public, if you're looking for like text or post content, you just go to /posts, or if you're looking for datasets, /datasets. This is all off of now the main base URL.

To fully construct a URL, that asset is the first part, and then the user or the organization that created it, so it's going to be like /posts/mmoderwell/name-of-the-post.

Like I was talking about how there's so much more information now in the URL that actually is meaningful. We have that all together now. It feels really good to have that. I think it's going to be worth it. It wasn't too hard to implement. And really what I'm most happy about is getting rid of that UUID that was in the URL. That was really kind of unwieldy and just not user friendly.

So that was last week.

Most recently is now continuing on this SEO train, but focusing on like the content of pages, specifically post content.

When SEO or when a web scraper, web crawler for Google, for example, goes to your website to index it, it's usually a really kind of bare bones, minimal browser. There's probably no JavaScript being executed. Not any.

So really what matters is like your base HTML content that gets sent from the server to the client and just that initial load. Most likely if you're a user, you can't really tell what's server side and what's client side.

Nowadays, like the load time is just so instantaneous and there's all sorts of preloading and fancy JavaScript that can be done there and the user won't notice. But the web scraper or the web crawler can, because it's not executing that JavaScript to be able to do any of that advanced functionality.

For posts, initially we had client side rendering on the post content itself. We had kind of like a header card where we had the title of the post and the description and kind of when it was published, the author and stuff like that. But to actually render the content, because we have a rich text editor on the platform that creates the content, we were using that same editor as the viewer. So it was kind of just a read-only version of that editor, bare bones a little bit, so you can't edit it when you're viewing it.

But yeah, that was all client side. So the problem was web crawlers, they're picking up the website, they're scraping and crawling the pages that we have, all the assets that people have created and posts, the things that people are writing about, but they cannot see what the actual content of the piece was.

That was kind of a big problem.

You get a lot of information now from the title, and that helped. But without actually being able to see the content, all the keywords that you might be putting in and the actual meat of the content, it wasn't there, so that was no good.

It did seem to work on making that server renderable. We still kind of have this dynamic approach where all the main text content gets loaded from the server, and that's sent immediately to the client. But for heavier resources like images and videos and 3D models, those will still be client-side rendered, and so what you get out of that is a really fast page load initially, but you still have the full kind of interactivity and dynamic content that you want to see however you want to create your posts.

So very happy with how that came together. We did lose a little bit of functionality, and I'll work to bring that back, but in this transition, syntax highlighting on code blocks has gone away. I imagine that'll be pretty easy to bring back, but it wasn't something I could immediately do. Hopefully that's not too much of an issue for most people, but we are working on it.

That's it for the latest platform updates.

I put out a couple posts recently. Most recently I was talking about StabilityAI and OpenAI's image generation routes that we support on the platform. DALLE for one, and Stable Image Ultra is the other. I was playing around with the look and feel, comparing how when you give them the same prompt, what are the differences in the images that they generate. Kind of just a showcase of the functionality we have, but also kind of fun to see the differences in each of those products.

Yeah, that's it for now. See you next time.