“Tab+N” new shortcut to create Sections


#1

Thanks, @Joe_Trollo, but I believe there’s a problem as I was trying to indicate before, and this has already broken a feature in Asana2Go and I suspect other apps too. I’ll try to explain better:

In my app right now, as of the Tab-N change, I can no longer distinguish subtask sections from subtasks, and I believe you’re saying that you have no plans in the API to remedy this, so that’s the problem. This happens now because a subtask ending in a colon is no longer a reliable indicator that it’s a subtask section. If today I add a subtask with a colon, it won’t appear as a subtask section in the UI (as it had in the past). But subtasks with colons I added prior to a few weeks ago do appear as subtask sections in the UI; that should be exposed through the API.

I believe internally Asana must have a way to distinguish subtasks from subtask sections or you wouldn’t be able to present them as you do now. I think this needs to be exposed as a property of the subtask so I can fix Asana2Go now, and so, generally, an app can distinguish a subtask from a subtask section; something that worked until a few weeks ago and is now broken, and is a significant property that should be available programmatically.

Thanks,

Larry


"Tab+N" our new shortcut to create Sections
#2

@lpb

Larry, I think if you query the resource_subtype property of the subtask section, it will return a value of section?


#3

Thanks, @Phil, but I’m not seeing that. For any subtask, for me resource_subtype shows a value of “task” today. That’s true for whether it’s a subtask, an old subtask section, or a new subtask section. Are you seeing something different?


#4

I am, but I’m not in the 10% of users who have been transitioned to “Tab+N” yet so I was hoping it would apply to you as well, but it seems not. For me, if I make a subtask section (via the old way of ending it with a colon), that task has a resource_subtype of section. But since you’re not seeing that, I think the problem you raised to Joe is valid.


#5

Much appreciated, @Phil_Seeman!


#6

Hi @lpb, I’ve gone ahead and moved the second part of your feedback to the #developersAPI category; hope that’s ok :slight_smile:


#7

@Joe_Trollo, My previous posts here, and @Phil_Seeman’s, were about distinguishing subtask sections from subtasks.

But I’d also like to ask about tasks in this post.

