Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Improvements to editor (write page, code pages)
I figure several moderate sized posts are preferable to one super long one. :)
phiw13 wrote #278498:
Indeed, that is something I’d like to see in TXP: a (light?) version history mechanism.
Offline
Re: Improvements to editor (write page, code pages)
OK, I’ll be back working on Textpattern in a couple of weeks or so, just got a huge site to launch which is taking all my time at the moment.
Offline
Re: Improvements to editor (write page, code pages)
of modularity, txp tags on admin pages & smd_tabber
etc wrote #278433:
The only thing I miss on the admin side are txp tags… compose one’s own write panel, wouldn’t it be loverly?
sacripant wrote #278436:
I’m talking about exactly the same idea in 2009 in french forum
etc wrote #278438:
Stef has written the great smd_tabber, but the road is still long.
Bloke wrote #278406:
By all means, as Sacripant says, let’s modularise the panels and make it simpler to shuffle things around to suit many different workflows. . .I’d prefer to open up the Write panel more to plugin authors so this kind of custom functionality can be offered more easily.
jakob wrote #278416:
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.
philwareham wrote #278417:
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.
My “CMS” worldview is that content management involves multiple tasks. A content management system generally does one or two of those tasks well, and leaves you wishing it could do a better job with the rest.
Among other things, content management does the following:
- Provides a way to input/save the content
- Provides for storage of the content (flat file, SQL, etc.)
- Orders the content
- Provides a way to manipulate the content (search, compare, contrast).
- Provides a way to output the content (publish to the web, print, etc.)
Few CMSes do all this in-house. Rather they offer their unique take combined with other tools: databases, scripting languages, html, pdf, etc. Since a CMS creates a front-end for all these functions, the breadth of its capabilities combined with the simplicity and beauty of it’s UI will determine how much I want to use it.
Textpattern’s xml style language plus it’s focus on writing in a light weight package that hid php from us is what make it a winner. We can do almost anything on the “publish to the web” side (output) The cry for modularity is because we need the same ability for input. The ability to customize the UI for input is as much of a need as to customize the output (whether as a website or a pdf).
When I first asked Stef about smd_tabber, the ability to create a custom UI for content input was really my heart’s desire. He did an awesome job of getting us as close to that idea as anyone ever has. Thank you Stef!
However, as I understand it, the admin side pages would have to be rendered by the tag engine. I’m not even sure if that is possible, let alone desireable.
Alternately, if there were tags that could securely recreate the admin UI on the front side – sort of like Manfre’s suite of plugins but more easier to use, that would also achieve the goal.
Imagine: <txp:custom_field_input field=“1” /> or <txp:body_input />. It seems like such a simple idea to achieve what we want. Except for the whole coding/tech side that is! Oh well, dreaming of the ideal is fun! :)
SymphonyCMS is another CMS that tried to achieve a customizable admin side UI as well. I’ve not check the last year or so to see how they’ve been doing.
Anyway – I agree modularity and flexibility in the write tab is highly desirable.
Offline
Re: Improvements to editor (write page, code pages)
No problem Phil! You’ve have done an immense amount of work on Textpattern over the last couple of years. Thank you.
Disclaimer: I’ve not been closely following the forums this past year. If this has been discussed, forgive me. Also, this is tangent, but seems closely enough related since we are talking about revision control, third party tools to be integrated, etc.
Has anyone else been trying out Draft? (DraftIn.com)
It is designed for for individuals or teams to write and collaborate, with major and minor revision control. It uses MarkDown. It allows multiple publishing options, including publishing to the following:
- Wordpress
- Tumblr
- Blogger
- Mailchimp
- Buffer
- iDoneThis
- WebHook URL
- Svbtle
- Ghost
- Basecamp
There is also a Chrome Extension that allows you to edit any text-editable box using Draft.
I am considering using it in conjunction with Textpattern.
Last edited by maverick (2014-02-06 19:09:30)
Offline
Re: Improvements to editor (write page, code pages)
Just to rev up this interesting discussion.
Speaking of the write page, has anybody tried Medium.com writing interface?
It is acclaimed as the best web-based editor around. It reminds me how Textpattern has felt me focused on content and why many fell in love with it.
And there is even a version history with autosave.
Again, Medium let you focus on your writing with minimal distraction and is a wyswyg, even if many hate the word. But, frankly, do your customers love writing in textile (or markdown)? Come on, after a couple of days, a non-geek user forgets everything and textile is by far the simplest writing tool.
Of course, the code writing pages in textpattern is another story.
I would push the separation between content writing and coding, even further.
It’s worth to take a look. Just my 2 cents.
Offline
Re: Improvements to editor (write page, code pages)
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.
I still think that’s the best option. No visual formatting, only Textile/Markdown/Whatever pluggable helpers with live preview.
Offline
Re: Improvements to editor (write page, code pages)
Although I am very happy with textile, I believe that a WYSIWYG editor would be a good crowd puller. There are indeed plugins out there but the problem remains for new users who might know nothing of textile or even html.
I guess that what has to be thought about is the current target audience which mostly consists of designers or people who are somewhat well versed with html versus the possible audience which could be anything from teenagers to old age pensioners and anybody in between who would like to control their own site.
The recent announcement of kuo_theme is a step towards the direction of attracting a wider user base.
Further to the above… 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?
- if unlimited custom fields were used to allow for flexible content rearrangement. I’ve been looking at tiddlywiki recently and although it does not fit my needs I like its idea of cards and also how the writer can work directly from the front end.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Improvements to editor (write page, code pages)
Hi Yiannis,
Both those things are already under construction and exist in GitHub branches
Offline
Re: Improvements to editor (write page, code pages)
i agree it lacks to textpattern a good wysiwyg editor tool, intuitive and sexy for non-textile geek users.
I agree it lacks to textpattern a nice editor with syntaxic coloration and live preview for textile and markdown lovers.
It lacks perhaps a Jade engine transpiler for some user that love this template engine
etc…
It’s very difficult to satisfy everyone.
For me, a good CMS give tools to build all satisfaction: with a very flexible api.
It’s no good to impose a solution for a specific profile.
The solution I could find acceptable :
propose during the “setup” an new panel for choosing some plugins. And choose between a official wysiwig plugin VS texile, VS markdown and a link to plugins list.
These plugins can be installed by default but not activated, and depending on the choice of the user they are activated or deleted.
Offline
Re: Improvements to editor (write page, code pages)
philwareham wrote #295859:
Hi Yiannis,
Both those things are already under construction and exist in GitHub branches
I know! I’m so looking forward to them! This was my gentle push for a vanilla release:)
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Improvements to editor (write page, code pages)
colak wrote #295858:
Although I am very happy with textile, I believe that a WYSIWYG editor would be a good crowd puller. There are indeed plugins out there but the problem remains for new users who might know nothing of textile or even html.
Sure, and I’m not against wysiwyg per se, but have not yet found an editor that produces a qualitatively better html markup than Office-something. Probably, there is a reason for this, and improvements are possible, but less bloat is still bloat.
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?
Offline
Re: Improvements to editor (write page, code pages)
etc wrote #295867:
Sure, and I’m not against wysiwyg per se, but have not yet found an editor that produces a qualitatively better html markup than Office-something. Probably, there is a reason for this, and improvements are possible, but less bloat is still bloat.
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?
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. Markitup looks nice to support differents markup styles (markdown, etc.) 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…
Offline
Re: Improvements to editor (write page, code pages)
I missed this thread before, apparently. But it’s on topic with some ideas I was trying to express elsewhere.
At least half of everything I see said in this thread so far would fit the iA Writer UI way of doing it. If anyone has that, open it up and look. But in relation to Txp:
- Bigger editing box
- Simple formatting bar (Writer’s is at bottom of editor, which is cool, and appears when you hover over it), with limited feature set so nobody tries to make flashing rainbow-colored headers. (rah_textile_bar is in the right direction)
- Basic syntax appears as the formatting defines, but you still see the syntax. (Kind of a compromise of having a full rendering preview, or a combination of the default/preview views.)
If you had just those three things in the main editor view, it might be the only view/preview you need. But at the very least it would make an ideal default and fit the interests of many people, and plugins can extend from there.
There is no text editor out there that looks as marvelously for writers as iA Writer but supports Textile (instead of Markdown). If Txp filled that gap (despite being a CMS as opposed to text editor), that would be something, a big step in the right direction that a lot of Textile-loving writers would notice.
Offline
Re: Improvements to editor (write page, code pages)
etc wrote #295867:
Should we close the eyes?
Hi Oleg,
I definitely agree with you re code but I also believe that if we would like txp to have a wider appeal we might indeed have to close our eyes to the intricacies of html validation. It would have been great if there was a WYSIWYG editor which was intuitive enough for people to create correctly structured articles but at the same time I believe that this might be a possibility in the not so distant future.
I think that if we manage to make our user-base larger, we will also attract more programmers whose collective work hours and – hopefully – interaction within this forum, some of these problems might be resolved. As such I see the WYSIWYG editor as a baby step towards the expansion of the number of our users and not as something I would personally use.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Improvements to editor (write page, code pages)
Hi Yiannis, there are plenty of syntax editors (aka WYSIWYG) that don’t pollute the code. MarkItUp and SimplyMDE are examples of that. They don’t actually write HTML – rather they provide a UI for Markdown (and Textile in some cases). That is my preferred route.
Offline