mottosso
commented
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.
Asana Basics
In Asana, there are 4 levels of granuality.
- Workspace
- Project
- Task
- Subtask (Optional)
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.
- Workspace = Show, e.g. Man of Steel
- Project = Sequence, e.g. shots or assets
- Task = Asset or shot, e.g. Bruce or Table or 1000, 1200
- Subtask = rig, model, lights, animation
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.
Implementation
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.
Launcher
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.
tokejepsen
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.