View Issue Details

IDProjectCategoryView StatusLast Update
0013406MediaMonkey 5Track Browserpublic2019-07-18 16:19
Reporterrusty 
PriorityurgentSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version5.0 
Summary0013406: NP Art & Details dialog improvements
DescriptionThe NP Art & Details dialog can be much improved so as to facilitate editing, especially for views that use a simple list which doesn't support in-place editing:

1) By default, a better set of fields should be displayed, and if possible, an improved 2-column layout:

Title, Rating
Artist:Artist, Genre:Genre
Album:Album, Track#:#
Album Artist:AlbumArtist, Date:Date
Composer:Composer, Original date:OrigDate
Conductor:Conductor, Lyricist:Lyricist
Comment:Comments
Lyrics:Lyrics

2) To keep the layout as clean as possible, in cases where a field is empty, MM shouldn't display it (and if the empty field is in the left column, then the completed field in the corresponding right column can move to the left column).

3) It should be possible to TAB between fields.

4) FMFS functionality would be useful, but since all displayed fields are editable, Field names could hyperlink to the relevant item. e.g. for "Artist: Beatles", the hyperlink would be triggered by clicking 'Artist'.

Note:
- For the NP track, hyperlinking uses the same set of rules as for tracks that are outside of a collection.
- For the Selected track, hyperlinking uses the same set of rules as would be applied to the view from which the track is selected.

5) Since the ability to edit is limited, it would be useful to have an 'Edit' link at the bottom right corner which would open the Properties dialog which would contain the complete set of editing tools.
TagsNo tags attached.
Fixed in build2174

Relationships

related to 0014006 closedpetr Customization and Tweaks re. management of in-app windows 
related to 0013579 closedmichal Options > Metadata Lookup isn't respected 
related to 0015830 closedLudek Editing in preview window can cause change in track selection 
child of 0013225 assignedpetr Properties dialog improvements 

Activities

jiri

2016-09-16 15:32

administrator   ~0045678

1) The currently layout could definitely be improved. I'd also consider a different font for labels (e.g. 50% transparent 'Artist:'?)

3) This might be useful in some cases, but I suppose that it would mean that all there fields would get into the Tab-order of the entire main window - i.e. the whole cycle of all items would become pretty long. Thoughts?

Ludek

2016-09-19 15:10

developer   ~0045692

3) I guess that the fields could be tab-able only in the edit mode?

rusty

2016-09-19 20:08

administrator   ~0045694

1) Transparency setting could be useful, though not critical.

Note also, re. build 2033: items in the right column should be aligned

3) Yes, I think that would make most sense--once the user gets into edit mode (i.e. selects a field), then tabbing can switch between fields.

jiri

2016-09-20 08:34

administrator   ~0045699

3) This probably could work fine.

Ludek

2016-09-20 14:31

developer   ~0045709

Last edited: 2016-09-20 14:31

View 2 revisions

Items 1,2,4 are fixed in 2034

Note that the settings is shared with MM4 so to restore to the defaults you need to delete MediaMonkey.ini
Let me know if you think that the settings should be separated from MM4 settings for AD window.
Also the default font-size could be changed from 9px to something higher?

jiri

2016-09-21 08:52

administrator   ~0045714

Looks good, just:

6) re. font size - it probably should share the default skin font size?

7) I'd add some padding around all the text, so that it isn't touching borders of the control.

8) Bug: After lyrics search, lyrics is found, but 'lyrics: ' label is missing, until a new track is shown. Btw, I'd prefer the Lyrics: label centered and possibly with an empty line above it?

9) I wonder whether header of the control shouldn't match e.g. Now Playing header, i.e. to only show 'Artwork & Details' (or better just 'Details'?) and a menu icon (3 dots) where user could switch between Selected and Now Playing. Note that the menu could also offer to hide all the texts, so that artwork is better visible.

Ludek

2016-09-21 16:07

developer   ~0045719

Last edited: 2016-09-21 16:09

View 3 revisions

Items 5, 7 are fixed in 2034 too.

3, 8 are TODOs

6) Do you mean as default or do you mean that the font size shouldn't be configurable for A&D window? I guess that the availability to customize the font is useful.

9) OK, sounds good to me. I guess it should include all the context-menu commands, that way the menu will be available also in touch mode (not only on right-click). But if I remember correctly we had a reason to create the [Selected|Now playing] switcher in the past?
Rusty?

