Re: VIDEO: Simplifying Plone with tiles and shortcodes

On 25-03-14 23:39, Dylan Jay wrote:
> 

> 
> 1. Losing "Folders"
> 

> I'm still not understanding what the actual complaint is here. It
> might be my use of the word "Page". Equally, that content type could
> be called a "Folder". Folderishness, containment and the way plone
> works with regard to having sortable content within an item won't
> change. The folder metaphor is still there. The proposal is to have 1
> more flexible type, instead of 3 separate but less flexible types.
> And we can call it whatever we like. A FlexiFolderPage? The only real
> difference is that the "add new" menu now works consistently by
> adding something inside something in all cases, not some, and we
> don't have to use default pages, which no one seems to say they
> actually like. As previously stated this proposal isn't incompatible
> with having pages and folders and collections as different content
> types however they would all be the same thing, just with different
> default text content. However since anyone can adjust the tiles to
> make a collection work more like a folder, or a page into a folder,
> the content type distinction here would be confusing rather than
> helpful I think. Fundamentally the folder metaphor is still there.
> What has changed is the default page metaphor (which isn't really a
> metaphor since it doesn't really map to anything in the physical word
> that I can think of).

While you can make your new pages work as folders (or more correctly as
collections, if I get the video right), it is a manual step that has to
be done for each folder. If I want to quickly organize 300 docs into 17
folders, which is more or less a daily occurrence, that just takes up a
lot of time.
In many intranet/extranet sites, the folder without any markup or text
is just a valuable, recognized way of structuring content. The reason
being that it's easy to explain to office workers who are used to file
systems working that way, and who like their intranets to be a good
reflection of that.

So while technically you can create 'folder-like' pages, it takes about,
what was it in the video, 17 clicks to do so? With plenty of conscious
decisions to be made on each one (simple listing, collection-style, ...)

That is just a *lot* of work to create a folder-like page.
I fully agree with Sean's comments earlier that some way of quickly
generating pre-defined subtypes (one of which I can then call "Folder",
thank you very much ;-)  would be a solution.



There's a separate concern: If my typical user will create 20 pages
after eachother in a folder, in the new system they will most likely end
up like this:
page1
  page2
     page3
       page4

etcetera, since once you've added a page and then click 'add' again, it
will be a sub-page of that. Not sure this is better or worse than what
we do now, but I'm quite sure this is what will happen, even if they
mean to create siblings.


> 
> 
> 
> 2. It's better to improve the default pages UI
>> - the 'default page' concept is something that's slightly difficult
>> to get across at first for new users, but in my training experience
>> users get it quite quick. The major stumbling block, and
>> panick-moment in a live site, comes later. The reasons for that:
>> the "View" menu does not have two essentials for good UI: Preview,
>> and Undo. So people mess around with it, and can't revert it to the
>> original state. (Try finding the 'pick an item as default view'
>> when that folder has now been filled with seventeenthousand news
>> items...)
> 
> I disagree. I think the issues with people clicking on the display
> menu later on are a symptom of the fact that they never really
> understood the default page idea in the first place. 

I disagree with that. The reason people use the display menu later on is
simply that the content evolves over time. When there were 3 pages in a
folder, the 'show all content' view was good. When somebody added 20
more, it had to change.
Or: at first, we show a folder with pictures in thumbnail mode, since it
looks cute. After a while, you just want to list them in default mode.
The pics have lost their instant relevance, and are just kept for
archival purposes.
And so on. I have many real-life examples where choosing differing views
for a folder is a perfectly natural and reasonal thing to do, depending
on the development of the content.

And choosing a different 'choose item as default view' is also not
uncommon. It's not unreasonable to have
http//my.intra.net/myteam/minutes always show the latest minutes by
default, and it still being a folder where all the minutes are chucked in.

again, I am not trying to block innovation. I am worried that making
things newbie-friendly in such a way that power users are despairing, is
not the way forward.
I'm sure a middle ground can be found, but that's why it is good to
discuss these issues.


It's still a
> hard concept to learn. 

but once learned, reasonably powerful. My question is: will I be able to
replicate it in your new idea?
(And not 'in almost all simple cases', which is why I still enable
old-style collections in every site, since the new ones don't have all
their powers. But I digress...)


(on shortcodes)
> 
> There is a UI. It's shown in the video. It is entirely usable without
> touching or understanding the shortcodes so the i18n argument doesn't
> really hold. Also, I've already said I'm looking into how to hide the
> shortcodes, so I think if we can remove shortcodes from the debate at
> this point it would be helpful.

fair enough. Although a few concerns are still with me:
- a semi-unified UI for tiles and embedding external things like video
would be preferable, I think, otherwise it gets confusing for users.

- accessibility. At this early point in the UI that's not a key one, but
it needs to be addressed, especially since TinyMCE 4 makes big progress
in that area. We don't want to mess that up with our home-grown
extensions tacked on to it. We did that once, time to not repeat ;-)


>> 
>> - maintainability. I have quite a few 5+ year old sites with Plone.
>> I have zero with Wordpress/Drupal/Joomla. When they had to change,
>> you just had to start over. While that may be good for consultants,
>> it's less good for implementors inside institutions.
> 
> So specifically what is your concern here? Are you worried about the
> upgrade step? This is covered in PLIP. It should be possible to do an
> automated upgrade. Are you worried about retraining? That is a
> concern but I don't see this as a big change for old users. Instead
> of adding a folder you add a page. Instead of using default pages you
> either edit the page or add a tile. That to mean is a lot simpler
> than training new people on default pages and dealing with the
> inflexibility on default pages.

I guess what worries me most is that it does not easily translate into
filesystems. On more occasions than I care to remember, having an
opt-out in the form of Transmogrify, Import/Export, Webdav or even FTP
has saved my sorry behind, and a lot of content.

Once users are re-trained (which indeed, they will have) they will of
course go wild with tiles. So while a simple NewPage with one
contentlisting tile is more or less equivalent to a folder, of course
people will put 23 tiles on a page. Just because they can. And that then
does not translate back into anything I could get *out* of Plone again
in a pinch. That worries me, in a long-time archival sense.


paul


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech