An omnivore's perspective
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Roeland, Paul
In my 25 years of developing, designing, and maintaining websites both on a technical and content level for a wide range of organisations, I've used an even wider range of tools. And to this day, I use a good dozen different systems besides Plone. Some of these make me very happy, some drive me crazy. All of them have lessons to be learned. Especially when you don't just deliver websites, but also maintain them for a couple of years. An opinionated view on where we can learn, what we should stop doing, and how choices play out. Including but not limited to: • why WYSIWYG editing might have to go, in favor of simpler formats combined with integration, • simplicity and beauty deliver real value, in terms of training and maintenance costs, • "mobile first" has consequences. We should embrace it fully, • our core market is longer-term, higher volume content. Make that easier to maintain, find, present, repurpose, • smart integration beats own innovation, • oh heck, forms. We need to do better.
 Yeah, this I will give a warning, will contain some gifs as usual in my talks and also some opinions. So just so you know. Yeah, the Omnivore perspective, what do I mean with that? Well, first a little bit about me. I work for a non-profit. I have worked and I still advise quite a few of other non-profits and in the course of that I tend to work with a lot of systems. I also work with Plone a lot. I have worked with Plone from version 0.99 and have always enjoyed it. But it's always good to see what you can learn from the others. So what do you mean by Omnivore? Well, indeed, lots of systems and in contrary to maybe a majority view who are consultants or developers who prepare a site, what I do is actually build and maintain a site. Quite often I also have to do some of the development because we never have money. But I also get to keep them. So if I break them, I get to keep them. And I have to revive them if they go down and after their useful life, I have to find a nice place for them. And the average lifetime of my sites are far exceeding three years, even though they always promise me, no, no, no, no, no, after a year this can be shut down and then it never can. So usually some sites have content that is over 12 years old or even older. So that gives you usually a different perspective on how to actually work with a site instead of like delivering a shiny new one and then saying, hi, have fun with it and walk away. The experience is different. So what do I mean by systems? Well, some that I use are quite familiar and a thing called Plone. Quave, which is the Plone Internet distribution, social internet, which is different but still quite familiar to Plone. But also I viewed WordPress. I'm actively using Drupal, both seven and eight, which are like completely different systems, even though there's only a slight version number behind it. But also Wagtail, some of you might know that that's a Python Django based system. There's a Python in which is kind of similar but also some that maybe people do not know, such as Ghost. Ghost is a blogging platform that is run on Node.js. I use PageKit, which is more of like a static site builder. Sulu, which is a full-blown CMS, which actually does multi-lingual write, which is quite rare to see outside of Plone. So that's a good one. But also I've used Graph, which is a flat file database or CMS, and Ugo, which is a static site generator. And those were just the sort of CMSs. I also have to deal quite a lot with even more systems, like CIFI CRM. CIFI CRM is basically a system to keep addresses and to mail them and to stay in contact with them. It's very much used by the nonprofit world. Those of us who can't afford or are not legally allowed to use all kinds of cloud services tend to use CIFI CRM. I like it a lot, but it also has its quirks. I'm using MailChimp, which is developing more and more into a user interface builder of its own. And Odo, which also has various modules that allow you to build sites, but also has a very sometimes peculiar way of looking at user interface and user experience. So if you use these other ones, and there's a few more, but these are the ones I've used in the last 12 months alone. So that's what I mean by a lot of systems. So if you try to summarize that, you always end up with things that, well, when you look at basically the competition, some of it is like really good. You're like, why don't we have it? Well, there's reasons why they can be good. They have no ballast, most of them. Some of them do like Drupal, but some of the newer ones, like Ghost, has no ballast. They just wrote it like one and a half year ago, so there's no need for backwards compatibility. So they could start fresh while learning from others. So that's always good. What would people do if they would start writing a CMS now and would not be bothered by what went on in the past? You can also see a lot of trends that I like. Some of the trends that I like is that design is getting simpler and simpler, that people have finally gotten in their minds that there is such a thing as mobiles and that there's actually quite a few of them, and that it would be really good to start designing for them first, foremost, but not exclusively. And some of them keep really good practice in terms of testing, in terms of being able to develop, in terms of being able to move a system from your laptop to staging to production with relative ease. So those are things that are really good. It's always good to have good, but as usual, when you have good, you'll have bad. And bad comes with various shapes and forms. The first, which is my opinion of bad, it may not be your opinion of bad, but quite a few of them are very developer-centric and consultant-ware. That mainly goes for instance, Wagtail and Metxinine. If you don't have an in-house developer, there's not a lot you can do with it. So anytime you need a change, you will have to phone up a company and spend a lot of money. That is of course really good if you're a company and you get those phone calls and you make money. It's not so good if you're a non-profit and you don't have a lot of money. So to me, that is something that I don't like. I have always liked the fact that once I get a blown site, there's quite a lot of power in my hands and only for the really difficult stuff, I need to hire somebody. And these are going back to like, well, you basically need either a service contract or a bunch of money. What's also bad, some of the other ones are simple. I would almost call it brochureware. You can create a site which has 10 pages perfect with it. It looks amazing. It's like responsive and then they have like 10 different themes who all look great as long as you don't have more than 20 pages on them. If you start filling up a site, you have like 20 people whose main job in life it is every day to write articles. And you look again after a year, their user interface and also their outward interface doesn't look all that pretty anymore. So for like a brochureware site or a very simple action site, it kind of works. But for your main site, for a university or a larger NGO, maybe not. So the question, and I know this has been beaten to death and probably everybody who says it should be sort of maltreated, but does it scale really is a good question. You can kill any discussion in IT with this, just randomly drop it. But sometimes you have to ask that question, does it scale? How does the system will perform in five years when I've had 300 content items per year? And we've survived three reorganization rounds where we renamed all our departments and now the site structure should reflect that. So that was the bad and then there's also the really ugly. You put your hopes up and you're like, yes, this is going to be really good. But unfortunately, some of the worst ideas resurface. Anybody will remember inline editing? We had it once in Plone and it looked great when you gave a demonstration. And if your life consists of like maintaining a site, you actively hate it because every time you click somewhere, cursors pop up and then the catwalks on your keyboard and things have changed while you did not mean it. It's just not handy. Other things that were really stupid, sometimes you ask yourself, like these people that design these systems, they don't really work for real life organizations. There were some systems where it was like, yeah, once you publish it, you can't change the URL. You know, like honestly, I do about two organizational restructurings per year. Departments get changed, our campaign name changes, and the URL should reflect that. And also I need to move large areas of content from one part of my site to the other side. Anybody that approaches it like once you publish it, there it stays. Honestly, that's not how real life works. And quite a few of them are also one way street or as I call it, a data grave. Anything that doesn't come with an export function now carries a big flashing warning sign for me. It's okay if the export is very geeky and technical. You don't need to do it every day, but I need to make sure that I can do better than just a curl or a WGAT image of the whole site. I need the data. And as, yeah, you sometimes can notice quite painfully, security is usually an afterthought. Nowadays, people do realize that there's something you should be doing, but you can sort of see like the first design, the system, and then they're like, oh, shit, security. Let's try to fix this. It's not ingrained in the design. So coming back from a lot of other systems, there's also a lot what I learned that Plone has that is really awesome. And sometimes it's really good to realize that. Placeful. You have no idea how useful the idea of placeful content is. Folders with stuff in them. That means you can find things again. That means you can also take a whole folder and put it somewhere else underneath another folder. Anything that has sort of a flat structure and then maintains its own navigation on it, it's okay for, again, about 20 pages, about 30 if you're really good at keeping track, do it for a couple of thousands and you go nuts. So the fact that we have placeful content, we've always had it, is a real boon for site maintainers who have to maintain their sites a long time. And sometimes I think we do not appreciate that fact enough. That was one genius idea and really it saved my life a lot of times. We also have collections. Yes, collections. Collections are so great for organizing content. You can get them out of the folders where you put them and make new pretend folders so you can show things on different parts of the site. They're awesome. I want more of those. I'll get back to that later. What kind of collections I think we should enhance because they're a really cool feature and we need better ones. So more collections. Yeah. Workflow. Almost none of the competing system have anywhere near our level of workflow. That's just unrivaled. The ease which you can set it up. The ease which it runs. The clarity in it really is a good feature. And content rules. Who of you are using content rules? The rest of you are missing out. Put content rules on your sites. They can alert you to all kinds of content problems. They can do all kinds of maintenance for you. They're awesome. And they are not available in most of the other systems. It's really a cool feature. So what I think, having seen a lot of the other systems and the other systems do have their uses, but what I think is clones happy place. We all need our happy place. And what I think is clones happy place in terms of content management is for long term content. Plone is really good for sites that you plan to keep or are supposed to keep for years and years and years. If it's a throw away site for an action, it's overkill. But if it's like your university site, your NGO site, where you have to keep the content over years, it's really good because you can shift it around. You can reuse it, reshuffle it. You also, to really appreciate clone, you have to have skilled editors. I don't think we should ever compete with the, I'm not prepared to spend more than five minutes learning a system crowd. That's just not the market that we should be aiming for. They don't need to be full time content editors, but they do need to be, to at least spend like half an hour to learn what to do. Anything else I think is, yeah, you're aiming for the wrong crowd and you're, first of all, you're probably making it so simple that your power users are going to hate you because they can't do what they want to do. Clone also need a commitment from your organization because, yeah, it is a heavy system, so you need an organization that will stay and that doesn't change the whole policy whenever a new director comes in. That kind of helps. And also, we should really trust and empower our power users. They are usually your best advocates once they get to know the system. And they can say, like, no, we really like the system whenever there's like internal politics going on about getting something else. Your power users are your ambassadors. So this is what Clone's happy place should be according to me. Don't listen to me, but this is what I'm saying. I'm going forward with where I think Clone could improve. And not so much in a really concrete way. I'm going to do that at the end of the talk. But first of all, in the way we approach content management as a whole. As a site administrator or as an administrator or as a power editor, what you really should be thinking of yourself, I think we're getting too much bogged down quite often in details in your daily work. And what you really should make a mental picture is that you should try to be a captain. You're a captain and you want to get things done. Captain Janeway always said, there's coffee in that nebula. Take us there. She didn't say, put the navigation onto 7.894 clicks and then put the thruster on three and then start up the engine and do that. She just said, make it so. And others start doing that. And that should be your role if you're in charge of a large site. You should say, this is what I want to achieve. And please take care of all the boring details for me in the best way possible. We have trains, staff members and crew members on board. They know what to do, but I will not be bored with all the small little details. Please just take care of those. One example for that is, I think it's ridiculous that in this day and age, I should be the one that sets images. They're sort of like how they should appear. I mean, Castle does that right. You set a focal point and you're sort of like, yeah, the rest, figure it out. I shouldn't be setting aspect ratios and crap like that. There's computers that do that for me. I'm the captain. I want it to appear good and you make it look good. If you're not into the whole hero and captain rhetoric, you can also think of yourself as a villain. Because also as a villain, you do the same thing. Let's say you want a really nice fur coat and you need like 101 Dalmatians or things like that. You're not going to run after the little critters yourself. You hire people to get the little Dalmatians and you hire somebody else to make the fur coat. So if you don't believe in the hero, believe in the villain stuff. But the attitude is the same. You say what you want and you hire people or machines or automations to do it as best as possible. And that's what I think clones role should be. And yes, that means I just compared to a million. A clone should be my minion and it should do what I want. I shouldn't have to fight it. I just have to tell it what it does and it should aim to make me happy. That's the attitude that I want, that I expect from my content management system. So I'm going to delve a little bit more on content life. Because as said, I have to work with sites that keep their content for a while. So what is the average life cycle of a piece of content? 20% of its time is spent writing outside of the CMS. No CMS involved whatsoever. We can fight forever on what is the best editor for writing content. Trust me, we don't write content in our CMS. Maybe one day we will, but currently we don't. And by outside, I mean by email, by Word files, by Google Docs. Because usually more people in more continents have to work on it. So it usually starts its life way outside of your content management system. Because sometimes it originates from outside your organization. They write the first draft and then other people look at it. So that's just how it goes. Then you spend about 5% of actually getting it into the CMS. And then 75% of its lifetime is spent rearranging it, editing it, reusing, refer to it, tag it, move it, archive it. So content management is much more important over the life cycle than the content creation. We should also look at the content creation. But the management side is where you either hate or love your system. That's where you're going to spend most of your time. And that's where the irritation factor comes up when you can't quickly move things in the way that you want. If you can't tag 15 articles at the same time and you have to do 28 clicks to do that, that becomes annoying. If it's the greatest, shiniest, new editor, I'm like, yeah, okay. But I want those power functions to do a lot of management at the same time. Furthermore, I want to dive a little bit on what I consider content types. And don't think of them as dexterity or archetypes, but content types, the different types of content that I deal with in my head. First is text and image. I treat them the same as this is like an article. It's like what traditionally in the old side structure would be the middle part of the page. That consists of text images, maybe even a video, but that's sort of like the actual contenty content. And that can be in the form of five different dexterity types. I don't care. It's still, to me, text and images. The other thing is embeds. Embeds are a fact of life. They may have security issues. Then we have to deal with the security issues. But nowadays there is no site that I know of that doesn't use YouTube, Twitter feeds, and others. You need embeds. And trying to make that difficult for people to use is just going to piss them off. The other part is what I call snippets and results. Snippets and results are portlets, navigation, footers. Next three items. Last three things bought by people just like you, and we would like you to buy more. All those kinds of extra things that normally appear on various sites of the actual content. So, yeah, they should be in place. You should have them. They're very useful. And the last what you need, not necessarily that much on the public side, but on the inside, is Office and PDF files. Office and PDF is a tough one because people expect an office file to look like an office file. So I really think we should be moving forward into integrating some of that. There are ways to do that now. There is something called only office, which you can relatively easy integrate. And yeah, there's thinking going on how that could be done. That's mainly relevant for insights. But basically it's your own version of Google Docs but run on your own infrastructure with simultaneous editing. And you don't have to put it in the evil clouds somewhere in countries that don't respect privacy laws. So that's, but it is a requirement because I have tried now for the past, I think, 18 years to explain to my end users who are quite often in Asia the difference between an office file and an internet HTML file document. People don't get it. It's a document. And why does the one open in this editor and the other in the editor? They have no clue whatsoever and that's never going to change. So if you have, if you use internet, you should think about how you can integrate a solution that will look sort of like Google Docs, act sort of like Google Docs to make it easier. Another difficult one that we're dealing with is composite pages. It is a really hard problem. I mean, we've, within Plone, we've had so many attempts. Currently we're sort of the best of the bunch is Mosaic, but we had like, well, I'm not going to name them all. We had like, I don't know, five, six, seven attempts at least. All of them didn't install for various reasons on various of my old sites. But composite pages are a reality and they are needed. So we need to figure out how to do that best. And Mosaic is pretty good on the way, but I think it could be better, namely also in remembering to be a captain. Because even in Mosaic, I still have to decide on a stupid grid how wide everything is. And then I have to compare sort of by hand how the grid would fold on a tablet or on a phone or on a really cheap phone. Whereas actually what I want to do is want to say like, this has the highest priority. Always display this little tile as best as possible. This, well, whenever you have some room left. This on a phone, just drop it, I don't care. So I want to give directions, but not be as specific as saying like, you are going to take three out of the 12 columns. It's like details, minions, fix this for me. I don't need to be doing this. So I want to be able to define what, what did you do? And not exactly how it is done. And also preferably I would like to write more or less a recipe. That's why the baking analogy where I say like, this is super important, less important. Yeah, could be fun if you have the screen real estate. That would work also in two years time when we have, we all have like 8K resolution mega screens in our living room. And otherwise we're having like little glasses with little things in there. So I don't have to change that recipe and change all my layouts whenever a new display technology or a new few port size comes along. That's what I would like. So for that we're going to need smarter minions. So one other thing that is an unfortunate fact of life, if you work a lot in universities or nonprofits are subsides. Subsides are far more common than you think. The people want like little subsides for the launch of an action, the start of the new year, something like that. To me they should just consist of a folder, a composite page and a theme. Nothing more or a theme variation. They should have a limited navigation. And if that needs to be handmade, that's good enough for me. I don't need all the power of a full blonde CMS for a subside. Because if my subside is too big, you're probably doing it wrong and it shouldn't be a subside. It should be its own site. Trust me on this one, if you go subsides and they grow so big that they have their own editors and their own, well their own editor is fine, but if you have like multiple editors or you need to hook another LBAP, directory in it, just make a new site, please. So limited subsides would be plenty for me. Yeah, and it would be good to have that as a function within Plown to say like, okay, this is a subside, here's a few tools and that's what you get. And don't make it more complicated than that. Next one, this one I call the great illusion. The great illusion is busywig. The acronym is horrible to begin with, but who of you knows what it stands for? What you see is what you get. Well, I propose to take this away and replace this with the following handy acronym. And I think Rostfarer Day can tell me if this is something really offensive in Welsh. It could very well be, in that case, apologies. It stands for what I see is most likely not what you will get. The whole idea of busywig is completely outdated in these days of wildly divergent viewports. So stop pretending that you will get a busywig because you won't. Anybody, like 99% of people will see a slightly different site than you are designing or editing. So why not look at how others are doing it? Well, for instance, Ghosts and Graph and quite a few others that have grown up in the past couple of years say, like, here's a markdown editor. We'll make it a nice markdown editor. And we'll give you previews and a button for links and images and stuff. And people are fine with that. I have inexperienced editors editing my ghost sites and they're like, oh, yeah, markdown. Yeah, really easy. No problem. So yeah, people are actually fine with it. And the fact that it's so limited is actually a strength. So it comes with a preview. So you have some idea of what they're doing and they come with easy and bad. So they just paste the raw HTML as YouTube or Vimeo gives it and you're done. Easy peasy. Great. And because it is indeed limited, but they also don't get tempted to paste in weird HTML constructs or mess with the styling. So I think we should literally just give up on this idea of what you see is what you get and say, like, okay, we should do what I mean is what you will get. And stop assuming how things should look. Left column. We're still using that in Plum 5. And I'm like, really? You have no idea where my Azure recipe is going to put it. You have no idea where my responsive rules are going to put it. It's probably not going to be left in most of the cases. And if my language happens to be written in the other direction, it's just, it's not a useful distinction. So do that with a recipe that says, like, important core content aside, another aside, even less important aside, only really if you have enough space for it. And stop assuming that things will appear left and right because they probably won't for most of your users. So be the director again. Be the director, not the person actually placing things carefully and then finding out that all your careful placement is not working because somebody with an $80 tablet in Bangladesh is trying to look at it. And their screen resolution is 640 by 480. What I really want is to set the priority. I want to set a display hint like make this super wide, make this as wide as you can, make it half of what you have, and that's fine. And I want to specify an alternative like, well, if the screen really is too small, just do text only. Or even better, if the connection speed is so small, just drop all the images. I'm not sure if that's technically feasible, but that would be ideal. Another thing where I think we can and should improve our forms. And forms are an unfortunate fact of life. All our shit. There is no nicer way of putting this. I think you can say shit these days because there's an emoji, and with emojis everything is allowed. So basically all form frameworks are shit. But what really hurts if the developer tools are not in sync with what you give the site admin tools, then the ones that are supposed to be for the site administrator usually bid rot. They don't get as much attention. All the developers' attention goes onto the shiny new stuff that the developers get to use, whereas you as an end user or as a site editor get a second hand nobody cares anymore implementation with crappy widgets, and yeah, it's just not nice anymore. So if you do that, that's one of the advantages of most of the Drupal-based CMSs. They tend to use the same widgets and drop-downs that they use for the admin interface and for the development stuff, also for the site administrator. That keeps it in sync. But now you can already see we have Plone Forum Gen, but honestly I don't know a single developer who still use archetypes and nobody's going to maintain those widgets. So we should move to Easy Forum because that uses the dexterity type so you get an equal chance to get the good stuff. And yeah, for forums, focus on how it looks on the end user. Forums need to look good to the end user, and by the end user I mean the site visitor. Sometimes I get the feeling we spend too much time on making the building of a forum look pretty, and usually I don't like that, and it doesn't always work. Plone Forum Gen where you can drag and drop new fields, I hate it. Usually the dragging and dropping doesn't work, and I tend to just do the action menu and add it from the time. So designing a forum is not something you do every day. Maybe every week, maybe every month, maybe every three months, and it's okay, it'll be a skilled editor that does that. So it's fine if that's a geeky interface. Don't spend any time on dragging, dropping fields. No need for it, or fancy drop down buttons for the options. I'm a site admin, if you just give me a text box where I can list the options, I'm happy. I don't need the fancy stuff there. Make the fancy stuff on the forum, say, make it so that it's easy to become a forum that has two columns or three columns, or automatically those columns even better. So the end forum should look awesome. The making of it, honestly, I don't care, and my editors also don't care. They know what they're doing, and it's fine if that's a bit clunky and a bit 1990s. We don't care. What should we do with the system setup? Well, first of all, it should be repeatable. Containers, they're here to stay. I'm not going to say which technology will be victorious in the Docker, Rocket, whatever wars, but they'll be here to stay. And that means maybe we can simplify things also by saying, well, this is how you should deploy, and this is what we're going to teach you, and this is what we're going to show in the documentation. If you want to do it otherwise, be my guest, but you're on your own. You see it, for instance, Ghost just says you need to have a virtual machine that does this. It needs to have Ubuntu, it needs to have one gig, and from there on, we'll take it. If you want to do it somewhere else, your problem. I think that's fine. So there should be one obvious way. Well, maybe two or three. We probably need DevTools and the Windows solution, but yeah, they're getting easier. But maybe we should stop supporting all the different deployment strategies out there in the world. If you have a highly specialized deployment strategy, you probably know what you're doing anyway, and you can contribute to keeping the documentation updated. Configuration. Always a dangerous thing to do. Readability really counts. Again, fancy interfaces for configuration. I don't care. Readability. Because I do this once every three months. I need to go into the site setup. I do it on a daily basis, and I go into various different systems, so I want it to be readable, but it doesn't have to be pretty. Things that I would like to be able to do through the web. I would like an emergency theming override. I don't want to do theming through the web, but I want an override. In other words, I want my custom CSS back, because you will always end up being somewhere else when you need to do that one final tweak on the CSS. So I want a custom CSS that is editable through the web for emergency things, which I will fix at a later point. Honestly, trust me, I will do this. But yeah, I want that. I would also love vocabulary and maybe also language files to be editable through the web, because sometimes the Plone Supply vocabulary or language is just not in line with what we use as an organization. It uses the formal tone, whereas we use the informal tone. So I would like to be able to change the language strings through the web, because I don't want to do that. My marketing people want to do that, and they don't want to do that on the file system, because they have no clue what a file system is. And maybe some templates, but I could be persuaded that that's a bad idea. Still, sometimes it's really handy to try something out on the fly. I don't want to do JavaScript through the web. I've learned my lessons. It's just not working. I want to do it on my local machine, and then I want to zip upload it. Nowadays, anybody who does JavaScript without a web pack or whatever is the newest thing without a SES or less compiler, you're crazy. You should stop doing that, and we should just... Honestly, I don't want to do it. And I was always the big proponent of through the web, but the whole JavaScript tool chain is so geared towards compiling and shaking and doing things, downloading the internet while they're at it, doing it on your local dev machine, and then uploading it as a zip is perfectly fine. Don't reinvent wheels. I'll give you one example, which is, yeah, it's actually one of the core functionalities of a competing system. Well, it's a sister system, CVCRM, where they have reinvented the wheel, I think, about eight times for one of the hardest problems in computing. What are the hardest problems in computing? Well, everybody knows. Cash invalidation and naming things, and often one errors. But actually, there is one more difficult problem, and that is writing responsive emails. For those of you that haven't done it, trust me. We're talking tables here for layouts. It's a nightmare. What is CVCRM's core business, writing emails? What did they do? They outsourced it. In the end, they gave up. They were like, we're not reinventing the wheel anymore. We're integrating the best solution out there, which is moseeco.io, which is an open source framework. And they were like, we should get over this inverse not invented here syndrome, where we need to, we try to invent everything again ourselves. This is so hard, just integrate it. So really, some problems we shouldn't be solving ourselves. The integration is the way forward, and then everybody is much, much happier. Some other random opinions I want to send. REST versus graph. For reasons I will quickly go to. But REST and graph QL are not the same. They have different purposes. One is really good at getting lots of information. The other one is really good at getting the minimal set of information. And both are extremely useful if Plone wants to be a team player. So it would be really great if we could have both. So quickly go through my user facing wish list. I say drop tiny mce and get a markdown or plus raw HTML editor with some previews and a nice select widgets. And we're done. This might be contemptuous. Tiles. I love tiles. Mosaic, it kind of works, but I would love more like a layout recipe, whereas as I said, this is how it, this is the importance, the relative importance of things, and you figure out to make it look nice. I want embed to make easy. Really, the way to piss people off is to make it difficult. And if that is a security problem, we should find better ways of dealing with that. But saying, no, you're not allowed to, it's not going to fly. What do we want more? I always want more. I want smart media handling. As said, I don't want to be setting aspect ratios on images. Sorry. Computers were invented to do stupid work for me. I want more consistency in the UI, but I mean, I've seen Pasta Naga in action and I'm a fan, so I'm hoping that will simplify and make things much more consistent. And I want cleverer collections. All those people doing AI, can we please get a collection that says the most relevant, relevant other content items on your site are these, not the last published, not the, but the most relevant ones. That would be awesome. Please. And a few of those that, yeah, that do act, that actually act on the content and give you real added value. That will be super, super awesome and a really defining factor for Plone and a selling point as well. So having cleverer conditions on collections that can reason for themselves and basically be your clever minion. I would plan to be a team player. Plone will never be my only website. So I want import and import as core or as close as core as possible. And adjacent dump is good enough, but I want that security. As said, I would like a rest and a GraphQL because with GraphQL, I can get the minimum amount of data from my Plone site in my action site, which is a static site. But I need like three content items from my Plone in there. And I don't want the whole thing. I just want to slice and dice and GraphQL is much better at it. It gets less data, which means it will also work in Bangladesh. I want office integration when needed. And if you tell me, well, then you have to do this and this and this and you have to do a Docker container with only office, fine. But yeah, it would be really great for insights. And yeah, security is always hard, but hey, we're very good at it, better than the rest. So that should be a challenge and not a stopper. And for the system, readability. Can we just move from XML to YAML? XML or JSON. JSON is also unreadable. I'm really sorry. If need be, just transform it into a YAML for display purposes, but I mean, typing in a JSON file by hand is like cruel and unusual punishment. Any comma, comma, wrong and everything breaks. And it's very unreadable. It's just too much visual clutter. There's like things everywhere that are not content like brackets and commas and stuff. It's really annoying if you look at it like three months later and you're like, where is the actual setting? I first have to go through all this visual clutter. I think we should just drop the whole thing where you could have multiple clones on a soap. I mean, containers. Could we simplify our logic by just saying you can only have one clone site per soap and if you want more clone sites, fire up another container or another thing. It probably simplifies a lot and it's always got to be called clone in the URL where you can skip a lot of those things. A command line interface will be awesome. I like Drush. I even like Ghost. Ghost has a command line interface which is even better. The Ghost one actually configures NGINX for me. It gets a Latsangript certificate and it does upgrade. Awesome! I'm not sure how realistic it is, but having a command line interface to do basic maintenance, great! What do I want more? I would totally want round trip configuration. If I configure a site through the WIPE settings, I want a great big export button that I can then apply to another container and oops, it's there. We sort of have it, but it's hard to find and we should make that a bit more prominent. And I said function triumphs over form for power users. Don't waste too much time in making admin interfaces look pretty. They should be functional. And power users are not afraid to use a drop-down menu by hand and not everything has to be draggable and swipeable and whatever, not for the admin interface, not needed. Do it for the end user. There it is important. And please warn me when updates are needed. Don't install them for me because that burns you, but we do need the warning thing, like he, your clone is outdated, he, this add-on is outdated. It should be configurable that you can set it to off. I don't think we should have web downloadable updates because of security, but the warning, yes please. I know there's work being done on that, so that's... But I'm just... I'm making a wish list. I can make wishes here. So make it so. Now I'm going to be the captain. Maybe you totally disagree. That's fine. Come talk to me and we can fight over it or not. No, I hope it's just starting up a discussion and give some ideas because some of the ideas that other sites have, or other systems have are really good. But we do also have our strengths, but I really am deeply, deeply partial to clone. I love it and I think we can make it so much better. Thank you. Thank you.
 Yeah, this I will give a warning, will contain some gifs as usual in my talks and also some  opinions. So just so you know. Yeah, the Omnivore perspective, what do I mean with that? Well,  first a little bit about me. I work for a non-profit. I have worked and I still advise quite a few  of other non-profits and in the course of that I tend to work with a lot of systems. I also work  with Plone a lot. I have worked with Plone from version 0.99 and have always enjoyed it. But it's  always good to see what you can learn from the others. So what do you mean by Omnivore? Well,  indeed, lots of systems and in contrary to maybe a majority view who are consultants or developers  who prepare a site, what I do is actually build and maintain a site. Quite often I also have to do  some of the development because we never have money. But I also get to keep them. So if I break them,  I get to keep them. And I have to revive them if they go down and after their useful life, I have to  find a nice place for them. And the average lifetime of my sites are far exceeding three years,  even though they always promise me, no, no, no, no, no, after a year this can be shut down and then  it never can. So usually some sites have content that is over 12 years old or even older. So that  gives you usually a different perspective on how to actually work with a site instead of like delivering  a shiny new one and then saying, hi, have fun with it and walk away. The experience is different.  So what do I mean by systems? Well, some that I use are quite familiar and a thing called Plone.  Quave, which is the Plone Internet distribution, social internet, which is different but still quite  familiar to Plone. But also I viewed WordPress. I'm actively using Drupal, both seven and eight,  which are like completely different systems, even though there's only a slight version number behind it.  But also Wagtail, some of you might know that that's a Python Django based system. There's  a Python in which is kind of similar but also some that maybe people do not know, such as Ghost.  Ghost is a blogging platform that is run on Node.js. I use PageKit, which is more of like  a static site builder. Sulu, which is a full-blown CMS, which actually does multi-lingual write,  which is quite rare to see outside of Plone. So that's a good one. But also I've used Graph,  which is a flat file database or CMS, and Ugo, which is a static site generator. And those were just  the sort of CMSs. I also have to deal quite a lot with even more systems, like CIFI CRM.  CIFI CRM is basically a system to keep addresses and to mail them and to stay in contact with them.  It's very much used by the nonprofit world. Those of us who can't afford or are not legally allowed to use  all kinds of cloud services tend to use CIFI CRM. I like it a lot, but it also has its quirks.  I'm using MailChimp, which is developing more and more into a user interface builder of its own.  And Odo, which also has various modules that allow you to build sites, but also has a very sometimes  peculiar way of looking at user interface and user experience. So if you use these other ones,  and there's a few more, but these are the ones I've used in the last 12 months alone.  So that's what I mean by a lot of systems. So if you try to summarize that, you always end up with things  that, well, when you look at basically the competition, some of it is like really good.  You're like, why don't we have it? Well, there's reasons why they can be good.  They have no ballast, most of them. Some of them do like Drupal, but some of the newer ones, like Ghost,  has no ballast. They just wrote it like one and a half year ago, so there's no need for backwards compatibility.  So they could start fresh while learning from others. So that's always good.  What would people do if they would start writing a CMS now and would not be bothered by what went on in the past?  You can also see a lot of trends that I like. Some of the trends that I like is that design is getting simpler and simpler,  that people have finally gotten in their minds that there is such a thing as mobiles and that there's actually quite a few of them,  and that it would be really good to start designing for them first, foremost, but not exclusively.  And some of them keep really good practice in terms of testing, in terms of being able to develop,  in terms of being able to move a system from your laptop to staging to production with relative ease.  So those are things that are really good. It's always good to have good, but as usual, when you have good, you'll have bad.  And bad comes with various shapes and forms. The first, which is my opinion of bad, it may not be your opinion of bad,  but quite a few of them are very developer-centric and consultant-ware. That mainly goes for instance, Wagtail and Metxinine.  If you don't have an in-house developer, there's not a lot you can do with it. So anytime you need a change, you will have to phone up a company  and spend a lot of money. That is of course really good if you're a company and you get those phone calls and you make money.  It's not so good if you're a non-profit and you don't have a lot of money. So to me, that is something that I don't like.  I have always liked the fact that once I get a blown site, there's quite a lot of power in my hands and only for the really difficult stuff,  I need to hire somebody. And these are going back to like, well, you basically need either a service contract or a bunch of money.  What's also bad, some of the other ones are simple. I would almost call it brochureware.  You can create a site which has 10 pages perfect with it. It looks amazing. It's like responsive and then they have like 10 different themes  who all look great as long as you don't have more than 20 pages on them.  If you start filling up a site, you have like 20 people whose main job in life it is every day to write articles.  And you look again after a year, their user interface and also their outward interface doesn't look all that pretty anymore.  So for like a brochureware site or a very simple action site, it kind of works.  But for your main site, for a university or a larger NGO, maybe not.  So the question, and I know this has been beaten to death and probably everybody who says it should be sort of maltreated,  but does it scale really is a good question. You can kill any discussion in IT with this, just randomly drop it.  But sometimes you have to ask that question, does it scale? How does the system will perform in five years when I've had 300 content items per year?  And we've survived three reorganization rounds where we renamed all our departments and now the site structure should reflect that.  So that was the bad and then there's also the really ugly. You put your hopes up and you're like, yes, this is going to be really good.  But unfortunately, some of the worst ideas resurface.  Anybody will remember inline editing? We had it once in Plone and it looked great when you gave a demonstration.  And if your life consists of like maintaining a site, you actively hate it because every time you click somewhere,  cursors pop up and then the catwalks on your keyboard and things have changed while you did not mean it.  It's just not handy. Other things that were really stupid, sometimes you ask yourself,  like these people that design these systems, they don't really work for real life organizations.  There were some systems where it was like, yeah, once you publish it, you can't change the URL.  You know, like honestly, I do about two organizational restructurings per year. Departments get changed, our campaign name changes,  and the URL should reflect that. And also I need to move large areas of content from one part of my site to the other side.  Anybody that approaches it like once you publish it, there it stays. Honestly, that's not how real life works.  And quite a few of them are also one way street or as I call it, a data grave.  Anything that doesn't come with an export function now carries a big flashing warning sign for me.  It's okay if the export is very geeky and technical. You don't need to do it every day, but I need to make sure that I can do better  than just a curl or a WGAT image of the whole site. I need the data.  And as, yeah, you sometimes can notice quite painfully, security is usually an afterthought.  Nowadays, people do realize that there's something you should be doing, but you can sort of see like the first design, the system,  and then they're like, oh, shit, security. Let's try to fix this. It's not ingrained in the design.  So coming back from a lot of other systems, there's also a lot what I learned that Plone has that is really awesome.  And sometimes it's really good to realize that.  Placeful. You have no idea how useful the idea of placeful content is.  Folders with stuff in them. That means you can find things again.  That means you can also take a whole folder and put it somewhere else underneath another folder.  Anything that has sort of a flat structure and then maintains its own navigation on it, it's okay for, again, about 20 pages,  about 30 if you're really good at keeping track, do it for a couple of thousands and you go nuts.  So the fact that we have placeful content, we've always had it, is a real boon for site maintainers who have to maintain their sites  a long time. And sometimes I think we do not appreciate that fact enough.  That was one genius idea and really it saved my life a lot of times.  We also have collections. Yes, collections. Collections are so great for organizing content.  You can get them out of the folders where you put them and make new pretend folders so you can show things on different parts of the site.  They're awesome. I want more of those. I'll get back to that later.  What kind of collections I think we should enhance because they're a really cool feature and we need better ones.  So more collections. Yeah. Workflow. Almost none of the competing system have anywhere near our level of workflow.  That's just unrivaled. The ease which you can set it up. The ease which it runs.  The clarity in it really is a good feature.  And content rules. Who of you are using content rules?  The rest of you are missing out. Put content rules on your sites.  They can alert you to all kinds of content problems. They can do all kinds of maintenance for you. They're awesome.  And they are not available in most of the other systems. It's really a cool feature.  So what I think, having seen a lot of the other systems and the other systems do have their uses,  but what I think is clones happy place. We all need our happy place.  And what I think is clones happy place in terms of content management is for long term content.  Plone is really good for sites that you plan to keep or are supposed to keep for years and years and years.  If it's a throw away site for an action, it's overkill. But if it's like your university site, your NGO site,  where you have to keep the content over years, it's really good because you can shift it around.  You can reuse it, reshuffle it. You also, to really appreciate clone, you have to have skilled editors.  I don't think we should ever compete with the, I'm not prepared to spend more than five minutes learning a system crowd.  That's just not the market that we should be aiming for.  They don't need to be full time content editors, but they do need to be, to at least spend like half an hour to learn what to do.  Anything else I think is, yeah, you're aiming for the wrong crowd and you're, first of all, you're probably making it so simple  that your power users are going to hate you because they can't do what they want to do.  Clone also need a commitment from your organization because, yeah, it is a heavy system, so you need an organization that will stay  and that doesn't change the whole policy whenever a new director comes in. That kind of helps.  And also, we should really trust and empower our power users.  They are usually your best advocates once they get to know the system.  And they can say, like, no, we really like the system whenever there's like internal politics going on about getting something else.  Your power users are your ambassadors.  So this is what Clone's happy place should be according to me.  Don't listen to me, but this is what I'm saying.  I'm going forward with where I think Clone could improve.  And not so much in a really concrete way. I'm going to do that at the end of the talk.  But first of all, in the way we approach content management as a whole.  As a site administrator or as an administrator or as a power editor, what you really should be thinking of yourself,  I think we're getting too much bogged down quite often in details in your daily work.  And what you really should make a mental picture is that you should try to be a captain.  You're a captain and you want to get things done.  Captain Janeway always said, there's coffee in that nebula. Take us there.  She didn't say, put the navigation onto 7.894 clicks and then put the thruster on three and then start up the engine and do that.  She just said, make it so. And others start doing that.  And that should be your role if you're in charge of a large site.  You should say, this is what I want to achieve.  And please take care of all the boring details for me in the best way possible.  We have trains, staff members and crew members on board.  They know what to do, but I will not be bored with all the small little details.  Please just take care of those.  One example for that is, I think it's ridiculous that in this day and age, I should be the one that sets images.  They're sort of like how they should appear. I mean, Castle does that right.  You set a focal point and you're sort of like, yeah, the rest, figure it out.  I shouldn't be setting aspect ratios and crap like that.  There's computers that do that for me.  I'm the captain. I want it to appear good and you make it look good.  If you're not into the whole hero and captain rhetoric, you can also think of yourself as a villain.  Because also as a villain, you do the same thing.  Let's say you want a really nice fur coat and you need like 101 Dalmatians or things like that.  You're not going to run after the little critters yourself.  You hire people to get the little Dalmatians and you hire somebody else to make the fur coat.  So if you don't believe in the hero, believe in the villain stuff.  But the attitude is the same.  You say what you want and you hire people or machines or automations to do it as best as possible.  And that's what I think clones role should be.  And yes, that means I just compared to a million.  A clone should be my minion and it should do what I want.  I shouldn't have to fight it.  I just have to tell it what it does and it should aim to make me happy.  That's the attitude that I want, that I expect from my content management system.  So I'm going to delve a little bit more on content life.  Because as said, I have to work with sites that keep their content for a while.  So what is the average life cycle of a piece of content?  20% of its time is spent writing outside of the CMS.  No CMS involved whatsoever.  We can fight forever on what is the best editor for writing content.  Trust me, we don't write content in our CMS.  Maybe one day we will, but currently we don't.  And by outside, I mean by email, by Word files, by Google Docs.  Because usually more people in more continents have to work on it.  So it usually starts its life way outside of your content management system.  Because sometimes it originates from outside your organization.  They write the first draft and then other people look at it.  So that's just how it goes.  Then you spend about 5% of actually getting it into the CMS.  And then 75% of its lifetime is spent rearranging it, editing it, reusing, refer to it,  tag it, move it, archive it.  So content management is much more important over the life cycle than the content creation.  We should also look at the content creation.  But the management side is where you either hate or love your system.  That's where you're going to spend most of your time.  And that's where the irritation factor comes up when you can't quickly move things in the way that you want.  If you can't tag 15 articles at the same time and you have to do 28 clicks to do that,  that becomes annoying.  If it's the greatest, shiniest, new editor, I'm like, yeah, okay.  But I want those power functions to do a lot of management at the same time.  Furthermore, I want to dive a little bit on what I consider content types.  And don't think of them as dexterity or archetypes,  but content types, the different types of content that I deal with in my head.  First is text and image.  I treat them the same as this is like an article.  It's like what traditionally in the old side structure would be the middle part of the page.  That consists of text images, maybe even a video,  but that's sort of like the actual contenty content.  And that can be in the form of five different dexterity types.  I don't care. It's still, to me, text and images.  The other thing is embeds.  Embeds are a fact of life.  They may have security issues.  Then we have to deal with the security issues.  But nowadays there is no site that I know of that doesn't use YouTube, Twitter feeds, and others.  You need embeds.  And trying to make that difficult for people to use is just going to piss them off.  The other part is what I call snippets and results.  Snippets and results are portlets, navigation, footers.  Next three items.  Last three things bought by people just like you, and we would like you to buy more.  All those kinds of extra things that normally appear on various sites of the actual content.  So, yeah, they should be in place. You should have them.  They're very useful.  And the last what you need, not necessarily that much on the public side,  but on the inside, is Office and PDF files.  Office and PDF is a tough one because people expect an office file to look like an office file.  So I really think we should be moving forward into integrating some of that.  There are ways to do that now.  There is something called only office, which you can relatively easy integrate.  And yeah, there's thinking going on how that could be done.  That's mainly relevant for insights.  But basically it's your own version of Google Docs but run on your own infrastructure  with simultaneous editing.  And you don't have to put it in the evil clouds somewhere in countries that don't respect privacy laws.  So that's, but it is a requirement because I have tried now for the past, I think, 18 years  to explain to my end users who are quite often in Asia the difference between an office file  and an internet HTML file document.  People don't get it.  It's a document.  And why does the one open in this editor and the other in the editor?  They have no clue whatsoever and that's never going to change.  So if you have, if you use internet, you should think about how you can integrate a solution  that will look sort of like Google Docs, act sort of like Google Docs to make it easier.  Another difficult one that we're dealing with is composite pages.  It is a really hard problem.  I mean, we've, within Plone, we've had so many attempts.  Currently we're sort of the best of the bunch is Mosaic, but we had like, well, I'm not going to name them all.  We had like, I don't know, five, six, seven attempts at least.  All of them didn't install for various reasons on various of my old sites.  But composite pages are a reality and they are needed.  So we need to figure out how to do that best.  And Mosaic is pretty good on the way, but I think it could be better,  namely also in remembering to be a captain.  Because even in Mosaic, I still have to decide on a stupid grid how wide everything is.  And then I have to compare sort of by hand how the grid would fold on a tablet or on a phone  or on a really cheap phone.  Whereas actually what I want to do is want to say like, this has the highest priority.  Always display this little tile as best as possible.  This, well, whenever you have some room left.  This on a phone, just drop it, I don't care.  So I want to give directions, but not be as specific as saying like,  you are going to take three out of the 12 columns.  It's like details, minions, fix this for me.  I don't need to be doing this.  So I want to be able to define what, what did you do?  And not exactly how it is done.  And also preferably I would like to write more or less a recipe.  That's why the baking analogy where I say like, this is super important, less important.  Yeah, could be fun if you have the screen real estate.  That would work also in two years time when we have, we all have like 8K resolution mega screens in our living room.  And otherwise we're having like little glasses with little things in there.  So I don't have to change that recipe and change all my layouts whenever a new display technology  or a new few port size comes along.  That's what I would like.  So for that we're going to need smarter minions.  So one other thing that is an unfortunate fact of life, if you work a lot in universities or nonprofits are subsides.  Subsides are far more common than you think.  The people want like little subsides for the launch of an action, the start of the new year, something like that.  To me they should just consist of a folder, a composite page and a theme.  Nothing more or a theme variation.  They should have a limited navigation.  And if that needs to be handmade, that's good enough for me.  I don't need all the power of a full blonde CMS for a subside.  Because if my subside is too big, you're probably doing it wrong and it shouldn't be a subside.  It should be its own site.  Trust me on this one, if you go subsides and they grow so big that they have their own editors and their own,  well their own editor is fine, but if you have like multiple editors or you need to hook another LBAP,  directory in it, just make a new site, please.  So limited subsides would be plenty for me.  Yeah, and it would be good to have that as a function within Plown to say like,  okay, this is a subside, here's a few tools and that's what you get.  And don't make it more complicated than that.  Next one, this one I call the great illusion.  The great illusion is busywig.  The acronym is horrible to begin with, but who of you knows what it stands for?  What you see is what you get.  Well, I propose to take this away and replace this with the following handy acronym.  And I think Rostfarer Day can tell me if this is something really offensive in Welsh.  It could very well be, in that case, apologies.  It stands for what I see is most likely not what you will get.  The whole idea of busywig is completely outdated in these days of wildly divergent viewports.  So stop pretending that you will get a busywig because you won't.  Anybody, like 99% of people will see a slightly different site than you are designing or editing.  So why not look at how others are doing it?  Well, for instance, Ghosts and Graph and quite a few others that have grown up in the past couple of years say,  like, here's a markdown editor.  We'll make it a nice markdown editor.  And we'll give you previews and a button for links and images and stuff.  And people are fine with that.  I have inexperienced editors editing my ghost sites and they're like, oh, yeah, markdown.  Yeah, really easy. No problem.  So yeah, people are actually fine with it.  And the fact that it's so limited is actually a strength.  So it comes with a preview.  So you have some idea of what they're doing and they come with easy and bad.  So they just paste the raw HTML as YouTube or Vimeo gives it and you're done.  Easy peasy. Great.  And because it is indeed limited, but they also don't get tempted to paste in weird HTML constructs or mess with the styling.  So I think we should literally just give up on this idea of what you see is what you get and say, like, okay,  we should do what I mean is what you will get.  And stop assuming how things should look.  Left column.  We're still using that in Plum 5.  And I'm like, really?  You have no idea where my Azure recipe is going to put it.  You have no idea where my responsive rules are going to put it.  It's probably not going to be left in most of the cases.  And if my language happens to be written in the other direction, it's just, it's not a useful distinction.  So do that with a recipe that says, like, important core content aside, another aside, even less important aside,  only really if you have enough space for it.  And stop assuming that things will appear left and right because they probably won't for most of your users.  So be the director again.  Be the director, not the person actually placing things carefully and then finding out that all your careful placement is not working  because somebody with an $80 tablet in Bangladesh is trying to look at it.  And their screen resolution is 640 by 480.  What I really want is to set the priority. I want to set a display hint like make this super wide,  make this as wide as you can, make it half of what you have, and that's fine.  And I want to specify an alternative like, well, if the screen really is too small, just do text only.  Or even better, if the connection speed is so small, just drop all the images.  I'm not sure if that's technically feasible, but that would be ideal.  Another thing where I think we can and should improve our forms.  And forms are an unfortunate fact of life.  All our shit.  There is no nicer way of putting this.  I think you can say shit these days because there's an emoji, and with emojis everything is allowed.  So basically all form frameworks are shit.  But what really hurts if the developer tools are not in sync with what you give the site admin tools,  then the ones that are supposed to be for the site administrator usually bid rot.  They don't get as much attention.  All the developers' attention goes onto the shiny new stuff that the developers get to use,  whereas you as an end user or as a site editor get a second hand nobody cares anymore implementation  with crappy widgets, and yeah, it's just not nice anymore.  So if you do that, that's one of the advantages of most of the Drupal-based CMSs.  They tend to use the same widgets and drop-downs that they use for the admin interface  and for the development stuff, also for the site administrator.  That keeps it in sync.  But now you can already see we have Plone Forum Gen,  but honestly I don't know a single developer who still use archetypes  and nobody's going to maintain those widgets.  So we should move to Easy Forum because that uses the dexterity type so you get an equal chance to get the good stuff.  And yeah, for forums, focus on how it looks on the end user.  Forums need to look good to the end user,  and by the end user I mean the site visitor.  Sometimes I get the feeling we spend too much time on making the building of a forum look pretty,  and usually I don't like that, and it doesn't always work.  Plone Forum Gen where you can drag and drop new fields, I hate it.  Usually the dragging and dropping doesn't work,  and I tend to just do the action menu and add it from the time.  So designing a forum is not something you do every day.  Maybe every week, maybe every month, maybe every three months,  and it's okay, it'll be a skilled editor that does that.  So it's fine if that's a geeky interface.  Don't spend any time on dragging, dropping fields.  No need for it, or fancy drop down buttons for the options.  I'm a site admin, if you just give me a text box where I can list the options, I'm happy.  I don't need the fancy stuff there.  Make the fancy stuff on the forum, say, make it so that it's easy to become a forum  that has two columns or three columns, or automatically those columns even better.  So the end forum should look awesome.  The making of it, honestly, I don't care, and my editors also don't care.  They know what they're doing, and it's fine if that's a bit clunky and a bit 1990s.  We don't care.  What should we do with the system setup?  Well, first of all, it should be repeatable.  Containers, they're here to stay.  I'm not going to say which technology will be victorious in the Docker, Rocket, whatever wars,  but they'll be here to stay.  And that means maybe we can simplify things also by saying,  well, this is how you should deploy, and this is what we're going to teach you,  and this is what we're going to show in the documentation.  If you want to do it otherwise, be my guest, but you're on your own.  You see it, for instance, Ghost just says you need to have a virtual machine that does this.  It needs to have Ubuntu, it needs to have one gig, and from there on, we'll take it.  If you want to do it somewhere else, your problem.  I think that's fine.  So there should be one obvious way.  Well, maybe two or three.  We probably need DevTools and the Windows solution, but yeah, they're getting easier.  But maybe we should stop supporting all the different deployment strategies out there in the world.  If you have a highly specialized deployment strategy, you probably know what you're doing anyway,  and you can contribute to keeping the documentation updated.  Configuration.  Always a dangerous thing to do.  Readability really counts.  Again, fancy interfaces for configuration.  I don't care. Readability.  Because I do this once every three months.  I need to go into the site setup.  I do it on a daily basis, and I go into various different systems,  so I want it to be readable, but it doesn't have to be pretty.  Things that I would like to be able to do through the web.  I would like an emergency theming override.  I don't want to do theming through the web, but I want an override.  In other words, I want my custom CSS back,  because you will always end up being somewhere else when you need to do that one final tweak on the CSS.  So I want a custom CSS that is editable through the web for emergency things,  which I will fix at a later point.  Honestly, trust me, I will do this.  But yeah, I want that.  I would also love vocabulary and maybe also language files to be editable through the web,  because sometimes the Plone Supply vocabulary or language is just not in line with what we use as an organization.  It uses the formal tone, whereas we use the informal tone.  So I would like to be able to change the language strings through the web,  because I don't want to do that.  My marketing people want to do that, and they don't want to do that on the file system,  because they have no clue what a file system is.  And maybe some templates, but I could be persuaded that that's a bad idea.  Still, sometimes it's really handy to try something out on the fly.  I don't want to do JavaScript through the web.  I've learned my lessons. It's just not working.  I want to do it on my local machine, and then I want to zip upload it.  Nowadays, anybody who does JavaScript without a web pack or whatever is the newest thing  without a SES or less compiler, you're crazy.  You should stop doing that, and we should just...  Honestly, I don't want to do it.  And I was always the big proponent of through the web,  but the whole JavaScript tool chain is so geared towards compiling and shaking and doing things,  downloading the internet while they're at it, doing it on your local dev machine,  and then uploading it as a zip is perfectly fine.  Don't reinvent wheels.  I'll give you one example, which is, yeah, it's actually one of the core functionalities  of a competing system.  Well, it's a sister system, CVCRM, where they have reinvented the wheel, I think,  about eight times for one of the hardest problems in computing.  What are the hardest problems in computing?  Well, everybody knows.  Cash invalidation and naming things, and often one errors.  But actually, there is one more difficult problem, and that is writing responsive emails.  For those of you that haven't done it, trust me.  We're talking tables here for layouts.  It's a nightmare.  What is CVCRM's core business, writing emails?  What did they do?  They outsourced it.  In the end, they gave up.  They were like, we're not reinventing the wheel anymore.  We're integrating the best solution out there, which is moseeco.io, which is an open source framework.  And they were like, we should get over this inverse not invented here syndrome, where we need to,  we try to invent everything again ourselves.  This is so hard, just integrate it.  So really, some problems we shouldn't be solving ourselves.  The integration is the way forward, and then everybody is much, much happier.  Some other random opinions I want to send.  REST versus graph.  For reasons I will quickly go to.  But REST and graph QL are not the same.  They have different purposes.  One is really good at getting lots of information.  The other one is really good at getting the minimal set of information.  And both are extremely useful if Plone wants to be a team player.  So it would be really great if we could have both.  So quickly go through my user facing wish list.  I say drop tiny mce and get a markdown or plus raw HTML editor with some previews and a nice select widgets.  And we're done.  This might be contemptuous.  Tiles. I love tiles.  Mosaic, it kind of works, but I would love more like a layout recipe, whereas as I said,  this is how it, this is the importance, the relative importance of things,  and you figure out to make it look nice.  I want embed to make easy.  Really, the way to piss people off is to make it difficult.  And if that is a security problem, we should find better ways of dealing with that.  But saying, no, you're not allowed to, it's not going to fly.  What do we want more?  I always want more.  I want smart media handling.  As said, I don't want to be setting aspect ratios on images.  Sorry.  Computers were invented to do stupid work for me.  I want more consistency in the UI, but I mean,  I've seen Pasta Naga in action and I'm a fan, so I'm hoping that will simplify  and make things much more consistent.  And I want cleverer collections.  All those people doing AI, can we please get a collection that says the most relevant,  relevant other content items on your site are these, not the last published,  not the, but the most relevant ones.  That would be awesome.  Please.  And a few of those that, yeah, that do act, that actually act on the content  and give you real added value.  That will be super, super awesome and a really defining factor for Plone  and a selling point as well.  So having cleverer conditions on collections that can reason for themselves  and basically be your clever minion.  I would plan to be a team player.  Plone will never be my only website.  So I want import and import as core or as close as core as possible.  And adjacent dump is good enough, but I want that security.  As said, I would like a rest and a GraphQL because with GraphQL,  I can get the minimum amount of data from my Plone site in my action site,  which is a static site.  But I need like three content items from my Plone in there.  And I don't want the whole thing.  I just want to slice and dice and GraphQL is much better at it.  It gets less data, which means it will also work in Bangladesh.  I want office integration when needed.  And if you tell me, well, then you have to do this and this and this  and you have to do a Docker container with only office, fine.  But yeah, it would be really great for insights.  And yeah, security is always hard, but hey, we're very good at it,  better than the rest.  So that should be a challenge and not a stopper.  And for the system, readability.  Can we just move from XML to YAML?  XML or JSON.  JSON is also unreadable. I'm really sorry.  If need be, just transform it into a YAML for display purposes,  but I mean, typing in a JSON file by hand is like cruel and unusual punishment.  Any comma, comma, wrong and everything breaks.  And it's very unreadable.  It's just too much visual clutter.  There's like things everywhere that are not content like brackets and commas and stuff.  It's really annoying if you look at it like three months later and you're like,  where is the actual setting?  I first have to go through all this visual clutter.  I think we should just drop the whole thing where you could have multiple clones on a soap.  I mean, containers.  Could we simplify our logic by just saying you can only have one clone site per soap  and if you want more clone sites, fire up another container or another thing.  It probably simplifies a lot and it's always got to be called clone in the URL  where you can skip a lot of those things.  A command line interface will be awesome.  I like Drush.  I even like Ghost.  Ghost has a command line interface which is even better.  The Ghost one actually configures NGINX for me.  It gets a Latsangript certificate and it does upgrade.  Awesome!  I'm not sure how realistic it is,  but having a command line interface to do basic maintenance,  great!  What do I want more?  I would totally want round trip configuration.  If I configure a site through the WIPE settings,  I want a great big export button that I can then apply to another container  and oops, it's there.  We sort of have it, but it's hard to find  and we should make that a bit more prominent.  And I said function triumphs over form for power users.  Don't waste too much time in making admin interfaces look pretty.  They should be functional.  And power users are not afraid to use a drop-down menu by hand  and not everything has to be draggable and swipeable  and whatever, not for the admin interface, not needed.  Do it for the end user.  There it is important.  And please warn me when updates are needed.  Don't install them for me because that burns you,  but we do need the warning thing, like he, your clone is outdated,  he, this add-on is outdated.  It should be configurable that you can set it to off.  I don't think we should have web downloadable updates  because of security, but the warning, yes please.  I know there's work being done on that, so that's...  But I'm just... I'm making a wish list.  I can make wishes here.  So make it so.  Now I'm going to be the captain.  Maybe you totally disagree.  That's fine.  Come talk to me and we can fight over it or not.  No, I hope it's just starting up a discussion and give some ideas  because some of the ideas that other sites have,  or other systems have are really good.  But we do also have our strengths,  but I really am deeply, deeply partial to clone.  I love it and I think we can make it so much better.  Thank you.  Thank you.
Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_0_119.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_120_251.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_252_1355.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_1356_3167.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_3168_7043.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_7044_13259.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_13260_24923.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_24924_27035.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_27036_29099.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_29100_31607.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_31608_41195.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_41196_45239.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_45240_47315.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_47316_55187.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55188_55271.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55272_55355.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55356_55403.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55404_55547.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55548_55607.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55608_55715.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55716_55811.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55812_55895.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55896_55955.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_55956_56051.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56052_56123.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56124_56183.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56184_56255.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56256_56351.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56352_56459.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56460_56519.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56520_56591.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56592_56675.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56676_56747.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56748_56807.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56808_56891.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56892_56951.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_56952_56999.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_57000_57047.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_57048_57119.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_57120_57215.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_57216_57263.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_57264_61487.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_61488_62195.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_62196_63623.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_63624_63731.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_63732_63851.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_63852_63911.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_63912_65951.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_65952_67847.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_67848_69503.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_69504_72191.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_72192_72767.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_72768_72827.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_72828_72887.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_72888_72947.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_72948_73247.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_73248_73307.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_73308_74111.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_74112_75203.png Day_1__Paul_Roeland_-_An_omnivore_s_perspective_DdSziZBm8rc_75204_75325.png