rusty

2016-09-22 02:56

administrator   ~0045732

6) Default font size is too large. I guess we can leave it configurable for now, though it doesn't really fit with the rest of the MM5 UI (in which fonts adjust depending on the mode).

9) We could show 'Details: Playing' / 'Details: Selected'. The reason for leaving this as a tab was because users often switch between the modes depending on what they're doing. So if we wanted to simplify it, we could have it work so that clicking the header would toggle between the two modes.

However, I'm not sure if that's an improvement over the current implementation or not.

In either case, we could add three dots to the right side of the header bar to add the context options associated with the Window.

jiri

2016-09-22 08:24

administrator   ~0045736

6) I prefer the default size, since it's supposed to be well legible. We should add an app-wide font size configuration anyway, so that it isn't skin-dependent only. That said, if we need configuration here, instead of fixed pixel-size configuration, I'd prefer something like Font size > [default], Smaller, Smallest - where default is the skin's default font size.

9) Sounds good, looks like an improvement to me.

Note that if we add the menu icon, we could move 'Edit' function there, in order to get a bit cleaner result.

Ludek

2016-09-22 19:16

developer   ~0045746

Last edited: 2016-09-23 16:07

View 7 revisions

3, 8, 9 are fixed in 2034

6) Assigned to Rusty for feedback. I agree with Rusty that default font size is too large for the A&D window. I also agree with Jiri that we should have a global font size config in Options > Appearance (skin independent). But I guess we will need both anyway (global + A&D)

jiri

2016-10-05 13:48

administrator   ~0045821

Looks good, just:
9a) I'd remove the Edit button from header and move it to the '...' menu in order to get a bit cleaner header.

9b) I'd make the whole 'Details: Selected' black and only change it to blue on hover (i.e. the same as e.g. NP header in Monkey Grove skin). Alternatively, only 'Selected' can change colors (as it currently does, but not only on hover), not sure what's better.

9c) A minor detail, but I don't like much ':' in the header. Wouldn't 'Playing details' and 'Selected details' look better? Or anything else?

Ludek

2016-10-07 12:17

developer   ~0045859

Last edited: 2016-10-07 12:26

View 2 revisions

9a) I agree, we have already item 'Edit artwork properties...' in the menu, so we should just replace it by 'Edit' and open the Basic tab of the properties dialog instead of "Artwork" ?

9b) I think that currently it is OK, it has 'clickableLabel' CSS class that indicates that the label is clickable, but probably depends on 9c decision.

10) The Selected vs Playing state doesn't persist after restart
=> Fixed in 2036

rusty

2016-10-07 18:21

administrator   ~0045860

6) Presumably, the default font size is based on some system setting. Ideally, the font configuration for this Window would work out of the box on any system configuration (e.g. it shouldn't be too small/too large on any system). Choosing a static font size, though, may result in this problem, so I wonder whether a suitable solution would be to choose a relative font size. e.g. +/- X. And by default, the font size for this Window could be -3 (i.e. 3 font sizes smaller than the default font).

9a) Yes--we could move the Edit button to the overflow menu, and replace the 'edit Artwork properties' with 'Edit'.

9b) As to the colour of the field labels (blue vs black(blue on hover): It seems like this might be a broader question that applies in other places as well. e.g. In
Albums > AlbumName view (and in other similar views), the ArtistName and the GenreName are hyperlinked but display as black(blue on hover).

In general, I think that's the cleanest approach, and that we could use it here as well. BUT, there's a distinction between the Playing/Selected _command_, and the metadata _hyperlinks_. Hyperlinks should appear one color on hover, and commands another.

This raises a second related issue: many of the commands currently appear as a 'grey block' on hover/click. I would suggest that command/hover on command/click on command should each just be different shades of the same color.

We should probably move this to a different bug, but since we started discussing this here...

9c) I'd show just 'Playing' / 'Selected' and see how that looks.

11) I'm unable to fully test the functionality because the Field chooser isn't working correctly (text fields are all truncated). See attached image.

12) The editing functionality of the window sometimes encourages editing within and other times discourages it. e.g.:
a) chosen fields are editable in place if they exist, but missing fields aren't shown
b) lyrics can be looked up directly
c) artwork can be edited from the context menu but can't be looked up

