[MGNLDAM-476] Allow asset upload when an asset or folder is selected Created: 18/Jun/14  Updated: 19/Jun/19  Resolved: 05/Aug/15

Status: Closed
Project: Magnolia DAM Module
Component/s: User Interaction
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Antti Hietala Assignee: Mikaël Geljić
Resolution: Won't Fix Votes: 1
Labels: usability, ux
Remaining Estimate: 0d
Time Spent: 7d 1h
Original Estimate: 7h

Attachments: PNG File 2014-06-18_15-58-56.png    
Issue Links:
Relates
relates to MGNLDAM-312 Clarify if we want to be able to add ... Closed
dependency
depends upon MGNLUI-3488 Expose property OpenCreateDialogActio... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Sprint: Sprint 4 (Basel)
Story Points: 1

 Description   

Usability improvement for direct asset upload. Make the upload action available even when an existing asset is selected. It doesn't make sense to users why they can't upload an asset. The default assumption shouldn't be that the user is trying to replace the existing asset or build a hierarchy. They just want to upload the asset quickly.

This is a common use case when overwriting teaser assets. The Assets chooser dialog won't allow direct upload when the prior asset is selected, which it is by default.

Comparable example: In Google Drive, you can have an existing document selected but you can still upload a new one. The new doc won't replace the selected one or go under it. It will become a sibling.



 Comments   
Comment by Andreas Weder [ 24/Mar/15 ]

I've been asked to comment.

Strictly speaking, our actions apply to the currently selected item only. In this case, uploading an asset should do something with the selected asset.

I would be fine with this proposed change under the condition that we also change the name of the action to "upload new asset", at least in this case, to make things clear. What I dislike, however, is that we have similar cases in other apps, which we would have to allow as well to remain consistent. Almost every app except for "Pages" has similar cases, where an "Add folder" or "Add item" action could be allowed as well. If this is a frequent use case, I'd still vote "yes", albeit with a small margin.

Comment by Sang Ngo Huu [ 21/Apr/15 ]

Dear Andreas,

There are my implementations, please let me know if I'm wrong:
1. Enable Upload and Upload & Edit buton when user choose asset. The uploaded file will be add as sibling of chose asset. If user upload 2 file with same name in same folder, the newest will replace old once
2. Add more action: Add folder, It is really useful for user
3. I still keep the label as upload and Upload & edit, because if add more string, the name too long, and will break the layout of action area of choose dialog

I've pushed the code into MGNLDAM-476_sn branch of UI and DAM git. Please help me review

Thanks,
Sang Ngo

Comment by Aleksandr Pchelintcev [ 21/Apr/15 ]

Re-opened because:

  • Not being able to access a private field in the OpenCreateDialogAction shouldn't be the reason to duplicate its code into your OpenCreateAssetDialogAction
    • Please consider making a protected accessor in the OpenCreateDialogAction (that's a backward-compatible change)
    • Use inheritance for your action.
  • Add folder action - It's a nice initiative but it is not a part of this particular ticket
    • All the changes related to it should be extracted into a separate branch with a different ticket id
    • AddFolderActionRenderer might become redundant when MGNLUI-3386 is integrated - take a look at the solution (also Trang knows a lot about it).
Comment by Andreas Weder [ 24/Apr/15 ]

Ok, had a look and quick discussion with Sang. Thanks for the nice idea of an "add folder" action.

Here's a short summary of what we agreed upon:

  1. Behavior is fine for uploading a single asset: yes, it should be added as sibling of a currently selected asset. If a folder is selected, the asset should be added to that folder.
  2. We're going to change the behavior in case an asset with the same name as the asset to be uploaded exists already. Just replacing an existing asset is risky, in particular for customers with a lot of assets. We instead add a suffix to the uploaded asset's name (e.g. "asset_1.png", "document_2.doc"). This is more comfortable, if you work with tools that tend to choose the same name for assets or asset exports they create. If we'd only show you a warning, you'd still had to abort, then rename, then re-upload the asset - this is tedious and most likely not what you want. Also, a suffix solution would still work if we chose to allow to upload multiple assets at once in the future.
  3. I've also asked Sang to use a light dialog instead of a regular dialog when asking for a new folder's name.

apchelintcev I've told Sang I'd be fine this time to leave the "add folder" button in the same ticket, for pragmatic reasons. I've asked him to create separate tickets for added functionality in the future. I hope you're fine with that - it's meant to be an exception to a strict rule

Comment by Aleksandr Pchelintcev [ 03/May/15 ]

awedermp I don't mind at all, let it be added to the changeset. There just were other reasons to re-open, so I thought splitting the changes would be beneficial for both assignee and the reviewer. Maybe then the ticket title should be re-stated accordingly.

Comment by Aleksandr Pchelintcev [ 03/Jun/15 ]

You shouldn't have replaced the info.magnolia.ui.framework.action.ConfirmationActionDefinition with info.magnolia.module.dependencies.action.DependencyAwareConfirmationActionDefinition as the latter is only available in EE version.

Comment by Sang Ngo Huu [ 04/Jun/15 ]

That is my mistake when exporting bootstrap file. I reverted.

Comment by Jan Haderka [ 16/Jun/15 ]
  • you are adding update tasks for version 2.0.9 but this version is already released so it's wrong. You need to add them for higher version.
  • why are there static methods in command? Either it's some utility method and belongs in to some Util class or it is not an utility method and as such should not be static or not be in command.
  • there should be ui/selenium test for this change
Comment by Federico Grilli [ 02/Jul/15 ]

A couple of minor remarks:

  • AssetUtils and PageEditorChooseAssetDialogUITest
    • wrong years in copyright 2013-2015 should be 2015 as those classes are new
  • javadoc of AssetUtils should say something like “Get the existing asset or create a new one”
Comment by Jaroslav Simak [ 09/Jul/15 ]

Since you had to do some changes also in the MGNLUI project (branch MGNLDAM-476), i'd expect that there is a ticket for those changes created in that project + its linked to this issue.

Comment by Sang Ngo Huu [ 10/Jul/15 ]

I created ticket MGNLUI-3488 to handle the changes for MGNLUI. Please help me take a look. Thanks

Comment by Mikaël Geljić [ 10/Jul/15 ]

This is madness.

It's not clear what the heck was the outcome of this, and how much sense it makes now; the gap is so huge between ticket description, comments, and more decisions during implementation...

  • Does it mean we're gonna support adding siblings in all content apps from now on? —And if so, shouldn't the fix be done solely in the UI (workbench, OpenCreateDialogAction)?
  • And are we really adding a fifth button down that choose-dialog?

In my opinion, this just drifted too far: it brings behavior inconsistency between workbench in apps vs. in choose-dialog.
Yes there are improvements to be made, but I'd rather have us think them through properly, rather than patch and single-out this choose-dialog over and over...

Comment by Mikaël Geljić [ 05/Aug/15 ]

Ticket status is not up to date: this should be unscheduled and either moved back to open/backlog, or even closed as "won't fix".

As common as the described use-case may be, uploading siblings raises questions in purely hierarchical (tree) or unordered (list, thumbnail) views.
The Google Drive example mentioned here uses a navigator, thus setting the view context to a flat representation of a single directory's content. In that case, it is very clear where new uploads eventually land. This is unfortunately not so clear for our present views.

This story will eventually be captured by general content-view improvements at some point.

Generated at Mon Feb 12 05:00:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.