Any reason why the dual composer view was chosen over WYSIWYG?


  • Plugin & Theme Dev

    Well, after using the dual composer feature on a few sites besides this one such as the one on Dillinger, Ghost, Discourse and a few other sites, I've come to the conclusion that the dual composer is a failure for the use of a forum for many reasons.

    When you are composing something, you want as much space as possible to write. I feel squeezed and constrained in a sense because I have this window pane to the right of me taking up half the space to write on. I'm sure there are mixed feelings about this, but if I had to choose whether I wanted the double pane view or the single WYSIWYG editor, I would definitely choose WYSIWYG.

    Use cases and many sites have successfully deployed this feature in unique ways keeping the logical approach as simple as possible. When you bold something you should be able to see it right then and there, and that goes for any type of formatting within the composer. I'm wondering what made you guys choose this over something more simplistic. There is completely no way possible this would work successfully for mobile (and I see why there is a mobile composer template created) and while the new mobile template for the composer can be useful in some ways, it ultimately was unnecessary.

    Okay, so Discourse has it where you can hide the preview pane, okay cool - not. That still doesn't solve the problem here because you still can't see what you've formatted unless you reenable that pane again, so again its total bullshit.

    When I think of a dual pane, I think of diff editors to compare edited changes, not for writing on a forum of any kind at all. Whoever originally thought this would be pretty neat for a forum should be banned for life of any form of UX that involves forums (and it doesn't originate here, so you guys are in the clear).

    So was it the community or was it your own deduction as to what competitors/other sites have or was it because it was easier to implement because the preview pane is already there (basically a no brainer)?

    In a UX standpoint its annoying to have so much wasted and unnecessary space just to see a live preview of your post when you can just see it using the WYSIWYG approach. I understand why the tabs were removed and the logic there was pretty flawed because I mean... who wants to click back and forth just to see if what you've typed is how you want it.

    -_-
    ####**What started this topic: **
    @psychobunny said

    Yeah it's based on screen size. Right now the templates are identical... we're not actually sure if its a good idea to build two different composers, but it's there for now until we figure out what we're doing with it grinning
    https://community.nodebb.org/topic/1928/what-is-composer-mobile/7



  • Have to agree with this. Live preview doesn't do it for me either. Confusing to new users and somewhat needless. Like the old way for previews.



  • @nik Let's add a setting in the ACP to enable / disable it.



  • Confusing!? Eh? It's pretty obvious what it does as soon as you start typing. I've not found a wysiwyg editor yet that can actually post legible code either. Granted I've not used one for about a year, but there's definitely better alternatives than wysiwyg editors...


  • Plugin & Theme Dev

    @a_5mith Yes, confusing. When a new user selects their texts and bolds it they see asterisks outside the word. Now we know what that means because we are tech savvy and know the basics of Markdown, but for someone who has never seen it before, it can be quite confusing.

    Another thing for example is that I use my 13 inch MacBook with the resolution at 1440 x 990 max, so my browser has to always be near maximized in width to even see both the write and preview panes.

    I've not found a wysiwyg editor yet that can actually post legible code either.

    See Quora example below.
    Screen Shot 2014-07-05 at 3.05.21 PM.png

    See Medium example below.
    Screen Shot 2014-07-05 at 3.07.49 PM.png

    See Xenforo example below.
    Screen Shot 2014-07-05 at 3.06.33 PM.png

    ###Now take a look at this double pane crap.
    NodeBB
    Screen Shot 2014-07-05 at 3.09.24 PM.png

    Discourse
    Screen Shot 2014-07-05 at 3.15.02 PM.png

    Ghost
    Screen Shot 2014-07-05 at 3.18.39 PM.png



  • @trevor You missed what I meant by legible code. I'm not talking about what you see. I'm talking about what that editor actually parses. Empty paragraph tags used instead of breaks, poor stylesheet applied to paragraphs that don't need it. The list is endless.

    You're mixing two different issues here. Are you complaining about the composer or Markdown? It's not the composer that makes you add the asterisks. Let's not forget here, for years, forum posting was, and still is in some places [b]bold[/b] and [i]italics[/i], worse than that, [url=URL]Link[/url], [img]imgURL[/img] or [quote]text[/quote]. Xenforo being one of them.

    The markdown is fine. I also don't have an issue with the side by side composer. WYSIWYG is just a step backwards here, the nice thing about NodeBB, is it's simplistic design when it comes to the composer. Adding kitchen sinks with comfusing icons like those in Xenforo would be a huge step backwards. How often do you actually use half of the items in a WYSIWYG editor? Things like aligning text just aren't needed on a forum. Posts should be uniform and simple to read.


  • Plugin & Theme Dev

    @a_5mith Its an example, when I used Xenforo before in the past, I took out those options so that users couldn't use the alignment, font resizing, font families, etc.

    I'm complaining about the need to add all of the extra crap such as the asterisk - most users don't even use it because of the same reason I am complaining about. This is just a forum, nothing more than a forum so no, theres no need for all of the complication when formatting your post.

    I like Markdown, more so than BBCode. I'm talking about having the "live editing" visible first then maybe in another tab or so, you can alter the Markdown manually, not in the first place. WYSIWYG is definitely not a step backwards, more so developers tend to implement it in the worse way. I gave some examples here and like I said, and I will stand strongly by this... the side by side preview is for developers and not the average user (the average user being your neighbor, your grandma, your uncle), and we can even go as far as psychological studies and using kids from the ages of 11-15 year olds to decide whether or not the side by side panes vs the WYSIWYG-type of editor is better for them - they will definitely use the WYSIWYG-like editor. Demographically speaking, your site will attract certain type of individuals just solely based on the type of editor you're using and the efficiency you will get out of it. Otherwise you will get a bunch of people typing without any care to format. Then they have to read up on Markdown, what it is and how to use it - most people won't even go as far as the URL linking.

    Posts should be uniform and simple to read.

    Thats the result of - a composed post, which has nothing to do with what I am talking about.

    Ghost has a modal box that shows "Markdown Help"... Well what the hell? Thats so much trial and error of having to format and its just too much going on. Leave the advanced stuff to the more advanced individuals. I don't feel that you should force a user to study and learn Markdown if they don't want to.



  • @trevor got to agree with you on that. You always have to think of your end users here or at least give the option to dumb down the composer view. 98% of users in my forums are middle aged non-tech guys. They like boring kitchen sinks, big buttons to insert links and so forth. They also like one place to type. It's really not supposed to be a tech demo.

    Double panes is a cool option that may be applicable to a certain demographic but it will be a small one.


  • GNU/Linux Admin

    To give some history on the composer:

    • @psychobunny implemented a plaintext composer
    • The decision was between BBCode and Markdown, and Markdown won because I was a huge fan (and @psychobunny was busy doing other stuff with NodeBB, so I beat him to it)
    • Popular demand for a live preview pane, so we added it
    • Experimented with a right-side composer (instead of bottom-up) -- people hated it, but liked the resizable aspect, so we reverted to bottom-up and kept the resizing
    • Popular demand for the live preview to be on the same "tab" as the composer textarea, so we added it

    Some thoughts

    • The composer design is a mix of what we want in a composer (albeit, a more technically biased POV), and what the community is most vocal about
    • I very vocally push for a schema where the raw post text is saved into the database. This may be why the front-end UI is still showing "raw" Markdown
    • Almost all existing WYSIWYG editors end up outputting HTML. This breaks the previous point.
    • upndown is still the only WYSIWYG editor that outputs Markdown, but has a nice interface.
    • Secondly, Markdown is a plugin, and NodeBB is designed to allow other input methods. If a community doesn't want to use Markdown, they can write their own BBCode parser, and disable nodebb-plugin-markdown. This is why we can't hardcode Markdown-y things in the composer in core.
    • Yes, I am fully aware that the toolbar buttons put Markdown into the composer. This breaks the previous point.

    Lastly, I absolutely LOATHE the floating toolbar that you see in MS Word (and Medium) use. Unintuitive and unsufferably minimalist. No need to make the composer complicated, but no need to just present the user with a blank textarea with no (easy-to-see) formatting options.

    @trevor, I do see what you're getting at, but I'm thinking that you're talking about an entire upheaval of the post composition dynamic. We'd be breaking every single plugin out there (and as much as @a_5mith likes NodeBB, I don't think he'd want to update 50 plugins at once), because our plugins work on the system of "post some raw text, the plugin detects it and renders it in HTML". If we were using a WYSIWYG interface, there'd be no way to edit a rendered YouTube link, for example... because all you'd see is the YouTube embedded object.


  • GNU/Linux Admin

    Upon further examination, upndown is actually an HTML to Markdown conversion library, which would open us up to using a WYSIWYG editor for the composer... except things still get kind of hairy when you start talking about plugin embeds/integration.

    The preview tab is nice, although it does take up room (and makes @trevor feel trapped 😛 )... what if it were toggled via a hotkey? Hold down alt and see the parsed post overlaid on top of the textarea? Let go and it disappears?



  • This may seem a bit farfetched, but I may have a solution, or at least the start of one. I noticed Hallo

    Keep the composer as before, but rather than having a seperate preview zone, it would just appear as if it were an actual post, then would be seen by others once posted.

    Made you a mockup. A further advance to this would be make the post editable from the actual post, without needing a composer. But I'm sure there's some limitations with all of this. 😆

    Untitled-1.png


  • Plugin & Theme Dev

    @a_5mith said:

    Made you a mockup. A further advance to this would be make the post editable from the actual post, without needing a composer. But I'm sure there's some limitations with all of this.

    I definitely like the mockup.

    My apologizes when I used the term WYSIWYG so loosely, because @a_5mith is on the right track as to what I am talking about. You see the actual post like Hallo, but you can click on the eye-closed (or whatever fa- icon it is) to see the raw Markdown. This is what I meant all along - you would be able to clearly see what the post would look like when you hit submit, and for those who are a bit more advanced in Markdown, they could toggle it off with one button and edit it raw as well.

    Thanks @a_5mith.

    I agree @julian - the floating toolbar is bad UX.


  • Plugin & Theme Dev

    @a_5mith But what about low resolution displays? Mobile users? They can't always see both the composer and the post.


  • Plugin & Theme Dev

    I'm still in love with the tabbed view 😛 it's pretty cool in combination with shortcuts that you go to preview after one press of Ctrl+Enter and submit on second press 🙂 the Ctrl+Shift+Enter was a quick way to get back to write...

    At least on mobile devices (small displays) the tabs should come back (I don't use mobile devices but tiling window manager so I experience NO PREVIEW at the time with only one other window when horizontal aligned).

    Maybe it's even nice to have the 'submit' button first show the preview and another click does the submit.

    In general I'm against any WYSIWYG since it's annoying for experts.



  • I like @a_5mith idea but isn't it the dual composer upside down kinda ?
    I don't think that WYSIWIG editor is the solution but I agree the dual view composer is disturbing.


  • GNU/Linux Admin

    @frissdiegurke The problem with introducing tabs back into the mobile composer, is that there is such little screen real estate to work with, that it's just impossible.

    Imagine a resolution of 720x1280 (which is pretty liberal already)... ~640 pixels are already gone when the keyboard is open, the titlebar, toolbar, and textarea all have to fit in 640 pixels. Ouch. (The numbers don't seem right, but I think because phones have higher pixel density, there's actually less space to work with, so 640px is a lot on a desktop, but not enough on a phone)

    Speaking of which... mobile view doesn't need a title bar... what is your opinion on this mobile UX?

    1. Mobile user clicks "New Topic"
    2. Browser alert: "Please specify topic title"
    3. "Title" input removed from mobile composer (just hdiden via css, or input type "hidden")
    4. [New] Toolbar button added to trigger the browser alert in case the user wants to change the title again.


  • @frissdiegurke said:

    Maybe it's even nice to have the 'submit' button first show the preview and another click does the submit.

    Please no. 😆


  • GNU/Linux Admin

    Keep in mind there's no reason the mobile composer has to follow the same UX as the desktop composer. Having them both on the same template was in retrospect, a short-sighted decision.



  • I came here by way of @erlend_sh's post on meta.discourse.org. Does NodeBB allow you to visit other topics while replying to one like Discourse does?

    It appears so.

    In that case, while I like @a_5mith's mockup, it would seem to break if you navigate away from the topic you're replying to.


  • Admin

    Actually, I don't personally see the dual composer as the future of NodeBB, it's great right now as a stop-gap solution. I'll keep my thoughts to myself but let's just say that we have a plan 😉 Just that we're so busy with so much right now! Appreciate all the feedback so far 🙂

    EDIT: heh, I'm so late to the party.


Log in to reply
 

Suggested Topics

| |