I would suggest that the design should facilitate simple edits, but encourage use of the Properties dialog for more in-depth editing / multi-selection editing. Thus:
- Add the ability to look up artwork by clicking the 'missing artwork' image
- Add metadata lookup (fingerprint based) should we add it in the future

jiri

2016-10-10 08:47

administrator   ~0045872

6) Agreed. Isn't this best achieved by my proposal of a config: Font size > [default], Smaller, Smallest , which is meant as relative to the default font size?

9b) re. hyperlinks - agreed, they should all be black and blue on hover (MonkeyGrove). Note that it's inverted in Groove Music app, since it's easier to tell what's clickable then. I'm afraid that it would result in a messy UI in MM5, since we have a more complex UI with many hyperlinks. Maybe we could consider taking the same approach for the Touch mode only, where it's more important to see what's a hyperlink?

re. commands - The current implementation seems to be ok to me - it's the same as in Groove Music, the rectangle and its color is the same as any other hovered region - e.g. NP list items.

Ludek

2016-10-10 17:35

developer   ~0045884

Last edited: 2016-10-10 17:55

View 3 revisions

6) Should I understand it that currently it is just about replacing
Font size: [9] px
=>
Font size: [Smaller]
in the "Choose fields" dialog?

Or there should be a general config in Options > Appearance?

11) has been already fixed in 2036

9a, 9b, 9c) => fixed in 2037

12) Should I understand that once the '[ ] Show file details' in the menu is unchecked then there should be "Lookup artwork..." link placed over the unknown artwork icon/image?

jiri

2016-10-11 08:27

administrator   ~0045890

6) Sounds good to me.

12) Not sure about Rusty's intentions, but seems to be right.

rusty

2016-10-13 16:03

administrator   ~0045915

12) Rather than placing the text in the middle, which would look a bit strange, I'd suggest:
Artwork: Lookup (only appears if artwork is missing. Default position should be above lyrics so that lyrics, if present, don't obscure it).
Lyrics: Lookup (note the change from 'Lookup Lyrics')

Ludek

2016-10-16 15:41

developer   ~0045939

Last edited: 2016-10-16 18:44

View 2 revisions

6, 12) are fixed in 2037

rusty

2016-11-25 03:12

administrator   ~0046249

1) Unfortunately, the suggested layout changes don't really work. With two columns, in many cases, the data requires an extra row, and the window looks even more convoluted than before :-(

The only true solution that I can think of is to:
a) modify the configuration so that it just displays a 2x5 grid that allows the user to configure which fields display in what spot.
b) truncate any fields that don't display in the allotted space
This would allow users to set a format that really makes sense given their layout/font settings. e.g.
Title:
Artist:
Album:
Year: | Track#:
Album Art: lookup, Lyrics: lookup

Otherwise, we should just revert to a single column :-(

3) Tabbing between fields once the user is in edit mode seems to work, though there's no indicator when the user tabs into this Window (related to: #13065)

4) FMFS works are specified, however, there's a problem with the spec: multi-attribute fields aren't linkable to each of the individual attributes. I can think of 2 possible solutions:
a) Add hyperlink buttons (like 'arrows') next to individual attributes. We'll probably need this type of functionality anyhow for purchases.
b) Make attributes hyperlinkable instead of editable by default, but add a toggle to switch between modes
Thoughts?

6) I prefer the smaller size as default, but 'default' would also be fine.

8) Lyrics does appear, but the not centered are with a line above. I think, however, that it's fine as is (it'll look bad if centered if the lyrics below are left justified).

9b) Re. commands: I was referring to 'Selected/Playing' and other similar Text commands--that it would be preferable to use a different color than Blue (which represents hyperlinks).

12) This looks good. But I would propose that it would be helpful to allow artwork to be looked up in Artwork-only mode as well (e.g. display 'Lookup' at the top left of the image).

jiri

2016-11-25 11:58

administrator   ~0046258

1) I'm not sure whether we can cover all potential layouts. My guess is that almost 100% users will either:
 i) never modify the layout at all.
 ii) wish there was more customization possible (more columns? different fonts? bottom/right aligned items? whatever...)

So I wonder whether we rather shouldn't create a good looking layout that won't be customizable, but will be easily modified by an Addon. As for the example how could it look like, our Now Playing view already looks pretty good with the hyperlinked Artist/Album/Title/Rating in different font sizes, etc.

