Asset Project: Workflow & UI
Open, NormalPublic

Description

Asset Project: Workflow

This design task aims to develop the basic workflows for asset interaction (see also main design task T46049).

Pre-assumptions

On most basic level, asset interactions are:

  • Browsing assets
  • Loading assets
  • Updating assets

Role of the asset engine in the workflow
We want to give the asset engine itself as much flexibility possible to integrate its data into the UI. Therefore, we only want to develop an UI "skeleton" that the asset engine can use to build up upon.

Open Questions

Open questions in the scope of this task are:

  • What are the (common) steps a user will take for each of the asset interactions?
  • Where will information and options be displayed (roughly!)? - This may overlap with workflow

Description will be updated to represent current state of discussion.

Details

Type
Design
Julian Eisel (Severin) updated the task description. (Show Details)

In T46049, there's already some information and some proposals on usage/workflow. Quoting related content:

Import
  • Open FileBrowser
  • Select desired asset engine
  • Browser requests asset engine to list a root directory ('/' by default).
  • Asset engine returns a list of entries, which are fake files and directories.
  • Keep navigating as in a regular file browser that way.
  • Filter shown entries by type, name etc. as currently, but also select a variant and revision for each entry (how to do so UI-wise is still WIP, aside from mere list buttons there are also ideas like global time 'scrolling' for revisions…) - filtering and sorting is provided by the asset engine (such that it can customize it to its needs).
  • (Optionally) request the asset engine to 'preload' some entries (assets). This is mainly intended for asset engines handling remote storage, to avoid having to download locally the whole selection at once at the end, but could be used for any other heavy/long pre-processing.
  • Once actually importing the selection:
    • asset engine's pre-import callback is called with selected (entry/variant/revision) items. This callback is expected to return a list of paths to real data.
    • import op actually imports those data (pretty much exactly the same way as current code, the only difference is that a reference to asset engine and asset uuid is stored within IDs).
    • asset engines's post-import callback is called with imported IDs. This is for advanced processing, like e.g. applying scripts on those IDs (auto-place/resize objects, whatever).
Loaded Asset Management

That is, remove an asset from current file, or change its variant/revision. This should be handled by the Outliner (to be consistent with current behavior, outliner is for 'current' data, while filebrowser is to add new data).

[...]

Note that in addition to always using a manually specified variant/revision of an asset, there will also be an option to use 'default' variant, and 'latest' revision.

Defining Assets

That is, creating, editing, deleting assets from the proposed collection. This is the second step of the plan, goal is to first have a relatively 'feature complete' version of 'Using Assets' before tackling it. Also, this may need a new space - not totally convinced it would be wise to extend current filebrowser to support that - and yet it would probably share a lot of code with it.

Main task would be to control metadata of the assets (tags, variants, revisions).

There are no detailed plans for this part yet, general idea would be to have two views, one showing the 'asset engine' content (i.e. available assets), the other a 'real' file browser. One could then select datablocks from the 'file' part to define a new asset, or add to an existing one, etc.

Editing the content itself of the asset (its data) could be done e.g. by launching a new Blender instance to make the edits (using a 'forged' Blender file to contain all the asset data, and only the asset data?). Think this should be left to the asset engine though.

Here is my rough workflow proposal (already got a comment from mont that it's possible to do via add-on, so I guess it's on topic?):

When you are working on asset management, you can also consider personal asset collections. Currently they are awkward to make and manage. I think that storing them somewhere in the personal config files, so they would be close at hand at all times, with an easy access from the UI would be best.

Would it be possible to save datablocks (like materials) as single files somehow? This was merging collections would be just a matter of pasting files in the config folder.

Currently the best design for asset collections seems to be the Shelf to me: You have a dedicated window in the software, where you can drag and drop assets (ex. materials), which will be accessible later (will stay there when starting/opening projects).

The File Browser could serve as such a Shelf, like in Fluid Designer. The Shelf would be a File Browser mode. It could also be a dedicated editor window. How is Shelf different from the standard File Browser:

  • Divided into data type directories (materials, node trees, meshes etc.) by default. Buttons for data types on the header.
  • Root directory of each data type is the corresponding folder in the config folder (under /Shelf).
  • No toolshelf sidebar (bookmarks are not needed, since it would be impossible to leave the data type folder anyway).

Bastien Montagne (mont29) renamed this task from Asset Project: Workflow to Asset Project: Workflow & UI.Sep 11 2015, 5:55 PM

@Paweł Łyczkowski (plyczkowski) Would not define such behavior in Blender itself, this is asset engine responsibility. And think we'll always need side panels (think about type filtering, but also tag, and other advanced search features…). Also, would keep the bookmark area, since it allows people to bookmark asset engines 'root paths' as well (we'll likely have to extend bookmarks to make them engine-aware, btw), that way people can easily chose to have a single asset repo, or several, etc.

