When creating a new cord by pressing enter, preserve the formatting

[CatoMinor]

Expected behavior: The card is green, I press enter, new card is also green, however, this does not happen. What do you think?

[pirijan]

i could do that. Are there any use cases you can think of where this isn’t what you may want or expect? (cc @bentsai)

[CatoMinor]

@pirijan

Are there any use cases you can think of where this isn’t what you may want or expect?

Hmm, I have to think. Nothing comes to mind. I feel that if one creates a new card with enter or shift-enter, one wants to copy formatting rather than use default one. Really curious to see what other will say :).

[bentsai]

My first impression was that this behavior would be unexpected. But thinking about it more, I’m on the fence. Here’s my thinking—setting aside the specific styling of card color, when I hit enter, my mental model and expectation isn’t to duplicate the card styling. So I wouldn’t expect it to preserve markdown heading style, comment, or frames. For most use cases, I am looking for a fresh card that is positioned with the same x value and neatly spaced vertically speaking.

But a card’s color feels slightly different for some reason. Maybe it is more inherent of a styling, so I can see why preserving that makes sense. I can’t put my finger on why exactly.

Now that I write this, I can think of use cases where you just want a plain card. When you’ve used color to indicate a header and you want the rest of the cards to be items in a list. Or generally, when you want cards to fall along the grid, but are using a colored card as the anchor:

The same goes for Shift-Enter. I can see cases for both. But if feels safer/more typical to just let the new card be plain.

(The color is like metadata, similar to frames. I wouldn’t expect a frame to get copied to a new card—then why the color?)

[CatoMinor]

I agree with the difference between color and other formatting. I think the color should be copied, not frames, headings etc.

This is how I use colors:

I am using almost exclusively the same color for cards under one heading and to change colors constantly is no fun :D.

[pirijan]

@bentsai

my mental model and expectation isn’t to duplicate the card styling

relatedly, my view is that ‘enter’ creates a sibling card. Like with humans, siblings don’t inherit traits from each other so I can totally see this being unexpected in some use cases.

@bentsai

When you’ve used color to indicate a header and you want the rest of the cards to be items in a list. Or generally, when you want cards to fall along the grid, but are using a colored card as the anchor:

in both of these cases I use the keyboard to create all my cards (‘xyz’ → enter → ‘abc’), and Then I color the one(s) that I want. Does this match your experience?

[pirijan]

@CatoMinor

This is how I use colors

that’s a very helpful example

[kordumb]

@pirijan

my view is that ‘enter’ creates a sibling card

This is the mental model I have as well, but with shift + enter I view it as a child.

For the child it would be cool, imo, if it could inherent the color, but a shade lighter.

[bentsai]

@pirijan

in both of these cases I use the keyboard to create all my cards (‘xyz’ → enter → ‘abc’), and Then I color the one(s) that I want. Does this match your experience?

Yes. I think one principle here is how Kinopio prioritizes content over presentation. That’s partly why I think it bothers me a little to automatically color a card when creating a card. Creating a plain card seems kinda “sacred.”

but…

I can also see how the card color is kind of like connection color too. Like a global property. So kinda like you can say “Use last type” of connections, you could have a mode where every card you make is the same as before.

@kordumb

For the child it would be cool, imo, if it could inherent the color, but a shade lighter.

That’s a fun idea. It also makes this a lot more complicated to implement lol

[kordumb]

@bentsai

also makes this a lot more complicated to implement lol

100% agree. That’s why I said “a cool idea” I don’t see it actually happening. Way too many things, but I like to throw out the wild stuff occasionally.

[bentsai]

Full disclosure: I haven’t found a good use for card colors yet. Changing the color of cards feels too invasive and heavy-handed for my taste. So for me, either way wouldn’t disrupt my workflow.

[kordumb]

I actually agree. Adding color to a space still feels a bit weird to me…

[CatoMinor]

I see. I am actually using colors all the time :). But I am also putting cards often on strings.

Instead of Connecting “Second generation” with every single card, I create a string and put things on it.

[pirijan]

@kordumb

Adding color to a space still feels a bit weird to me

@CatoMinor

I am actually using colors all the time

both make sense to me, this is the kind of feature that’s not going to make sense for everyone/every-use-case. That’s why the feature is nested behind Styles

What I’m reading suggests that:

1. there’s an expectation that new (non-child) cards are unstyled/blanks
2. if you have that expectation strongly (as I do), you probably have a card creation workflow that’s like: click to create a card, type stuff, hit enter
3. because of the workflow in #2 though, if colored siblings are supported they won’t be noticed by the #1 group of people

therefore implementing colored siblings from enter won’t cause any usability harm or jank irl

[bentsai]

@pirijan

therefore implementing colored siblings from enter won’t cause any usability harm or jank irl

That’s a fair assessment. I agree, I don’t think it would affect either workflow adversely.

[pirijan]

update released:

on enter/shift-enter: child and sibling cards inherit color (for scope reasons, it’s the same color rather than a lighter shade)

thanks all for the feedback/insights