Problem statement

I need to actualize the boxhouse.

The boxhouse must allow me to host various written and visual things. This includes structured essays, less structured discussions, a variety of photo albums, my books, and miscellaneous records (recipes, opinions, mental frames, etc).

I need to understand how to incorporate Claude into my workflow. I need to allow this new technology to facilitate and thereby amplify my preexisting capabilities.

Key lessons

The boxhouse is one of my canvases

I don’t need to force content into more traditional formats. The boxhouse itself is part of my aesthetic–and so how I’ve decided to design it is part of my content. This book looks so much cooler now that it has a visual relationship with the page.

Progress tracking has a strategic value when using AI as a tool.

During this process, I updated my git repo quite often. That wasn’t enough though. My changelog idea really solidified things, and ensured that I was focused–and knew how to ensure that Claude was focused.

Recordkeeping on process and reflections on what’s going well/not well are strategic for me, as they helped me think things through, and for Claude, as my documentation behaved as its compass.

Given the strategic importance, I wouldn’t trust anyone other than me to both store and maintain this document (so, no using external solutions to manage your recordkeeping).

Also, see my discussion (link) on persistence (/link). That links to this observation. Recordkeeping facilitates attention.

Ask what’s necessary from a package; ask if that should be reproduced by Claude

Paged.js has a lot of solid components that I needed. They were sullied by certain features–that were effectively bugs to me. Claude had enough context to just reproduce the feature I needed, which efficiently dealt with the issues we were spiralling around.

Work categories

Visual cohesiveness

I need boxhouse’s visual presentation to contain my essence, though I must maintain a cohesiveness as well. I landed on a replication of MacOS’ visuals with a degree of flexibility.

Navigation page

I need boxhouse’s landing page to mimic a spiral. Once clicked, the spiral should “unfurl” and display four overarching directories. A number higher than four would be untenable.

Post page

I need boxhouse to display my written content. I write with a lot of peripheral commentary that I like to provide, but can distract from my main point. I need a way to retain this commentary without disrespecting the post’s integrity.

Image viewer

I need boxhouse to display various images, such as my film photography, my outfit coordinates, and my collages. The framework must be flexible—I may decide to include other categories later on, or remove categories. Furthermore, my film photography (and certain collages) includes portrait images, which adds a layer of complexity.

Dream catalogue

I need boxhouse to display dreams in a catalogue—very similar to the image viewer. Essentially the same concept, just with text boxes instead.

Book page

I want to emulate a traditional book within the boxhouse. I need to paginate my books. I already have my first book, the gumgum galaxy, in a 39 page PDF.

Mobile considerations

I need to ensure boxhouse has some level of functionality on mobile. I am not happy about this, but it’s a good practice nonetheless.

Visual cohesiveness

My vision included a relatively simplistic navigation. Initially, I wanted this to be a spiral at the top left of each page. When clicked, I wanted a jittery line to crawl across the page. I then wanted my navigation categories to hang—initially, the idea was more like a curtain.

I also wanted rising bubbles—much like Madoka Magica’s visual motif.

Finally, I wanted to include colour theory in the website’s colour palette, and I wanted to allow the user to swap palettes. The footer was going to display the palette, along with the swap button.

Navigation

The spiral and menu idea transformed into the navigation/landing page.

In lieu of this navigation widget (more or less), I opted for a sidebar—like the MacOS finder. I thought this was very wonderful, since I really like file explorers.

I worked with Claude and got a working model pretty quickly. Bugs galore when I attempted to ensure it wasn’t in conflict with my main content windows.

Sidebar work

Bottom line up front: I nipped the sidebar finder. It wasn’t going to work with mobile. I would introduce too much dissonance if I stuck with the sidebar for desktop, and did something else for mobile.

Eventually, the sidebar got replaced with the sub directory pages and the drawers. I retained my vision, but harmonized it. I think it works much cleaner now.