I see now that sections I created a while ago, as well as newly-created Tab-N sections, both have resource_subtype: "section". Is this, going forward, the way to determine if a task is a section (until column-sections appear)? I didn’t see an explicit announcement for “New task subtypes” (https://asana.com/developers/documentation/getting-started/deprecations) of the “activation date” for this (or even really the “start date”) but it seems like it’s been activated for some users (including me). Or maybe just this portion of the change is not part of the deprecations framework?

Asana2Go’s recognition of which tasks are sections is broken as a result of this (previously I reported Asana2Go was broken for subtask sections, but it’s also broken for task-level sections).

I’d like to fix Asana2Go to distinguish sections vs. tasks for all users. Are all users seeing this yet or, if not, when will that activation date occur? Ideally that will be very soon so I can update to look at resource_subtype: "section". Can you let me know about this (and also about the subtype sections questions as well)?

I’m assuming other API clients that must distinguish tasks/sections are affected similarly.

Thanks very much,

Larry


#8

Hi @lpb,

Currently, because we have not begun the deprecation, “section” tasks (not just subtasks) indicate that they are “sections” through their resource_subtype. However, going forward, they will eventually indicate resource_subtype: "default_task" as mentioned in my earlier post:

Task-sections will no longer have special meaning. Currently, a task-section’s resource_subtype attribute in the API will read "section" , but they will eventually become standard tasks with resource_subtype: "default_task" .

You can use the resource_subtype to determine if a task is a “section” for the time being, but be aware that this will be deprecated over the next few months as task-sections are replaced with proper column-sections.

After the migration, the API will no longer distinguish “section” subtasks from “plain” subtasks because doing so would lead to inconsistent data. Sections in subtasks are purely visual markers, and there’s nothing in their structure that makes them different from regular tasks—they can still be assigned, given due dates, commented on, etc. Although this is difficult to do in the new UI, it’s not impossible, and it’s not forbidden in our data model.

Importantly, subtask sections can be multi-homed like normal tasks. After we have completed the migration, if you multi-home a subtask “section” into a normal project, it will be a plain task and look like all the tasks around it—it will not be a real section, and will not look like a section. The data you fetch from the API should not be different depending on how you access it, so fetching that task through GET /tasks/<id>, GET /tasks/<parent-id>/subtasks, and GET /projects/<project-id>/tasks must all return the exact same data for the subtask “section.” The only response that can be consistent with our data model and across all views of that data is to report that resource_subtype: "default_task", even if the task is styled as a section when you view it as a subtask in the task pane.

Regarding the activation date of the API migration: the API portion of this work is progressing independently of the web app work. The dates provided from the API team will reflect only the changes in the API, while the changes you see in the web app may happen earlier or later.


#9

@Joe_Trollo,

But since you’re saying that section subtasks will still be visually distinguishable from regular subtasks in the web app after the migration, then there must be something in the data model that will say “I’m a subtask section, not a regular subtask”?


#10

Yes, there is still a flag in our data model, but it is not exposed in our API and we do not yet know how we would expose it or if we can expose it. Our current API designs with regards to sections are based on things we are certain of from the product teams working on this. We aren’t yet confident enough in the long-term implementation/behavior of subtask sections to add that information to the API.


#11

Thanks, @Joe_Trollo, I understand that your group is not leading this, but I hope you can appreciate the cause for concern.

@Marie, could you escalate this post to the product team? @Phil_Seeman, @Bastien_Siebman, and I are all very surprised and alarmed (I consulted them to make sure I wasn’t either mistaken or overreacting). Also note @Vince_Mustachio’s concern in "Tab+N" our new shortcut to create Sections on CSV-export and other, non-API-related issues resulting from this change.

Because of the unannounced and now partially-implemented product change that an ending colon no longer designates a task section or subtask section, and an unclear future direction:

  1. There was no notice given and as of right now it’s not possible in the API or CSV exports to distinguish a task section due to a partial roll-out.

  2. While it will be possible eventually to use resource_subtype to distinguish, it’s not clear when, and even then code will need to change again when column-sections appear.

  3. Subtask sections are impossible to distinguish via the API/CSV now and there’s no plan to restore this in the future. This is a significant product change that was implemented without any warning.

These changes already have broken third-party apps and CSV-export-based workflows.

The API team goes to great lengths to prepare third-party developers for any changes both with detailed, advanced communications and their thoughtful deprecation framework. This UI change on the other hand, though it has great ramifications to both third-party developers and Asana customers with export workflows, came without any warning leaving us in the lurch presently, and with a significant, long-standing feature gone without notice.

We request you roll back, as soon as possible, the UI change that an ending colon no longer designates a task section or subtask section until 1) proper notification of such a change is offered, and 2) a clear plan is presented that includes exposing through the API the core feature of distinguishing subtask sections. Thanks for your consideration.


#12

Hi @Marie and @Joe_Trollo ,

As @lpb said above, a few of us conferred on this issue and I have to agree with Larry’s input.

While the API team seems very committed to making changes in a measured and orderly way with a lot of communication, the Section-related UI changes made to the web app came without any warning and have adversely impacted a number of 3rd party integrations. I’m guessing that while the API team is always focused on external developers, the web/UI team is perhaps less so, and didn’t fully realize the ramifications their changes would have on our apps.

While we realize it’s a big ask, we think the best course of action would be to roll back these UI changes until a clearly-communicated and thought-out plan is available for making the needed Section changes, so that we can all work together for as smooth a transition as possible.


#13

I concur, let’s find a way to make sure third-party developers are aware in advance of UI changes so they can adapt. Breaking other people apps on a regular basis is not a healthy relationship to have…


#14

Thank you all for your feedback and apologies for the trouble. Let me liaise with the API Team and we will be in touch soon!


#15

