Shortcuts in the Overview section

[radicchiodev]

I had some apps like Jellyfin, sonarr and need to know the Url to access them, my family uses yuvomi for everything, it will be so nice if they can access this webs through yuvomi

[GitEbu]

Oops. That's right, and I apologize. Apparently, due to my limited language skills, I used the wrong search terms and ended up creating a duplicate post.

[radicchiodev]

Answering this: #753 (comment) @ulsklyc

I think the widget should be as simple and flexible as possible: just let the user choose an icon, enter a name, and provide a URL.

For example, today I might want to add Immich and Jellyfin, but in the future I might discover another self-hosted service that I also want to link to. If the available shortcuts are tied to a predefined list of apps supported by Yuvomi, I wouldn’t be able to add it.

So rather than defining shortcuts app-by-app, I’d prefer a generic “custom shortcut” widget. That would also make it useful beyond just self-hosted apps, since users could add any service they want.

With that approach, I think a simple tile row in the Overview could be enough initially. If the number of shortcuts grows and people want more organization, it could later evolve into a dedicated module/page.

[avalynnrose]

Seconding this feature idea. I would really like to be able to add web bookmarks to the overview page.

[ulsklyc]

This comes up in two forms - yours (quick links to the other apps on the home server) and #759, which asks for a shared and personal bookmark library. They are the same data with different ambitions, so it is worth deciding them together.

Nothing in Yuvomi stores a link as a first-class thing today. Notes can contain URLs, but a note is prose, not a launcher, and it will not give you an icon on the overview.

The two are worth keeping apart, though, because the small one is genuinely small: a handful of household links on the overview is a short list of name plus URL plus icon, plus the question of who sees which. That is a widget, not a module. A bookmark library - collections, tags, personal versus shared, possibly a Readeck integration - is a module, and one that overlaps with tools people already run.

Your case makes the strongest argument for the small version: a family that uses Yuvomi as its home page needs the way to Jellyfin to be there, not in a note two clicks away.

Staying open, tracked alongside #759.

[ulsklyc]

Consolidating here: #759 asked for the same thing from the other end - a bookmark library - and its author has since concluded that a shared list of links is what he actually needs. Closed as resolved in favour of this thread, so the requirement lives in one place.

What the four of you have converged on, as one spec:

• A tile row on the overview, not a module. Name, URL, icon.
• No predefined app catalogue (radicchiodev). Anything keyed to a list of known services is wrong the day somebody runs one that is not on it. A generic custom shortcut costs less and covers more.
• Per-link visibility, the same personal/shared question every other object in Yuvomi answers.
• Uploadable icon (ElHado). Deliberately not a favicon fetch: that would have the household reach out to every linked host on every render, which is precisely the kind of quiet outbound traffic this app does not do. An upload stays local.
• Room to grow into a page later if the list gets long, but not built that way from the start.

Still open, and now the only thread on it.

[ulsklyc]

Shipped in v2.43.0, as the spec above.

A row of tiles on the overview: name, address, picture, and who sees it. No catalogue of known apps - a shortcut is just an address, and 192.168.1.5:8096 is enough, since https:// is filled in where no scheme is given. That is how anybody actually writes down a machine on their own network.

Three decisions that were not in the spec and are worth naming, because each one came out of building it:

The picture is uploaded, never fetched. As agreed - but the reason turned out to be sharper than "no outbound traffic". The tiles travel as data URLs inside the overview payload, so both the size and the count are capped (128 KB, 24 tiles). A generous cap times an unbounded count is a home page that loads megabytes before it shows anything.

Without a picture the tile carries its initial, on a colour from the same palette a member without a photo gets. Twelve identical globes distinguish nothing; "J" on blue does. The letter picks its own text colour - white on a light tile measured 2.7:1, which is the same finding the avatar initials cost once already.

The row starts hidden and is fetched from the customise tray. On day one it has nothing to show, and a tile that only asks to be set up is not worth putting on every existing dashboard unasked.

The address is checked on the server with the same function the browser uses, so a javascript: value is refused with that as the reason rather than quietly turned into something that fails to parse.

Thanks to all four of you - @radicchiodev for the argument against an app catalogue, which is the decision the whole thing rests on.