Chatbots & Safari Matter

Website Updates: Smarter Chatbots, Safari Fixes!

Another update to the portfolio - both under the hood and right in front of your eyes. If you read my last post about the Portfolio 2.0 launch, you’ll know I’m all about continuous improvement, and the beauty of being a one-person team? Lightning-fast decision-making and updates!

Chatbot Upgrade: From Terrible to Helpful with Gemini

Remember the chatbot I was so excited about in the last post? The one powered by transformers.js? Yeah, it was cool in theory. And it definitely showcased my interest in AI. But let’s be honest, its responses were… awful. Most of the time it just spat back my name as the answer -I think I overloaded it with context. As I mentioned before, it was more of a “conversation starter” than a reliable source of information.

I was determined to make it more than just a tech demo. So, I decided to swap out the transformers.js approach for something more robust.

Why Gemini? A few key reasons:

• Accuracy and Predictability: Let’s face it, when you’re asking a question, you want a sensible answer, not creative wordplay. Gemini is proving to be significantly more accurate and predictable in its responses. No more existential chatbot crises!
• Cost-Effective Awesomeness: While exploring options like OpenAI is always tempting, Gemini’s pricing structure is really appealing, especially for a personal project. Keeping things budget-friendly is always a win.
• Actually… Helpful?: The goal here is to move the chatbot from “fun experiment” to genuinely helpful feature. Gemini is taking us a lot closer to that reality. I want visitors to be able to quickly get answers to basic questions about my projects or skills without digging around the site.

The early results are fantastic. The chatbot is responding much more predictably, and the answers are actually relevant! It’s still early days, and I’m continuing to refine the prompts and context (I’ve added an easter egg and plan on adding some more with time, you just have to ask the right questions), but I’m really excited about the potential of Gemini to make the chatbot a genuinely useful addition to the site.

Making the Button Less Invisible: Wife-Driven UX Improvements

On a slightly less technical but equally important note… apparently, the chatbot button was nowhere in sight. When I asked my wife to test out the chatbot, her first question was just, “Where is it? I don’t see it.” Proof positive that user testing, especially with non-technical folks, is crucial!

Turns out, subtlety isn’t always a virtue when it comes to user interface. I thought it was nicely tucked away, minimal and clean. She thought it was practically invisible. Lesson learned.

Sometimes, the most important UX improvements come from the people closest to you (especially when they’re politely saying “I can’t find anything!”). Thanks, honey!

Safari and Container Queries: A CSS Puzzle Solved

Now, for a bit of CSS fun (and frustration, initially!). I’ve been really enjoying using container queries to make the website more responsive. They’re fantastic for styling elements based on the size of their container, rather than just the viewport. Super powerful for creating flexible layouts!

However, I ran into a bit of a Safari hiccup. Specifically, when I tried to implement container queries within my project grid, I noticed something weird: in Safari, the grid items within the container were rendering with a width of 34px. Talk about a layout breakdown.

After some debugging, it seems Safari’s container query implementation, in certain grid scenarios, wasn’t playing nicely. The container was being recognized, but the items inside were… collapsing.

Thankfully, CSS is wonderfully versatile. My solution involved a bit of a fallback approach, using @supports and @media queries to provide alternative styling specifically for Safari when container queries were causing trouble.

Here’s the CSS snippet that got things working smoothly:

.projects {
    display: grid;
    gap: 1rem;
    grid-template-columns: repeat(auto-fit, minmax(15.3125rem, 1fr));

    @supports not (--webkit-device-pixel-ratio: 1) {
        container: projects / inline-size;
    }
}