Regardless, I did learn quite a bit from reading the sidebar’s CSS/JS code. I manually fixed a number of display issues—both on my own, and with Claude’s help. My workflow included a review of the code, identification of the blocks/functions that caused issues/bugs, articulation in human language what that code did and how it needed to do things different, and fine-tuning. Claude popped in during the final two steps.

I now feel a lot more confident on my own though. This was cool.

Drawers

I can’t remember how I arrived at these drawers. It could’ve been Claude, but also they’re very similar to the UI of a project I worked on during my master’s.

I had Claude implement a majority of the code. I have done a lot of the tweaking. As I approached 1.0, I realized how productive these drawers are, and expanded them to all post types.

I’m still not settled on these, so nothing more to say other than what’s above.

Rising bubbles

I used Claude to create this asset, though it whiplashed a lot.

I provided Claude with my vision, along with some example assets (Madoka Magica’s bubble spread + general colour logic). Some time during this, though, I latched on to the idea of platonic solids. Icosahedrons and dodecahedrons. I prompted Claude to take the same concept as the bubble, and turn them into platonic solids. Then for flare, I wanted the solids to spike when the user clicked.

I believe the only adjustment I input to Claude involved a wireframe instead of an actual solid image.

I had a couple JS files—one for bubbles, one for solids. I made sure Claude highlighted the configuration values, and from that point I could do everything on my own.

In general, I think this was the most successful aspect of development—though, I have not returned to optimize some of the effects (I’ve been meaning to, but it’s really low priority, and at this point I think this would be a good opportunity to explore a different methodology—unfurling and stress testing the tweaking phase).

Colour theory / palette swap

This got lost in the rest of my work.

I’m not sure if I want to return to it. I have new plans for the footer now—probably displaying those early internet stamps, scrolling, in a collapsed drawer—only on the main and subdir pages).

I go to Accidental Dignity for my palette stuff now.

Navigation page

The landing page birthed from the initial navigation idea.

I like this page a lot, since it’s very simple.

I hand-drew the spiral and directory titles in my sketchbook, scanned them, and animated them with GIMP. I don’t have much to say about this other than it was interesting, and it certainly looks amateur.

Spiral issues

When Claude first implemented this page, the spiral had no contrast against the background. I tried swapping images a couple times, though I would have had to use a very bright image to make the spiral visible. Awful.

My mind then went to “there can be a window underneath the spiral that can have its own bright image”. This was funny, as Claude interpreted “underneath” as a y-axis concept—not a z-index concept. ꉂ(˵˃ ᗜ ˂˵)

Even with this window, though, it looked awkward. As an interim solution, I uploaded one of my sketches (cigarette saturday….), and prompted Claude to make the window’s sides jagged. This looked really bad initially.

I went through the JS responsible for drawing the jagged window and made some adjustments. As time went on, I warmed to the way the jagged lines and my sketch looked together.

I made a couple prompts to Claude, attempting to make the transition between the background image and my sketch a little more natural. These sucked. I continued to warm up to how things looked, though, and then I just left it as is.

Directory headers & arms with terminal spirals

This aspect of my landing page was seamless because I had a very strong vision. I knew I wanted: -> SVG animations -> A layer of lines. One base, relatively steady, three jittery with varying amplifications. -> Spirals underneath the directory title assets.

I had to do some back and forth with Claude regarding placement. Now, though, after I’d worked alongside and watched what it did, I could probably handle that on my own next time.

I had to do some adjustments to ensure mobile wasn’t out of wack. It still is (lines/spirals are too big), but it’s functional).

Similar to the platonic solids backdrop, I had Claude highlight configuration values and adjusted on my own.

This was certainly a “this is fine for now, I’m not going to play around now”, though I have some fine-tuning ideas (matching the lines to my hand-drawn sketches, adjusting the mobile size, etc).

Subdirectory pages

