Vision for Kirby: Frontend editor

Kirby 2 Suggestions đź’ˇ
, ,
#1

Kirby is for me really the one and only CMS. Thanks to the blueprints scheme the panel is very wide customizable. Also: with great Plugins made by also great people like @DieserJonas and @distantnative it is really easy to use without fully compromizing the joy of use. With the concept of @timoetting’s free page format plugin Kirby is really just some steps away to enable fully customizable webpages. But that’s all you already know, I guess.

But there’s still a gap between what you’ve created and where you’re creating it. It’s like painting a portrait without seeing what you’re already painting (I really recommend Bret Victors talk “Inventing on Principle” for this principle). And that’s also some behavior I’ve observed while working with Kirby: you really want to have some kind of preview.

Before Kirby I’ve used WYSIWYG content management systems like concrete5 or gpEasy that were easy to use for my clients.

My vision is to have soon a Kirby version with the benefits of a fully customizable inline WYSIWYG editor combined with all the benefits Kirby brings to the developers and users.

All right, but what happens to the fields?

Yes, the blueprint fields are very important to standardize the content you will find on the web page. @timoetting’s builder shows how to declare and develop a standardized block format with an extended version of the structure field. Additionally it is still very important to have some kind of meta informations and additional data. So the panel fields should still be used to standardize content.

A simple example

If you think about a blogpost page, you would think about having some kind of meta informations, like the author and the date and one big area for the content, typically formatted in Markdown. So the vision for this example is to write the blogpost directly in your page - everything will adapt the style of the page. You can see directly how it looks like. You don’t need some kind of preview mode or anything else.

Is it possible?

Well that’s truly the main question behind everything. Yes it is (like almost everythink) but I don’t know how hard it is to bring the idea to life.

Some images

Here is a pic to visualize concrete5’s drag and drop block principle:

concrete5 isn’t really a WYSIWYG-Editor, but this is also good to show a solution for a more complex block:

gpEasy is truly an inline WYSIWYG editor (but the code is awful):

The good and the bad

Last but not least: it’s needles to say that it wouldn’t always be useful to have such sort of WYSIWYG inline editor so this should be something optional - like an alternative Panel. But I think this could be really an enhancement for the users, for the clients and also for the agencies and freelancers out there. And of course it would be another argument for choosing Kirby.

Alright. What do you think?

1 Like
Alternative Content Editor
#2

Yes it’s definitely true that visual CMS is the future, even Webflow is starting investing on it. Also Craft CMS has implemented visual functionality for editing…

In future versions Panel blueprints will be in .yaml or .json so there’s a good possibility to build blueprints directly from the Panel, a bit similar that Webhook does.

It might be a killer feature.

1 Like
#3

I don’t think that building blueprints from the Panel goes in the right direction, because defining content types and building custom templates is a task for the designer, not for the user.
What @servicethinker proposed is that users would be able to arrange and change a given set of content blocks on the page itself, not to define the content blocks themselves visually.

1 Like
#4

That’s what I mean. The page blueprint contains also important meta informations like the date, authors, tags, SEO descriptions and keywords and so on.

My vision is to declare an area at your site (like at gpEasy) in which the user can insert and edit predefined blocks and style his concept of his site - directly on the site. The designer has to design the blocks and every single element to achieve the best possible usability.

#5

It sound quite simple but in fact it’s really complex. That’s probably why many CMS creators have tried this and failed. It’s because it’s a mix of admin stuff and frontend stuff. The frontend alone can be complex, or the admin alone.

2011 or so I myself had that vision and worked hard to make it real. I failed big time.

In conclusion I think it’s much much harder than it looks and it’s not that useful that it looks. Spend 99% time to get 1% back, kind of.

3 Likes
#6

That’s what developers always saying. I think complaining about the possible or expecting workload for developers isn’t an contra argument for this kind of suggestion or vision ;-).

In my opinion this vision will be the next step, because having a preview mode or previewing the site in a different window is simply separating the content from it’s appereance.

#7

The huge difficulty with this is, that Kirby isn’t really defining the front-end. It might know what fields a page has from its blueprint, but from where will it take the information how on the front-end these fields should be composed to what elements that a visual editor would allow to add and edit?

#8

A frontend editor would also complicate theme development, raising the barrier to entry for new programmers. This would fuse two parts of Kirby together – themes and the panel.

One of the major benefits of Kirby is how everything is compartmentalized – this goes against that philosophy.

3 Likes
#9

Wysiwyg is very, very (very) hard to do well.
A big issue is that what you see is not what most people get: they have different browser features, display sizes, user stylesheets, and so on. Even if you could preview in a dozen different contexts, that would only be the tip of the iceberg. In-place editing doesn’t really solve this problem, it creates the false assumption that you control precisely how things will be rendered. It’s a red herring.

“Seeing what you are painting” is a good principle, but I’d like to put another important one in the balance: data has no color. What I mean is that if your web content is mainly structured text, it doesn’t matter a lot if the titles are grey or pink or set in the right font when you edit them, because this visual layer will be lost when your content is displayed in a feed reader, printed, viewed on a phone, or when you will eventually redesign the website. It’s form will change.

Still, it’s immensely helpful for editors to have at least an approximation of what the content will look like. I would argue that what they really need is not a very precise preview, but a way to make what they type predictable.
That’s why I love the visual editor by @DieserJonas: it uses Markdown, so it’s all about the structure but still gives visual cues. Not a preview (you could make it closer to the front end with some custom CSS though) but so much better than plain text.

5 Likes
#10

Yes, Kirby doesn’t know the frontend. One hard solution is that the Kirby panel maps the fields with the templates, so it automatically detects what you’re changing there. Look to the demo of gpEasy. In my opinion this is really well done (even when I hate the text formatting pane). Another solution is to make two visible modes to separate viewing and editing mode. But I hate modes - and users hate them, too. As @Malvese wrote:

That can be, but I agree with you that this shouldn’t be. I’m sure that it is possible that you can bring every complexity of this into the backend of the backend [1]. It will work for existing themes as for newer themes.

That’s awesome for developers. But is it also for those whose you’re building the site?

Really good point - and a hard one, too. It’s true: you would design the content for the device you’re looking at.

But there’s also another pitfall I haven’t thought of: why do you need a WYSIWYG editor when you can’t really change the font face, the color of the heading, the column width, inserting grid columns and rows? You only can set some basic text formatting which are predefined by the designer.

Both points are totally right (in my Opinion) but they’re from our sight. As I developed the projects with concrete5 and gpEasy, I still had to give some training to my customers. But they were very surprised how easy it was to simply change content by just clicking on what you want to change. So let me change the question we have to answer from the user’s view here first:

Why should the mechanism to input a value be different from the mechanism to output the value?
– from: About Face 4

The answer could be @malvese’s point: because it will be displayed differently on different devices. But should users have this fact in their mind while they’re adding end editing their content? I think this is mainly the designer’s job. I don’t even think that this will be a red herring because the users will be much more focused on the content and on the context of the site.

It is an alternative to the vision but you will still seeing some kind of such mantra:
saving the content, previewing it, going back to the content, changing it,
saving the content, previewing it, going back to the content, changing it,
saving the content, previewing it, going back to the content, changing it,
saving the content, previewing it, going back to the content, changing it,
saving the content, previewing it, going back to the content, changing it,
and so on [2].

That’s where you’re thinking about how you can make the life of your user much more easier. My vision is to have just one line mantra:
changing it, saving the content.

And that’s why I think making in-place editing (thanks for wording @Malvese) possible is also a possible vision for Kirby.

  1. I recommend Don Norman’s “Living with complexity” for some meta principles.
  2. Tribute to Ben Shneiderman’s “Visual Information Seeking Mantra”, from: “The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations”.
#11

Ok I understand a bit better what your vision is about. It’s really three things:

  • in-place editing ;
  • wysiwyg ;
  • layout editor.

They all can be implemented separately, or in any combination.
In-place + wysiwyg can already be done with editors like [CKEditor][1] or [Aloha Editor][2] (click the “Try it” button), but then every instance of the editor is for one single field. Not what you talked about.

If I understand correctly, what’s missing for you in @timoetting’s plugin is a way to not only re-order blocks, but also the ability for editors to change the page layout: I want this image here on the left, with text on the right, split this in two columns, and so on…
That sounds close to [Squarespace’ site editor (video)][3], which integrates the three concepts in one interface, but the guy in the linked video complains that there are difference between “live mode” and “preview mode” (around 11:40). His issue is actually about responsive design, and the same point I made earlier.
I don’t think being able to do this in the front-end instead would solve the problem: it’s difficult to predict what it will look like in different sizes or contexts…

My opinion is that design decisions like a page layout are usually better handled by designers/site builders, and the editors should focus on the content. I’d rather give them a few great layouts I created to choose from, than give them the tools to create a million possibly weak variations.
There are of course exceptions, I’ve had clients who were happy to get their hands dirty with design or technical things, but most of the times they’re happy to just enter the content without hassle.
[1]: http://ckeditor.com/demo#inline
[2]: http://www.alohaeditor.org/
[3]: https://youtu.be/QXY7AY4RcTg?t=8m30s

#12

In-place editing and WYSIWYG
CKEditor and Aloha Editor is really that kind of in-place editing I would prefer (I would rather use kind of kirby-wysiwyg plugin for formatting options). Imagine both would using markdown that will be dynamically styled like in the markdown editor by @DieserJonas - that’s what I would prefer and what I’m calling “WYSIWYG in-place editor” in Kirby-style.

Layout editor
In my opinion it’s quite simple: the plugin by @timoetting defines which area of the site are changeable by adding, editing or deleting content blocks. But everything is happening in-place so the user sees directly what’s changing and how a block looks like. The blocks were predefined and preformatted by the designer so the user just have to choose the right block and fill it with markdown-formatted content. That ensures that everything the user does will look good.

I totally agree that the page layout should better handled by those who knows every single circumstances. That’s our job to know those and design the layout as perfect as it has to be. My vision is much more about a front-end in-place editor that will be predefined by the designer using blueprints. The designer has to define the areas and blocks that will be edited and used by the user. So the designer still decides how much is changeable on the site. But the change itself happens in-place.

I hope that makes it all a little clearer.

1 Like
#13

I’m impressed with this user experience: http://early-access.notion.so/

Could definitely be some lessons learned for any visual editor plugin.

Create from an assortment of building blocks: to-dos, files, videos, code snippets, and more. Notion helps you work the way you think.

Arrange your page any way you like — your work will always look its best. We take care of design so you can focus on content.

#14

That’s really interesting, thanks! Even if this goes far beyond what I mean: it shows clearly that it could work. Now imagine you have a predefined area on your frontend that you can edit like this if you’re logged in. Sometimes you just can write the text, sometimes you can drag new blocks into it.

#15

This discussion is fantastic and I love all your points :slight_smile:

There are indeed separate parts of the problem here:

WYSIWYG Text editors
They would always be a vital part of the “frontend” content editing process and I think we all agree that there’s not a single usable editor out there so far. There are many interesting approaches coming up at the moment though. A friend of mine is working on https://beta.frontkit.io/ which looks extremely promising. Prosemirror is another one that separates WYSIWYG editing from the generated code: http://prosemirror.net/ But in my opinion it will still take a bit until one of them will be completely ready and easy to integerate.

Frontend editing
As you already pointed out it’s extremely difficult to combine a good frontend editor with any possible theme. You would always need to introduce some restrictions in order to make it work or the number of possible problems and bugs would be endless. I agree that the coding effort should not necessarily determine if something should or should not be done, but it’s more a question of stability and maintainability here. Nobody wins if the solution is buggy as hell or breaks with every new theme.

There’s another issue here. I’m a big believer in a clear separation of data and display. I come from a background of building websites for more than 14 years. For years, before the rise of the mobile web, the data for a site and the display were very tightly coupled. You would build for one medium: a desktop browser. The only variable was a very limited number of screen sizes and resolutions. But in my opinion with the rising focus on content and the multiple devices and screen sizes we have to build for today, we should put all our effort into a very clear separation of content and design as far as that is possible. As a designer I definitely don’t mean that the design should be done without considering the content, but that the content should be flexible enough to fit into multiple designs. Karen McGrane has given a fantastic talk about this at beyond tellerrand last year on how we need to structure our content in order to make it available for any upcoming medium or device. The best case szenario in my opinion is that the CMS becomes a single source for content for a company and that content can be used for a website, a mobile app, a watch app, a bus stop ad display, imported into indesign for a brochure, etc. etc. That means that there has to be a very well designed underlying structure for each type of content. That’s exactly what I try with blueprints. The more well defined fields, the better. Karen describes WYSIWYG output as very similar to a PDF. She calls it a blob. A huge container where you just dump crap into and you can never get it out again in a usable way. That has to be avoided at all cost.

But I also agree that there are often use cases where users need to partly design longer text and combine it with quotes, videos, images, etc. and plugins like @timoetting’s blocks field are the way to go here if you ask me. The process of creating content is very playful for users and the result is still super structured.

I think in the end it’s all about providing better fields in combination with a better preview mode. If you ever used the new Swift Playground tool in XCode, that’s exactly what I have in mind. You have your form on the left and you can make changes there, which instantly get displayed in a live preview on the right. That way the live preview can be anything and it doesn’t matter how the code for the frontend looks. I already have some plans for it and I hope I can start working on it soon.

So those were my quite long 50cent :slight_smile:

7 Likes
Unofficial Kirby 2.2 features
Unofficial Kirby 2.2 features
#16

I fully agree. The content absolutely needs to be clean and maintainable.

I think that a preview mode could be a great solution, but the question is how to make sure that the preview is in sync with the content but not generated on the server for every single keypress either. Maybe that needs some kind of markers in the templates to tell the Panel which piece of content gets inserted where and how?

1 Like
#17

There are some other issues we need to handle, because a lot of CMSs nowadays use some kind of postprocessing on the content, take SmartyPants (which is part of kirby) for example. It turns straight quotes into curly quotes and can do some other tasks as well.