4b) I'd prefer this solution, which is also consistent with how the mentioned Now Playing view works.

4c) I'm not sure that A&D is the best place to edit metadata, particularly since we plan the docked Edit dialog to be implemented. I don't think that there's really big need to let user edit individual fields in A&D. If we decide that we need it, we could e.g. show an Edit icon on field hover (like after some 500ms). However, I'd probably prefer to not do it - and if we do, assign it a low priority.

9b) I'm happy with the current look, why do you think there are changes needed? Now both NP header and A&D header work the same way on hover, which is preferable imho.

rusty

2016-11-25 17:53

administrator   ~0046264

4c) Answering this first, because it's important that we agree on the purpose of the A&D window.

In the absence of a dockable / more compact Properties dialog, and given that many views have a simple List (which isn't editable), MM5 needed a place where users can easily/consistently edit tracks. That's why we had to add better editing to this Window (in addition, it made the Window more coherent by allowing both all properties to be edited--not just Artwork).

We can revert that, but then we would have to revisit the decision to disable editing in all views with a simple list or perhaps to not use Simple lists as default views.

Note: I'm not sure how a dockable Properties dialog would change my thinking, but I suspect it wouldn't change it much because such a dialog is unlikely to always be enabled by the user (i.e. it'll only be activated when they're actively editing a bunch of tracks)--otherwise it'll take up a lot of space.

1) If it isn't much work, I'd prefer to make it customizable because whether one or two columns are appropriate depends largely on the fields and on the size of the column. If not, then I can come up with some recommendations for each content type.

4b) OK, as long as the toggle is easily accessed (e.g. an edit icon toggle in the titlebar).

Note: I'm not sure what you mean about the fact that this is how Now Playing works.

9b) I'm just suggesting that hovering on commands should consistently switch black/grey , whereas hovering on hyperlinks should switch black/blue. Not a big deal though.

jiri

2016-11-28 13:03

administrator   ~0046284

4c) I think that we could add a docked Properties dialog fairly soon and so I wouldn't think about the current situation, but rather about what will be then. And having so many means of editing track properties then looks like rather a problem to me, than as an advantage. Could be confusing and unnecessarily adds complexity both from development and usability point of view.

re. Simple lists vs. Full Listviews - don't see a problem here, user can switch to the full listview if needed and the switch is persistent then. I guess that we'll better see after some alpha version feedback, whether it's a big deal.

1) It's mostly about priorities - speccing, developing and testing this takes quite some time. And, a fixed, but good-looking/usable design, will be preferred by some 99% of users imho. For others, an Addon could deliver whatever is needed.

4b) I didn't mean a general toggle, but rather just an Edit button next to a field, e.g.: 'Artist: ABBA' on hover over ABBA there's an Edit button shown next to ABBA that lets user edit this field. However, as I wrote, instead of implementing such things, I'd prefer the ordinary Edit dialog.

I meant how 'Now Playing _View_' works, i.e. that full screen view with Artist/Album/Year... hyperlinks formatted below artwork.

rusty

2016-11-29 19:49

administrator   ~0046307

1) OK, I'll try to spec better optimized defaults, although I prefer customization (e.g. using an approach like in MusicBee in which users can use the field chooser to modify customizable items e.g. Scroll in player as: <Artist> - <Title>).

Note: another reason why I think customization is important is that the choice of what data should appear in the A&D window is largely dependent on the users choice of skin; if the Player includes more metadata, it's preferable not to duplicate the same metadata in the A&D window.

In any case, here are some defaults that might be better for the current skin:

Music
------
Title
Artist
Album
Genre, Year
Lyrics

Podcast / Video Podcast
-----------------------
Title
Podcast
Artist
Genre
Date

Audiobook
---------
Album
Title
Artist
Genre, Year

Classical
---------
Title
Composer
Artist
Album
Album Artist
Conductor
Genres, Year

Music Video
-----------
Title
Artist
Album
Genre, Year
Lyrics

Video / TV
----------
Title
Series
Season, Episode
Year
Director
Producer
Genres

Note: given the limited number of 2-column entries, it might even be preferable to just revert to the original implementation (configurable & single column).

