[Plone-UI] Plip. Placeless adding

Dylan Jay djay at pretaweb.com
Thu Dec 27 23:51:06 UTC 2012


On 24/12/2012, at 6:14 AM, Cris Ewing <cris at crisewing.com> wrote:

> I think the contextual nature of the green frame is pretty important to preserve. Mixing local and global actions leads to confusion for end users. 

Any ideas on how to move forward with this? I'd rather submit something that most people agree on.

On one hand, breaking the context-only nature of the green bar is a big move, but on the other, splitting the function of "adding" between two different menus doesn't seem good UI either. plone.app.toolbar/cmsui doesn't seem to care about context vs global so should we still worry about this? Another option is we take the "add new" menu away from the green bar, but then thats not that much different p.a.toolbar isn't it?

Here is what the menu might look like. Perhaps if the bottom, global bit wasn't green?

Add new....
-------------------------
----Add here---------
Collection
Page
File
Folder
----Add----------------
Image...
News Item...
Event...
Link...
-------------------------




> 
> Cris Ewing
> ************
> Cris Ewing Developer, LLC
> http://crisewing.com
> cris at crisewing.com
> @crisewing
> 206.724.2112
> 
> 
> On Dec 23, 2012, at 8:46 AM, Jure Cerjak <jcerjak at termitnjak.si> wrote:
> 
>> +1
>> 
>> About the location of 'global add' - I'd prefer to have it in the edit bar. I think of edit bar as "the nice green thing that lets me manage my content". I know it's also context oriented, but I don't think global add breaks this considerably.
>> 
>> cheers,
>> ibi
>> 
>> On 12/23/2012 12:11 PM, Alberto Lopes wrote:
>>> +1 on the "global add" idea, and the location field on the add/edit form, defaulted to the context.
>>> 
>>> However, I would not put the "global add" option in the add item menu.
>>> 
>>> I feel like the edit bar follows a semantic in which everything you click on it applies to the current context. If the add menu included the global add option, that semantic would be inconsistent.
>>> 
>>> Besides, I think it could confuse inexperienced editors, which would see unrestricted content types on both the "add here" and the "global add" menu.
>>> 
>>> My suggestion would be to leave the "add item" menu as it is now and to include the "global add" in the site actions area along with the site setup and dashboard links.
>>> 
>>> That way, it is accessible from anywhere in the site and does not break the edit bar semantics.
>>> 
>>> Em 23/12/2012 04:42, "Christian Ledermann" <christian.ledermann at gmail.com> escreveu:
>>> +1 this is a common use case
>>> 
>>> On Dec 23, 2012 6:47 AM, "Dylan Jay" <djay at pretaweb.com> wrote:
>>> Hi,
>>> 
>>> We came up with this idea over PretaWeb drinks on Friday. Thoughts?
>>> Anyone interested in seconding?
>>> 
>>> Proposer: Dylan jay
>>> Seconded:
>>> 
>>> Motivation
>>> --------------
>>> 
>>> Many times custom types are only designed to be added in a certain
>>> place, or you may want restrict built in types to limited places in
>>> your site. In such cases plone is harder work than it should be to add
>>> a new item. You have know where to add it, browse to that location,
>>> often with a nav designed for exploring not fast access, then you can
>>> select from the menu. We've seen installs with lots of place specific
>>> types where training is needed to teach where to add each type.
>>> 
>>> Proposal
>>> ------------
>>> Instead, add new menu can be decided into two sections, add here,
>>> global add.  "Global add" includes any type not in "add here"
>>> All add forms will have a path/location field. If you click global add
>>> you can select from available locations using this field (perhaps with
>>> sensible default). If only one location in site, this will be read
>>> only. If item addable in current folder then context will be default.
>>> Some type might need to be excluded from global add like pfg types.
>>> Adding location field to types makes plone more familiar to users of
>>> other CMs and also allows a user to change their mind on where it
>>> should go as they are creating content. It could also be a URL field
>>> where uses could enter folders that don't exist and they will be
>>> added. This also allows setting short name.
>>> 
>>> Assumptions
>>> -----------------
>>> 
>>> 
>>> Deliverables
>>> -----------------
>>> - New add menu implementation
>>> - modify standard metadata on standard types so forms include path
>>> field. Or else use schemaextender. Modify dexterity to do same.
>>> - widget for path with browse button and editable path.
>>> - Change the way factory creation works in AT and dexterity to allow
>>> creation in different folder.
>>> 
>>> Risks
>>> --------
>>> Add menu could get long. Could be mitigated having a more button or scroll list.
>>> _______________________________________________
>>> UI mailing list
>>> UI at lists.plone.org
>>> https://lists.plone.org/mailman/listinfo/plone-ui
>>> 
>>> _______________________________________________
>>> UI mailing list
>>> UI at lists.plone.org
>>> https://lists.plone.org/mailman/listinfo/plone-ui
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> UI mailing list
>>> 
>>> UI at lists.plone.org
>>> https://lists.plone.org/mailman/listinfo/plone-ui
>> 
>> -- 
>> Jure Cerjak
>> Termitnjak d.o.o.
>> 
>> Web: 
>> http://www.termitnjak.com
>> 
>> Tel: +386 (0)40 162-740
>> Email: 
>> jcerjak at termitnjak.si
>> 
>> Skype: jurecerjak
>> 
>> _______________________________________________
>> UI mailing list
>> UI at lists.plone.org
>> https://lists.plone.org/mailman/listinfo/plone-ui
> _______________________________________________
> UI mailing list
> UI at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-ui



More information about the UI mailing list