Home » ryanseslow

Tag: ryanseslow

screenshot of the peekable web app in action

How Peekable Got Built

It started with a simple question: where are all my Adobe Dimension files?

https://ryanseslow.github.io/peekable/peekable.html

I have been making work digitally for over three decades, across a lot of different software, a lot of different platforms, a lot of different machines. Files accumulate. Formats change. Applications evolve in directions that do not always serve the work you already made. I knew I had a collection of .dn files (adobe dimension) scattered across both Google Drive and icloud drive, artifacts from a period when I was deep into Adobe Dimension, Adobe’s lesser used and even heard of 3D design and compositing tool. I wanted to find them all, put them in one place, and take stock of what was actually there..

The search turned up 68 files. Not just a few, sixty-eight. They were spread across dozens of folders, buried inside project directories, mixed in with everything else I had uploaded over the years. Google Drive found them quickly enough once you knew the right query to run. The harder part was what came next.

I copied all 68 into a single folder called Adobe Dimension Archive, which took a few minutes to organize. Then I looked at the folder and saw exactly nothing. Every single file showed the same generic icon, the kind of gray box with a zipper that cloud storage uses when it has no idea what to do with a format. No previews, no thumbnails, no way to know at a glance which file was which scene, which project, which year. I had organized 68 indistinguishable rectangles.

screenshot of the peekable web app in action

This is a problem that anyone who has worked with creative software long enough will recognize. Google Drive does not preview many creative archive formats at all, and for larger files it frequently cannot generate thumbnails regardless of format. (For the love of all things holy.. WHY google, WHY?!) The result is that large portions of a creative archive become opaque even to the person who made them. The files are there. The work is there. You just cannot see it.

What I did not know at first is that .dn files are ZIP archives. Adobe Dimension packages everything into a container using the same structure as a standard ZIP file, which means you can open one with any tool that reads ZIP format. More importantly, Dimension stores a thumbnail image inside that container. The thumbnail is there, embedded in the file, waiting to be read. The cloud storage platform just never looks for it.

Once that fact was on the table, the solution was obvious. Build something that opens the archive, finds the thumbnail, and shows it. The question was how..

The first instinct was to do this server-side, or with some kind of batch script. But both of those approaches have friction: you need a server, or you need to run code locally, or you need to download files that might be several gigabytes total. The cleaner answer was a browser-based tool that reads files directly on the client side, without uploading anything anywhere. JSZip, a mature JavaScript library, handles ZIP extraction entirely in the browser. The processing stays on your machine. Nothing leaves.

The first version was simple and specific: a drag-and-drop HTML page that accepted .dn files, used JSZip to unpack them, looked for a thumbnail at a handful of known paths inside the archive, and displayed whatever it found. I tested it against a set of 23 files. All 23 came back with thumbnails, which was better than expected, though the path where Dimension actually stores the thumbnail turned out not to be any of the standard locations I had guessed. The fallback logic, searching the entire archive for any image file regardless of path, is what actually retrieved them. Dimension tucks the thumbnail in a non-obvious location, and the only reliable way to find it is to look everywhere.

That result raised a question.

If this works for .dn files because they are secretly ZIPs with embedded images, what else works for the same reason?

The answer is: A LOT. Sketch files are ZIPs. Procreate files are ZIPs. Apple Keynote, Pages, and Numbers files are ZIPs. Microsoft Office formats including docx, xlsx, and pptx are ZIPs. Epub files are ZIPs. A wide range of creative applications use ZIP as a container and store a preview image inside it. The tool did not need to be specific to Adobe Dimension at all. It needed to be general.

So it became Peekable..

The idea is simple enough to say in one sentence: drop in any ZIP-based creative archive and see its embedded thumbnail in your browser. The supported format list covers Dimension alongside Sketch, Procreate, and a number of others, but really the tool works with anything that follows the same basic pattern. If there is an image file anywhere inside the ZIP, Peekable will find it.

The reason this matters beyond convenience is about access to your own work over time. Creative files from formats your cloud storage does not recognize or cannot preview become harder to navigate as collections grow. You can still open the file in the application that made it, but you lose the ability to browse what you have at a glance. Peekable does not replace the original application. What it does is let you see your work without opening anything, anywhere, on any machine, with no account required.

The tool runs entirely in the browser, processes everything locally, and requires no account, no upload, and no installation. It is a single HTML file. You can save it to your desktop and use it offline after the initial page load. It does not know who you are or what you put into it.

Getting it onto GitHub took more attempts than I am going to describe in detail. Authentication was the obstacle, as it often is. The web-based upload interface eventually did what the terminal refused to do, and the repository went up at github.com/ryanseslow/peekable. GitHub Pages turned the same repository into a live URL at https://ryanseslow.github.io/peekable/peekable.html, which means anyone can use it directly in a browser without downloading anything.

