Re: VIDEO: Simplifying Plone with tiles and shortcodes

On 24-03-14 22:58, Martin Aspeli wrote:

> 
> Second of all, this is a tirade of stop energy, and you're making a ton
> of assumptions about what Dylan is thinking and saying.

I don't think it's just 'stop energy', but a legitimate concern. I
partly share the same concerns. I don't think that's necessarily due to
unwillingness to change, but mostly due to differing experiences with
the many varied uses of Plone.




to continue the discussion, my 2 cents:

- the 'Folders and files' metaphor is extremely useful in
intranet/extranet settings. In my experience with training people, this
has never been a problem explaining. The fact that you can't have
'attachments' with a page is, however.
So while making everything folderish is potentially a big win, we should
not underestimate the power of the folder metaphor, especially for
collaboration sites with lots of content. For pure external-facing
websites, the concerns might be different. Although also there there are
differences between very content-heavy websites with 100000+ pages and
targeted, focused websites with < 1000 pages.

- 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...)

- shortcodes are very, very questionable in an internationalized
context. Their semantics/mnemonics have zero meaning to people not
speaking English, let alone using a completely different script. For
them, it would be pure copy/paste of random jibberish from the
Interwebz. That's not behaviour I'd like to encourage. Without a UI, it
seems like a big regression to me.

- the de-coupling of URL/menu with content seems to me like a very big
throwback. It is a crutch other CMS's use, because they have to map a
relational database onto a website.
In my experience with other CMS's this de-coupling has always led to
huge problems. Not in the initial setting up of a website, but in the
evolution and maintenance of websites.
Devising a menu structure for a website more or less independent of the
actual content has two flaws:
* it only works for a limited set of uses, namely where there is a
smallish team of editors thinking about it. It does not work in a
massive intranet setting, where the structure evolves without central
oversight.
* every organization will get their initial menu structure wrong.
Invariably. As time evolves, you will need to move content about.
One of the great powers of Plone, one that we sometimes take for granted
but that still impresses the hell out of people maintaining sites over
years and years: You can copy/paste content!!!
That means you can archive stuff, you can move stuff around as your
organization evolves and re-organizes.

So, while I'm fully in favour of making Plone easier to use for new
users, I also want to preserve the strength it now has:

- 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.

- workability for non-english users. Shortcodes that only work in latin
script are very suspect to me.


Paul Roeland


------------------------------------------------------------------------------
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