Improvements to editor (write page, code pages)

philwareham · 2014-01-23 13:12:37

We need to make some serious improvements to the editor pages of Textpattern I think. That means the coding pages (pages, forms, styles) and also the write page.

I’m building a new grid layout for Textpattern admin side that makes the editor areas much bigger (a two column span), and moves the other UI to a third column, which will help. But that is only half the story – we need to make use of existing open source tools in the core to make the process of writing stuff in the system actually a pleasant experience (currently I never write directly in Textpattern because of this – I use my IDE then copy/paste in content/code to the CMS).

There really is no excuse not to – plenty of open source options are available now which could be viable for integration, such as Ace editor, MarkItUp, txstyle and Textile live web editor to name a few.

I’ve already had a conversation with Jon Hicks in the last couple of days who is considering moving away from Textpattern because of the lack of live preview pane in the write page. He initially brought me to use Textpattern so it would be a shame to lose such a respected web designer.

I’m willing to put some funding towards this – but since I’m only a front-end person it’s not something I can create myself (although I can help skin where needed). Once again, these need to be core features, not left to plugin authors. It also should be available as an option for the custom fields that we plan to build into the system.

philwareham · 2014-01-23 13:20:31

There are also plenty of contextual popup text formatting bars that we could use, which are pretty cool. We could possibly use one of those in an edit window along with the Textile (or Markdown) live preview pane next to it, which would be very nice.

etc · 2014-01-23 13:50:03

philwareham wrote #278393:

There are also plenty of contextual popup text formatting bars that we could use, which are pretty cool. We could possibly use one of those in an edit window along with the Textile (or Markdown) live preview pane next to it, which would be very nice.

Hi Phil, nice ideas. Per se, integrating Textile live preview is fairly easy (I’ve done it for comments), but there are two “buts”:

if the text is formatted server-side, with txp own Textile class, there is no need for third party components, but you need a fast enough internet connection;
if it happens client-side (in javascript), then the js code must be revised on each txp Textile class update, to produce consistent results.

I prefer the second solution (and could help if needed) if someone can keep textile.js up to date.

philwareham · 2014-01-23 14:00:45

etc wrote #278394:

I prefer the second solution (and could help if needed) if someone can keep textile.js up to date.

Jukka is on the Textile team as well as Textpattern team so I guess he knows the code pretty well. The JavaScript solution would also be my preferred route from the sound of it, though as I’ve stated before I’m not a programmer so I don’t know how the inner workings of Textpattern work past the HTML/CSS. I just see these editor tools as standard in other emergent CMSes (Perch, Medium, Ghost) and want them to also be in my CMS of choice.

This subject has come up many times in the past without resolution. When I did a user poll of missing features in Textpattern last year, this, custom fields and flat file editing were far and away the most requested things by the community.

gaekwad · 2014-01-23 14:13:09

philwareham wrote #278395:

When I did a user poll of missing features in Textpattern last year, this, custom fields and flat file editing were far and away the most requested things by the community.

Are the results of that poll public, Phil? If so, where can I find them? Thanks.

philwareham · 2014-01-23 14:19:24

It was just an informal thing on Google+

gaekwad · 2014-01-23 14:19:56

OK, no worries -thanks.

etc · 2014-01-23 15:04:25

philwareham wrote #278395:

I’m not a programmer so I don’t know how the inner workings of Textpattern work past the HTML/CSS.

Nobody’s perfect! But that’s really ease, see here for a basic implementation. The problem is, js code is outdated, so some recent Textile features (like "$":http://some.thing) won’t work.

philwareham · 2014-01-23 15:32:37

That’s similar to whats here but older I think

Jukka started building something out for the official Textile site which does a similar thing, it’s not anywhere near finished yet though. It’s on GitHub here

That might give some clues as to the latest codebase.

sacripant · 2014-01-23 15:51:04

Hello Phil,

I don’t understand this discussion.
Now, textpattern is a CMS or a bloging plateforme ?

Because, in write tab, UI and needs are different for a blogger , an event website, a e-commerce website, etc.

For me, The best ideas last 3 years is bot plugins (write_tab_customize, bot_image_uplaod) pugin. I thinks it’s important to gain more modularity.
The objectif for write tab is to be a hyper-flexile interface for all needs. And not impose a system input

It’s a user want a big textarea for writting in mardown or Textile with live preview. Textpattern core does help to implement very easely that, and not implement that by default.

For my personnal need I’m implemented a Full Screen Ace Editor in write tab.
It is very comfortable to write directly in textpattern and I am very satisfied. I even plan to add a “live preview Front” based to view url. This can meet the need of some users, but not all. Did you tested?

After, for page and form tab, work on a better UI is good idea.

etc · 2014-01-23 15:55:50

philwareham wrote #278400:

That’s similar to whats here but older I think

Not exactly, txpstyle.org calls the server every time you type something (solution 1), while in my example the formatting is done locally, in your own browser (solution 2).

philwareham · 2014-01-23 16:06:31

sacripant wrote #278401:

I don’t understand this discussion. Now, textpattern is a CMS or a bloging plateforme ?

I feel it needs something in place on the write page, that can be switched on or off by the user as desired for any textareas, if their workflow needs it. For code pages, something like Ace Editor is almost a no-brainer, it should be included IMHO. Again, the user should be allowed to turn it off (though I don’t know why they’d need to for code).

The current ‘preview’/‘html’ tabs are just not going to cut it when proper custom fields are introduced – how exactly will those be processed otherwise? Should the preview show custom field text areas? Or should it not? Or should it show some and not others? How?

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.

Textpattern CMS

Textpattern CMS support forum

#1 2014-01-23 13:12:37