Just thought I'd put this out there. This is what persons expect of site authoring, Wix, Weebly and now Google Sites
3 Likes
I can confirm. We know of sites moving away from plone due to percieved high costs of layout changes due to having to back to expensive developers to achieve what they see as simple changes.
We need to get a move on with getting mosaic into the core and worry less (for now) about rewriting it, or anything underneath as users dont care as they directly or indirectly pay all our bills.
Let's honestly add that the current Mosaic functionality and usability is far away from what we see in competing systems. The whole enduser experience with adding, moving and changing tiles is not very good. I wonder why other systems get it right but Plone not?
-aj
Constructive detailed feedback perhaps?
Placing or moving tiles is error-prone. The handling is not really snappy or motivating to work with. It feels clumpsy and unnatural..will,get on tiles next week as part of a customer project.
-aj
If Mosaic UI feels already outdated, it might be because of it's from 2009.
We are still looking for sprint topics/focii for Plone Open Garden in Sorrento, April 18-22. This might be a nice thing to move forward!
More seriously. I don't think that the issue is that Plone "does not get it right", but that simply nobody in Plone is really working on it.
Remember that Deco was already usable in 2011 when the editor was still competitive. (We did build simpler UI on top of blocks & tiles already in 2010.) Unfortunately, because Deco was "revolutionary" and not compatible with the existing Plone UI, not many seemed to adopt it.
Probably the main feature of Mosaic reboot for Deco was to make the composition compatible with all our legacy, to make it possible to start using it gradually. Rewrite for the editor was not a priority, because it could be done later.
And it could still be done. Thanks to our insanely flexible stack, there's plenty of options to start writing a more modern editor for Mosaic. For example, one could override the layout (editor) pattern while reusing all its configuration. Or keep the old and new at the same time by making a new widget for the new pattern (possibly inheriting Mosaic widget). Blocks / Deco / Mosaic layouts are still just HTML and use of server-side rendered schema-aware application tiles is fully optional.
6 Likes
I like the fact that Mosaic is useful today, it provides a stepping stone for the next innovation. My post was to save us from getting caught in a bubble/echo chamber, we really need to keep our eyes open to where things are at today.
I expect the next iteration of Mosaic to only get better, in the mean time I'm trying to do a deep dive into more JS and UI design.
@ramon, would you have any screenshots of your layout editor prototype from Mephisto sprint? It should be a proof taht we are aware of the issue 
What I remember, the prototype minimized the need for dragging. Adding new tiles didn't need dragging at all. Dragging was reserverd for reorganizing and row reordering.
2 Likes
Any update on this? Is it a topic for the Sorrento event?
We are planning a PLOG organizer's meeting, which should take place by end of next week. Included on the agenda will be to identify sprint topics for PLOG, other than the headless CMS.
FWIW, unfortunaly, I personally cannot join Sorrento this year, but I will participate Bonn Beethoven Sprint to help PLOG headless CMS topic.
1 Like
I'm happy to discover this conversation - honestly talking about how Plone compares to the competition.
For me it's important to break it down and pick out the features we need to make up. The G Sites clip above looks good because:
-
The tile is created in an overlay first, and then placed (Note that it helps their cause to use a tile with a large amount of content such as a map - as opposed to a byline.
-
The tile can be dynamically resized to a (12 column) grid
-
A well placed clear "Publish" button
-
A large (and :. intimidating) list of tile types on the right
-
I would also add Andreas' point on the trouble moving and placing tiles - the thin line that Mosaic uses to place tiles isn't easy to locate - we should have "fatter" target areas to aim at dragging things into, and resizing should be done on tiles not on slots.
I don't see there's much else, so hat's not many points to work on IMO - 3 & 4 are quick wins, and jqueryui.resizable() would do a decent amount of work for 2.
Perhaps the main trouble though is building this in a way that enough people will feel able to and want to maintain it. I'm lost looking at the sourcebase.
On the subject though, has anyone played with ftw.simplelayout? If not trial it with plonetheme.blueberry (on 4.3.11) for 5 minutes. It comes with a lot of other tech decisions that you may not want, but it shows a different way to do things possibly closer to the G Sites above.
1 Like
A follow up on ftw.simplelayout - one big like is that creating new page elements ("Blocks" in their terminology) is apparently very simple:
- just add a content type with their ISimplelayoutBlock behaviour
- register a browser:page view called
block_view
That means they get "nice" problems like too many block types to list - worth a view just for the screenshots. I'm not ignoring that mosaic has more tiles than that, but I wonder if it's a higher barrier of entry to contribute them.
1 Like
I like the direction of ftw.simplelayout.
Thanks for looking. One thing I would like to clear up is whether their storage mechanism is correct. IIUC Mosaic and collective.cover use plone.app.blocks and plone.app.tiles which means layout is stored in the object itself, but tile data is stored in annotations. ftw.simplelayout by comparison stores the "blocks" as content objects within the folderish "Content Page". I think that's they way I would do it if I was started from scratch, but (as ever with Plone) I would be suspicious there are reasons not to do it that way. Anyone got an opinion on that?
I've not looked ftw.simplelayout in detail, but we've had years a custom Archetypes based composition content type, which has a "column" content type, which can contain normal Plone content to be rendered as "blocks". It has a recursive rendering algorithm, which makes ot pretty flexible. And some amount of responsivity can be achieved with CSS. Our homepage serves as an example: Front page | University of Jyväskylä
It works, but rendering can be a bit slow, because it being a composition of dozens of pages. Bigger issue is that each block is also a page of its own and because our blocks are default content types, they may appear in search results.
@datakurre thanks for the reply. Obviously dexterity implementations (such as ftw.simplelayout) are generally faster than Archetype ones - and their templates are fairly small too. Subrequests obviously have their overheads, but Plone isn't exactly avoiding them - they've been added to Diazo in recent years.
I thought (haven't checked) that we can eliminate content types from search?
It looks like ftw.simplelayout has some things going for it - my major concerns would be it not working (as is) with standard plone themes, nor (currently IIUC) with Plone 5, and it taking onboard technology which aren't mainstream in Plone (SCSS). "Needs work to be truely useful - and probably some performance testing"