Improvements to editor (write page, code pages)

Bloke · 2014-01-23 18:41:28

By Live Preview, do you mean complete front-end view, i.e. take the currently selected section, fetch the Page content and render it as if it was on the front page, but on the back-end? Or are we just talking article content without anything else? In which case, yes, custom fields aren’t going to render, nor is the excerpt, nor title so, ummm, what’s the point compared with hitting save and pressing refresh in another tab to see the content as the visitor sees it?

I compose content (articles, pages, forms) directly in Txp but plugins are developed offline and pasted in/uploaded using Plugin Composer. I hit CMD-S approximately once every thirty seconds, sometimes more, because I trust technology as far as I can spit it. So auto-uploading content to a remote server on save is a no go as that slows me down.

I also absolutely loathe syntax highlighters inside textareas. Slow slow slow slow. If I wanted to be penalised for writing in a textarea by having to wait for the DOM to load and the content to ‘jump’ and then to have it exert its stupid tabs-to-spaces rules and bad indenting then I’d rather go back to Notepad. And the less said about TinyMCE the better. Why anyone would want something as slow as that to design content is beyond me: you can’t even drop a single tag or any other markup inline without it wrapping paragraph markers round it. Argh!

By all means, as Sacripant says, let’s modularise the panels and make it simpler to shuffle things around to suit many different workflows, but forcing anything else on top in core is gonna slow things (ahem, me) down. I’d prefer to open up the Write panel more to plugin authors so this kind of custom functionality can be offered more easily. Or have I missed the point completely / am I too old and set in my ways to add value here? Maybe content creators really do like slow user interfaces and being forced to use third party tools just so they can employ version controll offline?

Fee free to shoot my arguments down — I’d love to find a better way to do things — but until I can find a system faster and more responsive than Save + refresh, or a syntax highlighter that doesn’t get in the way of the creation process, I’m gonna stick to lightweight and fast every time.

philwareham · 2014-01-23 18:46:49

Cool, thanks Stef. At least we are debating it now.

Maybe you’re right. Maybe I need to see how custom fields are going to work as well. I’ve refrained from doing too much on the UI until I can get my head round that.

In the meantime I can put the grid layout work into the system to ease all of this future stuff.

Bloke · 2014-01-23 18:58:13

Certainly don’t take my argument as a -1 for the idea. If we can do it in a way that is transparent and logical to the majority of users, then that’s brilliant. But otherwise I feel we’re going to hamstring the engine for not much real world gain, when a plugin solution would be more effective.

monkeyninja · 2014-01-23 22:18:26

Hi Phil,

Funny you should bring this topic up as I was only thinking about it the other night and was going to say something about it.

Personally I never use the textarea to write anything. I always tend to fire up my favourite text editor (Sublime at the moment), write something in there, then copy and paste it. In my experience I’ve found people generally hate working directly within the CMS to edit. Our clients are forever copying and pasting from Word, which can be a real pain if you’re using a WYSIWYG editor. So I suspect there is something really wrong with the way CMSs in general are handling this.

For me there are a couple of issues with the editor on Textpattern:-

The font sizes is very small so uncomfortable to work with
When I’m writing I like it to be as distraction-free as possible and fill the window (hence the use of a text editor)

I’m not all that bothered about a live preview when I’m working in Textile. I just want the focus of what I’m doing to be on writing the text.

I’ve always liked how Textpattern has felt focused on content, but the way it handles the writing of the content is beginning to feel dated and could be done better. I’m just not quite sure how best that could be done to satisfy all people.

philwareham · 2014-01-23 22:34:15

monkeyninja wrote #278414:

I’ve always liked how Textpattern has felt focused on content, but the way it handles the writing of the content is beginning to feel dated and could be done better. I’m just not quite sure how best that could be done to satisfy all people.

Exactly this.

I’ve played with a few live preview text demos today and I’m beginning to think they are pretty redundant in practice. But there also has to be ways to improvements to Textpattern’s editors (both code and text writing). Bumping the text size up on write page text fields is already in my plans (the UI font will stay at the current size though). The larger textarea (two thirds of page width) in general will also help I think.

Maybe that’s enough. It’s a start anyway.

jakob · 2014-01-23 22:43:19

I agree with lots of things in this thread starting with Phil’s initial sentiment of the need for a more comfortable writing-focused pane and I’d love to see that develop. Particularly like your idea of making it wider so it really is the focus – something I’ve done with several admin mods in the past. I also like the idea of lean and fast syntax highlighting both for code and for textile (like many of the markdown-based interfaces).

Otherwise, as sacripant and stef both mention, workflows vary so much depending on the kind of site that a live preview option can be great in some circumstances and useless in others. The current “preview” tab provides an idea of how the textile notation will be rendered, but because it’s still not the same as how the actual page looks like, most end users don’t really see the point. It just seems like a half-way house.

