Commit behaviour for in-line editing

[MattTown]

Hi,

I'm doing lots of database updates via inline editing, generally to a bunch of custom fields and the Comments field. I have found that an edit to an inline field will be committed if:

• I press enter or

• I click on another field in the line being edited or

• I select another line on the same screen without moving the view.

I have also found that if I scroll the view sideways or up or down (for example to see more file or album context), the edit is abandoned.

I would like this behaviour to be changed so that if an edit under way and the view is moved then the edit is written to the database rather than being abandoned.

Cheers

Matt

[Lowlander]

I think the risk here is unintentional edits, especially if the field to be edited is out of view.

For example you accidentally engage in-line edit and scroll away not noticing that key presses are editing.

I'm not sure if that's the reasoning behind this behavior.

Inline edits allow you to edit tags directly in the Filelisting: https://www.mediamonkey.com/wiki/WebHel ... Media_Tree

[Rob_S]

I would not like edits to be committed merely by scrolling away from my location.

Current implementation works fine for me, and I use it a lot.

If you want to commit, press enter, and then scroll is better.

[MattTown]

I think the risk here is unintentional edits, especially if the field to be edited is out of view.

Thanks for the response Lowlander.

I understand the issue of unintended edits but my experience is that it is actually somewhat *difficult* to initiate an inline edit - I have had to learn a specific double click timing and careful location of the cursor to get editing to initiate in the field that I want (apart from rating - reported separately). And even then I sometimes have to try several times to get a field to edit, especially if I'm not near the left edge of the field.

I seek clarification of your point about an edited field being out of view - you can't initiate an inline edit of a field unless it is in view, so I don't understand what you're getting at there. My perception is that the chances of an untended edit of an inline field is low, unless you're in the habit of randomly clicking around the screen, which is not smart behaviour in the first place.

I have lost many more uncompleted edits to intuitive screen moves than I have had unwanted edits. I understand that it is sensible to bias behaviour to protect data, but a balance with usability has to be struck.

Cheers

[MattTown]

I would not like edits to be committed merely by scrolling away from my location.

Current implementation works fine for me, and I use it a lot.

If you want to commit, press enter, and then scroll is better.

Thanks Rob,

I understand that we probably all approach this complex and capable system in different ways. I am stuck with pressing enter to complete an edit and do manage to do that most times. But (repeating the point made to Lowlander above) that I frequently want to see other data before completing a field edit and, over decades of software use, am pretty much hardwired to go find (scroll to) that data before completing the edit.

So commit on scroll would suit me better, but if it doesn't get any traction then I'll just get on with it.

Cheers

[Lowlander]

You could start an inline edit in view and scroll out of view. Or it closes on scroll out of view, it would be a commit.

[MattTown]

Hi Lowlander

You could start an inline edit in view and scroll out of view.

In my experience, if I start an inline edit in view and scroll out of view then the edit is abandoned, in every instance. If there is a way of not having a scroll abandon an inline edit then I'd love to hear it.

Or of it closes on scroll out of view, it would be a commit.

I don't understand what you're saying here - an inline edit can only be initiated in view. I haven't found a way of having an in-view edit scroll out of view and be committed, can you elaborate please?

Cheers

[MattTown]

Another annoyance with in-line editing for me is that in my system (current MM but slow hardware) the black background that allows the editing of a inline field sometimes lags by a second behind the dotted outline selecting the field. So, on my system, the sequence for inline-edits often is:

• Use tab to move from one main panel edit field to the next (typically a Custom Field for me)

• dotted line appears around the field

• <variable delay> black edit background fills the field

• edit the field contents

• tab onwards.

The problem for me is that the occasional delay between the dotted line outlining the field and the black edit background causes keystrokes entered then to be interpreted as search request and my editing view gets blown away to the search result. The new functionality to use ESC to undo the search does help but does not always work. When I'm doing lots of editing this can happen about once every half hour or so, and that gets tedious.