If we care about beautiful and interesting layouts, we need tools like those to provide decent typography. We can convert straight quotes on-the-fly using JavaScript in a frontend editor, but what about more advanced features? Take PHP Typography for example, which also adds some <span> tags for styling your content and provides hyphenation by adding &shy; characters were applicable. This is getting so complex, that doing text transformations like PHP Typography does are very hard to integrate into an WYSIWYG-editor. You also really don’t want to have all those special characters like zero-width spaces and shy hyphens in the source of your content.

I know, that not everyone needs PHP Typography, but I think there are other examples, where postprocessing plays an important role. So what solutions do we have?

  1. Drop server-side processing of the content entirely and handle everything from curly quotes to dashes and hyphenation in the editor using JavaScript. The pitfalls: It needs a very advanced editor and also server-side checks to make sure that the code of the content is valid. Also, your might contain a lot of strange characters.
  2. Use a WYSIWYG-Editor in the frontend and do post-processing after the user has finished editing. This is not 100% WYSIWYG, but in most cases, body copy does not look to different from the output without hyphenation, curly quotes and correct dashes.
  3. Edit blocks of (text) content in a modal (some frontend editors handle it that way), but is this still true frontend editing? Maybe not, but it by far the most flexible approach, because it also allows us to use markdown for writing. This forum is a great example of how it can be done. By moving the editor to the bottom of the page and providing a live preview. For content management, this preview could be integrated above the editor right into the block of text, you are editing. Another big advantage of the approach is, that the editor’s modal can also be used for settings, metadata and behavior of a content block which will not be visible on the final page.

Which approach would you prefer?

#18

I don’t get the hype about. Frontend editing is clumsy. If you’ve a 27" imac, you may’ve enough space left to work with. People tend to make sure their page looks good on their computer then, add some space there, resize images, trying to set every pixel exactly. They forget about other devices – much more if they see their changes in real time.

1 Like
#19

Wow! BTW: Thanks for every single answer of you all! You’re awesome and I really appreciate this discussion. :+1:

Okay, forget about the WYSIWYG Editor. I’ve used the wrong term to name it. As I wrote:

So I personally would prefer an editor like the markdown editor by @DieserJonas. It’s sort of WYSIWYG but it’s also still a real markdown editor. An editor in which you can’t see which markdown commands you’ve used is way too complex on both sides: on code and on usability.

I like the idea having a preview beside of the content.

Or alternatively like the Ghost Blog Web-App.

Yes, that’s true. That’s also what I love on Kirby as a developer. And that’s also something I wrote down somewhere in this thread: in my opinion this has to be optional because the panel has to fit the workflow of the person who is adding, filling and editing the content and also to the use case - not vice versa. But in simply one use case it can be the perfect one: the use case of filling, editing or adding content on a website. And I guess this is the use case of about 80% of Kirby projects.

But I have to say this is the view of us designers and developers. And I totally agree that separating the content of it’s appearance is really important to have a clean and reusable content. But that doesn’t matter for a user who is just building blocks and writing text for his own or for his company’s webpage. It’s irrelevant for the user what’s happening under the hood.

Could you explain why a frontend editor or a preview is clumsy if “people tend to make sure their page looks good on their computer”? I assume that it doesn’t matter if people have a separate window, a preview beside of the content or a frontend editor: they will always tend to make sure their page looks good. So this suggestion is simply about making the preview thing as easy and as good as possible.

#20

Don’t make the developer work the asses off

If the preview requires extra stuff to the template, or the blueprint for the preview to work, then it adds extra load on the developer every time a site is built. Those kind of features can easily break because some backend JS + some frontend JS has to work together.

Preview split-screen idea

I wrote an idea for the panel-bar plugin made by @distantnative

Preview in the making

It’s already in the making. The screenshot part is really buggy + hackish and I would not recommend anyone to use it at this stage. The panel-bar at master branch is stable and awesome, but not the preview yet.

This is how it works: It works with iframes, one for backend and one for frontend. It feels when the submit button is clicked and updates the frontend to the right when saved. That way there are no dependences at all, no extra work for the developer. That part I really like.

https://github.com/distantnative/panel-bar/tree/feature/preview

Preview in the panel

@bastianallgeier I would love to have a preview in the panel, just have this stuff in mind:

  • Make sure it has an URL so we can link to it from outside the panel.
  • Don’t make the developer work their asses off by modifing the template / blueprint just to make it work. It can turn into a bloat-mess, frustration. It will probably also add a lot of unknown issues for the Kirby crew because it can be a huge project to develop if taking it that way. (my opinion)
  • If updating an iframe, try to get rid of the blink-effect. I don’t mind the delay, but the blink makes me blink. When I blink I lose focus and when I lose focus I can’t get anything done. The issue probably depends on that the JS and CSS links are removed and added again. I don’t have a solution for it.