As I worked on my site, I realized that subdirectory pages—sort of mimicking the sidebar finder in essence—made the most sense. Also, tables of information are very user friendly, very well-explored and documented, and well supported on mobile.

I don’t have a ton to say here, other than my initial vision had more tabs (wordcount, tags, summary). These increasingly seemed noisy, so I just ensured they were included on the post page proper—and in the post drawer.

A to-do I have here, though, is to make the tagging functional. I think sorting by tags makes sense—and that’s something that would be beneficial for my image viewer page.

A fun aside, I only have three of my four sub directories properly wired up. This is actually breaking the site when I serve it locally, because Jekyll doesn’t know what to do with posts with frontmatter like “type: games”. A nice follow-on project on my own. I’ll probably make a small dev diary as I approach that, because I need to inventory how these paged are wired so I can implement it on my own.

I have little interest in tapping into Claude for this unless I hit some crazy wall (which would be really concerning! (ó﹏ò｡)).

Post page

The post page was super straight forward.

The only issues I had involved CSS properties—partially thanks to the legacy of the sidebar finder. These were easy to fix.

Peripheral function

The peripheral function added quite a bit of complexity, which was a little bit surprising.

Claude implemented my vision by using the HTML element “details” and “summary”. When a post encounters a details tag, it embeds a symbol in the text. When a user clicks this symbol, a box pops up on the right-hand side and displays the peripheral text.

I had two requirements: (i) this cannot be rendered on mobile. Mobile users just won’t see this—too bad, site’s made for desktop; (ii) this should have minimal impact to the user’s focus.

Hide on mobile

Requirement (i) was pretty simple, but Claude had difficulty with “don’t show this”. It took a couple prompts and solid language, but eventually it implemented it cleanly. It wasn’t difficult, after all. Just setting displays to hidden (though I need to go confirm how it handled “don’t show this text at all).

Don’t impact post integrity

Requirement (ii) was also simple on the face of it, but introduced some weird complexity. For whatever reason, the JS Claude provided for the peripheral function had a strange interaction with paragraphs. If the details tag was mid paragraph, it would treat the text following the closure tag as a new paragraph.

This took a couple back and forths, but eventually Claude implemented it.

I need to go review how—I know it involved the JS and how it handled paragraphs.

Image viewer & Dream catalogue

These two components of boxhouse are very similar, so I’ve merged them for my discussion.

These pages are unique as they’re probably the most fluid. Each relies on the space available to the webpage. So: on desktop, it’s super wonderful and lovely. On mobile, it’s super cramped.

Desktop implementation

I encountered issues with how the images overlapped with the album/catalogue drawers. I just decided to anchor these to the left side of the screen, since that left more of the bottom page space for the images/dreams.

I had initially figured it would be nice to allow the user to adjust the windows. This functionality exists, but it struck me that many may not care to move things around. So, initial render size and position grew in importance.

I also wanted the user to open numerous images at once. I set the limit to five.

This was a pretty easy thing to adjust—I had Claude point me to the JS that was responsible for rendering images, and went from there. The main complexity that I definitely couldn’t handle involved portrait images. I asked Claude to add an if statement to handle this (if image is portrait, display like this). This was simple, and done quickly.

Also, Claude initially coded this weird feature where images would spawn off centre from the last image, but hit at a cap at the fifth image. I think I understand why someone would want this, but it just looked bad. I removed that from the JS.

Finally, some pretty simple things that aren’t worth going too into detail on: -> Users can navigate with keyboard strokes (arrow keys, esc button) -> Users can click a button to enlarge the image. -> A random tab to pull an image from any album

Mobile implementation

This proved to be much more buggy (somewhat unexpected).

