Visualize scope via relative card sizes

[kudzuweb]

always wanted a visual indicator of scope for tasks, and finally Fizzy came along, the perfect "show, don't tell" app to carry it. the idea is to have the cards show up as different sizes based on the size of the task. i forked the repo and implemented it with tshirt sizing(easily replaced with Fibonacci if that's preferable). I really like it in my local version, easy to see what my capacity is just from glancing at the board.

feature is fully cooked, just waiting for a PR. repo + before/after screenshots included

https://github.com/kudzuweb/fizzyXL/tree/add-tshirt-sizing

[jasonfried]

It's an interesting idea and we actually played with it early on back when we had round bubbles instead of cards. The bubbles would grow in size depending on the number of comments, +1s, etc. But in the end we found that it made more sense conceptually than practically as determining scope from abstract metrics didn't really represent reality.

Would be curious to hear more about how you'd define scope, or would this be a manual dial you could turn to "make this bigger" or "make this smaller?" IMHO, the manual dial, or some manual control, would be the best implementation. You know in your head what's bigger vs. smaller, and there's no reason the software needs to try to figure it out.

[kudzuweb]

I added a simple tshirt sizing picker to the new card and edit card views(screenshot). Z to toggle, select size with a click, arrows, or just typing the size you want, Enter to apply.

My observation in team environments has been that t-shirt sizing is a solid abstraction for scope because of its flexibility. XS, S, M, L, XL are relative terms with an embodied meaning that allow teams to use their intuitive sense of how much time/effort/bandwidth a given task is likely to take and communicate that succinctly. When used thoughtfully, I find it quite useful for planning when is best to tackle what, as it helps me make the most efficient use of my time.

[kudzuweb]

wow i sound like an LLM. lmao TL;DR: it's manual

[seiz]

Interresting indeed. But why not just use Tags (like i.e. "Effort_S", Effort_XL" etc.) for that? Provides the same benefits minus the visual indication via the card size which might be hard to get and might not scale well, i.e when a user wants to pick "low hanging fruit" out of hundreds of tickets.

[kudzuweb]

because I believe that using text to do UI's job is the engineering equivalent of presenting from a spreadsheet instead of using graphs, lol. the human brain has the best software in the world for processing complex visual information quickly, lightyears better than it does for words and numbers. i also believe that "why not just write yet another piece of information" is the slippery slope that leads directly to bloated Jira hell.

i like size precisely for the purpose of scanning for low-hanging fruit! literally just pick the smallest ones you see lol

[kudzuweb]

i do see what you mean about tagging, as it would allow for filtering cards by size, but i think that should be implemented under the hood, while still relaying the information visually to the user. no reason for me to read it just because the system needs to lol

[jasonfried]

I like the t-shirt sizing concept. To push further... What we saw in our early experiments, and what I'm seeing here, is that size is too brute force a differentiator. I'd like to see other variations explored. So not card size, but maybe card border. Thicker border for a more substantial item? Different textures on the card itself (or the border itself)? Something where the size is maintained so information proximity and location is preserved, but a visual differentiation is applied. Keep exploring!

[kudzuweb]

hmm, I thought about the border weight, but my instinct says that would visually approximate a glow effect, which tends to get processed as urgency rather than heft. there is also already a literal glow effect(goldenness) that I didn't want to interfere with, as i think overloading the same area of the design with different information muddles the efficiency of using a visual representation of the information in the first place("one channel, one message"). I'll noodle on it and see what I can come up with! Thanks for the feedback

[seiz]

Good points. We'd need a visual way that represents a card's "weight". Imo, the varying card width isn't a winner here, as it ads all sorts of complexity (why is the title shorter on this card?…) and clutter (gaps on the right of the cards).
I don't have a good idea yet either but will sleep over it…