When building a formula for a formula field, it allows you to enter a ‘Unit’ name, which is essential for context. This field however is restricted to only 5 characters - that’s incredibly short. I’m sure this was a UI affordance issue, but it’s very limiting.
You can see from the screenshot, I’m trying to create a “Started n days ago” concept to track how many days it’s been since an issue/task was started. This is incredibly helpful to track tasks that are blocked, stale or otherwise being ignored. It’s also very common and valuable (Jira, Sunsama, Asana, etc.)
From the screenshot though, there’s just no way I can create a meaningful unit. When I display this field on cards, it comes across nearly meaningless if I try to force a 5 character unit name in.
I’d really love a longer limit, i.e. 16-20 characters. Yes, you might need to put in a text-overflow: ellipsis function in some views for the Unit field, but it seems a small price to pay for an easy and meaningful UX win. An even better improvement would be a custom prefix and suffix, allowing unit labels before and after the formula value:
‘started’ unit prefix, {formula value} ‘days ago’ unit suffix.
I would say that there’s a lot of info that can be conveyed between the field name, the field description and the unit.
So is the problem specifically that you want to see more info on the cards on board view? If so, you could change the card setting to ‘full’ and you’ll then see the field name.
Agreed, it’s just an information density and layout issue. More layout and data display precision = less noise + lower cognitive load/easier processing = faster + more accurate decision making = less user stress (lovable product) and better business outcomes. Small effects at the level of this discussion for sure, but they accumulate over time, and the principle of it is a good one I think .
To be more specific, as far as layout goes, any healthy degree of complexity + decently high stakes (which we have in spades) means we need to see enough info that having the ‘full’ card layout just takes up too much space, plus it’s too verbose. Creates a lot of visual processing noise. Plus there’s usecase differences (potentially very large depending on the size of company) between what is effectively backend data mgmt and frontend user+use context. Specifically, well enough cases where the db field name will be different than the unit label.
Even though as a company we’re still getting familiar with and migrating some stuff to Fibery (and things are looking good for it ) I’m finding that I rarely use the Full card layout - mostly b/c it just stacks everything in a single vertical column. Just takes up so much space. Compact layout seems the most effective - but runs into the field context problem.
.
) I’m finding that I rarely use the Full card layout - mostly b/c it just stacks everything in a single vertical column. Just takes up so much space. Compact layout seems the most effective - but runs into the field context problem.