Jump to content

Arantor

Clients
  • Posts

    11
  • Joined

  • Last visited

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Arantor

  1. Honestly, that's not what happens in practice. The majority will simply use and grow to work with whatever the default is set to, even if the default is a functionally inferior version, as long as the minimum feature set for creators is maintained. My source for this is Moodle - which made a transition from TinyMCE to its own home-grown editor Atto a few years ago. While inferior functionally (objectively) compared to the legacy version of TinyMCE they were using, the reality is that Atto did enough to support most things that people needed, and the community plugged the remaining holes as they saw it. My source for the other end of the scale is one of the Moodle derivatives, which followed the TinyMCE -> Atto route and in the last couple of versions introduced their own editor to replace Atto, called Weka. All three editors remain available, but Weka provides zero table support which is a deal-breaker for some content creators. (Their justification is that they intend content to be consumed by mobile and their mobile app does not support tables.) Basically as long as whatever editor is not so broken that it's deemed unusable by the majority, whatever the vendor does will just be accepted because people will generally move with change. A new editor, in whatever capacity, is a hefty undertaking to consider not only users' needs (all sets of users) but also to consider security of whatever formatting is being done, as well as side functionality such as uploaded/embedded media.
  2. Where Markdown starts to flail is for the somewhat edge-case where you're doing something in a reply that really is more detailed than simple markup. This is where it gets complicated. Most replies in forums will have bold, italics, links, things that are fairly easy to parse - but it's when you have something that doesn't map *exactly* to the markup (or Markdown) that you have to reverse engineer it in some fashion. Now, of course, IPS already does this when you're playing around with quoting, embedding metadata into the markup to indicate author/source of post/whatever, all the things you'd want to have in order to take that quote and springboard events off it like alerts. There are a few things you can do about this. You can either 1) simplify the markup to simply be a mention to the author, a simple link to the post and rely on the mention to handle the notification, or 2) reinvent the kind of markup you're embedding to keep the metadata intact. The former is what NodeBB does if memory serves, the latter is what Discourse did at least initially; at least one early adopter of Discourse referred to their markup as DiscoMarkBBcodeDown or some similar mashup because it tried to handle Markdown as its primary lingua franca, HTML for the things that Markdown couldn't do, and bbcode for meta markup that didn't align to HTML. It also amuses me that WordPress eventually reinvented bbcode for such cases (this is, after all, what shortcode is) precisely for the cases where their editor couldn't handle it. But then you get into the question of: how much do you *really* want to support in replies? I would make the argument that complex and rich editing for topic starters (plus cases like Pages) is very desirable, and that yes, Markdown or something like it is probably all you *actually* need for replies. But that's a value proposition that has to be weighed up against the communities that *don't* do that. I could over in my little weird niche, find you any number of forums that have the most ridiculous and intricate snippets of raw HTML embedded into each post to make decorative frames around the content, sufficiently complex that they require to be posted as templates for users to copy/paste because you'd never use them normally, far beyond what even the usual types of bbcode support. Some of these templates are so ornate they even include user-driven animation (e.g. a decorative picture, hover over to see the content). Whether this is user friendly or not is, largely, irrelevant to outside observers; those are their customers, that is what they do, and most other forum software increasingly is just not going to support it. But that's where we get to the value proposition: those users aren't going to be moving to IPS any time soon, and those that are... they'll accept the reduction in functionality even to align to IPS 4.5/4.6 (because there will be some for them without major dev work, I think), and probably even to Markdown - meaning that you wouldn't really lose any users this way because they weren't going to be your users anyhow. For the IPS core market on the other hand, I think it's very reasonable to suggest that, actually, Markdown represents a sufficiently robust set of core formatting that users would want. I still wouldn't ask _us_ however because we're not the userbase at large. We are the customers, the people who pay for some flavour of the software - but we're not the vast hordes of people who _use_ it, a critical distinction a lot of forum admin places (hi TAZ) seem to forget. Additionally, anecdotally the thoughts I've had from people who want a mobile app tend to align along 'I want notifications and a simplified editing experience' because they're likely not editing the full rich content on mobile, but replying where the Markdown-esque editing experience is sufficient.
  3. That wasn't what killed SMF 2.1 - but that's a debate for somewhere else (perhaps we can continue this on TAZ?) I know no-one suggested it. I was getting in ahead of the otherwise-inevitable suggestion because no doubt someone was going to suggest it with crystalised examples of 'why you shouldn't'. Even CKEditor has written articles explaining the rationale for dropping aspects of the browser 'helping' before reimplementing the functionality on its own because browser support for this is frankly awful. I would actually suggest that the entire concept of trying to do it is somewhat a fool's errand. Google Docs is actually moving away from using HTML to render docs going forward because as far as they're concerned, they've reached the limit of what can be done and that ripping it out and doing something different is actually viable. What it ultimately comes down to is which audience you're actually trying to target. The majority of commenters in threads don't really need particularly rich editing. You need the basics, sure, and some richer elements like quote handling, as well as some functionality for embedding media with *some* choices to make formatting. But the vast majority of *replies* do not need to be delightfully rich in content because the general nature is that commenters in threads are doing a different kind of content creation to topic creators. Now, topic creators - and by extension with things like IP Pages, IP Blogs, and related 'opening posts' where you expect and want richer media options - and where CKEditor isn't actually a poor fit. Neither is Gutenberg, incidentally. They all have their foibles, and you're picking the least worst choice for your situation. All of the suggestions on the table are reasonable alternatives for some subset of the target market - the question is whether you care most about the creators and giving them all the options, or the commenters on content. I also think this is a complex case because the people who are responding in this thread are going to be predominantly the content creator types, who will obviously want richer and more interesting content creation tools - rather than being the much-larger segment of people who will simply interact on the forum. I find it interesting that after decades, we're still looking at the core posting experience and going 'Hmm... that's not quite right'. Tell you what I'd do at this point: I'd make it pluggable and let users decide what they want to use, since they all interchange raw HTML at this point, why not just let the site admins pick which one(s) they want to use - allow for CKEditor 5 for admins, and I dunno, QuillJS for regular users? (Quill has the advantage that it's deliberately set up to have a limited surface area and focus on what it offers rather than trying to be rich and detailed) The only pain points then become interoperability with existing tools and things like drag and drop. But it's an idea to throw out there.
  4. There is one option that could be considered and I am here to... firmly... attempt to discourage it. It is possible to roll your own editor from scratch. SMF did it back in the day for 2.0 though it was realised how much pain it would be to maintain and it will be dropped in 2.1 (and the bbcode-based editor they moved to has many of the 'standard' WYSIWYG editor issues that most contentEditable based editors have). The LMS Moodle rolled its own a few years ago to get away from TinyMCE but it's not without its pain, and even now it does some strange things - which is awkward given that it is implemented throughout the platform everywhere for basically any non-trivial text entry. Some very strange bugs manifested. IPS has the technical skills in house to roll their own editor... please don't. Would I suggest CKEditor 5? I don't know. Having done extensive stuff in CKEditor 4 in the past, I know I have huge reservations using CKEditor again in a project - but I have similar ones for using TinyMCE as well for much the same reason - they're pretty massive and bring their own maintenance nightmares. Gutenberg on the other hand I'd firmly discourage for a general purpose editing experience; it's viable for admin level content creation. IPS Pages for example potentially might leverage something on that scale - but for general posting? Probably not.
×
×
  • Create New...