Improvements to editor (write page, code pages)

colak · 2015-10-16 17:46:08

Hi Phil, I did see that post but SimplyMDE is still geeky IMO. What happens with those who know nothing of textile? The textile syntax shortcuts might seem strange for them and they will possibly delete them.

when this community started over 10 years ago, it mainly consisted of designers and programmers. The web is showing us (whereas we like it or not) that the masses are not interested in learning but they all want to broadcast. (one of the proven reasons why facebook is so popular).

I could not emphasize it strongly enough that I would rather use txp and textile and because of that, I would love to see a lot of fresh faces in this forum which – in my view – will help us all.

hcgtv · 2015-10-16 18:51:42

colak wrote #295880:

The web is showing us (whereas we like it or not) that the masses are not interested in learning but they all want to broadcast. (one of the proven reasons why facebook is so popular).

Today’s elementary and middle school kids growing up on tablets, will give us a fresh generation who will already know programming to an extent. That generation is not going to go for the one-size-fits-all of a Facebook or Instagram or whatever social buzz that’s happening.

I could not emphasize it strongly enough that I would rather use txp and textile and because of that, I would love to see a lot of fresh faces in this forum which – in my view – will help us all.

Same here, I can’t see myself running another CMS, no matter if the call their re-usable code snippets a cool name like the Matrix.

Textpattern is it for me, get used to my face around here :)

etc · 2015-10-16 21:09:04

NicolasGraph wrote #295869:

That is why I like SimpleMDE. It looks like a wysiwyg editor with nice and simple visual effects to help people to understand what they are doing, but it still uses good old markup.

It looks nice until you inspect the HTML code behind these visual effects. I respect the hard work, but it feels just wrong (idem for CodeMirror). I’ve got an impression that the current browser technology just does not allow for easy visual text markup. iA Writer is not written in Javascript, I guess.

GugUser · 2015-10-16 23:35:58

colak wrote #295858:

Wouldn’t it be nice for the average new user,

if txp came with a number of front end themes such as gallery, blog, text based cms, whatever we can think of, which they could just select after they first install the software? (…)

On the other side, I would prefer an empty Textpattern version, completely empty, without forms etc.

etc wrote #295867:

(…) Users that know nothing about html generally end with <big><b>Header</b></big> instead of <h2>Header</h2> if you give them wysiwyg. Should we close the eyes?

In German there is for this a very long, compound word: Inkompetenzkompensationskompetenz

NicolasGraph wrote #295869:

(…) but if only talk about Textile I can’t see a big difference with rah_textile_bar which is easy to use and customize… If I could have a rah_textile_bar with nice visual effects, I would be happy with it…

I mentioned this before too, but no one responded.

Last edited by GugUser (2015-10-16 23:37:21)

NicolasGraph · 2015-10-17 08:13:51

GugUser wrote #295889:

I mentioned this before too, but no one responded.

Ok, so anyone know if it seems realistic to add visual effects wtih the rah_textile_bar?

philwareham · 2015-10-17 08:31:33

@GugUser

I don’t know where Gocom is, he hasn’t been on the forum, Twitter or even GitHub in months, or corresponded with us. The rah_textile_bar idea is the kind of thing I want in core, but extensible so it supports Markdown too.

NicolasGraph · 2015-10-17 08:37:08

philwareham wrote #295902:

@GugUser

I don’t know where Gocom is, he hasn’t been on the forum, Twitter or even GitHub in months, or corresponded with us. The rah_textile_bar idea is the kind of thing I want in core, but extensible so it supports Markdown too.

I think it is realistic to make it support Markdown but I don’t know about highlighting or other effects… Anyways it could already be in the core as it alters nothing but helps with textile.

Last edited by NicolasGraph (2015-10-17 08:37:48)

Destry · 2015-10-18 13:31:56

philwareham wrote #278434:

then provide some static HTML mockups for discussion on how we can move forward…

Please do this, because I’m finding myself wanting to on a daily basis. There are so many threads on this topic now, and the same ideas and suggestions are being repeated over and over. Time to put the central idea to concept.

element · 2016-06-03 10:35:52

Been using the 4.6 beta and the position of “Custom fields” in the Write tab is way too low on the page for good use, you need to scroll up and down a lot. Consider switching the position of “Custom fields” with “Date and Time”.

philwareham · 2016-06-03 10:46:59

element wrote #299463:

Been using the 4.6 beta and the position of “Custom fields” in the Write tab is way too low on the page for good use, you need to scroll up and down a lot. Consider switching the position of “Custom fields” with “Date and Time”.

That’s subjective really, plenty of users won’t use custom fields whereas all will use date and time. In Textpattern 4.7 we hope to allow authors to move the panels around to suit their tastes – for 4.6 I am leaving as is. Thanks anyway.

element · 2016-06-03 11:18:33

What about moving “Meta” below “Custom fields”? I believe one would use custom fields more than meta.

gaekwad · 2016-06-03 11:20:54

element wrote #299465:

What about moving “Meta” below “Custom fields”? I believe one would use custom fields more than meta.

Respectfully, I’d counter with the opposite – at least as far as my clients are concerned, far more are interested in tweaking the metadata than the custom fields.

phiw13 · 2016-06-03 12:05:30

element wrote #299465:

What about moving “Meta” below “Custom fields”? I believe one would use custom fields more than meta.

