Asset Project: Workflow & UI #46059

New Issue

Julian Eisel · 2015-09-09T17:09:49+02:00

Julian Eisel commented

2015-09-09 17:09:49 +02:00

Asset Project: Workflow

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

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.

Integrating the asset management functionality into Blender

We have decided to integrate the Asset Manager with the Blender File Browser. We are doing this for a few reasons:

It allows us to re-use as much shared code as possible between the asset browser and file browser
As we make improvements to asset browsing, the file browser will come along for the ride

People already use the file browser as a kind of asset manager

In Blender 2.8, to better reflect this, we will rename the File Browser to 'Asset Browser'. Using the the Open, Save, & Save As... commands will continue to work seamlessly, and users won't be bothered with any asset-related options where not applicable.

When using the Asset Browser editor type, we will present different views to the user, to switch between File Browser, Current File as well as various asset repositories.

Setting up asset repositories

We've decided to do this in Preferences. Users will only set these up once, and from then on be able to quickly switch between them in the Asset Manager. While you are browsing your assets, you don't want to be bothered with setting up the repositories themselves.

UI pending for this.

UI Wireframes

This section will give an idea of what our plans are for the user interface.

First, to better support both file browsing and asset management in one editor, we'll need to start by re-designing the file browser somewhat:

See #54642 for details

Description will be updated to represent current state of discussion.

# Asset Project: Workflow This design task aims to develop the basic workflows for asset interaction (see also main design task #46049). ## 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. ## Integrating the asset management functionality into Blender We have decided to integrate the Asset Manager with the Blender File Browser. We are doing this for a few reasons: - It allows us to re-use as much shared code as possible between the asset browser and file browser - As we make improvements to asset browsing, the file browser will come along for the ride # People already use the file browser as a kind of asset manager In Blender 2.8, to better reflect this, we will rename the File Browser to 'Asset Browser'. Using the the Open, Save, & Save As... commands will continue to work seamlessly, and users won't be bothered with any asset-related options where not applicable. When using the Asset Browser editor type, we will present different views to the user, to switch between File Browser, Current File as well as various asset repositories. ## Setting up asset repositories We've decided to do this in Preferences. Users will only set these up once, and from then on be able to quickly switch between them in the Asset Manager. While you are browsing your assets, you don't want to be bothered with setting up the repositories themselves. UI pending for this. ## UI Wireframes This section will give an idea of what our plans are for the user interface. First, to better support both file browsing and asset management in one editor, we'll need to start by re-designing the file browser somewhat: See #54642 for details ---- *Description will be updated to represent current state of discussion.*

Julian Eisel commented

2015-09-09 17:09:49 +02:00

Changed status to: 'Open'

Julian Eisel commented

2015-09-09 17:09:49 +02:00

Added subscribers: @JulianEisel, @mont29, @JonathanWilliamson, @pablovazquez, @PawelLyczkowski-1

Philipp Oeser commented

2015-09-09 17:34:36 +02:00

Added subscriber: @lichtwerk

Julian Eisel commented

2015-09-09 17:51:18 +02:00

In #46049, 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.

In #46049, 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.

Paweł Łyczkowski commented

2015-09-11 10:58:10 +02:00

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).

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). ![asdfdf.png](https://archive.blender.org/developer/F232175/asdfdf.png)

Bastien Montagne changed title from ~~Asset Project: Workflow~~ to Asset Project: Workflow & UI

2015-09-11 17:55:19 +02:00

Bastien Montagne commented

2015-09-11 17:59:42 +02:00

@PawelLyczkowski-1 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.

@PawelLyczkowski-1 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.

ronan ducluzeau commented

2015-09-15 16:17:20 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2015-09-15 16:17:20 +02:00

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. 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. ![AB_header_proposal.png](https://archive.blender.org/developer/F233432/AB_header_proposal.png) 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.

Bastien Montagne commented

2015-09-15 17:03:53 +02:00

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…

> 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…

ronan ducluzeau commented

2015-09-15 18:10:04 +02:00

In #46059#334993, @mont29 wrote:

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 ?!

> In #46059#334993, @mont29 wrote: > 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 ?!

Philipp Oeser commented

2015-09-16 23:04:14 +02:00

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 @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...]

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 @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...]

Philipp Oeser commented

2015-10-30 11:04:37 +01:00

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?) 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`

mathieu menuet commented

2015-10-30 21:45:27 +01:00

Added subscriber: @bliblubli

mathieu menuet commented

2015-10-30 21:45:27 +01:00

In #46059#344258, @lichtwerk wrote:
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.

> In #46059#344258, @lichtwerk wrote: > 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.

Jason schleifer commented

2015-12-17 18:31:24 +01:00

Added subscriber: @JasonSchleifer

William Reynish self-assigned this 2018-04-14 18:09:09 +02:00

michael knubben commented

2018-04-16 15:45:27 +02:00

Added subscriber: @michaelknubben

Dalai Felinto commented

2018-04-23 13:21:43 +02:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2018-04-23 13:21:43 +02:00

Petter Lundh commented

2020-07-05 08:41:22 +02:00

Added subscriber: @PetterLundh

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Asset Project: Workflow & UI #46059

Asset Project: Workflow

Pre-assumptions

Integrating the asset management functionality into Blender

People already use the file browser as a kind of asset manager

Setting up asset repositories

UI Wireframes