Oh, man, yes, this is unfortunate :frowning: I’m going to leave any technical details on how to move forward to @Joe_Trollo as he’s far more capable of holding the whole state of Asana’s data model in his head than I, especially during these times of transition.

What I would like to throw out there is the reason that you’re seeing the Tab+N change: y’all know this old thing? Switching from Boards to List View (and vice versa)? More or less the most-requested product enhancement in the Asana forums?

:fireworks: We’re fixing that this year in Asana :fireworks: and it will become possible to switch views between board and list projects.

The feedback in the above comments is really helpful in highlighting how seemingly minor changes (from our internal perspective) can have major impact for our integrations. We do our best on the platform team to keep abreast of these sorts of changes to flag breaking changes for our apps, and we’ve made a lot of progress in working with product teams to raise awareness of the impact of these sorts of changes, but sometimes these systems and changes are so complex that these apparently minor tweaks have a large impact, particularly for our API developers. We’re sorry about the negative effect this has had, so I’d like to peel back the hood a bit to explain some of Asana’s internals to make it clearer why this change was made.

How did we get here?

It would seem like switching between a board layout and a list layout would be relatively straightforward - and it should be - except that there’s historical data model technical debt that has to be paid down to make it happen.

As @Joe_Trollo mentioned in Sections are dead! Long live sections!, sections in list projects are implemented as tasks. More specifically, they are tasks that, when their name ends with a colon, tell the Asana data model that they should be rendered as a section. Joe called these “task-sections”, so we’ll call them that here. For further clarity, the colon is not significant for determining that a task is a section - as Joe mentioned, this is a property on the task that is not exposed in the API. A colon simply triggers this property to record the task should render as a section.

When they were originally built, sections as a container wasn’t the primary use case for them (they could represent a checkpoint, say, with no container semantics), but after gathering enough data about how sections are used, it became clear that the “containership” use case was their stickiest use. In fact, shipping task-sections fast was a very valuable way to improve the product while gathering the sort of usage information we wanted to determine what the value of sections is to our users. The point is, over time we’ve learned that sections work well as containers and we’ve built quite a bit of code to handle task-section containership seem like it’s a “real” thing.

Knowing this when boards were built is why our boards view did made columns a first-class data structure that contain their tasks. Let’s call these column-sections.

With these two different data models for our projects, we can’t switch between board and list projects very efficiently; we’d have to do some operation to keep two different data model copies in sync in real time. This would be yet more code to work with the task-section data model that we don’t want to keep encouraging to exist :slight_smile:

That’s why we’re back-porting column-sections to list projects.

What is Tab+N?

The first change that the product team has made during this transition is to make task-sections behave more like their upcoming column-section implementation. You may notice that columns in board projects currently don’t have to have names which end in a colon, and this will be true for list views’ column-sections in the future. Additionally, Tab+N now creates a new section at the end of the current section in a list project, just as it will in the future with a column-section. (Previously, ending a task with a colon used to convert it to a section, and it would immediately start to “contain” the tasks below it. Now, with Tab+N, a new empty section is created after all the tasks in the current section).

Although list view sections today are still task-sections, the move to Tab+N from a terminal colon is meant to start our users’ behavioral migration now - to get people used to the fact that list view sections must behave this way when they’re implemented as column-sections.

So what’s going to happen with task subtasks?

For now the team that is focusing on the section migration is focusing on projects. That means that subtask sections will more or less remain the way they do today as task-sections (with the Tab+N behavior) for at least the near future, because that “feels” to our users like sections are consistent regardless of how they’re implemented, both during this transition and throughout our product. At this point in the process you can’t assume a terminal colon is the way to determine the section-ness of a task. Rather, for subtasks you should look at resource_subtype to determine this information.

More changes will follow as we make this migration, some of them visible to Asana users, many invisible or nearly so. Unfortunately, it’s the nature of an API’s close access to its data model to be more exposed to these kinds of otherwise internal changes, so we have a harder time insulating our developers from any of these changes. Even when we try to anticipate some of them we’ll miss some and some might sneak under our radar, and even more challenging, some of them can’t be made invisible to our integrations. Thanks for your patience and understanding while we try to do our best to keep our API stable as we make changes behind the scenes.

