lerni
commented
3 years ago Open micschk opened 3 years ago
lerni
commented
3 years ago 
maxime-rainville
commented
3 years ago I wish it was that simple. This modal is also used in many context where the user has to provide context information like when inserting an image in a WYSIWIG.
You also end up with somewhat ambiguous interaction .. if you click the "insert file" button in your upload field, you're would also be updating its data. You could also end up confusing some user who might not realise that they are actually updating the source file when changing that data.
micschk
commented
3 years ago This modal is also used in many context where the user has to provide context information like when inserting an image in a WYSIWIG.
OK, well I think the main Ui problem is that the read-only 'looks' too editable. So then I'd propose to fix this the other way around; make the 'read-only' image data not look like a form/formfields.
Either just show the data as regular info text? (this would also be a better context for an 'edit details' button imo, below the actual details instead of in the modal header where clients tend to overlook it)
OR: make a clear separation of 'image data' and 'placement settings'?
purplespider
commented
3 years ago This area definitely needs a re-think, it's quite confusing in multiple ways at the moment.
@micschk's suggestion to just display the details as text instead of read-only fields does actually sound like it would go a long way to improving this.
But in the meantime, can we please just rename the button to "Edit Details"? #1116
micschk
commented
3 years ago Revisiting this issue as it gets mentioned over and over by clients.
I wish it was that simple.
It actually can be that simple if we make it that simple instead of looking for complications and exceptions to 'fix'.
This modal is also used in many context where the user has to provide context information like when inserting an image in a WYSIWIG.
Yes, it is. See previous comment, main point is that you simply need to 'containerize' and label the fields/displayed data appropriately. Then users know what areas their changes affect, solution is really as simple as that.
You also end up with somewhat ambiguous interaction .. if you click the "insert file" button in your upload field, you're would also be updating its data.
I'd argue it currently is way more ambiguous (eg not being able to edit details in an editable-looking form, no way to actually edit the details when the modal gets loaded from an Uploadfield). It actually has not been possible for editors to perform the simple task of updating say an image title where they'd expect to be able to, for quite a while.
You could also end up confusing some user who might not realise that they are actually updating the source file when changing that data.
Still better than not being able to edit details at all.
clarkepaul
commented
3 years ago Yup this area still needs loads of work to get the experience on track.
Just to clarify how we got into this situation Originally if you were placing a file and wanted to edit it you need to go to the files are to edit it, losing the page you were working on. Our initial aim was to allow people to adjust any placement details, edit the original file details/permissions if needed and return to the page they triggered the editing from. We couldn't combine the two editable areas into one because they had different actions and different outcomes (file versioning vs page versioning). For Uploadfields there is also the two varying flows, someone selecting a file and inserting, or selecting and editing requiring save/publish actions rather than insert/update.
More to think about The "Details" link acts as a "view" or "edit" details, happy to have the button text as something else but be aware that file names are typically really long so the button label takes up this valuable space. With this layout I wanted the button to just be an edit icon, but gave in to having text as well (I wasn't the designer but was involved).
Either just show the data as regular info text? (this would also be a better context for an 'edit details' button imo, below the actual details instead of in the modal header where clients tend to overlook it)
Showing readonly fields as plain text could work but we used to have the edit button at the bottom of all the readonly fields and it would often be hidden from view under the fixed action bar which contains the main action insert/update. If the read only info was just a list this might not be as much of an issue, but also the "Edit file" link could go next to the "Insert/Update" button possibly. For example have a link at the top and bottom (just imagine it's the readonly fields :)
Also bear in mind that the upload field could get some "placement" type fields as the accessibility of these files are lacking the same experience that TinyMCE fields do and it would be good to align the experiences. The Uploadfield actually has so many fixes/enhancements needed to match the intended UX, the whole thing needs a bigger refactor.
Wordpress... I don't think Wordpress has both the "save" and "publish" functionality that we have (from memory), so their "insert" is save changes and and insert all in one.
This was an alternative design which might be of use
Actions in each tab area, but relies on people to return to the placement tab in insert/update, and there was a concern people would get lost in the flow after saving/publishing.
For me the ultimate experience would be to show everything in one view as editable fields and if any of the "original" files fields were edited, then guide the user to either cancel, save, or publish before inserting/updating the changes to the page. Probably not as easy as it sounds.
purplespider
commented
3 years ago the "Edit file" link could go next to the "Insert/Update" button possibly
I like this, and feel it solves many of the issues (at least until a more significant rethink is undertaken), without any downsides? It:
May I suggest we also change the label of the green button while we're at it, as "Update file" seems misleading when it's actually updating the placement of it, and not the file itself. Maybe just "Update"?
clarkepaul
commented
3 years ago @purplespider sounds all good to me, Yeah my example label wasn't thought out text-wise but more to give placement a go. I like "Edit file", short and snappy. I also prefer "Update" compared to "Update file". It would show the "Update" label regardless if any changes where made to either placement or file details but I think that is something which is acceptable UX wise. Also the icon isn't one that we've used much for "edit", so that might need refining for a more commonly used one.
Once the "Details" link has been changed, we can perhaps make a decision around whether the readonly fields should be plain text for the Uploadfield or see if we can navigate people straight to the editable fields:
maxime-rainville
commented
8 months ago I've put this in the CMS 6 milestone. There's a lot of related/interdependent questions I would be keen to address as well:
updateCMSFields) doesn't actually work right now.
See also: https://github.com/silverstripe/silverstripe-asset-admin/issues/1116
Right now when you click the 'eye' icon on an uploadfield, a file selection/view modal will open. In this modal, the currently selected file/image is shown in sort-of-preview mode. That is, it is basically 1:1 the 'edit' formfields, but in read only mode. I've clicked maybe over a hundred times on one of the shown fields in order to edit some file detail, only to find I needed to click 'Details' first in order to deactivate read-only mode.
I guess this initial read-only mode is meant as a sort of preview mode, but it looks 99% identical to the editable version. Besides the button not being very obvious UI-wise and the term 'Details' not indicating edit me, I cannot actually think of a reason why it would provide value to have read-only mode instead of just 'edit if you need to' mode (which is the mode when 'opening' files via the regular asset admin interface). It's basically just one extra step to click the edit button (two if you count the click on the read-only form field).
I'd like to propose to just load the editable version by default and get rid of the read-only mode altogether.
This would coincidentally also fix/prevent some outstanding issues:
AND provides (what I'd consider) a better solution when also using FocusPoint module (currently this also looks 'clickable' but also requires 'edit details' first, which I find it still unintuitive & burdensome as clients keep mentioning it seems broken).