Improvements to editor (write page, code pages)

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.

philwareham · 2014-01-24 13:06:45

OK, thanks etc.

I think the way forward is for me to put the new grid layout in place, then provide some static HTML mockups for discussion on how we can move forward (taking into account that the write tab layout and elements need to be customisable for users).

etc · 2014-01-24 13:32:43

I’m very limited UI-speaking, sorry, but still:

modern browsers handle resize and draggable attributes, so the grid could be dynamic;
we could test some element-wise improvements(?), like inputs growing up and centered on focus;
separate live textile preview is preferable (for me) to direct input enhancements (wysiwyg, syntax highlight, …)

And thanks for your hard work!

sacripant · 2014-01-24 13:35:48

For a light improvment of Pages and Forms tab, Behave.js is very interesting :

it’s very light.
Result is allways a textarea. Just improve textarea typing. It’s perhaps important because some users use “It’s all text” for open textarea content in text editor.
It add
- Hard and Soft Tabs
- Auto Open/Close Parenthesis, Brackets, Braces, Double and Single Quotes
- Auto delete a paired character
- Overwrite a paired character
- Multi-line Indentation/Unindentation
- Automatic Indentation

And it’s possible to extend possibility with Hooks

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

I’m talking about exactly the same idea in 2009 in french forum

etc · 2014-01-24 13:55:01

sacripant wrote #278436:

I’m talking about exactly the same idea in 2009 in french forum

Stef has written the great smd_tabber, but the road is still long.

philwareham · 2014-01-24 14:11:00

Yep, Behave.js looks like it could work, too. Lots of suggestions coming in, keep them coming!

monkeyninja · 2014-01-24 19:03:26

After a bit more thought I’ve realised another thing that bugs me about working directly from within Textpattern (and other CMSs) is that lack of ability to easily save my progress. By this I mean that from my text editor I can regularly hit cmd+s and save where I am. I know I can regularly click Publish/Save but it is not as convenient and only really works whilst in a draft mode.

I know this is a big change to the workings of Textpattern, but it would be great if you could save a working copy of an article that is live without the working copy being published until you’re ready for it. If Textpattern had this sort of functionality built in I’d probably be more inclined to work from within the Admin area. This sort of thing is also missing from other CMSs I’ve worked with (or available, but not easily implemented/worked with).

GugUser wrote #278420:

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’m definitely not supporting the use of Word to produce content. It has caused numerous headaches in the past when dealing with customers copying and pasting from Word to TinyMCE (although I’m beginning to figure out how best to configure TinyMCE to fix these issues). I always advise copying and pasting from a text editor rather than a word processor if people must do this.

Textpattern CMS

Textpattern CMS support forum

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

#25 2014-01-24 13:06:45

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

#26 2014-01-24 13:32:43

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

#27 2014-01-24 13:35:48

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

#28 2014-01-24 13:55:01

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

sacripant wrote #278436:

#29 2014-01-24 14:11:00

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

#30 2014-01-24 19:03:26

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

GugUser wrote #278420:

Board footer