4c) OK. So I'll update the specs re. docked properties dialog at 0013225 , but I'd prefer not to revert editing functionality here until the properties dialog is implemented to our satisfaction. With that in mind...

4b) ... would it make sense to (at least for now) implement the suggested toggle? If not, let's just hold off on fixing the hyperlinks until 0013225 is resolved.

jiri

2016-11-30 13:54

administrator   ~0046326

1) In order to satisfy more needs with the fixed design, what about two versions? I.e. versions 'Metadata summary' and 'Extended metadata' selectable from the local menu, where the 'summary' looks more or less like the Now Playing View, i.e. in case of Music: centered Artist, Album, Title and Lyrics (possibly Track# somewhere), all without labels and possibly in a larger font. The extended version would offer most fields (all nonempty? or use the currently implemented simple customization?), left aligned with labels. And, as suggested earlier, leave any more customization on Addons.

4b) I think that a checkbox [ ] Edit mode in the local menu could work. I.e. the default (unchecked) value would result in hyperlinks working, if checked - clicks would result in edits. Or, alternatively, to extend my idea from 1), the Summary mode could support hyperlinks, while the Extended mode would support Editing? Seems to be more suitable in both cases.

rusty

2016-12-01 06:33

administrator   ~0046335

1) I think that no matter what we do it's not going to be ideal for many cases so I wouldn't spend much time on this. We should just revert to the original single column layout (modified with the defaults per 0013406:0046307) with the possible addition of support for two columns for some fields (though I expect that this is unlikely to be implementable without making the customization changes originally proposed at 0013406:0046249 1a).

4b) Agreed, though I think it's preferable to implement this as an Icon that appears as a toggle in the A&D title bar.

jiri

2016-12-01 14:01

administrator   ~0046340

Per IM discussion, Ludek will implement some of my ideas, since it should be quite easy to do, and then we can better review the functionality.

Ludek

2017-01-10 19:28

developer   ~0046896

Last edited: 2017-01-11 14:12

View 6 revisions

Fixed in 2058.

I introduced new 'Simple' layout and user can switch between 'Simple', 'Advanced (*)' and 'Artwork only' layouts.

(*) is the clockwork icon to open the 'Choose fields...' dialog.

Scripters can easily add another layout there.
As an example I created sample addon (artAndDetailsLayout.mmip) that shows the artwork as smaller image within the properties (no overlay) like on the attached screenshot (layout.png)

Thinking about it maybe the layout from the addon looks better than our 'Simple' layout with overlay. To be decided which layout to choose as default, I let the 'Advanced' editable layout as default for now.

Ludek

2017-01-11 14:10

developer  

Layout.png (81,895 bytes)
Layout.png (81,895 bytes)

rusty

2017-03-03 18:43

administrator   ~0047393

I like the alternative layouts, but:
1) there's a bit of context menu overload (especially considering that this will be a one-time configuration for most users)
2) the usage of the 'Configure' icon is confusing
3) Advanced mode has no way of switching b/w single and double columns (or to configure which fields appear in which column).

I would suggest the following adjustments:
0) Change wording to Vertical, Horizontal, Custom
1) Remove artwork only (custom can accomplish the same thing)
2) Perhaps add a 'Configure' entry at the bottom of the layout view selector _if_ relevant to the active view.

OR

Get rid of the layout view selector and just have a 'Layout [gear icon]' menu entry that opens the following:
Context menu: 'Configure' entry
-->
---------------------------------
Choose layout:
---------------------------------
Layout: _[[Vertical], Horizontal, Custom]_v_
----------------------------------


This area displays what it looks like
except in the case of Custom -- see below

----------------------------------

3) If the user choose a 'Custom' layout, they should be able to:
a) use 1 or 2 columns
b) choose whether the fields are editable (if not, they are linked)
---------------------------------
Choose layout:
---------------------------------
Layout: _Custom_v_ (optional: depends on item 2 above)
----------------------------------
File Type: _Music______

Album Art . . . . . . . . . . . Track#
Album Art (transparent) . . . . Filename
Title . . . . . . . . . . .<--->
Artist
Album
Track
...


Font size: _______
[ ] Make fields editable
--------------------------------------

jiri

2017-03-03 21:16

administrator   ~0047394

