[APPROVED] View descriptions

Would be nice an optional rich text description that will appear just below the view name. On my views in Coda and Notion I always add some extra info or instructions about the view, it also helps with context for new team members. Since Fibery views are not inserted inside documents, I think a rich text description would be very handy.

Also, maybe show the Icons we set for selects and workflows in Rows and Columns :slight_smile:

2 Likes

@Jean, interesting I just posted this too!

with particular reference to Notion in fact! So I second wholeheartedly!!

What do you think about my suggestion of also adding that detail to the columns and rows? I think this would provide great Sprint Boards in particular, if you could see the entire feature details that’s being worked on - ala Azure Boards, Pipefy, Jira, in particular of course TargetProcess.

Thanks!

1 Like

I’ve been using ClickUp recently for a consulting job, and they make heavy use of “List” descriptions that show at the top of list views. It has made me realize how handy it is, at least in theory (I say that because I don’t know how much any of the internal staff read these anymore :grinning_face_with_smiling_eyes:). So I just voted for this (because I’m hoping to move them to Fibery over time).

Here’s an example of what this looks like from ClickUp:

I agree that being able to introduce users to a view with some background info is useful.
Sometimes, I feel it’s useful to be able to have several views grouped together with an overall description, so I wonder if this need might just as well be solved with the ability to embed views in documents? With that, you could have a description followed by (or interleaved with) any number of views.
I recognise that this method introduces a bit more friction (create document, add text, embed view) compared with having a dedicated area, but given the limited number of votes we have :wink: I think I’d rather use one of mine on this:

1 Like

Hah! Well, you know I support that call. Personally I do still think there is separate value in this feature request, but you’re right that given a finite number of things that can be done in a reasonable time frame, the other would be more impactful overall by far (for example it would make a big step toward Configurable Dashboards I think). I may well redistribute my votes again soon, like I did today, hah. But since I’m working with this particular client, I want to be able to minimize what they are losing in migrating. This is hopefully a small thing for them though, so it’s a fair point…