I opted to remove a ton of functionality because I don’t like mobile users (´｡• ω •｡`). No navigation, no image adjustment, no multiple images open. Really bare bones—click on the line in the table, see the image.

I ran into placement issues. I more or less fixed them, but also I’m not going to try and make a portrait image display dynamically with my drawer. That is so much extra work for basically nothing—the site’s not meant for mobile.

One thing, though, is when I spammed the random button, I accidentally zoomed into the page a couple times. This was really annoying. I then noticed the bookpage did the same thing. I propted Claude, asking to remove that double-tap feature, which it did in short order. So that’s cool.

Book page

Four months ago, I created a book using notepad and GIMP. My book consisted of typographically consistent pages, along with page separators. Each page was a .jpg. I used Claude to create a script that bound these .jpgs into a PDF.

Initial idea

Display the PDF. I chose this method to maintain a level of security—I wanted to ensure my book wouldn’t be scraped by crawlers. Or at the very least, I wanted it to be difficult to scrape my book. While I understand this may be a bit of an unproductive task (it’s hard to prevent if something is publicly available), I figured an attempt at prevention would communicate clear intent.

I worked with Claude to implement this quite easily, though quickly realized that this solution was pretty awful. The PDF viewer was too rigid, especially when embedded into a webpage. Furthermore, issues quickly arose with the PDF’s dimensions. When I created the .jpgs. I hadn’t been able to fully appreciate some of the sizing factors.

This initial idea was a failure.

Pivot: paginator

I eventually decided to move to a model where my text would be paginated and displayed that way. This method seems like a fair middle ground, however I’ve lost any protection I’d envisioned for my book. I don’t really care anymore because I don’t value my writing anymore.

I believe Claude output a solution using paged.js and marked.js as I worked with it. These are two JavaScript modules that find use within various websites when displaying paginated text. Marked.js translates a markdown file into HTML, and paged.js takes that HTML and embeds it onto the webpage, The solution has some dynamism, as the HTML is affected by CSS properties. Accordingly, on a normal webpage my book would have somewhere around 40 pages, whereas on mobile, it would have around 70.

Development process

I often spun my wheels on the book page. Now that all is said and done, it’s very interesting. In the moment, it was very frustrating.

The initial implementation of the marked.js -> paged.js pipeline was simple. I did some monotonous work in translating the .jpgs into a markdown, but this was overall a good way forward (it also let me reassess what I actually wanted the book to say, which is why the vignette “virgin” was censored).

The tweaking phase, however, went poorly. No matter what I did, the embedded book would not respond to CSS properties. I wanted the book to be centred, with some space from the top. I wanted the controls on the bottom. I wanted a content warning. I wanted top headers to display the separator pages.

If I fixed one thing, something else broke.

Over a couple of days, I worked with Claude, sending screenshots, and making minor adjustments. While none of this was very productive, I did pick up a few really good key lessons.

First, dev tools are really helpful. I debugged using the inspector, which taught me a more general debugging progress. I also intuited that I could just start using the element’s displayed properties to change variables one at a time to home in on what was causing issues. Second, JavaScript debugging console logs are great. Admittedly, this still sits a little bit out of my domain, but going forward I will definitely be building in my awareness of console log flags for JavaScript outputs that I’ve identified as buggy.

After the site went live, I had some issues arise with how the paginator treated paragraphs. This was very apparent, as the first page of my book was about 60% dead space—it punted the second paragraph to the next page.

I fixed this with Claude—partially due to exhaustion, partially due to inexperience. It created more code that instructed the paginator to handle paragraphs dynamically, splitting them once it hits the bottom of the book body’s length.

I then had some follow-on issues with the book body’s length. For this, I just had Claude isolate the code responsible for the length, and fine-tuned.

THEN, I found that the page didn’t work super great in instagram’s webpage emulator, to which I said “that’s nice, go explode” and moved on.

Removing paged.js dependency, distilling key components

After a fair amount of debugging, I observed that paged.js seemed to be a little too heavy for my purpose. I wasn’t very aware of what it was used for more generally—which I should have gotten more information on immediately. Upon presenting this observation to Claude, it suggested pulling the dependency, and instead writing around 80 lines of paginator code—effectively distilling out what really mattered for this project.

I am struck by how powerful this solution was. It solved the main display issues I’d be grappling with—while also strengthening the codebase by removing a dependency.

I am also struck by the amount of superfluous code I could’ve had swimming around if paged.js hadn’t been so strict. My mental model grew quite a bit, in that I am able to identify concepts from packages or dependencies, and translate them into my own codebase without any auxiliary functions that aren’t necessary.

I feel as though this is also a good security practice too, as now the only changes introduced into the paginator are internal.

Mobile considerations

The most impressive accomplishment of my work with Claude is the mobile functionality. In general, mobile devices have vastly complicated web development. I know this well now—and I hate phones, I wish they’d all stop working.

Claude allowed me to effectively bypass mobile development. To do this, I made a couple of top level considerations: first, mobile users will get a less complex, streamlined experience. Second, certain pages will just be buggy, and I don’t really care.

The result: boxhouse loads pretty well on my phone. The image viwer struggles the most, but the written content displays well.

Since my site is personal and unapologetically designed for desktop, I think mobile development was generally easier anyways—Claude just set a mobile breakpoint and I worked within that. Going forward, I dread trying to adjust for numerous types of devices. That said, I’m not sure if it’s all too hard to have numerous mobile breakpoints. It’s just messy (in my opinion, unnecessarily so, but I’m definitely in the minority).

End matter

networking stuff

Github

boxhouse was a fantastic introduction to Git and Github.

I initialized a Git repository early on, so by the time I launched boxhouse I had most things in place. I hadn’t had to play with pulling and pushing.

I have some remaining blindspots, but I’ll work on them as the days come and go. My number one issue right now is how do I manage commits on a site with written content… since I make a lot of really silly typos.

I’ve just started using Claude as a proofreader, and I plan to further develop it as a proofreader. But I think I have… 5-6 separate commits that are all dedicated to one or two typos. I can’t keep that up.

DNS

DNS is funny in that it’s so critical, somewhat simple in its concept, but so esotric. It was cool to apply some of my prior knowledge, and I definitely need to meditate on this point further.

Latency and propagation

Once boxhouse went live, images took a while to load. I don’t think this is necessarily bad, though I hadn’t experienced any load time as I developed the site.

This is a bit of a non-statement—I served boxhouse locally during development. No latency, duh. I don’t have plans to adjust anything to hide the load times—I’m happy with how boxhouse is.

Going forward, though, this has been a useful experience to keep in mind. Whatever I do next, I ened to think about the material flow of inforamtion/data through wires and tubes and such. Other projects will require optimization.

On that, I’ve had to update my site a couple of times to fix some errors/typos. One day, I worked with Claude to implement a laundry list of changes—I also made some adjustments to the site colours.

I pushed the update to Git, excited to see the colours. Refreshed. Nothing.

Refreshed again—some of the changes are live, a post is live… but that’s it. I checked my repo and noticed that files hit at slightly different timestamps—I hadn’t considered this as a factor until now.

Then, to add some more complexity, I checked my phone: the colour was live there, but still not on my laptop. I refreshed my laptop’s browser—still nothing.

Propagation is complex, and super interesting. Luckily, this was irrelevant in my circumstances, but I can envision where latency/propagation considerations take up a lot of mental burden.

Next steps

I am happy with boxhouse as a place to spill my brain. I like its vibe. It meets my vision well enough. I think I will start to inventory changes until I have enough to justify a version 1.1. I’m just copying Final Fantasy XIV versioning because I’m a loser. Also, it’d be funny to literally treat it the same (so, after 1.5, I go to boxhouse 2.0—maybe change the domain too ԅ(¯﹃¯ԅ).

A serious concern bubbled up as I launched boxhouse, though: I’m not sending this to like, aaaaaaanyone. So, I’m now seized with identifying a new web framework and making a lighter weight professional website to post consolidated versions of my relevant posts.

Which is so dumb but whatever.