Could the code could be examined to see whether that delay between outline and black edit background can be minimised or eliminated? I know that having a slow and small system probably exacerbates this problem, but it still is a problem and might be behind some of the user experience problems you get.

Cheers
Matt

[MattTown]

Hi,

I had made this point in another thread but that got no traction. This particular matter is subtly different to the original thread so I thought it was worth a separate thread.

A persistant annoyance with in-line editing for me is that in my system (current MM but slow hardware) the black background that allows the editing of a inline field sometimes lags by one or more seconds behind the dotted outline selecting the field.

So, on my system a typical sequence for successful inline-edits is:

• Use tab to move from one main panel edit field to the next (typically a Custom Field for me)

• dotted line appears around the field

• <occasional delay> black edit background fills the field

• typing to edit the field contents

• tab onwards.

The problem occurs when I type during the occasional delay between the dotted line outlining the field and the black edit background. If I type a second before the black edit background turns up then the keystrokes get interpreted as a search request and my editing view gets blown away to the search result.

The typical sequence with an edit background delay is:

• Use tab to move forward

• dotted line appears around the field

• <1-2 sec delay> several characters typed in

• search box at top right is invoked and typed characters initiate a search

• edit view gets blown away to search view

• delete search characters and get the main panel back to the previous edit view.

The new functionality to use ESC to undo the search does help but does not always work. Note - the "previous view" icon just takes me to the top of the All Tracks list, well away from my edit location. When I'm doing lots of editing this can happen about once every half hour or so, and that gets tedious. I have taken to having a search for artist or album that can be readily invoked through the search pulldown to rapidly return to the edit view, but that is a workaround that should not be necessary in the first place.

Could the code could be examined to see whether that delay between outline and black edit background can be minimised or eliminated? I know that having a slow and small system probably exacerbates this problem, but it still is a problem and might be behind some of the user experience problems you get.

Cheers
Matt

[MattTown]

I have found a solution which fixes my overall search blowing away edit problem. There is a (now?) a control in Tools > Options > Search to "Show results only after pressing ENTER". For me, that has fixed my main complaint about the UI immediately changing an edit view to a search view. Now if I type ahead of the capacity of the system to show me a black edit background, the only thing that happens is that the characters go to search box without (thankfully!) immedately changing the view away from my established edit view. It is then a simple matter to erase those errant characters and get on with the intended edit.
Has that always been there? If not, thanks for updating the system. If so, guidance to use it would have saved me months of frustration.

[Lowlander]

No, that option is new.

[MattTown]

Awesome, thanks. It has made a big difference to the usability of the system for me.
Cheers

[MattTown]

I do heaps of inline edits from a filtered artist or album view, and have previously commented on the propensity for MM to throw away uncommitted inline edits if the screen gets moved around. This are typical examples of inline edit behaviour that I have found:

• Use slow double click to enter edit mode for an inline field (eg Original Album). Type value in. Press Enter, edit is accepted

• Use slow doulbe click to enter edit mode for an inline field. Type value in. Press Enter, edit is accepted and edit highlight moves to the next field

• Use slow double clik to enter edit mode for an inline field. Type value in. Use mouse to shift the view on the screen using the scroll bars - either to scroll up/down or left/right - edit is abandoned. The field is returned to its previous value (i.e. all edits are lost) the moment that the screen is moved.

So the first two behviours are fine by me, but I routinely get caught out on the third.

I would prefer that MM held onto the edited content of the field even if the screen is moved, and commit the edit if the mouse is clicked onto another field.

Is it possible that screen movement is part of your problem?

Matt

[Rob_S]

Even a slight touch on the mousewheel scrolls and thus kicks me out.

Tab key, Enter key, or mousclick elsewhere commits for me

I wonder if maybe the idea of scroll not committing is that if you have an unfinished edit, and scroll, you might not find your way back???

I think I would prefer that any move off the field commits my edit for consistency.