Agree with gaekwad on that. ‘Comment options’ could be moved lower down in the list – although not everybody will see it (it only shows up if you turn commenting on).

Destry · 2016-06-03 13:53:07

philwareham wrote #299464:

In Textpattern 4.7 we hope to allow authors to move the panels around to suit their tastes

Relevant to that future vision, something occurred to me while working on a spec to structure a content type with RDFa (which may end up being JSON-LD instead, but that’s a different story).

CMSes are undeniably moving to more “structured” models. In other words, being able to break content down into separate components so content models can be conceived more efficiently.

Textpattern is pretty good, but still suffers from the big body “blob” field, where a lot of individual content components need to go but can’t easily be done because you have to insert stuff into the body field in an inflexible way.

Consider this spec, for example, that describes structuring academic articles. The template I’m working on follows that to some degree. Briefly, an academic article has these components, more or less:

Title
Authors (several, with affiliations links)
Abstract
Intro
Background
Methods
Results
Discussion
References
Funding

If you imagine that as a Textpattern article, everything from Intro to Funding would be crammed into the body field in “blob”-like fashion, and Markdown and Textile are out the window because you need more specialized use of HTML in order to map the semantic schema correctly. In fact, when you remember that templates are usually parsed into nested form components in Txp, the notion of using RDFa starts to wobble because you’re breaking all those scoping attributes apart and it gets really hard to work with, thus JSON-LD starts looking like the better choice. However…

With the arrival of Txp 4.7 and extended custom fields, notably the ability to define them as textarea and move them around, we gain more control over componentizing content — leveraging it out of the body field in many cases, and people will get increasingly better at doing this as they get more familiar with the idea of chunking content and mapping it to schema.org, for example.

In that respect, two things might be worth thinking/asking about here:

First, if we can start leveraging content out of the body field, it becomes less necessary for it to be the dominant box in the panel, both in size and in concept of being where everything is dumped. It no longer has to be so big, and especially if it’s going to have less content in it. So in this respect maybe all textarea fields, body included, have a three size behavior: a minimum height when empty or a few lines, a max height when some determined number of lines is reached (but can be dragged open further), and maybe an option/plugin for auto-extending heights as you type, or whatever. The point being that component boxes, and namely textarea boxes, could/should behave more uniformly because content might end up being broken out more uniformly.

Second — and getting back to the notion of semantically structuring components — the body field, in a way, starts acting like another Txp form for HTML because we can’t use Textile, etc, which just falls apart when it comes to the semantic web.

So if you think back to an academic article, which provides a great example of semantically structuring web content, the body field would either just be used for one section of the article, take your pick:

<section typeof="ClassType" id="results">
<h2>Results</h2>
<p> ... </p>
</section>

Or maybe the body field serves as the holder of the <article typeof="Article"> ...</article> container part of the template, with all the <sectionn typeof="ClassType" id="">...</section> components in it, which, significantly, makes it easier to see them in one place, as opposed to spread out over a dozen form files:

<article typeof="Article>
  <section typeof="ClassType" id="intro">
    <h2>Intro</h2>
    <txp:custom_field name="intro_section">
  </section>
  <section typeof="ClassType" id="methods">
    <h2>Methods</h2>
    <txp:custom_field name="methods_section">
  </section>
  <section typeof="ClassType" id="results">
    <h2>Results</h2>
    <txp:custom_field name="results_section">
  </section>
...
</article>

And then custom fields are used for the structured content inside each section. You could even break those sections down into as many sub-component custom fields as needed.

So you not only have the ol’ Pages, Forms, Tags nesting as always, but a fourth nesting item too, the Body field, so that when working with schema you have everything together in one place, in context of the damn body field that ties it all together.

Can we get something like that? ;)

maverick · 2016-06-03 14:49:32

I’m of a similar mind to Destry in changing up the paradigm of the body field as the elephant on the page. Though I’m still thinking on the implications of his specific proposal.

With the advent of unlimited custom fields, we create a pragmatic need to manage custom fields – not just for output, and not just for content type and form controls, but also for input on the UI.

In many ways we are not far from the reality that every field is a custom fields. Ala CraftCMS, SymphonyCMS, and a number of others.

Perhaps we go beyond just draggable panels (which is a good start!) and begin to think about making it an option for developers to design an entire admin page with just the custom fields they want; without having to hide a bunch of stuff with CSS and plugins.

Textpattern CMS support forum

#61 2015-10-16 17:46:08

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

#62 2015-10-16 18:51:42

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

colak wrote #295880:

#63 2015-10-16 21:09:04

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

NicolasGraph wrote #295869:

#64 2015-10-16 23:35:58

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

colak wrote #295858:

etc wrote #295867:

NicolasGraph wrote #295869:

#65 2015-10-17 08:13:51

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

GugUser wrote #295889:

#66 2015-10-17 08:31:33

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

#67 2015-10-17 08:37:08

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

philwareham wrote #295902:

#68 2015-10-18 13:31:56

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

philwareham wrote #278434:

#69 2016-06-03 10:35:52

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

#70 2016-06-03 10:46:59

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

element wrote #299463:

#71 2016-06-03 11:18:33

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

#72 2016-06-03 11:20:54

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

element wrote #299465:

#73 2016-06-03 12:05:30

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

element wrote #299465:

#74 2016-06-03 13:53:07

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

philwareham wrote #299464:

#75 2016-06-03 14:49:32

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

Board footer