It also never helps for any non-standard site concept where an article doesn’t correspond exactly to an actual page. A complete front-end rendition, for example, could not possibly function in that case. In those cases, I hide both the “preview” tab and the “view” button because the latter shows a page that will never be reached in that form from the homepage.

Sacripant’s mention of admin side layout flexibility – re-arrangeable elements, image-upload to article, custom fields+types – is in my view more urgent, or perhaps rather part of the same problem. Aside from the actual site design, I probably spend most time trying to make it easy for the client to use their site so they actually use it properly instead of sending me their edits. I have no problem doing the edits for them, but clients invariably embrace using their site more if they use it themselves, and that’s when they take on a life of their own.

Maybe the preview pane (as live preview or extra view) could be:

a) optional
b) a re-arrangeable module in the write pane (like the other fields are with etc)
c) programmable (via a txp_form)
d) be than one of them if needed.

If the site designer was able to write a txp-form to determine how the article or snippet renders, he/she can include the article image or custom field as needed, and the problem of whether or not to process the entire page disappears. It can be as fully fledged or localised as the designer makes it. If you can have more than one, the designer could show a “list view” (live-)preview as well as a “full article” (live-)preview, for example showing what appears between the html <article> tags.

Alongside that, if the textile/markdown pane did syntax highlighting with the sort of pseudo-layout that a lot of the newer markdown editors à la editorially/typewrite.io that might provide writers with just enough visual cues to how textile works to obviate the need for what the current preview tab does.

philwareham · 2014-01-23 22:57:40

I am liking the Ace Editor a lot, it handles on-the-fly syntax highlighting of Textile, Markdown or any number of other languages – it’s also highly configurable regarding fonts, type sizes, etc. So thanks Sacripant for bringing it to my attention. I’d like to see what could be done with that in core.

The new custom fields are going to need some way of users placing and moving them around the write page, so that too needs investigation.

I don’t see how the current HTML and Preview tabs are going to work with all this. Maybe they’ll be removed. I also just hide those when doing client builds as they provide little, if any, benefit as to what their real page will look like.

GugUser · 2014-01-23 23:58:09

monkeyninja wrote #278414:

Our clients are forever copying and pasting from Word, which can be a real pain if you’re using a WYSIWYG editor. So I suspect there is something really wrong with the way CMSs in general are handling this.

As others have written, there are different points of view and ways of working. I for my part I don’t like working with Word and could reverse your sentence: “I suspect there is something really wrong with the way Word in general is handling this.”

;-)

I don’t have problems with edit text in the body textfield and I like Textile. I don’t need buttons for bold or italic etc. I like the cleanliness how Textile transforms the texts in HTML.

I don’t understand in this discussion whether it comes to change this conversion and at the end we will have a result like with the JS based hak_tinymce WYSIWYG article editor. I hope not.

Maybe I understand this discussion wrong.

philwareham · 2014-01-24 00:22:52

No, the last thing I want in Textpattern is a WYSIWYG. Something along the lines of rah_textilebar or MarkItUp would be acceptable though.

GugUser · 2014-01-24 01:15:18

That pleases me.

;-)

philwareham · 2014-01-24 12:39:38

Here’s another text editor option

etc · 2014-01-24 12:59:47

The only thing I miss on the admin side are txp tags… compose one’s own write panel, wouldn’t it be loverly?

Back to Earth, sir Trevor mangles lists and looks too wysiwyg, -1.

Textpattern CMS

Textpattern CMS support forum

#13 2014-01-23 18:41:28

Re: Improvements to editor (write page, code pages)

#14 2014-01-23 18:46:49

Re: Improvements to editor (write page, code pages)

#15 2014-01-23 18:58:13

Re: Improvements to editor (write page, code pages)

#16 2014-01-23 22:18:26

Re: Improvements to editor (write page, code pages)

#17 2014-01-23 22:34:15

Re: Improvements to editor (write page, code pages)

monkeyninja wrote #278414:

#18 2014-01-23 22:43:19

Re: Improvements to editor (write page, code pages)

#19 2014-01-23 22:57:40

Re: Improvements to editor (write page, code pages)

#20 2014-01-23 23:58:09

Re: Improvements to editor (write page, code pages)

monkeyninja wrote #278414:

#21 2014-01-24 00:22:52

Re: Improvements to editor (write page, code pages)

#22 2014-01-24 01:15:18

Re: Improvements to editor (write page, code pages)

#23 2014-01-24 12:39:38

Re: Improvements to editor (write page, code pages)

#24 2014-01-24 12:59:47

Re: Improvements to editor (write page, code pages)

Board footer