Project

General

Profile

Feature #589

Preview of Forum Posts

Added by Matt Gold over 8 years ago. Updated about 5 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Group Forums
Target version:
Start date:
2011-02-17
Due date:
% Done:

70%

Estimated time:
2.00 h

Description

It would be nice to be able to preview forum posts before publishing them to a group. Perhaps plugins already exist with this functionality?

post-preview.png (121 KB) post-preview.png Matt Gold, 2014-02-15 12:04 PM

Related issues

Related to CUNY Academic Commons - Design/UX #3059: Forum Post Permissable Content Explanatory TextNew2014-02-21

History

#1 Updated by Boone Gorges over 8 years ago

  • Target version changed from 1.2 to 1.3

There's something out there but it will take adaptation.

#2 Updated by Boone Gorges almost 8 years ago

  • Status changed from Assigned to Reporter Feedback

I looked at the plugin that I thought did this, but it turns out that it does not in fact do this. So I'll have to write something from scratch.

How important is it? I would like to push it forward to a different release if it's all the same to you, as it's going to be a pain to write, and I'm not certain if it'll be worthwhile in terms of impact.

#3 Updated by Matt Gold almost 8 years ago

Fine to push it back. But it is a pretty standard feature on most posting interfaces (including this one), so I would like us to keep it on roadmap.

#4 Updated by Boone Gorges almost 8 years ago

I'm testing out the feature here on Redmine, and I have to say I don't really get it. What advantages does it offer, above and beyond just reading the text in the editing window?

#5 Updated by Matt Gold almost 8 years ago

It's useful especially for long forum posts that have more lines than the text box (I realize that the corners of the text box can be pulled to make it larger, but not everyone does). It's also useful because the way the text looks in the posting interface for, say, links, looks different than when it is rendered in the post. Similarly, our bbpress forums accept limited HTML, so it might be useful for people to see what code will be rendered correctly and what won't.

Additionally, most people want to check over/proofread their messages before posting them, and it can be easier to do that on a preview screen/window/box/field.

Again, this seems to me to be a standard feature of most posting interfaces. But I'm happy to ask for more input from other members of the team/CAC committee on this.

#6 Updated by Boone Gorges almost 8 years ago

The HTML part makes sense.

I don't see much value in the longer-than-the-textbox part, since you can be longer than the preview window as well. Either you understand the convention of scrolling, or you don't.

I just want to understand what's expected here, and what features are found valuable, before I go implementing anything. I can imagine about a hundred different ways to do this, and I want to pick the one that is right for the desires of the community.

#7 Updated by Boone Gorges almost 8 years ago

  • Target version changed from 1.3 to 1.4

#8 Updated by Boone Gorges about 7 years ago

  • Status changed from Reporter Feedback to Assigned
  • Assignee changed from Boone Gorges to Raymond Hoh
  • Target version changed from 1.4 to 1.6

I don't want to sink a lot of time into this for the current implementation of bbPress in BP. Within the next few months, a full-fledged bbPress 2.0 integration will be available; our efforts should go toward that instead. (It will be easier there too - we can take advantage of post_status = draft, for instance, like WP post previews do.) Ray, assigning to you for the moment, as I anticipate that you'll be taking the lead on other forum-related improvements.

#9 Updated by Boone Gorges almost 7 years ago

  • Assignee changed from Raymond Hoh to Dominic Giglio

The UX for this has to be worked out. There are a few different ways it could be done (this is not exhaustive):

1) Dynamically display a preview underneath the post. Requires AJAX (JS for the DOM manipulation; PHP for running through the relevant filters). See how WP's Trac does it.

2) Display a preview underneath the post, but require hitting a Preview button first. Use either AJAX or a form submit. See how Redmine does it.

3) Display preview in a popup/lightbox on a button click. The preview would be minimally styled.

4) Display preview in a popup/lightbox on a button click. The preview would be styled exactly like the forum page, except with a large "This is only a preview" message.

In all of these cases, we should make sure that the text is run through the same save/display filters that regular forum posts are run through, so that we have some reasonable guarantee that the text will be a reliable preview of the final product.

There are arguments for and against all of the above - it really depends on what we're trying to get out of this feature. I lean slightly toward (1) and (2), though they won't work right with forum attachments.

Reassigning to Dom for exploration. Dom, any development for this feature should be done against a stock installation of bbPress 2.x. (Actually, something may already exist. Look around before you start building too much.)

#10 Updated by Dominic Giglio almost 7 years ago

