Feature suggestions and discussion [READ THE FIRST POST]

@Brokedownandmadeone  
Well, sorta. In the end as long as the preview doesn’t rely on ajax, relying on a click vs change event isn’t really a big deal.

@Background Pony #5B7B  
(and it does use ajax, so it makes perfect sense that a live preview would be a bit of a mess)

Having it so that the entry box is still visible over the preview, even if it wasn’t live, would restore a lot of the convenience of the live version.

@Keith Mowz  
I think you mean above, not over. You’d still need to hit the preview button again to get a preview. I don’t really see the point; it’s cleaner (less stuff jumping around) to hit a button to edit and another to see what the result will be.

The ability to close your own reports.
 
_{Oh, God, this better not be in the main post.}

@Princess Luna  
It sounds significantly more convenient to have a button instead of a separate tab to me.

@Princess Luna  
it’s cleaner (less stuff jumping around) to hit a button to edit and another to see what the result will be  
It’s… not at all, though. If you’re making multiple edits, jumping around is most of what you’re doing with the way it is now; if the text entry field stayed separate from the Preview, you wouldn’t have to keep bouncing back and forth between them, you could make the edits as you find occasion for them and just check the result once at the end.

@TexasUberAlles  
Looking at this from a use case perspective, because I’m very interested in user interface design, how is clicking on the current “Preview” tab different from clicking a preview button?
 
In both cases, the preview is not generated until it is requested.
 
Is there an advantage to having a potentially out of date preview visible while editing?
 
I’m asking because one clear disadvantage of a concurrently displayed preview that is not being automatically updated is that the preview is not live so a user might click “Post reply” based on a preview that doesn’t show the latest edits. And that seems like a bad thing.

@Ciaran  
how is clicking on the current ‘‘Preview’’ tab different from clicking a preview button?  
If all you’re doing is checking that your syntax markups agree and hitting [Post reply], there’s no real problem; but like I said, if you’re making multiple edits it’s just extremely clunky and annoying to have to keep bouncing back and forth between Write and Preview. Especially in a long post where there might be many typos to correct and sentences to rearrange and dangling syntax to fix and content edits to make, being able to read through the preview and fix whatever needs fixing one after the other as you find it is much more convenient than having to go back and forth and back and forth and back and forth and…
 
a user might click ‘‘Post reply’’ based on a preview that doesn’t show the latest edits  
That’s what Edit is for. It seems like an edge case anyway, since a user would already have had to click [Preview] to get there in the first place.

@TexasUberAlles  
You can post today without having to preview - that could be changed of course, forcing a user to preview before submitting, but I kind of like being able to just hit the “Post reply” button without previewing, because as you said; edit.
 
But I think I understand what you’re describing, and have had similar problems myself. Of course, I tend toward walls of text, and sometimes I wonder if the kinds of comments I’m posting are really what the system was intended to be used for.

@Ciaran  
forcing a user to preview before submitting  
Boooooo, that would be bad, yes.
 
Being able to click on [Preview] and get an update without having to drop the text entry field to do it just seems like it would be the best of both worlds, assuming it wouldn’t require a massive effort on the coding side of things; it’s a lot more streamlined and stable than the old constanty-updated preview, but leaves the ability to make changes on the fly without switching back and forth like the current one-or-the-other system.

@TexasUberAlles  
plus, it’s how it works on basically every forum i’ve ever used

@Ciaran  
I actually I agree with this. From a web design perspective it seems like a really bad idea to leave an old preview visible while you’re editing. Live preview or hide the preview while editing does seem logical.

Would it be useful if all canon character tags were displayed under a unique color? It could be used to automatically imply “solo” for images only containing a single oc:x or character tag.

@Background Pony #5B7B  
That would create a lot of false positives from images that have one named character and a bunch of BPs.

@TexasUberAlles  
Didn’t think about that. That’s true.

@Background Pony #5B7B  
Also species and gender implications if gender swap or species swap isn’t tagged. I’m sick of all the gildas not tagged Gryphon.

@GyroTech  
Uh. We don’t do that? Tagging Gilda as gryphon is like tagging pinkie pie as earth pony. It is their default setting.

@Keith Mowz  
Well, you say that …
 
Tagging the mane6 with their species is not an uncommon practice.

@Ciaran  
Yes I am aware some brain donors do in fact do that, but the general consensus whenever such a thing is pointed out is “That is stupid, pedantic and pointless.”

@GyroTech  
@Keith Mowz
 
I don’t think GyroTech is either a brain donor or stupid. That you find it pointless and pedantic doesn’t mean it’s that way for everyone, or that those in the minority don’t have a valid use for the tag.
 
Please try to be less derogatory.

@Keith Mowz  
I do wish stuff like “default” things were tagged, because, for example, doing a search for “pinkie pie, pony” is so much easier than “pinkie pie, -anthro, -semi-anthro, -humanized, -etc”.
 
Not to mention I can’t filter out EQG humans without also filtering out images related to EQG in some way that don’t involve humans (for example, ponifications, Spike the dog, plot elements, and so on) because we don’t actually tag those as human, but that’s another topic.

@Keith Mowz  
Gryphon is used almost universally on all other Gryphon characters. And I watch the tag Gryphon cause I have an affiliation for them. Not every picture tagged Gilda actually includes a Gryphon… Some are humanized or shit like that, and sometimes hey Gilda is a Gryphon and something else is humanized or w/e. Pedantic tagging is useful for things such as references as well.
 
I suppose maybe it doesn’t help you, but there are, in fact, plenty who would like such things.

@GyroTech  
@Ciaran  
@SuperSupermario24
 
We don’t enforce tagging defaults though. It’s assumed that “Pinkie Pie” would be a female earth pony. Exceptions to that (rule 63, anthro, etc) should always be tagged, but there’s no rule saying you have to tag Twilight Sparkle as a unicorn or tag Applejack as a pony, etc.
 
Personally, I feel like adding all those character default tags just clutter up tagging. Especially when it comes to groups - imagine a picture of the Mane Six and Spike, you end up with {female, male, unicorn, pegasus, earth pony, alicorn, pony, dragon} - basically killing any distinction those tags would have added to begin with.

@Joey  
That’s true. I know I still do that mainly because of habits I picked up when I started here, and with the exception of things like distinguishing between Unicorn Twilight versus Alicorn Twilight it is of questionable use for default cases.