It's confusing that links to files behave different to editors than public

[djay]

Describe the bug
A UX bug is that editors think links will not directly download a file because it doesn't for them

To Reproduce
Create a file.
put it in a listing
note that you see it's view when clicked on rather than downloading it

Expected behavior
It should behave the same as for non logged in users.
To get to the file object so it can be edited should be handled another way. By a on hover popup that allows the user to go directly to edit or view the file.

Screenshots
If applicable, add screenshots to help explain your problem.

Software (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Volto Version [e.g. 8.5.0]
• Plone Version [e.g. 5.2.2]
• Plone REST API Version [e.g. 7.0.1]

Additional context
Add any other context about the problem here.

[davisagli]

I think this could make things less confusing. It needs a specific design proposal, and we should be consistent about how we handle Files and Links.

[ichim-david]

@davisagli @djay
I think we need less magic and more configurable behavior and predictability. I was bitten today at work with this issue where we are using within https://github.com/eea/volto-listing-block a custom card model for the teaser card where an editor added a file with a preview image as a teaser source. Logged in you see everything fine while anonymous the url contains @@download/file/@images/image/preview which obviously failed.
On top of this I wasn't passing to ConditionalLink to param, only item which meant that UniversalLink didn't receive a href.
https://github.com/plone/volto/blob/main/packages/volto/src/components/manage/UniversalLink/UniversalLink.jsx#L59
With the way UniversalLink is constructed it adds the @@download/file link because again we have magic non authenticated checks and puff for them they get @@download/file/@@download/file.
This is because regardless of what is written here https://github.com/plone/volto/blob/main/packages/volto/src/config/index.js#L115 even if you set it to empty the file arrives from plone.restapi or from plone itself only for anonymous with the /@@download/file at the end of the url. (P.S. If you know how I can turn this off please let me know :))

I propose we add settings to make url display predictable with the possibility to have the same display as auth and anon without auth hardcodes. There shouldn't be any implicit hardcoded decisions but configurable and documented options.

[davisagli]

Yes, the status quo is confusing. Please someone make an actual UI mockup/proposal for how to show a link for editors in addition to the link for normal users.

[ichim-david]

Yes, the status quo is confusing. Please someone make an actual UI mockup/proposal for how to show a link for editors in addition to the link for normal users.

@davisagli before any visual tricks I think we can make it more configurable at least through code if you want to go one way or the other.

One solution that might make sense UI wise is when the editor is hovering over the link it get's a popup with icons like we have with the html block when it's focused. Could be expanded for other forms of interactions such as tab focus or you click/touch the link and it shows popup and you select from it if you want the view or download button.

EDIT:
I am afraid that with UI solutions we will have a hard time picking one since everyone has their own opinion on what is usable but for the sake of brainstorming, I got the first ball rolling.

[djay]

@ichim-david

I am afraid that with UI solutions we will have a hard time picking one since everyone has their own opinion on what is usable

I couldn't agree more and I think it's creates so much stop energy that it's draining to think about even raising or suggesting solutions to UX problems... or even working on them. This is why I proposed awhile back that unless there is a volunteer, plone should consider paying a UX expert that we all trust to triage and guide solutions. Telling developers how to fix UX problems and have them ignore it is as thank-less a job as the release manager IMO, but just as important.

but for the sake of brainstorming, I got the first ball rolling.

Technically I did and we agreed.

By a on hover popup that allows the user to go directly to edit or view the file.

But I now suspect on hover is no good for accessibility.
I suspect you have to click on the link and then get a popup. Somewhat similar to google docs (but that a slightly different use case)

It's not a great solution because it's still changing the behaviour of that click for logged in and anon users. And the now the logged in user is doing 2 clicks to navigate which could be a pain on some sites.

The only other solution I can think of now is putting an extra icon after the link but that is worse because it can screw up the design and it's likely too small and easy to forget to click there instead.

[ichim-david]

@ichim-david

I am afraid that with UI solutions we will have a hard time picking one since everyone has their own opinion on what is usable

I couldn't agree more and I think it's creates so much stop energy that it's draining to think about even raising or suggesting solutions to UX problems... or even working on them. This is why I proposed awhile back that unless there is a volunteer, plone should consider paying a UX expert that we all trust to triage and guide solutions. Telling developers how to fix UX problems and have them ignore it is as thank-less a job as the release manager IMO, but just as important.

but for the sake of brainstorming, I got the first ball rolling.

Technically I did and we agreed.

@djay LOL I was referring to being first to share a "mockup" as David was suggesting not that I was the first to come up with the suggestion. Of course you've been mentioning many times the deficiencies of Volto but as others suggest we can't only complain about hard problems we also must come up with actual proposals which might be accepted as it or iterated until something awesome comes up. Me personally I'm happy with having progressive improvements, it's better to have 5 pull requests that all build on each other as you get more inspiration or real world usage than 1 big awesome work that takes forever to finish leading only to burnout. It would also make it easier for that work to be reviewed and some agreement going.

[djay]

LOL I was referring to being first to share a "mockup" as David was suggesting not that I was the first to come up with the suggestion.
fair enough

Of course you've been mentioning many times the deficiencies of Volto
I'm talking about a problem with any open source where the developers aren't the users, not just about volto.

but as others suggest we can't only complain about hard problems we also must come up with actual proposals

" that unless there is a volunteer, plone should consider paying a UX expert that we all trust to triage and guide solutions" is an actual proposal. But Victor said it would never work and no one else seemed to support the idea so I dropped it.

Me personally I'm happy with having progressive improvements, it's better to have 5 pull requests that all build on each other as you get more inspiration or real world usage than 1 big awesome work that takes forever to finish leading only to burnout.

I refer back to the original problem I stated. "t's creates so much stop energy that it's draining to think about even raising or suggesting solutions to UX problems... or even working on them". UI is hard to code. knowing you are headed to an acceptable solution is motivating.
You seem to be saying just implement anything you come up with as a developer no matter how bad the UX is and then fix it later. Even if it makes the developers happy you get so much churn in the product. changing documentation. chaving customisations. confusion over changing names. UX is not the same as inefficient code.
Hence why a single UX expert would be so much more efficient on developer resources and user good will.

But none of this solves the immediate problem of what makes a good UI for this particular case. I'll see if I can find some more specific examples on solutions that would be WCAG compliant.

[stevepiercy]

@djay What do you expect will happen each time you post your informal proposal in an issue tracker?

I suggest that if you want Plone to pay for anything, then you need to make a formal written proposal to the Plone Foundation Board.

Even then, it is not likely that the Plone Foundation will pay for a development proposal that is not a sprint or conference. With only USD$250K in cash and USD$50 - 80K in annual revenue, with most of it going toward sprints, conferences, and operations (https://apps.irs.gov/app/eos/), there's no money for any large development project. I've also asked about paying for documentation, and it was kindly explained to me that documentation has always been written for free by the community, and paying someone to write documentation could alienate those contributors and disincentivize future contributions.

Thus for Plone documentation, I hunt for external funding sources. The Board supports my efforts, and they are keeping their eyes and ears open for potential funding sources for the development of documentation. I network with documentarians from other projects and organizations. The Write the Docs community is a good resource for the profession. Last spring I wrote a formal proposal with guidance from the Board, and the Board applied for Google Season of Docs, but we were not accepted. I have a few other leads to follow. Of course, if anyone has any suggestions for funding sources for documentation, please hook me up.

If I had any good leads for UX efforts, I'd send them your way.

[ichim-david]

Me personally I'm happy with having progressive improvements, it's better to have 5 pull requests that all build on each other as you get more inspiration or real world usage than 1 big awesome work that takes forever to finish leading only to burnout.

I refer back to the original problem I stated. "t's creates so much stop energy that it's draining to think about even raising or suggesting solutions to UX problems... or even working on them". UI is hard to code. knowing you are headed to an acceptable solution is motivating. You seem to be saying just implement anything you come up with as a developer no matter how bad the UX is and then fix it later. Even if it makes the developers happy you get so much churn in the product. changing documentation. chaving customisations. confusion over changing names.

@djay it seems I need to explain myself even though I didn't think I needed to just like with the jab about you being first and what I meant by that.
Let me explain than my view about multiple pull requests and continuous improvements vs a single take everything at once.
Let's take the style wrapper which was added in one state and over time improvements came to it in the form of new features as new patterns arose from using it. Or the Object browser which received the ability to select external or not or link mode. It started from one state and it got improved as time went by.

In the same way, you can improve one aspect of the UX of a particular feature and improve it over time as there is more real-world usage and someone has the inspiration to improve it.

Let me tell you also why I think that several pull requests will be needed with a specific example.
Rob from Kitconcept used his time to improve the UX of the file picker by implementing another view with large icons making it easier to know what image you are selecting.
It was merged and I discovered something that was missing from that implementation for which I added an issue as you can see here: #6054

Should I complain now that this bug exists or be happy that someone gave me an improvement over what exists for free?
Personally, I am grateful for every improvement and realize that in every aspect of every work, we can do better. We should strive to continuously improve things and not ask for perfection as that will never happen.
I'm so grateful that I will try to fix it myself and not expect him to fix it for me just because he was the one that added this feature as he might have other priorities or could be unable to work on this.

This is all open source which is built on firms that employ individuals and individual contributions. Look at the contributor graph https://github.com/plone/volto/graphs/contributors to see just many many commits are made by so many individuals.
Unfortunately, I don't see your name in even one commit :( although I hope that our call to step up coming up with proposals and then solutions can embolden you to champion some solutions for the many UX issues that you found and added to the Volto repository.
I know that you already started doing something with the decoupled editor for which I applaud your initiative and I look forward to seeing what comes out of it.
Just realize that the free software that you use can only be as good as the investment that is given by all actors that use it and many times if you want something to get done, you will have to do it yourself and contribute to it like so many other companies and individuals already did so until now.
Take for example the work that RedTurtle did to create a new plone contents section which they made for their projects and now want to make it even better and have it in core. I can give many other examples of things that were added in core from all of the firms that use Volto and desire to contribute to Volto in order to see it improve.
In the same way, there is more than enough room for your improvements if you are willing to put in the work and champion a solution. Worst case scenario if you create it as an add-on, you still remain with your work which is an improvement over what is currently available if not merged in core since you've made it according to your specs.

[davisagli]

@ichim-david I think your comments toward @djay miss the mark a bit. Maybe he hasn't made commits himself, but PretaGov developers have. Also, let's be careful not to set the expectation that someone has to make commits in order to be considered a contributor. Participating in discussion of problems and possible solutions is also valuable and I appreciate @djay's work in these areas.

You do have some fair points which I think I could paraphrase as:

• Sometimes it's hard to evaluate a possible solution until there's a proof of concept to try out.
• It's unrealistic to think many people will have as much motivation to fix a problem as the person who reported it.

@djay, I find your repeated suggestions to hire a UX expert a bit of a distraction. Even if the Plone Foundation had the money and will to do it, it wouldn't make tricky UX problems like this go away. There would still be things to discuss based on the UX expert's input. As things stand currently, you are welcome to hire your own expert, report their input here, and make the case for why the community should follow their advice. kitconcept has done this with the UX people that work on our client projects. Also let's not discount the UX expertise that exists within our community -- we've been around the web for a while and have seen things that work and things that don't. The discussion of possible solutions above and pointers to how other systems do it have been helpful. (I'm not saying UX expertise and experience is worthless, just that there are multiple places we can find it.)