Open tokejepsen opened 8 years ago
First off, awesome that you're using Asana for this. I'd like to see it get more attention in vfx and think it's sufficiently complex for custom needs yet simple enough for anyone to understand and use as their personal todo list, as opposed to Ftrack/Shotgun which are massive beasts by comparison.
Secondly, yeah, this would be cool.
At the moment, the context is stored in files alongside each project, but it should be possible for this data to be stored alongside each project in Asana instead.
In Asana, there are 4 levels of granuality.
The workspace represents the top-most level and is what you switch between when clicking the top-right user icon, whereas the subtasks are optionally added to each task within the commenting section.
Spontaneously, each level would map something like this.
Subtasks can also be nested (up to four additional levels, it seems) which may come in handy. Both tasks and subtasks can be assigned and commented upon.
Separating vfx projects into Asana Workspaces, as opposed to Asana Projects, benefit from a per-project chat and notifications and user associations and permissions, along with occasionally avoiding to pay for projects that have less than 15 people involved.
Technically, I think this would be a rewrite of be
. But the implementation isn't really what's interesting or challenging to nail down anyway; the workflow is, and it can remain as is.
I'd imagine the work to take place in a be-asana GitHub repository, until it's obvious how it can blend with the original repository.
I'd imagine there to be a convention on where assets and shots are in Asana, meaning we'll have to make a few assumptions that might not fit everybody, which is fine.
Asana would need to keep track of templates and inventory. Inventory is obvious, it could be the list of tasks; assets, shots etc.. The name of the Asana Project then could then represent the "key" to which be
templates are associated.
E.g. The Asana Project Shots
could be associated with the template {root}/{project}/shots/{shot}/{task}
.
The template could be stored within the Asana Project either as an individual task, or within the project description of sorts.
On top of project content and tasks (Asana) and directory and envrionment variable management (be
) there should of course also be a Launcher. Something to actually start an application within a given context.
This is where I see the additional GUI come in. It wouldn't be be
, per se, it would be a separate project based on be
and Asana. It would need to parse the inventory and template, from Asana, in order to create the hierarchy and initialise the environment.
It would need to allow a user to see/maintain a list of his own tasks from which to launch software, along with direct, project-sensitive links to the actual software, so as to not overwhelm him with every asset and task in a given project.
_________________________________________
| Launcher _ x |
| |
| -+- |
| Project Asset Task |
| _____________________________________ |
| | The hulk | Bruce | Modeling | |
| | The hulk | Shot 5 | Animation | |
| | The hulk | Shot 6 | Animation | |
| | The hulk | Shot 9 | Animation | |
| |___________|________|________________| |
| |
| | Maya | Houdini | Nuke |
|_________________________________________|
An alternative, as you say, could be to launch from within Asana, though I'm cautiously sceptical about that approach.
Asana Basics So the way I'm using Asana right now, is like this;
Describing sequences are done with a "Section", but it goes into the shot name anyways to make the shot unique, ei. "sq001sh001" etc.
I think using workspaces as Projects, and Projects as sequences are bound for user confusion.
Launcher Yeah, if you could query Asana or be or Ftrack/Shotgun, then I think this could be quite useful. Note that Ftrack/Shotgun have their own launchers directly from the web browser.
I think a side-ways hierarchical browser would work well. I would probably not limit the amount of children, and also leave the naming of the columns to the users. Maybe for the Asana "extension" for the launcher, you would just have "Workspace" > "Project" > "Task" > "Subtask" > "SubTask", so people can use Asana how they want.
I see this as a standalone project, where you make "plugins" for getting the context. Whether that is Asana, be or Ftrack/Shotgun. What do you think?
I think using workspaces as Projects, and Projects as sequences are bound for user confusion.
Fair enough, it's just that you loose out on 1 of 4 levels when it comes to navigating. How often does an artist change company?
Either way, 3 levels should suffice.
Note that Ftrack/Shotgun have their own launchers directly from the web browser.
I wouldn't let one implementation of a launcher hinder us from making another (better) one. Not even Fido uses that launcher. :)
How often does an artist change company?
Not often at all. But I still think there would be a confusion about the Projects not being treated as projects.
What do you think the next step from here?
We are using Asana for making tasks and project management. Would be cool to using the data in Asana for getting the right context of a task.
There are two options I could think of; extending be to query Asana and launching be from Asana. The first being the easiest to implement, and the second being the best user experience.
\ Extending be ** So there is a python api for Asana; https://github.com/Asana/python-asana, which makes it easy to query Asana.
\ Launch be ** Since the user already is in Asana, having a launch button would make it super easy for them to get the right context. Could possibly look at modifying this chrome extension; https://github.com/toggl/toggl-button
There is a third option, which might pull the best of both options; building a gui for be. With this option you could pull all the data from Asana, you need and present to the user. Launching the correct context would be a lot easier visually, than typing on the terminal.