Ticket #4407 (closed Bug: fixed)

Opened 9 years ago

Last modified 5 years ago

folder_contents should not switch back to non-folder_contents view

Reported by: ajung01 Owned by:
Priority: major Milestone: 2.1
Component: Templates/CSS Version:
Keywords: Cc:

Description

When you are inside the folder_contents view and click on the link of a subfolder then I do expect to see the folder_contents view for this particular subfolder but instead Plone switches to the default view of this folder (if there is one)....which is a PITA when copying and pasting content around.

Change History

comment:1 Changed 9 years ago by alecm

The main utility for such a feature would be to paste a batch of content from one folder to another. However, the 2.1 ui has a paste action in the actions menu on every piece of content which pastes the current clipboard content into the current folder (or parent if the current object is not folderish), and should deal with this use case effectively without the need for the folder_contents view. Having the links in e.g. the navtree behave differently based on the current view template would be very confusing for many users. The navigational links need lead to consistent views regardless of the current context/template. The bulk back and forth copy/paste that such a ui change would make easier is not a common enough use case to necessitate inconsistent navigation.

comment:2 Changed 9 years ago by ajung01

The justification for the behaviour is just stupid IMO. When a user want to click through a hierachy of folders looking for a particular file or folder then it is painful to switch always back to the folder_contents view when you need to see all items including all details e.g. review states. Such a behaviour is totally inconsistent for advanced users. Otherwise I must have the impression you design a CMS for dumb people without having advanced users in mind. Sorry but I have to say that such a view on usablity *disatracts* people from people from using Plone if it hinders their productivity.

comment:3 Changed 9 years ago by alecm

We need to cater to both (all) sets of users as best we can. The addition of the paste button was an attempt to retain the power granted by keeping of folder_contents while maintaining UI consistency (hobgoblin of simple minds, I know). You fail to point out what is wrong with the paste action based solution, other than that it is not exactly the thing you want. Compromises are a necessity of interface design. I personally don't care either way, but I'm sure limi does, so I'll assign this to him.

comment:4 Changed 9 years ago by ajung01

As I pointed out in #4408 it is not only about cut&paste. The current behaviour requires the double number of clicks and the double amount of time to walk through a hierarchy using the folder_contents view compared to Plone 2.0 which is a a step back - means this behaviour is counterproductive.

comment:5 Changed 9 years ago by ajung01

The behaviour is especially inconsistent when you click on the "up one level" link from within the folder_contents view. This link links to the folder_contents of the parent folder (as expected) but not to the default view as one would expect from following your arguments.

comment:6 Changed 9 years ago by geoff

I'm with Andreas on this one.

comment:7 Changed 9 years ago by limi

Andreas is right, this is a regression. If you are in folder_contents, it should stay in folder_contents for folderish items, like before.

The only change that has been done explicitly is that clicking in the navtree will take you to the view always, whereas Plone 2.0.5 would try to guess whether you were in folder_contents, which was inconsistent and expensive.

To sum up, folder_contents should always link to some-folder/folder_contents in the links within itself. This also goes for the Up One Level link.

comment:8 Changed 9 years ago by alecm

  • Status changed from new to closed
  • Resolution set to fixed

Excellent, fixed in svn.

comment:9 Changed 5 years ago by hannosch

  • Component changed from Usability to Templates/CSS
Note: See TracTickets for help on using tickets.