I also agree that 1 and 2 are the ideal scenarios, with my top vote going to 2. I am not a fan of popup/lightboxes at all. I'm right in the middle of #1386 right now, so I'll start working on this as soon as I get something going there (unless you and Matt think this is more important than that feature).

I'm testing out the feature here on Redmine, and I have to say I don't really get it. What advantages does it offer, above and beyond just reading the text in the editing window?

Just so you know, I use the preview feature here religiously!! LOL I like being able to make sure my text formatting and grammar are as correct as they can be. When posting publicly I am always afraid that my words will make me sound unintelligent or ignorant, so I'm always re-reading my posts over and over. :-)

#11 Updated by Matt Gold almost 7 years ago

Thanks, Dom. If you're in the middle of work on the other ticket, I'd say that you should keep going with it.

#12 Updated by Dominic Giglio almost 7 years ago

OK, that issue is actually going pretty well. So it shouldn't be long before I can get to this.

#13 Updated by Dominic Giglio almost 7 years ago

Boone,

I really like the "live ajaxy" previews on BuddyPress Trac, what do you think about that kind of preview on the Commons?

#14 Updated by Boone Gorges almost 7 years ago

I really like the "live ajaxy" previews on BuddyPress Trac, what do you think about that kind of preview on the Commons?

It's cool by me. But I'm more concerned with what Matt thinks of that kind of implementation, as it's not (IMO) the typical way that forum posts are previewed on the web (insofar as there is a "typical" way).

#15 Updated by Dominic Giglio almost 7 years ago

That's a good point, could end up confusing more than helping.

#16 Updated by Matt Gold almost 7 years ago

Agreed. I'm not sure I can articulate what a traditional preview button does and what the difference between it and a "live ajaxy" version would be. Maybe that, when clicked, the preview button would reload the page with a version of what the comment will look like posted, with "Edit" and "Submit" below? I notice that here on Redmine, the preview is done without reloading the page (which I assume means its 'live ajaxy'), but I think that the preview versions I've liked in the past do a better job of showing what the comment will actually look like when it is posted.

Definitely open for discussion and for hearing thoughts about what would be best.

#17 Updated by Boone Gorges over 5 years ago

  • Assignee changed from Dominic Giglio to Boone Gorges

Let's go ahead and do something that is similar to what WP/BP Trac does. I'm reassigning this to myself for the time being.

#18 Updated by Boone Gorges over 5 years ago

  • Status changed from Assigned to Testing Required

I've implemented a first pass at this in https://github.com/castiron/cac/commit/e1ba360abb64ba7bc9478910d58b0342200eb218

It's basically a modification of the very slick system that Ray built for bbPress 2.x: https://github.com/r-a-y/bbp-live-preview I modified it to work with bbPress 1.x inside of BP groups.

It's active on cdev. Start typing a new forum post or a reply in a group. When you pause for a second or two, you'll see a preview pop up below. The preview is formatted in the same way that the post will be, with HTML, shortcodes, and oEmbed all rendered.

#19 Updated by Dominic Giglio over 5 years ago

Just checked it out on cdev...super slick and SO simple!! Really nicely done - both you and Ray!!!

#20 Updated by Matt Gold over 5 years ago

Very cool, Boone and Ray.

My only concern in our implementation is that it can be hard to notice that the preview is happening, in part because the ags text box in between the forum posting box and the preview makes it hard to see, and in part because there is no visual cue (a different color around the box, or something) that would indicate that preview field is different in some way than the other text fields on the page.

Chris, what do you think of this? Seems to me like a little UX touch could improve the legibility of the preview.

As far as the functioning goes, it's great. Many thanks.

#21 Updated by Matt Gold over 5 years ago

Also: I noticed that the preview rendered HTML tags (I tried the strong tag, for instance). Do our forums on the live site display html? Am I correct that our email notifications don't display them (so that text that looks bold because of the strong tag in the preview might end up producing an email notification that shows HTML strong tags rather than bolded text itself)? If so, we should be sure that the preview actually displays both what will be posted to the forum and what will be sent out via email notification.

#22 Updated by Boone Gorges over 5 years ago

Am I correct that our email notifications don't display them (so that text that looks bold because of the strong tag in the preview might end up producing an email notification that shows HTML strong tags rather than bolded text itself)?

Correct. Does this mean that you want to have two separate previews, one above the other?

#23 Updated by Matt Gold over 5 years ago

