Choices UX ✨

[brillout]

@phonzammi WDYT of following? 👀

A) Expand <select> on hover

If mouse hovers the <select> dropdown, automatically expand it:

Hono
----
Hono
Express.js
Fastify

Apparently it isn't possible to programmtically open/close <select> but maybe it can be worth it to do a little bit of research. Does select.focus() work with modern browsers? If it isn't possible, then I guess we must use a custom <select> implementation? In that case, maybe we can find a nice React library (or we implement it ourselves).

B) Newcomers UX

New setting: +choices[groupName].secondary: boolean (default false).

If secondary: false and the user didn't choose yet (localStorage isn't set) then let's always show all choices — even if the mouse isn't hovering the code block. So that, for example, a first time visitor going to https://vike.dev/vike-photon instantly sees all the servers Vike supports.

Example values

For example, we would (eventually) set folowing values:

• packageManager.secondary: true
• codeLang.secondary: true
• server.secondary: false
• uiSyntax.secondary: false (JSX/Vue SFC)
• uiFramework.secondary: false (React/Vue/Solid)
• uiFrameworkVikeExtension.secondary: false (vike-react/vike-vue/vike-solid)

This shows how secondary enables us to predominantly show important choices to newcomers.

C) Bonus: Icons

New setting: +choices[groupName].icon (to add an icon to the choices in the <select> dropdown).

We can do this later.

D) Bonus: clean visual design

I liked our previous JS<->TS toggle inspired from SvelteKit's docs. Can we adopt a similar design for +choices?

I've been thinking a bit about this and I've a design in mind but it isn't trivial. Let's do this later, and only if we feel like it.

The design I've in mind in a nutshell:

• When the user clicks on the first line of the <select> dropdown (the selected choice) => automatically switch to the next choice.
• Show <select> entries only once (note how the native <select> dropdown shows the selected choice twice)
• If mouse hovers the <select> dropdown, automatically expand it
• All choices are shown as a vertical rectangle:
  • The content of the rectangle is completely static (never changes)
  • When expended, the whole rectangle is shown
  • When not expended, only one line of the rectangle is shown (the selected choice) => this line is always shown (regardless whether the dropdown is expended or now)
  • The whole rectangle moves up and down: when the user selects another choice, the rectangle moves up/down so that the always-shown-line remains at the same position.

AI prompting

Implement the following and make it copy-pastable to some live React code preview tool such as StackBlitz (define the App.jsx entry).

[Copy design described above here]

Then copy-paste to https://vite.new/react.

If it doesn't work:

It doesn't work exactly as specified in the spec! TAKE YOUR TIME. DO IT RIGHT. EXACTLY FOLLOW THE SPEC!

Some rough but almsot fully-functional implementation done by ChatGPT: https://stackblitz.com/edit/vitejs-vite-7jpp2xak?file=src%2FApp.jsx

Pretty but less functional implementation done by Claude: https://claude.ai/share/05f13bc7-28f0-40f7-bff9-91148baa6848

[phonzammi]

I think those would make for a very nice UX.

Honestly, I know it would be complex to implement, but I believe it would help to improve the DX first—specifically, getting the choice group object at compile time. I think achieving that requires the ability to pass +choices to remarkChoiceGroup().

[brillout]

How about we define +choices as standalone config instead of +docpress.choices? Actually, we'd still have the .svg imports issue (but maybe that's fixable).

Quickly thinking about the features of this ticket, I'm thinking it's all frontend and we don't need to access +choices in remarkChoiceGroup()?

[phonzammi]

Quickly thinking about the features of this ticket, I'm thinking it's all frontend and we don't need to access +choices in remarkChoiceGroup()?

I think it would really help. Just thinking out loud—we’d have more control over the children.

[brillout]

I think it would really help. Just thinking out loud—we’d have more control over the children.

If you think it's a blocker or if it helps significantly, then let's do it 👍 But so far I don't see why we'd need it for this ticket.

[brillout]

@phonzammi I think there is a way to relatively easily/quickly implement this? Or are you seeing a major blocker? 👀

[phonzammi]

I can’t say much yet—I haven’t fully understood everything, but I’ll start and try implementing “Expand <select> on hover” first.

[brillout]

👍 Let me know if you believe something's unclear in what I wrote.

[brillout]

FYI, Vike newcomers will see this almost immediately. It’s how we’ll communicate that they can choose between React, Vue, or Solid on the vike.dev/start page, which is linked from the landing page’s main call-to-action button Get Started.

[brillout]

They'll actually even see it on the landing page...

[brillout]

Actually, there are some issues with the design I've in mind. Let me thoroughly think this though.

[brillout]

I've updated the original post. @phonzammi Is it clearer now? Let me know if you've questions.

[brillout]

I've further updated the original post: I've added some AI prompting demo for D) Bonus: clean visual design.

[brillout]

I've added some AI prompting demo for D) Bonus: clean visual design.

The POCs done by AI are relatively simple, maybe it's worth it to try this — let's see if we can make a fully functional and beautiful (I can help with that) custom <select> implementation.