Document Actions

#236: Move Display menu to edit and allow for custom properties

Contents

by Danny Bloemendaal — last modified September 3, 2008 - 08:24

The Display menu is a setting that only belongs in the edit form of an object (settings tab). Also it should allow for custom configuration options.

Proposed by: Danny Bloemendaal
Proposal type: User interface, Architecture
State: being-discussed

Definitions

Motivation

The display menu is a setting that controls how an object presents itself to the user. Right now it suggests it is a switch that every user can change at will not knowing it is persistent among all the users. Therefore this menu should be part of the settings tab in the edit form.

Assumptions

Proposal

First: remove the Display menu and add a field to the settings tab of the edit form where it belongs.

Second: a Display view should be able to provide a custom property sheet that is loaded into this settings form whenever you pick a display type. These properties give the user options to set parameters for the chosen view. A thumbnail view for instance could provide an option telling how many thumbs are shown. The point is that you don't know this in advance so the view should somehow provide this property sheet.

Implementation

Deliverables

Risks

Progress log

Participants

Agree

Posted by Ben Mason at September 21, 2008 - 09:55

+1

This would be really good. No longer would clients 'accidentally' remove the default object from the display menu.

3.3 Framework team vote

Posted by Martijn Pieters at October 26, 2008 - 17:08

-1, see the framework team list discussion on what should be in 3.3 (We can't remove, change or move major pieces of the UI).

Framework team vote (for Plone 3.3)

Posted by Andreas Zeidler at October 27, 2008 - 22:01

-1, i too agree with Martin and the others with regard to UI changes in minor releases (see http://lists.plone.org/pipermail/framework-team/2008-October/002228.html and http://lists.plone.org/pipermail/framework-team/2008-October/002211.html)

+1 for making this a 4.0 PLIP, though.

Posted by Andreas Zeidler at October 27, 2008 - 22:07

[eom] :)

Framework team vote

Posted by Danny Bloemendaal at October 27, 2008 - 15:25

Sigh.. ok -1 since we are not allowed to fix plone in these releases ;-)

Framework Team vote

Posted by Tom Lazar at October 28, 2008 - 10:45

same here... I love the proposal but IMHO even the notion of "but it's UI bugfix!" won't hold here, since users will (at least initially) think 'hey! the display menu is gone! something broke my 3.3 update!" etc. etc.

so, regretfully a -1 from me, too... (and a +1 for 4.0)

Provide a usable component for non Archetypes Content

Posted by Carsten Senger at November 19, 2008 - 14:50

This is an essential CMS functionality. All content should provide it in a unified way. If we move this from a generic place to an Archetypes/ATCT specific location, we should have a fallback for content that uses other frameworks like formlib or z3c.form. Otherwise we will have some addons that provide a different user experience.

Plone CMS: Open Source Content Management

Sections

Personal tools