-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asana context #43
Comments
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 BasicsIn 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. ImplementationTechnically, I think this would be a rewrite of 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 E.g. The Asana Project The template could be stored within the Asana Project either as an individual task, or within the project description of sorts. LauncherOn top of project content and tasks (Asana) and directory and envrionment variable management ( This is where I see the additional GUI come in. It wouldn't be 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
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 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? |
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.
I wouldn't let one implementation of a launcher hinder us from making another (better) one. Not even Fido uses that launcher. :) |
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.
The text was updated successfully, but these errors were encountered: