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…

[kudzuweb]

@jasonfried okay, i mocked up 15 variants just to assess how clearly they conveyed the intended info, and implemented the top three to see how they translated in Fizzy: paper stack, signal strength, and cornerstone. cornerstone suffers from the same issue many others(eg border weight) did, which is that it derives most of its meaning from comparison to other cards, and is less clear in isolation. the paper stack was my favorite mockup, but it's just not as clear as i'd hoped in Fizzy.

strongest contender for clarity & minimal visual and cognitive friction turned out to be signal strength, which surprised me! i played with textures a bit, but it was distracting and a bit arcane in the sense that there's no intuitive link between any particular pattern and concepts like extra small and extra large.

screenshots of top 3 included, curious what you think?

[mbajur]

I like signal the most. Couldn't it be simply a chosen tshirt size as a raw text though? That could be even more self-explanatory than an icon

[kudzuweb]

nah lol #1965 (reply in thread)

[jasonfried]

Curious: How does this beat just adding "XL" or "L" or "M" or whatever to the title of the card itself? We always try to find the less-software approach first. Is it worth adding more software? Is more software better than less software? If you just add [XL] to the end of a card, does that solve it? And is it just more flexible? It allows you to say "XXL" if you absolutely must.

[kudzuweb]

The icon takes advantage of the difference between how the brain processes images vs text(faster, more directly, fewer brain regions involved, seeing vs decoding) to minimize the cognitive bandwidth used to process the information. Imo, it is better to leave textual representation for information that necessitates it, and use visual representation for everything you can without sacrificing clarity(which eliminates the advantage). It's less about the difference between "XL" and a signal strength icon directly than it is the total cognitive load of the interface. There is much information being relayed on a kanban board, and delegating the scope information to visual processing is one less piece going through the more complex decoding network used by text. A fractal application of the same idea behind using a kanban board to visually display the relationships of tasks to each other and the team members rather than writing it all out, so that you just SEE what's going on rather than reconstructing it from text.

Adding XL to the end of a card relays the information, just in a less efficient way. It would show in different places on each card, reducing scannability. With the icon, I can take in my workload at a glance. You also wouldn't be able to filter cards by scope, eg when looking for a task the right size to fit the window you have before your next meeting. It becomes information storage rather than information display.

Finally, I think the lack of flexibility here is a feature rather than a bug. Tshirt sizing is a fuzzy ordination, but inherently constrained to a 0-1 range that ime keeps everyone on the team closer to the same page than a theoretically infinite scale. This is why I chose it over the Fibonacci convention, which seems to induce more variation in how people on the same team use the sizes, causing the sizing to lose meaning(and thus usefulness).

[kudzuweb]

This, but for UX. "What's the most aerodynamic user experience? The UI that feels most effortless in practice? Day in, day out, large project or small, one person or multiple teams, what's the lowest friction, lowest cognitive load experience possible without sacrificing utility?"

That's why the icon. https://x.com/jasonfried/status/1998813514073616580?s=46&t=Wuvp1HtDu1f33_uNLhlhTQ

[seiz]

To me, the Signal-Icon provides no benefit over a Textual (Tag to Title…) representation (it might even reduce accessibility).
The Problem with the graphical representations of Ticket-Effort is, that they only work by comparison. Imagine you have a screen full off only "S" Efforts. Would you know it is "S" and not "XS"? I don't think one would.

[kudzuweb]

Yes, I found that to be an issue with the majority of visual ways to represent this, and it's one of the main reasons I think signal strength is my first choice icon. It carries its comparison with it, so you can always tell that a card is S(2 filled bars, 3 empty) rather than any other size. One card on the screen, all cards one size, doesn't matter. The comparison is self-contained within the icon.