Closed samuelstroschein closed 5 months ago
I am unsure about:
I think @NilsJacobsen would be a fit:
Why not I am happy to work on that. I guess the timeframe is to get an MVP ready until we get the getting-started right? Gonna explore a bit and select requirements for the component.
Notes from convo with @NilsJacobsen
settingsSchema
(also a JSONSchema) can be used to build the settings UI Insight: The entire component is "just" a rendering engine for JSON SChemas. APp settings, module settings and project settings can all be rendered from a JSON schema.
<inlang-settings
project={project}
onSettingsSet={(settings) => project.setSettings(settings)}
appSettingsSchema={appSettings}
onAppSettingsSet={(settings) => {}}
>
</inlang-settings>
if there is a problem & the settings component can't resolve the JSON schema, we can always fallback to "Edit in settings.json" – it should then only be clear which settings source file. The one from VS Code, the inlang one etc.
First exploration into styling and other questions: https://www.loom.com/share/b3835c31ed3745a9832754bd023cbbd0
TL;DR
Questions:
Do we want to have versioned releases for UI? (Yes)
Yes.
Create a separate package for the settings component that is released like the other NPM packages.
Does something speak against storybook? (I like it)
Nothing speaks against storybook.
Waht do you think about the CSS variables approach for style overwrites? (I like it)
Yes, good. Don't expose shoelace variables, though/have your own naming convention (ideally the same one as the pattern editor will have).
Further notes
Notes after a call with @felix:
no need to ship themes. Apps need to adjust the style to their env anyways
thus, ship the component with "base" style that can be overwritten by the app. Base style = for example no colors, clear that the styling is not complete BUT usable
variants like button small, large etc seems redundant.
@NilsJacobsen Call me tomorrow so we can clarify on a few thoughts I had after seeing your loom what led to my response loom & a call with samuel about how we should build & enforce the right things to make our life really easy by not compromise on the goal we want to achieve (highly flexible styling, unified UX).
In short: (what samuel said above and) the right set of CSS variables with near unstyled defaults make variants & themes obsolete.
Moreover, the less we have to maintain = the better & we do not have to keep syntax & theme(s) in sync all the time.
Also, let us have a brief chat about the beloved topic of icons.
please just agree to ship icons with the component. this will ensure that:
at the cost of:
- no need to ship themes. Apps need to adjust the style to their env anyways
- thus, ship the component with "base" style that can be overwritten by the app. Base style = for example no colors, clear that the styling is not complete BUT usable
Apps have full control over styles, but if they want to take the base styling with small adjustments there is no need to define 300 CSS variables. Problem: If I build an app with dark styling I basically need to manually invert 300 tokens, instead of importing the dark base styling and change only the primary color. That was the idea.
We can also remove the dark styling for now. Because the ide extension can not set static dark themes, because it is based on a user-based theming.
Our UI will use a lot of shoelace components under the hood. The easiest way to style them is to change their css variables. So why not just using the same system with a inlang-token wrapper. That makes my components so much easier.
Let me explore how to make the wrapper.
the right set of CSS variables with near unstyled defaults make variants & themes obsolete. variants like button small, large etc seems redundant.
Well the idea was to use CSS variables. They are used as a theme at shoelace. Where is this variant thing coming from?
If I build an app with dark styling I basically need to manually invert 300 tokens, instead of importing the dark base styling and change only the primary color. That was the idea.
Q: This will never meet the apps reqs in terms of styling. Think about it: If I have an app which supports dark mode, would I really want the settings component dark theme?
A: Likely not, because this theme works with its own shades of black which is not working with my own design which ships with other shades of black. There will always be the case of adjusting variables in order to unify the styling.
Could Fink use this dark theme? No, Fink doesn't even support dark mode yet. Does the VS Code extension need it? No, there is no such thing as "dark theme" in VS Code, but 1000+ dark themes all with slightly different colors where I want the settings component to match every time to not look broken/alien.
Ship the component with near unstyled defaults (a bit like a blank html page but a bit more beautiful) that it doesn't look broken and let the app handle the design from a-z.
@felixhaeberle You mean, just take the base color and text color from the parent? This way it always fits the theme. (black on white in Fink, white on gray in VS code default theme, etc)
Call with felix:
Update: https://www.loom.com/share/543ed27d63a74608a5134718b56e9ae2
Two questions:
<inl-settings/>
while the package is named @inlang/settings-compoenent
?Should we name the component
while the package is named @inlang/settings-compoenent?
Don't abbreviate. Name it <inlang-settings>
. The package name and HTML tag name prob do not need to align.
Samuel can clarify the versioned interface mistake?
Nesting is wrong. Just have a flat packages registry. Same problem with namespaces for keys.
Update settings component: https://www.loom.com/share/25cac383d4164fbdb4c26018d7697971?sid=5de62c4e-19d2-4bf6-a00e-949d0574c6c8
TL;DR -> Deriving the input fields from the schema and filling it with the settings was pretty straight forward
@NiklasBuchfink @felixhaeberle @martin-lysk
What do you expect from an input field in the settings?
Pro:
Cons:
Pro:
Cons:
Pro:
Cons:
Proposal: Let's start with save whole form
Agree. Have a save button that is always visible (not at the very bottom!) and nudges users to save their changes.
Proposal: Let's start with save whole form
I agree. To fix the position problem:
Sketch for 1, but the button on the right:
Only a WIP: Update before the weekend https://www.loom.com/share/5b9914cdcb1c420086faa12092ac961e
@NilsJacobsen i propose to design the settings UX in figma before you code stuff. you can align everyone much better if you show what the resulting UX will be rather than showing "i coded this".
https://www.loom.com/share/9894ef2e87c94160b0afd0c92ba41d7a?sid=3963f6f6-2899-4ff7-aab0-d8b161cc7ee6
I want to go in that direction.
Quick feedback:
Most apps won't need the headline / context: "Project Settings" and subheadline are therefore to be put by apps if they needs this in the context.
Would be cool to have full control over the width of buttons and inputs, I likely want to have all input fields 100% width in really small widths (or you account for that ootb)
The save overlay is a pattern not being used by the vscode extension for example and therefore inherits a UX the user might not be familiar with.
Extending 3, I don't know how to style this element (overlay) with elevation from the background, because the "grey" color you anticipated for it already in the design mockup doesn't reliably exist in the vs code coloring hierarchy.
There are a few minors still in addition to that, but we can clean this is development.
@NilsJacobsen can you share the link to the exaclidraw? It's likely easier to comment directly on the excalidraw.
I have several questions about the UX flow:
+1 for not exposing the concept of modules to users in the settings display but rather split them into the logical blocks/types = plugins & lint rules.
how is this currently being solved at manage.inlang.com ?
Excalidraw link: https://app.excalidraw.com/s/1RmnkzJA3Ph/7X9Tbfx6kAn
separate plugin and lint rules
yes
Remove modules for v1
-> + 1
save overlay?
let's have a quick chat @felixhaeberle
Decision in call with @NilsJacobsen @felixhaeberle:
Design the settings component as a dedicated "page". The tradeoff to design the component "embedabble" (to be rendered in the page of an app) is too high with questionable UX outcomes.
The tradeoff to design the component "embedabble"
This tradeoff should be accounted for / fixed sometime in the future but for a v0, the approach of introducing a component based save UX is tolerable.
closing because duplicate. see progress in https://linear.app/opral/project/seed-round-2fdb85393b97
Context
Just like opral/inlang-message-ui-components#16, we need a settings web component:
Features
Must have
Maybe
Out of scope
Additional information
We used to believe that we should build a site like
manage.inlang.com
that offers a settings view. Apps can open the external site and spare themselves from building a settings view. However, linking to an external site is a large user flow breaking point. Instead of developing one website with a settings view, we can invest the resources into a web component that apps can embed.