Now that default max width has been changed from 230 to 200, it leads me to always want to resize cards after creating a list. In Discord, I suggested a feature to set default card width as a user preference.
btw, germane to this feature is a previous request/discussion about having some size presets: Support ability to toggle card sizes - #3 by bentsai
I’ve been using Kinopio on mobile less and more on iPad and desktop lately, but I personally never had an issue on iPhone with the old size.
If I eyeball it, the new default feels about half my phone width, but I personally feel an extra 10% (~60% of the phone width) would be ideal. Maybe smaller phones struggle though…
if no one ends up argue-ing the other way in favor of the newer narrow width, then i can change the default again. Just gotta figure out how to do it without breaking the layouts of recently created spaces
i can do this sooner rather than later by telling the db:
- all spaces should have a default max card width of 230
- except spaces updated in the last 3 months, those will have a default max card with of 200 (so as not to break current spaces)
- new spaces will use 230
the one caveat with this approach is that spaces from the last 3 months that use 200 will continue using 230. Unless you PATCH
space.defaultCardMaxWidth via the api to another integer
This is great! Would you consider adding a property at the user level so I can set my default card size for every new space I create?
I imagine then, new spaces would get a card width of
user.defaultCardMaxWidth if defined, otherwise 230. I’m fine if this is only exposed via the API
should user.defaultCardMaxWidth always override space.defaultCardMaxWidth ? this also introduces complexity to handle collaboration situations
Yes, I think so. In my view, the space-level property should be entirely hidden from the user. It was introduced to handle the fact that default card sizes changed.
The default card width is a user preference. A user can always manually change card widths, regardless of whether the space is shared or not. (What complexity do you see with collaboration?) Card width is even more of a user-level preference than card color.
in a collaborative space, we might have different space/user.defaultCardMaxWidth set, so at what max width should the card be rendered? what should a third party user see?. This value is purposely not scoped to each card, i’d like to avoid going down that rabbit hole
I feel like
space.defaultCardMaxWidth should always be ignored. The card max width should be set to
user.defaultCardMaxWidth (of the card creator).
I don’t understand why the card width would be different for a third-party user.
Taking a step back, why is it called “max” width? Maybe I don’t understand what this setting is supposed to do
What I am advocating for is, when I create a card, I want the width to extend to (let’s say) 300 before it wraps the text. i want to configure this setting globally, so every card I create behaves like this. Right now, I end up creating a bunch of cards, then selecting them, then dragging the corner to resize them wider.
it’s the max width that the card will grow to if you just type a bunch of stuff in it and don’t manually resize it (manual resizing = card.resizeWidth).
So in this scenario you’re collaborating with personA who has their space.defaultCardMaxWidth set to the default 230. You come in and you add a card with lots of text, your client sees that you have user.defaultCardMaxWidth set to 400 so it renders it at 400. personA however doesn’t know about your user.defaultCardMaxWidth so that card would be rendered as 230 for them.
So now you’re in a scenario where you’re both seeing diff things, which isn’t great.
I agree, this is not good. But I don’t understand how users would see different things. All users would see
card.width. personA doesn’t need to know what the other person’s max width setting is. It’s the same thing as default card color. Other users don’t know or care what the setting is. They will only see what is rendered.
oh right i forgot about card.width , ya maybe it’ll just work, we’ll see