This is probably on your roadmap as a very fundamental feature, but I wanted to just add my 2c and some uses of Checklists, which I think would work best as an extension that would complement each entity.
I realize we have checklists now in a simple form that can be added as a block within the canvas of Docs and Rich Text fields. However, aside from “x-ing out” when checked, there is no substance around them. So for things like Software dev, they aren’t as useful as more integrated lists like you might see in some Jira add-ons and other programs, which have:
ability to add due date
state (status) like “in progress,” etc.
assignee - could be multiple within one entity
I’d be looking to use these for the obvious dev stuff like Acceptance Criteria and Test Case Management, as I still have big hopes that you guys will bring some of this to a more built-out Software app template soon!
As an extension, I think you’d have the advantage of the checklists existing “around” the entity, and not embedded like current checklists, so they could also be used on dashboards, for example, where you could show a user assigned entities, checklist items, and comments (which I just wrote about here).
What is the difference between the “checklist” idea you’re referring to here, and simply having Sub-task as a Type with a 1-to-many relationship from Task to Sub-task?
The only difference I can really see is you can’t mark it “done” from the parent Task. But with Fibery’s excellent UX for navigating between Entities and Relationships, it’s just 1 extra click. And if you need to track that much info for a “checklist” item, what’s 1 more click?
Perhaps you want the assignee for checklist items to automatically inherit from the Task? Or something else more complex and specific? If not, I don’t really understand the value of what is being suggested, but I’d like to.
I would not call this a high priority, but I’ve found good use with some apps that have the notion of a “checklist” vs. subtasks. ClickUp and Jira (via marketplace extensions) are some of the better I’ve used. They attach to a task, and have very simple attributes of “assignee, due date, done/not done.”
I think it would be great if they were developed to link them to the entity they are attached to, potentially allowing for them to affect the completed State.
They would also be great in a Personal Dashboard of assigned items, along with @mentions to comments, and entities that you are assigned to.
My use for checklists has been mainly around Acceptance Criteria and QA stuff in software development.
Hmm, I’m still not clear on why this is better than sub-tasks, or at least enough of an improvement to justify the added UI/UX complexity. Is it just that sub-tasks seems “heavier”?
Right now nothing can “contribute” to done status of another entity, but Automations may allow sub-tasks to affect parent task completion state in the future.
In any case perhaps Fibery team sees the benefit even if I don’t. In the meantime you could consider using in-line @mentions for assignment of checklists already. That takes care of done/not done and assignee, then you just need date for a basic feature set.
Which raises the question: what if you can get 90% of the functionality you’re talking about here (as outlined above), but using features that are separately usable, rather than dedicated checklist functionality? Would that be good enough for your need?
@Oshyan all valid points. Let me clarify what I was trying to express earlier - sorry if it wasn’t clear - that I would put this down pretty far on the priority list. Just off the top of my head, I’d rank things like Recurring Entities, Time Tracking, Formal dependency handling, and other potential Extensions way ahead of this one!
I agree 100% that if you could incorporate some @mentoining recognition of blocks and this functionality from your post:
you would have a ton of what I am trying to accomplish here. I would love to see that Notion functionality here in Fibery, too.
I really like this suggestion:
Indeed, if you could bring this into some way to recognize a block with a combination of:
the content in the Block itself
the user who is being @mentioned
The reminder you are suggesting
And if it is a “checklist” type block, perhaps this could be a specially treated function so it might show up on a future Dashboard.
Until then though, this would certainly be a good solution if we could add in reminders that would roll up into Notifications, perhaps incorporated into Due Dates we have been discussing. And I fully agree with your discussions lately around the need for stronger Notifications. The lack of Notifications and Activity Stream as really held back my use of Fibery, since these are such key needs when a team is using Work Management software.
Finally, I will also go so far as to say that in some cases, for some more complex Acceptance Criteria or QA stuff, I have created a separate type of Entity already in my Fibery Instance that I have as a sub-Type to my generic “Dev Task” in my Software Development workflow. So in this case, yes I agree a “subtask” entity can be more important.
Really hoping over time to see some good flexibility with these Work Management-centric “add-ons”. I really think Fibery can continue to be more useful to teams than AirTable/Notion/Coda with development of these badly needed features that are essential to team function.
I tried out Fibery specifically looking for checklist functionality not present in existing case management systems, FWIW.
The UX friction for using checkboxes on child entities is not one additional click as Oshyan mentions. When checking a series of checkboxes it goes like this:
Click to open child entity
Click checkbox
Navigate back to parent entity
Scroll back to the list of child entities
[repeat]
I’m really hopeful that the Fibery team will address this with upcoming improvements to the UX/UI around linked entities (collections) whereby you can interact with the child entity’s fields directly from the parent.
I think that would mean that this issue would be solved: child tasks with the needed fields (assignee, checkbox, etc.) embedded in the parent entity view.
Woah, has this been discussed elsewhere before? Definitely an interesting possibility, but also seems a challenging without some other tools for organizing entity views, such as tabs, grouping, etc.
I’m not sure that it has been explicitly discussed here in the community forum, but the fibery blog post on the Fibery 2.0 vision (Fibery 2.0 Vision Foundation) seems to indicate that embedding structured information is part of the plan, and I assumed that it would mean editable views, but I could be wrong.
I realise now that what I wrote above could appear to be a statement about the roadmap, whereas it was more of a wishlist
Now I have more incentive to do so!