No -- I think that would be awkward. Maybe this isn't a big deal since we don't give a wysiwyg interface, encourage HTML tags, or note that they are possible. So, for now, let's just change the placement of the previews and separate them visually in some way; people who know enough to add HTML tags manually will discover quickly that the email notifications don't match.

and, since we're working separately on HTML email, everything will be aligned soon.

#24 Updated by Boone Gorges over 5 years ago

let's just change the placement of the previews and separate them visually in some way;

I'm confused - do you want two separate previews or not? Sorry for the confusion.

#25 Updated by Matt Gold over 5 years ago

Sorry on my part for the confusion.

1. Only one preview, which should show what the message will look like on the web when it is posted to the forum.

2. We should move the preview up so that it is directly under the posting text box or somewhere else where it will be visible.

3. We should mark out the preview visually in some way indicate that it is distinct from other text fields on the page.

#26 Updated by Boone Gorges over 5 years ago

  • % Done changed from 0 to 70
  • Estimated time set to 2.00 h

#27 Updated by Boone Gorges over 5 years ago

Another pass at this is available on cdev.gc.cuny.edu. I did the following:

- Added a blue border to the preview
- Moved it directly below the Content box

If you're still unhappy with the appearance (but don't have specific suggestions), let's reassign this over to Chris for help.

#28 Updated by Matt Gold over 5 years ago

Thanks, Boone! The positioning really helps, as does the blue box. Can you please try out a lighter shade of gray for the background of the preview text box?

#30 Updated by Matt Gold over 5 years ago

Thanks, Boone. Can you please remove the dark gray box around the previewed text (don't think it's necessary, and it clutters the page). two other small notes:

1. Is the gray color on the preview box the same shade of gray that is in the main text box when it is in an active state? It looks a shade darker to me, but that may just be a visual trick due to the blue border. If it's possible for them to be the same, I think they should be.

2. I notice that the text size is larger in the active main text box than it is in the preview window. I'd say that all text sizes should be the same unless there is a reason for them to be different.

Minor points, obviously. This is very cool.

#31 Updated by Boone Gorges over 5 years ago

Can you please remove the dark gray box around the previewed text (don't think it's necessary, and it clutters the page).

Can you please post a screenshot? I don't know what this refers to.

#32 Updated by Matt Gold over 5 years ago

Please see attached

#33 Updated by Boone Gorges over 5 years ago

Thanks for the screenshot.

Can you please remove the dark gray box around the previewed text
Is the gray color on the preview box the same shade of gray that is in the main text box when it is in an active state
I'd say that all text sizes should be the same

I've made all these changes in https://github.com/castiron/cac/commit/4d7ce414780586b8f718cdc56121feded8a2d490 and they're ready to test on cdev.

#34 Updated by Matt Gold over 5 years ago

Fantastic. Looks great to me. Just realized Chris wasn't a watcher and may want to comment. But I'm happy!

#35 Updated by Chris Stein about 5 years ago

Just took a look. It looks fine to me. Testing it out made me realize that you can't tell what is permissible in the forum fields (like urls will be turned into links, or how to add images). I think it would be nice to add some text about what you can enter or at least a link that explains more.

That could be a separate ticket but would be a simple add on to complement this bigger update.

#36 Updated by Matt Gold about 5 years ago

Chris - where would you suggest putting such information? Per earlier discussions in this ticket, I'm not sure we want to do anything to encourage HTML formatting in forum posts, since that will lead to lots of email notifications that contain HTML tags (at least until we create HTML emails). Maybe we should create a separate ticket for this so that we can work through the issues there and finalize when HTML email is ready.

#37 Updated by Chris Stein about 5 years ago

If we have time we can talk about it on Friday. But yes, I agree we should create another ticket to discuss this and what needs to be done when. I'll create one.

#38 Updated by Matt Gold about 5 years ago

We will soon have html emails so it shouldn't be an issue - can we strip tags for now so plaintext email notifications don't show tags? If so, will hyperlinks remain, or will they be stripped along w/ the <a hrefs>?

Chris, is there a redmine ticket as mentioned above? Otherwise this seems ok to close, and add to the codebase.

#39 Updated by Chris Stein about 5 years ago

There is a related ticket #3059 that addresses whether or not we should add explanatory text about what kind of HTML is permissible in the forums.

I'm OK with pushing that discussion to a further release (no version yet).

I recommend resolving this if no one has anything else to add.

#40 Updated by Boone Gorges about 5 years ago

  • Status changed from Testing Required to Resolved

Great. Thanks, Chris.

Also available in: Atom PDF