Reorganizing the GUI #41700
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
26 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#41700
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
You can place proposals and mockups that deal with the organization of the GUI here.
Some of the issues:
Related Design Tasks:
Tool Settings Location in the UI
Reorganize 3d View Toolbar
Changed status to: 'Open'
Added subscriber: @PawelLyczkowski-1
Added subscriber: @xrg
Added subscriber: @gandalf3
Added subscriber: @michaelknubben
Added subscriber: @BartekMoniewski
Added subscriber: @JulianEisel
Added subscriber: @tychota
Added subscriber: @Januz
Another common problem is using expanded options when a dropdown would be better and save space.
Examples: The BW/RGB/RGBA options in the output panel (color depth too), Units and Color Management in Scene.
They would be better used as a sort of in-panel tabs, only if they affect the widgets below them (for instance, how they are used in the Duplication panel).
Many of the problems with the Properties Panel could be solved by reconsidering what needs to be there, and in what form.
For instance: an object's location, rotation and scale in 3d space is there, and together with the 3d cursor's location takes up half the vertical screenspace. One thing to debate should be 'does this belong in the Properties Panel, or the Properties Window?'. No matter which you're in favour of, though, it should be much less large and overwhelming, and I will do some thinking about how to solve this.
I'm in favour of more dropdowns/pop-up palettes, and think these could even be done dynamically by allowing the user to collapse the side-panels of the 3d viewport to a minimal bar, as in this example:
Added subscriber: @HugoSales
Added subscriber: @rocketman
The video output and encoding panels are poorly organized and misleading.
Here's the full proposal on how to fix them.
Some of the changes in the above proposal involve new features, but there are also many small improvements that could be added incrementally.
Added subscriber: @Lapineige
Added subscriber: @ideasman42
@rocketman. Splitting out video & audio encoding could be nice.
Note that I think giving Frame Server a prominent position in the UI isn't justified, Possibly frame-server could be removed, though thats another topic.
Here is something to clean up the panels a bit - sub-panels:
Only one would be open at a time - so they work like ctrl-clicking the triangles. That wouldn't close the main panels of course, just previously open sub-panel. This introduces a bit of self-management of the GUI, which is currently overly user-managed (the user has to clean up after himself).
All can be collapsed - just click on the triangle of the currently open sub-panel.
I like the cleaner look, and the added ease of use of being able to collapse an entire section of related functions, but this way we do lose the ability to re-order panels absolutely how we want them.
I'm also not really a fan of the 'only one panel at a time' solution, as it's currently found in Zbrush for instance. It's a logical solution for an overabundance of panels, but it feels clumsy and only combats the symptoms, not the underlying cause.
edit: I notice that the abscence of the dividing lines and grab-handles does wonders for making this panel feel less crowded! Sadly this is at the expense of communicating to the user that these can be grabbed; Would only showing the lines when the mouse is in the panel, and the grab handles when the mouse is over the line itself be an option?
@PawelLyczkowski-1: as @michaelknubben said, without the lines this is less attractive to the eye, cleaner. But we need some visual information about grab and separation between panels.
I think that very soft (i mean very little lighter/darker than the background) lines can be cool, the same for grab handles.
And why not more visible lines when overlapp is activated (because of less readability).
A little mockup from your image, to let you see what i mean:
About your mockup @michaelknubben, I think that the icons on the tabs are very very cool: we can't read the name vertically as fast as we can recognise the icon. Great idea !
About the panels pinning, that a good idea, and I think that can work very well, especially when the user is not using the overlap option.
But I have reservations about the last operator panel. That kind of popup is not so nice (I'm thinking about some big parameters panels, with lot of options).
Something closer to the F6 popup can be more usable.
These can't be grabbed in my mockup : )
Is that necessarily a bad thing? Let's take my example: Texture, Stroke and Curve settings all affect the Brush. So putting them inside the Brush palette makes the organization correct, while making them auto-collapsing (only 1 open at a time) reduces clutter - so no need for the user's ability to reorganize all panels.
Elaborate please.
Here is a small one:
In a lot of case, we need some particular panels to be on screen, while the rest is at the bottom (off-screen).
For exemple, you may think that Sampling, Light Path and Volume sampling needs to be attached.
But personally I rarely use Volume Sampling, while I use sampling all the time, and light path when i'm on the rendering step.
So I move them off-screen when i'm using others tools.
If that was no need to have multiple panels, why are they there ?
About the secon mockup, item+transform in 1 panel is a very good idea.
Tackling the multitude of view settings with sub-panels (I would still prefer a popup though):
Not so readable, may need more shift to the right.
But a good idea. Better organization.
It looks cleaner, but you're giving up customisability, while taking up more space.
I realise those parts can't be grabbed, but that's a regression in functionality. This could be forgiven if it would solve other issues, but I don't fully believe that it does. I also don't enjoy auto-collapsing (one panel at a time), as I find it cumbersome in practice. I can elaborate on that at a later time.
The way I see it, the underlying problem lies in three seperate areas:
There's a LOT of information in the properties panel. This is partly because some of it doesn't belong here (and I believe there's a consensus about this so far), and parly because it's being displayed in an overly verbose way (for instance, you could bring the Transform panel's loc/rot/scale section down to three lines, with a combined x/y/z box)
The graphics try to communicate all the information to the user, all the time. Dividing bars, grabhandles, collapse-indicators... subpanels solve this, but at the expense of functionality. I think having some of this information only be shown when the cursor hovers over the element could go a long way towards making the panel clearer, when information isn't actively shouting out its function all the time.
The only way to organise and navigate this information that's available to us right now is collapsing/moving panels and scrolling.
We have to make sure we don't just solve one of these, and give each problem equal attention.
Tabs could certainly help, and I'm of the opinion that it doesn't make sense for them to exist in the Tool panel but not the Properties panel. Either we decide that tabs aren't a good solution, or the Properties panel should get them as well. This aids in organisation, and I think is a more elegant solution than subpanels.
I think the question of which information belongs where is the most pressing one right now, and we're more likely to get anywhere by brainstorming together. This might be easiest if we can share screens and make annotations, so if anyone from the UI team's up for a Hangout conversation about this, let me know.
Sounds good. Could you make a mockup of how exactly?
I was also thinking about hiding drag areas and dividers and adding a "Customize UI" button that would show them, along with other options, like checkboxes to hide unused panels. Any thoughts on that?
I'm currently trying to design a display settings popup. I could use also some mockups by other people.
+1 to that, see above.
I sure can :D
I coloured it as an experiment, but we could also colour the text. If we go with either of those though, there will be clashes with the colours of animated values, so on second thought that's not great.
I really like your suggestion of having a Customise UI button and hiding this functionality otherwise. Good call! I've thought about this before, but kind of forgot about it. I'd also like to have the 'customise ui' option in the rightclick menu, on any item in the panel.
But that's not readable at all. Where are the labels?
Added subscriber: @kevindietrich
Note that the multi button drag feature relies on button being on a column, so that will most likely break it.
@PawelLyczkowski-1 It would still have the labels, ofcourse. This was only to show the widget itself, in comparison to its old version.
This combined version will show less decimals, but I think the current system of showing 5 decimals even when there shouldn't be any is very noisy looking without imparting useful information.
When there are no decimals, just display a number as 5, not 5.0 or 5.00000
@kevindietrich
That's true. I personally don't feel that's such a terrible loss, but it is a regression.
For this reason, and because people often don't want the toolbar to take so much screen space (this implies a narrower window), I think that not so usable.
Especially it is not possible to enter decimals, except with a larger toolbar.
About the background color, individually it's cool, but I think that will create more distractions for the eye. And people can learn very fast that the X value is on left side, y on center, etc. So without color, that's not a problem.
About tabs in the properties, that's very consistent. Tabs on the 2 sides, or no tabs. And in this case, properties needs tabs, now it's a big mess.
About a Customise UI button, can you make a mockup ? Because that's sound good, but i thik that can "hide" this possibility of customisation for users.
Is it not better to show the line + grab handle on only 1 panel, when the mouse is over it ?
As kevindietrich said, having the XYZ buttons horizontally will break the multi button editing functionality.
I use it all the time to set XYZ values like scale, and I wouldn't like to lose it..
@PawelLyczkowski-1 - can you constrain the scope of this task?
Reorganizing the UI is fine, but this looks to be everyone suggests random ideas for the UI with not much direction.
This gets hard to manage and usefully respond to each suggestion. - splitting off tasks is an option too.
Maybe I'm being too strict here, but I think end result of these kinds of open-ended tasks is we get many comments but not much useful outcome.
@ideasman42 I can split tasks off, but I don't really want to spam the list more. I would prefer to do that if there was a decision from the module owners that an idea looks decent, and let's explore more and later try it out in a prototype. That's would be the useful outcome in my view.
It's true that going through long discussions is cumbersome, and some things get buried in time - that's why I created a doc where I gather the ideas that are worth exploring IMO (not just mine) in an organized fashion - concise description, sections and a table of contents. It's like a report of some of the stuff done in such threads.
About splitting this task, I think we you can create a specific task about what we said about toolbar: grab handles and separating lines (+ the "popup" idea).
And 1 about the video & encoding panel.
Added subscriber: @JonathanWilliamson
@PawelLyczkowski-1, @ideasman42 what I think works well for splitting tasks is to first create an Overall Task (such as this one) and then add individual items as Subtasks. This way the discussions can stay constrained while also following a consistent thread. In this case, this task would set the goals and direction while the subtasks would contain the discussions and actions for individual tasks.
@JonathanWilliamson Sounds good. As not to unnecessarily spam tasks - can you or Pablo create these subtasks if you see an idea you deem worth pursuing further, at a time where such a task may become relevant (UI developers running out of TODO's for instance)? Or even when an idea seems good enough, and has low probability that it will become irrelevant in the future due to other development.
I don't have that much free time, but if this task becomes too long and cumbersome to skim over, I can summarize it in more concise reports from time to time.
Also, there are two candidates for subtasks in the description of this task (I don't have the authorization to move tasks).
Here is a mockup for the "Customize UI" button I mentioned:
Added subscriber: @lamoot
Here's my small proposal. When menus are collapsed in the header, they could keep the same layout.
I think this makes it more complex and less user-friendly.
Consider that moving outside of the menu bounds results in a 'failure', because that closes the menu again, and that with this redesign you're forcing the user to move up only a little bit, and then move sideways in a straight, narrow line. In the current design, the width of the text means that there's a much larger target that can't as easily stray from.
This seems like it requires more surgical precision from the user, and doesn't offer equally compelling usability-gains to balance that out.
Added subscriber: @JosephPoole
Added subscriber: @natecraddock
Added subscriber: @wevon-2
I would move all attributes from all view properties to regular properties window.
I totally disagree with that proposal. In fact taht just remove the properties bar, and hide all the tools, in addition to disperse them.
For the display and shading panel, that's impossible to add all these buttons in the header shading's mode selector.
For the background image, it is less convenient, and that will add the tools.
For the transform, you are not always using the properties view, and not always on the object part. For example, when i want to delete some keyframe, i go here and not on the properties view.
And so on.
@wevon-2 +1 to the general idea, since the properties sidebar is a mess where things that don't fit anywhere else go. Or where display settings which really shouldn't be persistent elements (that stay on screen) are. But these arrows don't give us much. Each one is it's own separate design problem. I'd be interested to see more concrete mockups, since I'm also trying to tackle the problem.
"For the display and shading panel, that's impossible to add all these buttons in the header shading's mode selector"
Why not? All these parameters could be inside camera attributes.
"For the background image, it is less convenient, and that will add the tools."
Mudbox and other softwares use cameras with linked image planes
"For the transform, you are not always using the properties view, and not always on the object part. For example, when i want to delete some keyframe, i go here and not on the properties view"
You don't uses regular properties window because you have a duplicate attribute in properties view, that's all. I normally have both of them active.
With a good scene explore I don't see any problem with these proposal.
How/why do you want to put all of that:
In the 3D view header's shading selector, or inside camera attributes ???
I agree, we need a better organization for these tools.
Why not, a camera linked image in back ground. But in this case, just on the camera background, and the rest on the 3D view.
Because of your example, i was thinking you want to displace all the option in the camera panel...
Sorry, I spoke too soon. After reflections, that's more consistent.
About the properties panel, I think it is usefull: the big difference with the toolbar is that the toolbar just show some tool, and the properties panel show... properties.
For instance, the 3D Cursor properties has no place in the toolbar.
I think we need to think carefully about it. All the properties we need in the 3D view (witch are used less often thant tools, but witch are also important to have within easy reach) have to be here, and the others... It depends.
For instance, the grease pencil properties (and yeah, tools) need to be in the 3D view. There is no sense to put them somewhere else.
And the "Item" panel, with just the object name, is just taking screen space.
Assuming the default camera can not be deleted and clicking twice the "Z" key can temporarily access their attributes
In the camera transformation properties, could be saved by default (maybe as a data blocks), the position of the orthogonal views and other bookmarked camera planes, I don't really now
Is it not better to have a separate menu for viewport shading ? You don't want to select all the time your camera to be able to change shading and so on.
And for the image texture in background, that's more consistant, but less easy to use and less user-friendly I think.
But for some render background, why not.
Added subscriber: @WarrenBahler
http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Properties_Tabs_as_a_customizable_Dock
here's a possible solution to the properties editor tabs not fitting into the horizontal space,as well as some other changes,consisting mainly of transforming the properties editor into a customizable dock.The tabs for each instance of the dock can be hidden or displayed independently, so multiple editors can be utilized for specific areas(see mockup) feel free to comment.
here's the tabs in GIMP 2.8 for comparison, they're similar in many applications using the tabbed "sidebar" format.
But we have a problem: you can't have the 2 windows displayed simultaneously.
And that take a bit more place than a classical tab.
I prefer the idea of this mocup (see before, the @michaelknubben post): https://developer.blender.org/file/data/ca6dlde5ituhlswahokj/PHID-FILE-dzeoq6aaruyihhvxhu2d/bl_tabs_mockup.png
With a better UI of course, but the idea to show only some panels (even from differents tabs) needs to be considered and further explored seriously.
That's like an double overlap ^^
But in the both cases, we just least disrupt the eye, and we hide lots of tools.
Added subscriber: @DoctorShenanigan
For my own sanity, we should have one "task" aka "discussion thread" per window or topic. One for the render settings, one for the toolbar/properties panels, and additional threads where needed. That way we can be sure that none of these great ideas are lost to the dark depths of the internet.
That being said, this is a topic that I have thought quite a bit about, from the time I started using blender.
I propose that we get rid of the properties panel for a few reasons. The darn panel eats up an enormous amount of window space, and with a little bit of re arranging, every button that exists there already exists in a different location in the menu.
Starting with the topic of screen space, I will give you an example. My blender often winds up looking like this. Granted, this is an exaggerated example, but I am sure it gets my point across.
Why do we need so much repeated information, when most buttons in that menu do the same thing regardless of which 3D view your mouse is currently over?
For example, you can type in the object or cursor coordinates in any of the properties panel, and the result will be the exact same. All that information is duplicated all over the place the second you have two properties panel on screen at the same time.
In the name of screen space, it makes sense to only include the viewport depenant buttons in the 3D viewport. All other buttons can be located elsewhere, with the exception of tools. I can give formal definitions of these at a later time.
That being said, let us move all the buttons that do not care what viewport you are looking at to either the properties window or the information window.
This change makes sense, and I am suprised it has not been done already. There are two other buttons up there that change what "mode" blender is in, why not have a third? (the two buttons I refer to is the scene button and the render engine button.
The header in blender has the same problem as the properties panel. It has functions that do all sorts of different things. I propose that we use that header for all drawing mode related functions. This includes changing the shading mode, the viewport background, viewport focal length and clipping distance, and so on.
Even the motion tracking menu could be moved down to the bottom.
Next we get rid of the view, select, add, and object menus. Like the properties panel, they have information that is duplicated all over the user interface, and is so long and convoluted that nobody uses it anyway.
Let's do some cleanup. The add menu is identical to the create menu in the toolbar. The select menu is a "tool" so it can be moved to the toolbar. The object menu has a lot of things that only exist in hotkey form, but that is a discussion for another time. The view menu relates to the drawing of the 3D view, so it can remain in the header.
There is a lot more that could be said, but in conclusion this helps to solve the problems of inefficient screen space usage. Not only that, but this gives context and reasons for why buttons should be placed where. Mode changing buttons go in the info window. Buttons that manipulate objects (also known as tools) go in the toolshelf. Buttons that change the drawing style of the 3D view go in the header. Things like specific coordinates go in the properties window. If you quick access to the coordinates of objects, simply have two properties panels. open at the same time. If absolutely necessary, the properties panel could still exist with only the coordinates of the active object, the 3D cursor, and the last used operator properties.
I agree with that idea. Ok that is a 3d view 's relative selector, but it apply to all the 3d view, and we already have mesh information in the top side of the Blender's window. That makes sense.
I agree with that (but it needs to be carefully explored). I often found users who want the matcap selector, or the lock camera to view, to be located in the header.
Yeah there is a lot of duplicates. I agree with that, but we have to think about how we can do that without hiding all the non-duplicated tools. And there is another problem: that takes a lot of screen space in the toolbar.
In return that makes tools used regularly more visible and accessible.
In summary, a lot a good ideas to explore. We need to do more mockups and thninking about that (in a specific task ?).
Added subscriber: @zeauro
I disagree. It does not make sense to see mode in which is active object in a Video Editing screen layout.
This piece of info is influencing only UI of a 3DView Editor in a Scripting, Game Logic or Compositing screen layout.
A problem in Blender is that UI is too much dependant of active object.
When skinning a character, armature can be in pose mode and mesh in weight paint.
Actually, we can have an object in sculpt mode and another one in texture mode and switch from one mode to the other by changing active object with a right click.
In the future of Blender, maybe that UI could display caracteristics of 2 modes at the same time for better ease of use.
I think that it would be a mistake to give too much importance to modes of active object by putting this switch in an info bar, present everywhere.
I agree with that. Most of display properties can be toggled on/off. A display menu could group them and use same checkboxes that the brush menu.
I think that we should keep settings with numeric fields in view properties panels. Because it is fastest to scan than pop-ups.
But instead of having motion tracking and background images panels that are visible even if they are not use. This panels could appear in Properties column only if their chekbox is enabled in Display menu.
I am using menus. Each time, I don't remember exactly the name of an operator and I cannot find it by using search.
They are reminders and grouping of specials menus that you cannot guess their existence like Ctrl A, Shift S, Ctrl V, Ctrl E, Ctrl F looking at toolbar.
I am using shift A shortcut to add a rigify armature. Does it mean that the shift A menu should disappear, too? How user could understand that he can call menus and don't use toolbar without these reminders in header?
For the mode selector, I said that because we already have some information that are not used in all kind of screen, but related to the mesh.
But after more reflexion, that can give a "global" appearance to this selector. And this is nonsense.
I agree about numerical input.
And i think a lot of properties can be converted to icons to use less screen space.
Because we have that problem: Currently the screens are wider than high (in a ratio of about 1.7). So we can take more vertical space than horizontal one. And users will more often split the view vertically when they used lots of views (except for some particular cases, like with the timeline). Especcialy for the 3d view.
So more options in the header meens more horizontal screen space used.
I think the idea of "floating" toolbar panel can be great in the case that @DoctorShenanigan showed.
Indeed there is that shortcut issue...
As I said, we must think about that more further. Why not opening a new task ?
Because a lot of good idea are hidden now.
For instance, the video encoding panel....
Is it any stranger then having the render mode and scene options available when you are doing a "composite only" render? I agree with the fact that you can have two different objects in two different modes. That is kind of weird.
Really, I feel like the button could go in either place. Not to big a deal. Although, like I said it is a button that changes every 3D view out there, not just one of them.
Seems like we agree to put display and rendering options in the header. Quite frankly, it makes sense. It takes the some of the load of remembering where these darn buttons are off of the user.
The biggest question is if we want these buttons to be text only or icon only or both. There is quite a mix and match going on in the header.
Having the operators as reference is really handy. I am not suggesting that we get rid of the buttons. I am saying that we move them to more logical locations. If you ever need to remember a hotkey, hover over one of the buttons in the toolbar.
Shift+A will still work. That menu will still exist, but not in the header.
I can make a mockup for this once we agree on the icons for the header. I suppose the properties panel will still exist for anything numeric, with the possibility of the user being able to add buttons there.
How feasible would it be for the operator settings to still exist if you undo? For example, you extrude and then scale. You decide that you do not like how you scaled it, so you undo. Currently, you are not able to change the extrude settings without undoing again and re-extruding.
Added subscriber: @mont29
Meh… We end up again with a wall of text, with three-level quotes… Please, this is not a forum.
Should this one be closed now (and open split ones)?
@mont29 This wall of text (which is what you get when talking about UI, since there are multiple ways solutions can go) is not really for the devs to read, it's more for the designers. And I do read it. To see a summed up "report" of the more polished ideas (not all polished enough for a design task though), nicely divided into sections and with a table of contents, you can go here . This "report" is also not for the eyes of the devs though, it's rather for the UI module owners.
You can kick this discussion out of here of course, but that would be unfortunate IMO, because the quality here is a bit better than on BA.
Removed subscriber: @BartekMoniewski
Added subscriber: @MikePan
Added subscriber: @PaulGeraskin
Hi.
I would like to have tabs for any window. As this makes workflow much better.
Here is i would like to show you how cool tabs in modo/houdini: http://youtu.be/JfYe1vTNPO0
Also "+" button is important to add new tabs.
Also, "x" button on a tab is important too. To close a tab quickly.
PS: in modo i had lags a bit because of recording.
Here's a little functionality demo I made , that I think would really work well to clean up the properties editor.It separates Scene/organization from object properties. It would also make a practical place for a layer manager, and make it easier to interact with the outliner.
full blurb here:http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Properties_Tabs_as_a_customizable_Dock
.. goes and hides under a rock until the war is over
Added subscriber: @JasonSchleifer
Added subscriber: @brecht
Changed status from 'Open' to: 'Archived'
Archiving old task, outdated by UI changes in 2.8.