The whole thing took less time than I expected to build and more time than it should have to ship, which is a ratio that will be familiar to anyone who has tried to push something to GitHub after midnight. The tool works. I tested it against my own files. Other people who work in creative software and have accumulated archives of formats their cloud storage cannot render should find it useful.

If you have .dn files, Sketch files, Procreate files, or any archive from software whose previews cloud storage ignores, Peekable is at https://ryanseslow.github.io/peekable/peekable.html. Drop the files in and see what you made.

The repository is open, the license is MIT, and the code is a single HTML file.

Take it, change it, make it yours. Have fun and share!

 

From Archive to Agent: Making Creative Work Machine-Readable and AI-Accessible

From Archive to Agent: Making Creative Work Machine-Readable and AI-Accessible

Over the past several days, I have been working on transforming my personal archive into something fundamentally different from a traditional website or portfolio. I took an existing body of work spanning decades and converted it into a structured, machine-readable system that AI can discover, interpret, and act on.

The result is a live environment where over 10,000 items are now organized as a dataset rather than a collection of pages. This includes original artworks, digital compositions, writing, and a large media archive. Each item is structured with metadata, categorized, and made accessible through a central catalog file.

This system is not designed primarily for human browsing. It is designed for machine interaction.

In addition to structuring the archive, I implemented a discovery layer that allows AI systems to understand what is available and how it can be used. This includes standardized files that describe the contents of the site, along with endpoints that expose the archive in a clear and queryable format.

I also experimented with a transaction layer, where items in the archive can be licensed or accessed through automated processes. This part is still evolving, but it introduces the idea that creative work can be not only viewed, but also transacted upon without direct human mediation.

What becomes interesting is not just the technical implementation, but the shift in perspective..

What happens when an archive is no longer just something a person visits, but something an AI system can query, interpret, and build upon?

What happens when content is structured in a way that allows it to participate in new forms of circulation and reuse?

This has clear implications for creative practice, but it also raises questions for teaching, research, and institutional archives.

Within the context of CUNY, it opens up a number of possibilities.

Course materials could move beyond static documents and become structured knowledge systems that AI can engage with directly.

Student work could exist as more than final submissions, becoming part of a larger, searchable, and interactive archive.

Research outputs could be organized in ways that allow them to be discovered and referenced through emerging AI interfaces.

Libraries and institutional collections could begin to extend their reach into machine-readable environments, increasing access and long-term relevance.

This is not about replacing existing systems, but about adding a new layer that prepares content for how it will be accessed in the near future.

I have documented and deployed this system across my own sites, and it is currently live and functioning.

If there is interest, I would be glad to explore a small pilot within the CUNY ecosystem. This could take the form of a single course, a limited archive, or a hybrid approach that tests how these ideas operate in practice.

I am particularly interested in how this might intersect with teaching and learning, digital humanities, and library systems.

Curious to hear thoughts, questions, or potential directions this could take within the CUNY community!

 

By the way, I launched a museum (yes, it is a part of this too – RSMAD <– )

An Exhibition in Virtual Reality

a low angle perspective view of the interior of a VR art gallery of digital arts by artist Ryan Seslow

My First VR Gallery: A New Portal Opens

Over the last few years, I’ve been experimenting with VR and something that feels like a return to a truth I’ve always known:

Art wants to live in worlds, not just walls.

Using a platform called OnCyber, I built my very first VR gallery space. You can watch the video above as a preview, but if you have a VR headset, go to this link (obviously).

It’s a simple structure, but it’s filled with powerful energy, the energy of real work, real time, real effort.

Inside the gallery, you’ll find a collection of my 1/1 Crypto Art originally minted on my SuperRare profile (many of which have not sold yet, which is a perfect reminder that creation doesn’t depend on outcome). Along the floors, I dropped a few of my newest 3D sculpture experiments as well.

They are playful markers of the new worlds I’m beginning to build.

This space wasn’t about selling.
It wasn’t about chasing attention.
It was about honoring the archive and giving life and motion to pieces that otherwise sit quietly behind digital walls.

It’s about creating a new portals where the work can continue breathing, evolving, and radiating its energy. I love my work and deeply believe in its value to inspire my fellow humans.

“The Tessellation Garden” project is coming soon… but this first step felt necessary.

(Oh, and I promise that I will be sharing my full artist residency works / studio with the Loop Art Critique / MUDD foundation here soon too!)
A reminder to myself that building worlds starts with the tiniest acts:
dragging, dropping, rearranging, giving your work a home inside imagination.

In a way, this first VR gallery isn’t just a space.
It’s a seed.

A seed for new worlds, new viewers, new expansions I can’t fully predict yet, but can already feel the buzzing in the air.

 

Thank you for being here!