Rethink the per-square actions

[fulldecent]

Currently when you mouse with a square, the only option is either to mint that square or go to the linked website.

@ritorhymes has some improvements in this UI shown at #52 / https://su.ritovision.com/

---

Click an empty white square below to mint an available Su Square (0.5 ETH). Or click a filled-in square square to show more information and visit its hyperlink.

---

One idea ^

---

Below is an update we could use:

You are leaving this site

We are not responsible for the content of linked sites. Proceed at your own discretion.

// SHOW URL AS HYPERLINK // clipboard symbol to copy the URL without visiting (including tooltip)

[ More information about Square #XXXX ]

[ritorhymes]

Full Solution Ready

I have a solution implemented and ready to go for this repo.

Live demo 2 commits ahead of main: susquares.ritovision.com

However, to implement it properly, which is the only way I'm willing to, it requires PR #68 for adding panzoom functionality to the Billboard for mobile / touch devices instead of depending on browser native zoom for small screens.

The reason: browser level zoom results in the entire page scaling up, which means the modal is also immediately scaled up so the standard user flow is that the user has to zoom in to see and select the square then they are greeted by a blown up modal that they have to zoom out to see every time.

See below:

Broken UX Flow - Zoom in to activate modal then zoom out to see modal

mobile-billboard-broken_1.webm

That is a broken flow that I can't co-sign.

I realize you initially signaled enthusiasm for the panzoom touch functionality in #52 when my fork first introduced it.

The pinch and Zoom control for the main square is cool.

but then later changed your mind in #64

browsers already have pan and zoom features

Last week lore.kernel.org became fully mobile responsive on my initiative, and same story today with the bulk of this site in #61. I'm not willing to upstream a broken mobile flow on the primary interaction surface when the fix is already implemented, without new dependencies or significant architectural shifts.

Here's what it looks like working properly:

Proper UX Flow - Contained panzooming to activate modal, modal is immediately fully visible

mobile-billboard-modal.webm

It also adds a touch device-only two step square selection flow: tap once to select square (starts glowing blue), then tap it again to open the modal, so there's clarity on which square the user is selecting (easy to accidentally press the wrong square). On desktop / mouse and keyboard it just requires one click to activate.

Variant State Images

Unminted

Unpersonalized

Personalized with website URI
It omits the title if missing, and omits the Go there button if URI is missing and changes the heading text accordingly

Personalized with deeplink URI
Pressing open triggers deeplink URIs

Blocked URI
Prevents JavaScript, Data and File URI's from running

It's important to me that if we do my modal implementation, we do it properly. I'm not willing to push the modal branch I have without the necessary panzoom functionality.

[fulldecent]

The problems with the above video is that when zooming in only 40% of the viewport pixels are showing the billboard.

With native browser zoom, 100% of pixels are used.

---

Also there seems to be some double click errors at 6s in.

---

And by using a nonstandard step, this necessitates teaching a new interaction paradigm "reset zoom" button / new instructions for how to zoom or pan.

[ritorhymes]

The problems with the above video is that when zooming in only 40% of the viewport pixels are showing the billboard.

The Billboard occupies the same viewport area zoomed in as it does at default scale, zooming just magnifies the content within it. There's no usability issue with that or the amount of space it allows to see or interact with it. Users don't need the Billboard filling the entire screen to navigate it, nor is it preferable to tap the very top or bottom of the viewport to trigger squares. They just need to zoom in and center to the area they're interested in, interact with it, and zoom out when they want the full picture (or press the "reset zoom" button).

The contained area is a deliberate design choice. The alternative would be allowing the Billboard to spill outside of its container onto the rest of the page, it would span more of the viewport height but at the expense of covering the content above and below it. That would be a far messier implementation with no material benefit to usability.

With native browser zoom, 100% of pixels are used.

This is also misleading. It's only 100% of the viewport pixels when you are specifically positioning for Squares toward the center of the Billboard,

Here is an example of me wanting to tap one of the bottom left Squares and centering that area on my viewport to make it easier to tap:

Now the Billboard is taking up roughly only half the viewport height (plus space on the sides so probably also about 40% viewport total), similar story for all edge area Squares.

Also there seems to be some double click errors at 6s in.

This is the select-and-confirm tap pattern working as intended: preventing accidental Square activation from my finger touch overlapping multiple Squares.

The Billboard grid has touch targets well below the recommended 44px accessibility minimum, which means on a dense grid like this, it's easy to accidentally contact multiple squares with a single tap, especially with larger fingers. That's exactly what happened at 6s: my finger overlapped adjacent squares on the first two taps, so the selection didn't commit. On the third tap I cleanly hit only the highlighted square and the modal opened. The last Square in the video I was able to cleanly open in 2 taps.

Without this flow, that same ambiguous tap would have immediately opened a modal for whichever square the browser decided I hit, with no indication whether it was the one I intended. The glow selection feedback gives the user a chance to verify before confirming.

There may be room to refine the touch logic further, but the select-and-confirm pattern is the right foundation for managing dense touch targets like this.

And by using a nonstandard step, this necessitates teaching a new interaction paradigm "reset zoom" button / new instructions for how to zoom or pan.

There is honestly nothing remotely close to a new paradigm being introduced here.

The behaviors for initiating and engaging in browser-native vs billboard-contained panzoom are completely identical: pinch-to-zoom in and out with two fingers, pan around with one finger on the screen; works the same on both.

The "reset zoom" button is a convenience; it resets the billboard back to its original zoomed out state, just like refreshing the page would or pinch-zooming out, but faster. Because the function is so obvious in what it does, it's hard to argue the button introduces any sort of learning curve or friction; there is more friction needing to manually do either of the above other methods to reset it.

[fulldecent]

Adding a blocker on this issue. Things applying here can also apply to the per-square page.

And in the end, a simple solution for the main billboard can be to just link every Square to the per-square page (or the mint page if appropriate).

[ritorhymes]

And in the end, a simple solution for the main billboard can be to just link every Square to the per-square page (or the mint page if appropriate).

This is changing the core experience of the platform
From: you interact with the Billboard and it takes you somewhere off-site
To: you interact with the Billboard and it takes you to an information page on-site

Going directly to the mint page for unminted squares would be the same as before, but that's a temporary flow anyway until sales conclude.

The bigger issue is what happens on mobile. If the user can no longer open or preview squares on the actual Billboard, then the Square page becomes the primary means of Square navigation because tooltips are hover-based and aren't naturally supported on touch devices. Even on desktop, tooltips are currently a limited means of previewing Square info, so the Square page takes on that primary navigation role there too unless tooltips are expanded.

That creates a contradiction I'd like to clear up.

In #62 you said

Regarding the Square page. Adding any other kind of navigation distracts from the main navigation, which is the main billboard.

And of my suggestion for an input field on the Square page:

typing in a number does not sound good to me. Anybody who really wants this will know to edit the URL directly.

Yet you are now proposing that the Billboard's primary interaction redirect users to the Square page, and then from there users use WASD keys to navigate Square info, making it the de facto center of Square navigation, while also rejecting a tool that would satisfy basic use cases like users navigating the page on mobile devices or traversing between Square #s that are far apart.

But more importantly: Su Squares has 476 holders and a Discord channel of 911 users. What do they think about a change like this?

I have a constructive suggestion:

My Billboard panzoom + modal implementation is already live at susquares.ritovision.com. I can stand up a second preview site reflecting your proposed flow for direct linking to a new version of the Square page that has keyboard navigation, so we can compare the two side by side with your actual audience.

UX is a domain of expertise for me, but so far I've been using my judgment to estimate what's likely best here. If you'd prefer, we can use real feedback from real users to clarify what's most desirable and if anything is a real blocker. Su Squares has a community, let's get them involved.

We've made great progress in a short time. I'm around for another week and half or so.. we have time to run some user testing research.

[fulldecent]

WASD is not the primary navigation. It is an easter egg for the homepage. That easter egg is duplicated downstream on the detail page.

Either way the detail page should be updated.

---

I'm open to other ideas, but I am not open to an idea where the main billboard is limited to at most 40% of the device screen.

The billboard is the whole point.

[ritorhymes]

Will, I’ve taken the time to lay out substantive concerns and detailed rationale across these threads, and the responses to them have repeatedly not addressed that substance in kind. At this point, that has become a consistent pattern in how disagreement is handled on this project, and I no longer think this is a workable collaboration model for me.

I am now concluding my involvement with the project.

But so there is no confusion on the public record:

WASD is not the primary navigation. It is an easter egg for the homepage. That easter egg is duplicated downstream on the detail page.

This is exactly the kind of response I mean when I say the substance of what I wrote is not being addressed in kind.

• Keyboard navigation is not an easter egg. On a 10,000-square grid, keyboard navigation is a legitimate accessibility and usability feature, not a novelty. And as I already stated about your idea, once users are forced off the homepage Billboard to preview Square information and access personalized links on the square page, keyboard navigation stops being ancillary and becomes one of the primary ways to move through Square discovery there.

• The mobile consequence was ignored entirely. Without a Billboard modal preview, square.html becomes the primary Square preview surface on mobile to see Square info (and use personalized links), because the Billboard's hover-based tooltips do not naturally work on touch devices. But mobile users cannot rely on keyboard navigation the way desktop users can, and you also rejected the input-field idea, so this leaves them without any serious way to move between Square previews beyond manually editing the square.html URL.

• The proposed primary browsing flow is far worse for exploration.
  If keyboard navigation on the square.html page is not primary, then the expected primary user flow becomes: click a Square on the homepage Billboard, load square.html to inspect it, then navigate back to the homepage again to preview the next one. That means repeated page exits and backtracking just to browse Squares, which is a significantly worse exploration flow than allowing users to inspect them directly from the Billboard, or not expecting them to use an input field or the keyboard navigation on the square.html page.

  • Could you imagine Google search results if it was just a list of images with no content and each result had its own preview page you had to navigate to first then decide to use its link or go back to the search results page? Same idea. They don't do that.

• Incoherence about your stated position that the Billboard is the main navigation and everything else is a distraction. If as you say, the Billboard is the “whole point” and the primary Square navigation surface, then it makes no sense to reduce it to an index for square.html, the page that now holds the critical content for engagement. Under this model, square.html stops being secondary and becomes a critical part of the navigation flow. Your reasoning about the navigation controls on square.html is also inconsistent: you treat an adding input field there as a "distraction" from the main navigation, while treating keyboard navigation on that same page as acceptable.

• The missing input problem becomes even worse. If the square.html page is going to carry this much weight in the Square navigational flow, then the lack of a direct input field to query Square #'s directly becomes even less defensible, especially for mobile users who don't have any other way to navigate properly and for desktop users on square.html jumping between Squares that are far apart (without leaving to go back to the homepage). Telling users to manually edit the URL is not a serious substitute for that.

So no, I do not think calling WASD an “easter egg” is a substantive response to the points I raised.

but I am not open to an idea where the main billboard is limited to at most 40% of the device screen.

I made a substantive case for why that tradeoff works, and you did not engage that rationale or explain what specific flaw you see in it. More importantly, you never defined the actual user-facing problem this supposedly creates. As written, it comes across as a preference assertion rather than a materially grounded UX concern.

I'm open to other ideas

Without substantive engagement on the ideas already proposed, there is no real basis for me to keep investing time in proposing more.

The billboard is the whole point.

The users are the whole point. The Billboard and experience around it are in service to them, not the other way around.