Feature #29790
closedList-View necessary?
0%
Description
Dear people and community,
there is often the same problem by editors on working with the backend:
1. normally you are editing content with the module Web -> Page
2. if you are reaching records (news, etc.) the backend informs you to change to the List-View (screenshot)
3. after change to list-view and editing records, the most people does not change back to the Page-View and are confused about the position of the content-elements
Suggestion:
Is the separate list-view necessary? Maybe the layout of the content-area change in dependence of the page-type automatically:
Folders = display the List-View
Pages = display the Page-View
and you don't neet an additional module view anymore.
Best regards
Gunther Schöbinger
Files
Updated by Fabien Udriot about 13 years ago
- Status changed from New to Needs Feedback
Hi Gunther,
I understand your point but things aren't as simple as that.
Folders = display the List-View
Yes, I agree. For me, it makes sense to automatically switch to the List View if User is on the Page module. Don't know how easy to implement it... To make this happen you should either provide a patch to the Core or find a developer that could do it.
Pages = display the Page-View
No, ;( as Pages may content other kind of content element that needs to be displayed in a list.
If you asked me, module "page" should be replaced by a versatile frontend editing... That is the most convenient way to edit content for the End User, I find.
Updated by Gunther Schöbinger about 13 years ago
- File modul_page_01.png modul_page_01.png added
- File modul_page_02.png modul_page_02.png added
Hi Fabien,
thank you for your answer. The problem is well known and maybe there is another simple way to solve this (remembering to TYPO3 v.3.x):
1. Module Page
- displays all content-elements in the typical layout (scrrenshot 1)
- if there are reocords (all records of the type "no content-element") - these records are displayed under the layout (screenshot 2)
2. Module List
- no changes
By this solution the editor has not to change the view during editing and the module list becomes a more advantaged (pro) editing alternative. By the way "Folders" could display no layout of content-elements only records.
What do you think about?
Greetings
Gunther
Updated by Jens Hoffmann about 13 years ago
With real content, this is than way to much on one page >> modul_page_02.png
Possible Solution: A simple text line, which links to the list modul and explains
that there are more (different) records on this page, and that you could access
them via the list modul.
As Less, as Better :)
Updated by Gunther Schöbinger about 13 years ago
Ok - the screen modul_page_02.png is only if there are records on content-pages.
In this case a link or another option like the "Extended view" (maybe "Display records") could help to achieve the records.
1. Modul page
1.1 Content pages without records
- regular view (no changes)
1.1 Content pages with records
- regular view
- link to list
- alternative option "Display records" -> display the records under the content
1.2 Folders
- display all records automatically - no text "The current page is a folder..."
2. Modul list
no changes :-)
With the option 1.2 the editor can reach all content without changing the view... (i think this is a problem for a lot of people)
Updated by Steffen Gebert about 13 years ago
Hi,
I can understand your problem a bit.
- I guess it will not be easy to show all tables below the Page content (Page module itself is an (extended) instance of the List module - and it's a bastard..)
- Showing the tables will slow down the Page module. With your suggestion to create a checkbox for that it's a bit relaxed, but well, I'm still sceptic.
- You can already show tables below the Content Elements - tt_news and tt_calender do that. I think it's part of the problem that some extension tables are listed there, but not all.
Steffen
Updated by Gunther Schöbinger about 13 years ago
Hi,
the problem with tables below the page is more complex than i thought (I'm interesting, how tt_news solved this). To get a smooth solution we should care about two cases on the module Page:
1. Sysfolder (most used by editors for tables/records)
- display all records automatically - no text "The current page is a folder..."
2. Content pages (exceptionally for tables/records)
- display records by enabling a checkbox, etc...
Greetings
Gunther
Updated by Steffen Gebert about 13 years ago
There is also a use case for using a Folder like a normal Page in the Page module and just create content there as usual.
I've often seen configurations, where contents of such a special folder are used in other places of the web site (e.g. in a border column on every page). So IMHO we can't just redirect to the list module.
Updated by Gunther Schöbinger about 13 years ago
Steffen,
your case of using the Folder would work too - I don't want to redirect the user in any way. The Folder could display content elements (your case) and additionally records (my opinion) on the Page.
Greetings G.
Updated by Tanel Põld over 12 years ago
Hi!
I have been thinking about this a lot as well. True is that in last 7 years I'd say 97% of my users don't need to change the view manually, it could be changed automatically for folder type pages.
On the other hand it's true, sometimes list view is needed for regular pages as well.
For TemplaVoila there is a page module that does automatic switching if opening a folder. Really useful for most of the sites. Now using TemplaVoila no more the problem is back.
One possible solution.
Remembering the last set module for the page? True, might become flow killer.
But what about setting defaults? Opening all folders in List module and regular pages in page module by default, but leaving possibility to change manually.
Adding a tiny feature but solving the problem for most common content editors.
Regards,
Tanel
Updated by Jens Hoffmann over 12 years ago
- Priority changed from Should have to Could have
I will put this on the agenda for the next meeting.
Right now I fear there is no possibility to really do
this change, as the liste module is quite bad code.
Greez Jens
Updated by Tanel Põld over 11 years ago
Another thought on this one.
As it's still one of the most annoying things working with the TYPO3 backend every day.
I'm figuring why does it feel so unnatural.
Clicking "Page", first column, makes it very clear, "you started to work with a page".
So why should I go back to the first column if I still work with pages?
"List" is just an alternative view for the page, so as "View" "Columns / grid", "Translate", "Quickedit", "Info" etc. So why not to place it above there with other views?
Selector just needs better solution than drop down.
On the screenshot. User should go back to point 2. if he needs to change the page. Changing the view should always happen in point 3 with no need to go back to point 1.
Should the view be selected to remember per page or until next changing selection it could be user option.
Updated by Benni Mack about 8 years ago
- Tracker changed from Suggestion to Bug
- Project changed from 78 to TYPO3 Core
- Category changed from Usability to Backend User Interface
- TYPO3 Version set to 8
Updated by Alexander Opitz over 7 years ago
- Tracker changed from Bug to Feature
- Status changed from Needs Feedback to New
- Target version set to 9 LTS
Updated by Riccardo De Contardi about 7 years ago
- Related to Story #82206: list module enhancements/bugfixes added
Updated by Susanne Moog about 6 years ago
- Target version changed from 9 LTS to Candidate for Major Version
Updated by Riccardo De Contardi over 5 years ago
- Related to Bug #55300: Inconsistent handling of Sys-folders added
Updated by Riccardo De Contardi over 5 years ago
- Related to Feature #36705: Forward pages with defined doctype to list view added
Updated by Christian Kuhn over 2 years ago
- Status changed from New to Closed
Hey. I hope it's ok to close here for the time being: There is currently to approach to get rid of the list module as such. I agree some use cases might not be perfect from a users point of view, but this issue is stalled since 10 years and it does not seem as if anything will happen in this scope, soon. We should continue with fresh tickets if usability concerns regarding page & list module usages are picked up again.