Cloudron Forum

The disabled option attribute might be a solution.

I have no idea what happens if I delete the user.

How could you? It's a matter how the apps handle a deleted OICD user account. I'd almost bet (unverified) that Nextcloud would uncouple such user accounts and keep them standalone.

Awweesoomeee!

True, there are limitations. I withdraw my class names suggestion

On third look, only very few inline styles are set (e.g. width for grid-item). As to class + data attribute selector, it'd be easy to use higher specificity, try: .grid .grid-item { border-radius: 50%; } or .grid .grid-item img { object-fit: contain; }. And there are a bunch of possible declarations that need not even override anything (e.g. filter, border, box-shadow).

Additional thought: add class names (instead of changing) and maintain a list of class name deprecations

Obvious constraints, of course. IMHO a "use at your own risk" should do. The concept of custom CSS is known from other tools. Most folks in the target group should already have experienced a breaking CSS concept change or two, e.g. with Nextcloud.

For mitigation, document the class name changes, ideally in form of before/after.

I think the Cloudron dashboard could even benefit from users' experiments and hopefully enhancement suggestions.

How about a toggle to en/disable custom css and include the dis value in testing?

Let's dust off this feature request

A little CSS injector textarea would be so nice to have!

This private dashboard screenshot struck me - if only there were a possibility to make the dashboard look less like a spilled logo bucket (no front, not your fault) and more like "our workspace lobby"...

Already great that we can use different images for the tiles:

CSS as the magic wand for modifying some colors (accessible links styles!) or adding a characteristic border would be awesome.

Available screen space

Still focusing on tables, but to consider in general:

• When the task focus is on working with complex tables, the space should not be limited for the sake of the design

-> Let the content width be a subject of user preference: make .content max-width (900px) class-dependent and offer a per-user or per-session toggle to swap a body class. The design looks good without the max-width, so there's really not much to change

• Sidebar consumes too much space in narrow viewports (already mentioned here in this thread)

-> Option to reduce the sidebar width to the width of the icons (see Discourse or GitLab

@nebulon Some UX-friendly approaches for the several table-related issues:

• Scrollable table wrappers (check)
• Consequently (tables can grow infinitely wide) limit column lengths with CSS to a readable size, e. g. max-width: 40ch; word-wrap: break-word;
• Consequently (rows can then have variable heights) top-align table cells
• Support orientation in table rows with either alternating backgrounds or subtle horizontal borders (hover bg is already helpful - but only when your device has a hover state)
• Wrap all concatenated data with markup (like group names in the users table, unlike aliases in the mailbox table) - reserving us the option to set entries inline or stacked. Ideally, use invisible list markup - commas can be added with CSS

@luckow @necrevistonnezr "untamed" either way

Makes sense. +1

Every time I read AI powered I wonder where the model is running in first place (and if it's an ongoing model training). Especially when personal data is involved.

Folks, your private vacation videos are just too large

https://docs.cloudron.io/apps/hedgedoc/

Section Custom configuration, "Link in See HedgeDoc docs for configuration options reference" responds with 404.

I guess this would be the new location: https://docs.hedgedoc.org/configuration/

I love you

@nebulon Any progress with the description field yet?

@nebulon Aaaawesome! The tooltip solution is closer to where it's needed, good. (But be aware of possible accessibility implications.)

@marcusquinn Sounds like a good idea. I'm sure we can trust the wonderful Cloudron team with design decisions (and weighing those against technical feasability).

As long as they can make this happen - nag, nag

Now that we've satisfied some basic power users' needs - mind if I get back to the original motivation (description field, login type)?

At least once a week I have to tell an app-using team member that it's not their fault and to stop blaming themselves (no, you are not "too stupid").

It would be such a blessing to help non-admins help themselves.

@nebulon Awesome improvements!

given that we haven't done any visual focus handling

Unfortunately it's a very widespread bad habit among web designers to unconsciously style only :hover states. By omitting :focus, accessibility is actively reduced. Not blaming anyone. You might want to check if your CSS files serve this finding.

The defaults are not always a good fallback. Not many people actually know that they could adjust their system (not even many among those who rely on assistive technologies). When we avoid touching the way the defaults do the styling (e. g. outline) we can still do a lot for accessibility