Thank you very much for the demo doc! Unfortunately, judging by what is presented in the doc, my concerns have been confirmed. Coda followed the path of least resistance and simply created subitems just like Notion did. That is, we will not have any independent columns here, and all subitems will be overloaded with the properties of the parent element, which will be inconvenient. In the video attached, there is an example of how I believe Coda could have implemented this. And the question of how this will look in other views and how convenient it will be also remains open.
The way the subitems feature is implemented for tables looks pretty spooky, to be honest. Maybe itās time to show some love to the UI/UX designers .
The vanilla behaviour is to create a new subitem row when requested. In the subitem row the parent column will be populated, and in the parent row the subitem column is populated. All other columns can be independently filled.
Thank you, Piet, for bringing up that point. Iām fully aware of how properties work in the context of the subitems feature, and I understand that child columns operate independently. This is an expected functionality ā after all, thatās the purpose of having subitems. However, I think there might be a slight misunderstanding. What Iām referring to is the ability to have an entirely different set of properties for subitems, without inheriting the columns from the parent item. Iād like to refer you to the video in my previous post, which illustrates how this could potentially be implemented.
This becomes especially important in complex projects with different task categories that require tracking various metrics, but still need to fit into a unified task tree. While itās possible to combine all properties into one large table, it can quickly become unwieldy and hard to manage. When working on multiple projects with hundreds of sub-tasks of different configurations, the current subitems implementation could make task management quite challenging.
Activating the feature would imply selecting a pre-prepared table to use for the child elements ā something like āMerge Table for Subitems.ā At the same time, we would still have the option to choose the same table, which would give us the traditional subitems setup similar to whatās presented in the beta. This way, we would achieve flexibility and full control over the project structure.
Whatās being prepared for release seems like a lazy approach and an underdeveloped solution, which is very unlike Coda, a company that has always prioritized well-thought-out functionality.
Regarding the timeline view is this possible now? Or are you grouping by parent task? (which i dont think would work for me because some parents have 2-3 subitem levels vs others only have 1 subitem level)
Timeline view definitely at the top of my subitems request list
Hello, Iāve been longing for this feature for a while and Iām glad itās finally coming.
However, some feedback wrt the current state of it, as well as personal wishes:
Being able to slice different views by different relations would be very important to me.
Iāve build a db to handle as many different cases as possible using 6 base relations to the same db: Type ā Instance, Parent ā Child, Dependent ā Dependency.
For a more analytical look Iād often want to see things nested by type/instance, but for task management itād obviously need to be parent/child, so I hope that can be accomodated. I now Notion supported that with their subitem toggle for a bit, but then just stopped for some reason. It is possible to do though.
Changing the parent and subitem columns without first turning subitems off completely is possible, but dicy rn because it requires you to first set one of the two to ā+ Create new columnā since all other than the already selected relation will be greyed out and unavailable.
I hope thatās a beta quirk and will be fixed by the time it releases.
An āexpand/collapse subitemsā keyboard shortcut would be pretty key for power users.
Being able to shift around db entries with keyboard shortcuts is one of the main selling points that makes me wanna use Coda over competing offerings right now.
In that vein it would be great for my use case if shortcut-moving an entry below another one that has its subitems expanded actually entered the moved entry there, new relation and all, and out of there respectively.
At present, it just moves things around as if the subitem toggle didnāt exist at all, even though manually dragānādropping entries into the subitem section of an entry does relate the items as youād expect.
Rather than Monday-like display of childitemsā differing properties, Iād like to be able to expand several different relations below an item, like actual Subtasks and related Dependency tasks, which in my case reside in a child and dependency relation (when looking at an actual project or task obviously) opposite parent and dependent relations all relating to the same db, and sometimes Iād like to see them all nested under the same task.
The already existing behavior of the āsubitem display columnā option makes me hopeful this could be done on a technical level, where the user decides what to expand/collapse by which columnās toggle chevron they actuated (Iād gladly navigate to the respective columns before using one generic subitem toggle keyboard shortcut as long as it was at all possible)
Just chiming in that I agree with @Stefan_Stoyanov@Tamerlan_PRO that having this type of functionality for relations would be ideal. I want to be able to see my sub-rows right in the main table view in a customizable and interactive way, like you can in the detail view.
This sub-item feature seems like a narrow and constrained approach. Sub-items often (nearly always?) need to have different structure and data in them. I love that Coda is looking at this problem but Iām concerned if the current approach is released then it will not be able to roll-back.
My concern exactly, @Ed_Liveikis. Some mini-upgrades are always welcome, but not really solving much for the power users. My overall feeling is that Coda is releasing features not considering the power-user cases who build platform/app-like docs. Rather, they cover some basic cases for general corporate doc users coming from Google sheets. Hopefully they prove me wrong.
Agreed, and in addition, sub-items are now yet another feature in an already feature-rich environment, requiring the user to learn, taking up menu space, using up cycles when navigating the app. To me this seems like a clear opportunity to improve the power of the existing Relation feature, a core feature of Coda.
Hey everyone, I hope itās okay to post this here. As a new Coda user, I was really drawn to the unique combination of code blocks inside table cells and Subitems. From what I can tell, Coda seems to be the only collaborative workspace that offers both these features.
I signed up for the Subitems beta about three days ago, and Iāve been searching around but havenāt found much info about it. Iām wondering if anyone knows how long it typically takes for a new user to get access to the Subitems beta? Any updates would be super helpful!
Its not turned on as soon as you submit the form. Those clever Coda chaps have to turn it on for your workspace. You will receive an email when this has done - and then you have subtasks.
Thanks for all of the feedback and enthusiasm for the subitems beta!
We will continue to enable subitems on a rolling basis as the team continues to improve and iterate. Given the shear amount of signups already, we will be enabling in batches over the next several weeks, so if you havenāt been selected yet, there is still time.
We greatly appreciate the patience!
For folks who do have access to the beta, please continue to share feedback here.
So many things are possible now with subitems. But there is a drawback when the list is growing:
I really miss the Collapse all/Expand all function that is for Groups. Sometimes Coda forget the state, and closes all. To expand all again is quite a job when you have a very long list with many collapsed areas. 40-50 clicks makes in impossible to work like that, unfortunately. Can this be fixed in near future?
.