.project:first-child {
    @container projects (31.625rem < inline-size < 47.9375rem) {
        display: grid;
        grid-column: span 2;
        grid-template-columns: repeat(2, 1fr);
        column-gap: 1rem;
        row-gap: 0;
        grid-template-rows: repeat(3, 1fr) auto;

        > img {
            grid-column: 2;
            grid-row: 1 / -1;
            place-self: center;
        }
    }

    @supports (--webkit-device-pixel-ratio: 1) {
        @media (34rem < width < 50.875rem) {

            grid-column: span 2;
            grid-template-columns: 1fr 1fr;

            > img {
                grid-column: 2;
                grid-row: 1 / span 4; /* Corrected grid-row value */
                margin: 0;
            }

            > div {
                grid-row: auto;
                grid-column: 1;
            }
        }
    }
}

Let’s break this down a bit:

• @container projects (31.625rem < inline-size < 47.9375rem): This is the container query in action. It applies the styles within when the element’s container (with the name projects) falls within the specified size range. This is the ideal scenario, working in most modern browsers.

• @supports (--webkit-device-pixel-ratio: 1): This is a bit of a Safari-specific hack (but a reliable one!). @supports checks if the browser supports a particular CSS feature. --webkit-device-pixel-ratio is a property that is supported in WebKit-based browsers (like Safari). So, this @supports block targets Safari (and other WebKit browsers).

• @supports not (--webkit-device-pixel-ratio: 1): Does the exact opposite. So now I can target all other browsers with this query.

• @media (34rem < width < 50.875rem): Inside the @supports block, I’m using a regular @media query. This acts as a fallback for Safari. Instead of relying on container queries (which were misbehaving), I’m using a traditional media query based on the viewport width to achieve a similar layout adjustment in Safari. The size ranges in the @media query are roughly aligned with the container query ranges to keep the layout consistent across browsers as much as possible.

Essentially, I’m saying: “If the browser is Safari (or WebKit) and the viewport width is within this range, use these styles; otherwise, try to use the container query if possible”.

It’s not quite as elegant as just using container queries, but it gets the job done and ensures the layout doesn’t break in Safari. Browser compatibility – always a fun adventure!

Want to see the query magic in action? Just resize your browser window while viewing the projects page or the projects section on the homepage.

Embracing Playwright: My Safari Savior (As a Windows/Android User)

Here’s the funny part: I’d even shared the site with a friend who’s deep in the Apple ecosystem, and he didn’t notice/mention the issue. It wasn’t until a few hours later, when I was testing on my own (new-to-me) iPhone SE, that I spotted the problem myself.

I was totally stumped. Was it some weird Safari version quirk? Thankfully, Playwright came to the rescue! I fired up a Safari instance in Playwright and boom - there was the same broken layout. Now, here’s where Occam’s Razor should have kicked in immediately. My first thought was container queries. But I quickly dismissed that because, according to Can I use, Safari has full support for container queries. Full support! So, I figured it had to be something more obscure - some bizarre browser bug, or a weird interaction with grid. Nope and nope.

Turns out, the simplest explanation was the correct one all along: container queries. Despite what caniuse said, Safari’s implementation, in this specific grid layout scenario, just wasn’t behaving. I’d essentially been led astray by trusting a supposedly definitive resource, and ended up chasing more complex theories when the answer was staring me in the face the whole time. It’s a good reminder that even seemingly reliable sources can be… well, not entirely reliable!

To really nail down the issue, I even wrote a quick Playwright test to programmatically check the width of the first .project element at different viewport sizes (375px, 800px, and 1440px). Essentially, that one line of code was overriding everything and squashing my project items to a fixed 34px width. This was a first for me: properly using @supports. And I have to say… it’s a lifesaver!

Here’s hoping Safari catches up properly with container queries soon. But in the meantime, I have my @supports workaround!

Wrapping Up: Small Tweaks, Big Improvements

So, there you have it - a slightly smarter chatbot, a less elusive button, and a Safari-proof project grid. These might seem like small changes, but they all contribute to a better, more functional website. And that’s the goal, right? Continuous improvement, one tweak at a time. Go ahead and take the updated site for a spin!

Thanks for reading!