The idea of an asset tab in shelf is probably too complicated.
It would imply another tab for browsing options and adapting filters to context.

But we have a problem with the idea of two views.

Current linking/appending workflow with file browser is fullscreen only.
Desired behaviour to drag and drop data from asset browser to 3DView, Node Editor, Movie Clip Editor, NLA Editor...etc is not possible for blend datas like it is for files.
File Browser have lots of option in his header.

I think that it should be a new editor.

Workflow
User defines area used by asset browser in screen.
User will start by defining repos that interest him. So, for this step, he can temporarily maximize asset browser's area to display side panels.
Then, user minimizes area and hide side panels.
Finally, he can drag and drop data when needed.

Here, a proposal with a shorter header with what should be kept.


Navigation icons could be in a side panel.
User is often preoccupied by only one type of data at a time.
So, a unique filter can be choosen at a starting point. And if more are needed, advanced filters in side panels would be used.
Maybe, name filter or other crucial options could be inside asset browser's main region instead of inside header.

The idea of an asset tab in shelf is probably too complicated.
It would imply another tab for browsing options and adapting filters to context.

I really do not see why? Tons of addons already add their own panels in UI, really have no idea why asset engines could not do the same?

Current linking/appending workflow with file browser is fullscreen only.
Desired behaviour to drag and drop data from asset browser to 3DView, Node Editor, Movie Clip Editor, NLA Editor...etc is not possible for blend datas like it is for files.

It is absolutely and perfectly possible - and is part of my TODOs, it’s just a matter of implementing it.

File Browser have lots of option in his header.

Actually, each asset engine redefines that header as it likes (it has a callback to draw the header).

In fact, I think Outliner will need much more work than FileBrowser (given all that .has been done there already) to be asset-ready now (it lacks, among other things, the concept of active element…).

Also, I’m quite not convinced we should split filebrowser in two to edit an asset repo, would rather have two FB side by side, and user drag'n'drop between them, Blender only providing a mere glue code through the D'n'D process and everything else is handled by source and destination engines (which can be same, different, mere file browser itself, etc.). Probably dragging from the Outliner too when current opened .blend file comes into play…

I really do not see why? Tons of addons already add their own panels in UI, really have no idea why asset engines could not do the same?

I don"t mean it is impossible.
I mena it would probably difficult to maintain if for examples, in paint modes, filters are restricted to brushes, palettes, paint curves, textures, image.
And if in object mode, it should be groups, objects, materials etc...
And if it is different in each editor.

Actually, each asset engine redefines that header as it likes (it has a callback to draw the header).

In fact, I think Outliner will need much more work than FileBrowser (given all that .has been done there already) to be asset-ready now (it lacks, among other things, the concept of active element…).

Also, I’m quite not convinced we should split filebrowser in two to edit an asset repo, would rather have two FB side by side, and user drag'n'drop between them, Blender only providing a mere glue code through the D'n'D process and everything else is handled by source and destination engines (which can be same, different, mere file browser itself, etc.). Probably dragging from the Outliner too when current opened .blend file comes into play…

In fact, I think that file browser and asset browser should be splitted to distinguish files opening/saving and assets importing.
In first case, panels displayed are relative to formats.
In second case, only blender datas are treated with global options that can be relative to engine.
In both cases, repo have to be defined. A drag and drop between two file browsers looks like a slow workflow.
A user can have organized data into directories and he would have to re-fill his bag for each new .blend ?!

I would also think that having as much of asset interaction (widgets) available in own panels in the UI would be good [even though 'default' places for this could be filebrowser/outliner]

just a quick note/todo about this (already had a quick chat with @Bastien Montagne (mont29) about this):
atm. we cannot display the previews of non-loaded data in own panels. they of course show fine in the filebrowser but there is no way to display them from py using e.g. row.template_icon_view() which would allow for flexible "shelf-like" panels already. [iirc, this requires an API for thumb-manager...]

was also looking into dragndrop .blend contents from filebrowser (but the current fullscreen limitation is blocking -- why do we actually have this limitation?)

Another thing that came up is handlers (to implement extra actions upon linking/appending): how about implementing something like
bpy.app.handlers.append_pre
bpy.app.handlers.append_post
bpy.app.handlers.link_pre
bpy.app.handlers.link_post

was also looking into dragndrop .blend contents from filebrowser (but the current fullscreen limitation is blocking -- why do we actually have this limitation?)

That is very true. Would be awesome to just have a little file browser window near the viewport like in Fluid Designer to be able to drop assets and place them directly where needed.