1) Well, mostly, just that currently in all other layouts the artwork is 'dimmed' in order to be able to show text over it. So, unless we fix/modify this, we probably should keep this view. I think that it's fixable by a small tweak to the logic - show artwork bottom aligned (instead of the current center alignment) and 'dim' it only when there's a need (there's some text over it). However, rather low priority, could be defered.

2b) Looks interesting, but in order to make a simple solution, providing you don't like the current 'gear' icon configuration, when about adding '...' instead of the icon and thus _always_ show to configuration dialog when 'Custom...' is chosen? Since it means only one more Enter press in case user doesn't want to configure anything, it shouldn't be too much of a nuisance?

3) Not the highest priority for me, but ok.

rusty

2017-03-07 21:37

administrator   ~0047428

Last edited: 2017-03-07 21:41

View 2 revisions

2b) It's a bit strange to send the user to a config screen just for the custom case. An alternative to 2bi) (which I assume you understood to have included the layout selector sub to the 'Layout' context menu) would be the following which is probably cleaner:
2bii):
i)
Edit...
Paste
Add image...
Remove image
Images >
-------------
Layout -->

Clicking Layout -->
Open the following dialog
---------------------------------
Choose layout:
---------------------------------
Layout: _[[Vertical], Horizontal, Custom]_v_
----------------------------------


This area displays what it looks like
except in the case of Custom.

----------------------------------

jiri

2017-03-08 06:58

administrator   ~0047436

2bii) Sounds good, I'm just not too keen on this change since its benefits seem to be rather minor compared to the work involved. So, I'd keep it in the to-do list, but rather let the idea to mature a bit and possibly review after http://www.ventismedia.com/mantis/view.php?id=14006#c47279 is implemented, since it also might be used for A&D window customization or possibly even to place several A&D layouts around the main MM window.

rusty

2017-05-18 16:24

administrator   ~0047991

User feedback: A&D window should support ALL fields that are visible in the Properties dialog. (User was asking in particular for 'contained in Playlists:' function.

rusty

2017-08-08 22:33

administrator   ~0048493

Here are the remaining issues:
1) Assuming we're going to keep the various pre-configured A&D layouts, let's present them in the following order:
Artwork only
Basic (instead of 'Simple)
Side by side
Advanced

3a) The current 'Advanced' layout is hardcoded to 2 columns and the user can't configure which columns appear where. So we should either:
i) revert to single column layout (which limits the utility of this view as described earlier)
ii) allow the user to configure which fields appear in which column (which may take too much time to implement)

3b)/4b) The current 'Advanced' layout allows for in place editing thereby forcing us to implement hyperlinks in a non-intuitive fashion. I would propose that:
i) rather than enable in-place editing by default, we add an 'Edit' toggle button that allows the user to switch to 'edit' mode (which gets rid of hyperlinks). This would allow hyperlinks to be implemented normally.
ii) alternatively, as suggested by Jiri earlier in this thread, we can just add an edit button(s) and implement 0013225

5) Add any missing fields as options to the Advanced A&D layout

jiri

2017-08-09 08:11

administrator   ~0048495

1) Agreed.

3a) Doesn't seem to be a big deal, as user can reorder to fields which actually results in fields placement in the required column.
iii) We might consider adding # of columns selection though.

3b) I'd also prefer standardized (thorough MM5) hyperlinks implementation.
ii) I'd prefer this approach, an edit button for each field on hover looks like a good option to me.

5) Agreed.

Ludek

2017-08-15 13:42

developer   ~0048539

Item 1) fixed in 2075

Ludek

2017-10-04 13:10

developer   ~0048885

3b)/4b) Fixed in 2080.
Added 'Edit mode' toggle switch to the context menu and the hyperlinks unified with 0014395

peke

2017-10-20 00:14

developer   ~0049001

1, 3b/4b tested in 2081

Ludek

2019-05-02 10:43

developer   ~0053406

Re-opened based on https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94339&p=458028#p458008 to make the number of columns customizable or a more easily changeable by an addon.

Ludek

2019-05-02 18:37

developer   ~0053411

Column count configuration (1,2,3) added in build 2174

rusty

2019-07-18 16:19

administrator   ~0054162

Verified 1, 3a, 3b/4b (bugs in edit mode tracked elsewhere),5 in 2186.

Note: multiple columns is still problematic due to formatting issues, however, it's probably not worth changing for 5.0.