CUNY Academic Commons

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.

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?

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.

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.

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. :-)

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

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

Boone,

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

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).

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

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.

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

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.

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.

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?

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.

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.

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.

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.

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?

Changed in https://github.com/castiron/cac/commit/0068c210b64e0ca86a60c57f21cf77c91dc0a88b and ready to test on cdev

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.

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.

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.

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

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.

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.

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.

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.

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.