Start Designing the UI/UX for `Borea.App`.

[MrJeranimo]

This issues is a blanked issue that marks the start of Borea.App UI/UX Design. This does not cover any actual implementation of Borea.App's UI/UX, only the design ideas and specifications.

[PlazmaBoltz]

The design should be modern and not just a wall of text like ckan. I’m thinking the end goal should be to make something of similar quality to modrinth (see https://modrinth.com )

[renancamm]

Hey, here is my first draft for the design of the app.

---

Content Manager App: UX plan

Goal

A desktop app that makes it easy to add/remove community-generated content to KSA

Entity model

• Instance: A isolated profile with installed content and game settings.
• Content Mod: A community-generated content, like a code mod, parts, vehicle, planets or saves.
• Content Mod Pack: A community-generated pack that groups mods with pinned versions.

Main navigation

• Discover:
  • List view: Filter content from the index by description category/tags, compatibility status or social signals
  • Detail view: Description of the content, related links and actions
• Library:
  • List view: Filter instances by activity date and compatibility status
  • Detail view: Instance metadata, actions, and list of installed content
• Game setup: Where the path for the game install lives
• Settings: Client-side preferences

User journeys

1. App installation: User downloads the app from the website and installs it. No need for pre-configuration.
2. Onboarding: On first launch, the user is shown popular content in Discover to start browsing immediately. To install or check compatibility, the user needs to setup game install folder.
3. "First content installation": Users check content details, and tap on "install". If there is no instances, it creates a new one. If there is only one instance, the default action is to add it there. If there are multiple instances in the library, offer to pick to which one.
4. Recurrent usage: Returning users check for updates and manage installed content with as few clicks as possible.
5. Conflict recovery: If an instance compatibility breaks, the user gets clear diagnostics and a way to recover or revert.

---

Open questions

Does the metadata format support search/description enhancements beyond core functional support (Markdown descriptions, categories, art)?

Description and art could wait, but the ones that affect searching and filtering are more critical. I would say that adding a sub-type (or category) is necessary for proper top-level filtering for code mods/parts/visual/planets. Using free form tags are great for detail pages, but is easy to pollute filter lists with improper plurals, typos, etc. (e.g.: parts/part tag).

Having top-level category enable us to unlock specific detail layout for each category of mod. Not sure if it is entirely necessary, but having a 3D preview for parts/crafts/planets would be really cool. (Maybe we can infer only based on the mod content?).

Lastly, if we make "thumbnail art" optional, we need to provide image placeholder for it. Having some top-level categories would make it a better experience.

[MrJeranimo]

The below is just a heads up for most and a couple of thoughts/ideas in response to yours.

Content Mod: A community-generated content, like a code mod, parts, vehicle, planets or saves.

Just a heads up, Vehicles Saves and Game Saves are going to be treated as a separate content type to Mods. Code mods, part mods, and planet mods will all be wrapped up under Mods. So the final categories are Mods, Mod Packs, Vehicle Saves, Game Saves, and Mod Loaders (Mod Loaders are separated to make dependency resolution easier). Vehicle and Game Saves will list which Mods are required for them to work.

Content Mod Pack: A community-generated pack that groups mods with pinned versions.

This can also include Game Saves and Vehicle Saves. Kind of like how Minecraft Mod Packs can include Texture Packs and World Files.

App installation: User downloads the app from the website and installs it. No need for pre-configuration.

This depends on if we can auto-detect a KSA Install and any Mod Loader Installs. My reccomendation is to ask the user at first install but have the option of "Skip For Now" so someone can jump straight into looking at content. Also Borea should not give out KSA downloads currently, it should only redirect to the offical KSA download site. StarMap and other Mod Loaders are at their creators' wishes (We should ask @KlaasWhite).

If there is only one instance, the default action is to add it there. If there are multiple instances in the library, offer to pick to which one.

I say, unless the user clicked an "Add Content" button to an instance, it should always ask which instance to add content to with a checkbox of "Add future content to this instance" until some condition is filled to reset that. This also includes the 1 Instance situation. Let me know if you disagree or anything.

Does the metadata format support search/description enhancements beyond core functional support (Markdown descriptions, categories, art)?

Currently, my ideas for some filters are, By OS Compatibility, By Mod Loader (or none at all), By Tags (standard tags can be provided with a search for the free form ones), by title, by author, by Game Version, by Mod Loader Version, By content type (Mod, Mod Pack, Vehicle, Save, etc.), License? (not sure on this one), and some basic stuff like Download Count and Age.

Definitely not an exhaustive list but just my current ideas.

[Maximilian-Nesslauer]

Great draft, thanks for carrying it over.

Answering the index and format side of your open question:

Searching and filtering is not constrained by any API, by design. because the client fetches the whole index as one snapshot and keeps it locally (content-manager-design#33, in review), so every filter is a local query over data you already have, offline included.
Design whatever filter UX is best, the only real question is which fields exist.

What exists today for filtering (RFC 0031): type (mod, modpack, mod-loader, later vehicle and save), name, authors, abstract, tags, license (SPDX), os, the loader with version bounds, game compatibility as revision bounds (evaluable offline per RFC 0017), release_status (stable/testing/dev), and release_date.
That covers almost all of MrJeranimo's list.
Download counts do not exist yet, they are named as a future static aggregation in #33, so "sort by downloads" should be designed as optional rather than assumed.

Categories: agreed, and the format anticipated it.
Free-form tags pollute filter lists, which is why RFC 0031 says a curated vocabulary can come later without a format change.
My suggestion: we define a small curated starter list (parts, planets, gameplay, visuals, tools, ...) now rather than later, because retrofitting categories after listings accumulate means re-tagging everything.
Publish-time validation would warn on unknown tags instead of rejecting, so free-form stays possible next to the curated set.
I will propose that in the design repo, the UI side can already assume a curated set exists. (EDIT: KSAModding/content-manager-design#34)

Art and 3D previews.
A thumbnail field does not exist in spec_version = 1, and adding an optional field later is explicitly not a format break, so a placeholder-based design now is the right call.
3D part previews need no metadata at all: KSA parts are GLB, so a client can render previews from the downloaded archive, the way flexo does.

[renancamm]

I say, unless the user clicked an "Add Content" button to an instance, it should always ask which instance to add content to with a checkbox of "Add future content to this instance" until some condition is filled to reset that. This also includes the 1 Instance situation. Let me know if you disagree or anything.

This would be the functional way of doing it, and honestly, the most simples way to implement. The "magic" solution is me trying to make a superior UX, and assumes that:

• New users want to install something as fast a possible
• Learning what a instance is isn't that easy, you need to think a bit about it
• Having multiple instances is a advanced usage already, most of user will use keep only one instance.

Function vs. Superior UX is a good debate, but it boils down on us having a logic and function app vs a app that anticipates what will be the next goal/step for the user.

My suggestion: Let's have a first functional app but not forget about making it a great UX before it gets too late.

[renancamm]

Ok, I think the general structure is on a good shape, I will proceed to draw some wireframes so we have a collaborative approach and on the main flows.

Next steps is to detail:

• What are the filters for each list view
• States for content and instances (not installed, installed, pending update, etc)
• Action for each content/instance state (install, remove, delete, update, duplicate, share, etc)
• Settings and Game setup fields. What is store locally that is app wide reach.

Mock data:
What is really helpful to have in this design stage is mocked data, so we can simulate things like how a highly detailed mod description is rendered in comparison to super simple one. Do we already have this initiative somewhere?

[Maximilian-Nesslauer]

What is really helpful to have in this design stage is mocked data [...] Do we already have this initiative somewhere?

Not yet, but the design repo reserves an MIT-licensed examples/ path that is still empty.
I would fill it with a small set of listings in the RFC 0031 format.
That set then serves double duty, format examples for the index tooling and mock data for the UI work here.

Until that lands, the worked examples inside RFC 0031 itself are the canonical shapes to mock against, and after #32 the TestFixtures in Borea.Core.Tests build valid objects of every type.

I will probably find time to implement mocked data until tomorrow evening and will update you here :)

Good work btw! 😄

[renancamm]

Amazing! I still need to finish the wireframing part, so no rush from my side.

[renancamm]

This is a working in progress of a larger wireframe

I realized by looking at this screen, that the current "category filter" will only work for mods, but not Vehicles and Saves. Not a big deal, but lets keep an eye on how the filtering experience will be with what we are planning to expose in the index.

[PlazmaBoltz]

This looks good. I would change the font in the final design to have more of a “serious space program” feel. Maybe you can add more categories that vehicles can use, since mods that improve some types of vehicles can use those tags but vehicles won’t use stuff like “celestial” or “ui”. Same applies for saves. Maybe we could also add a way to upvote and downvote and leave comments on mods to improve the popularity search