Regarding the Tab+N change, we can’t roll back from this point, because Tab+N sections really don’t have a terminal colon, and a “rollback” would modify user-created data, which we only to do if it’s a big security concern. At this point we’re stuck in the new world, I’m afraid. The best we can offer is to assure you we’ve highlighted this as a zero-day API breaking change for our product teams to stay aware of the impact of changes made to Asana.

So here’s where we are today:

  • Boards use column-sections; the endpoints in our docs that are boards-only (like reordering sections with POST /projects/{project_gid}/sections/insert ) only work on boards layouts.
  • Lists use task-sections; they need not end in a colon, but they will have the resource_subtype=section property to determine that they are a section and not a task.
  • Subtasks use task-sections; they need not end in a colon, but they will have the resource_subtype=section property to determine that they are a section and not a task.

Here’s where we are after all projects use column-sections:

  • Boards use column-sections, and the boards-only endpoints will continue to work for boards projects - with improvements. For instance, we’ll get better iteration order over tasks in a boards view; instead of semi-random, it will become top-to-bottom per column, left to right across columns.
  • Lists use column-sections, and the (today) boards-only endpoints will start to work for them - you can bulk-move whole sections relative to each other in a list section, for instance, just like reordering columns in a board view.
  • Subtasks use task-sections just like today. They don’t have to end in a colon and will no longer claim they are sections in resource_subtype; they will have resource_subtype=default_task. This is to reinforce that they are tasks and will show up as plain old tasks in all projects, both list and board view. (The analogy with the world of today is how a section, when moved/multi-homed to a board view, shows up as a plain old task in the board view; it’s really a task when you look closely at it). Joe and the API team are focusing right now on how to handle this case so apps can determine subtask sections in the future.

There are a number of edge cases in this future state that are frankly no worse than the edge cases in the current state, but they will be new edge cases. @Joe_Trollo is working with the API team and product teams to figure out how we might better head off these edge cases with new features or properties in our API, so stay tuned for updates from him.


"Tab+N" our new shortcut to create Sections
#16

We’ve talked to the product team about the future of “sections” in subtasks and My Tasks, and (1) we have no intention of fully removing those kinds of sections from the web product, and (2) we will not be moving those kinds of sections to a new data model as part of this work. We now have clarity on the future of these task-sections, and can now make a decision about how we’ll handle this in the API.

We’re going to continue keeping the word “section” to refer to exclusively proper, data-model-backed column-sections, and task sections will have resource_subtype: "default_task". To signal whether these tasks are rendered differently in subtask and My Tasks views in the web product, we will be adding a new boolean field is_rendered_as_separator. The API will use the distinct term “separator” to refer to task-sections.

While we implement this new field, you can continue to use resource_subtype: "section" to determine if something is a separator, and I’ll update this post again when we’ve finished implementing the new is_rendered_as_separator field.


Sections are dead! Long live sections!
#17

Thanks, @Matt_Bramlage, and thanks @Joe_Trollo.

I appreciate the explanations and the changes coming.

I’ll have to think more about what I need to do immediately with Asana2Go given this. I know it would help me to learn when you think the past change will be 100% rolled out, since that might simplify work/timing of changes.

Regardless, I think it would help to restore as soon as possible the Tab-N behavior to insert

New Section:

where all but the colon is selected for replacement upon typing. (I was naive when I originally requested that the colon be removed.) I think this will help immediately and throughout the transition.

Thanks,

Larry


#18

This update is another in a string of unannounced changes.
At the end of the day, I would like improved Sections in Asana. But that improvement for Asana and it’s users is going to appear like Asana is broken if it’s done in a way that surprises users with unexpected and misunderstood changes.

I highly recommend to stop putting your users in a position that forces them to stop working and wonder why Asana has changed, how it’s changed, and if it’s permanent.