Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Post History

80%
+6 −0
Q&A Some things I observed as I started poking around Codidact

Thank you very much for this feedback. Seeing our platform through the eyes of a newcomer is very valuable, and there's a limited time window to capture those impressions. I'm going to comment on...

posted 11mo ago by Monica Cellio‭

Answer
#1: Initial revision by user avatar Monica Cellio‭ · 2023-12-12T01:52:29Z (11 months ago)
Thank you very much for this feedback.  Seeing our platform through the eyes of a newcomer is very valuable, and there's a limited time window to capture those impressions.

I'm going to comment on some of the points you raised without attempting to cover everything, in the interests of doing something sooner rather than waiting for everything later...whenever later comes.

## Votes and scores

There's been [recent discussion](https://meta.codidact.com/posts/276749) of this, and I'd like us to explore other ways to present this information.

Over on SE I was a moderator on Workplace, which was a magnet for controversial posts that attracted lots of attention, so I've seen the struggles, within a community, caused by a snarky borderline-troll +200/-30 answer dwarfing the actually-good +50/-1 alternative.  I saw a community frustrated that its regulars, the people who were actually there for the community, lacked real agency over visiting vote-bait.

I want us to show, somehow, when an answer is controversial -- whether that's raw votes, a graphical representation, or something else.  I hope we can find a way to do that cleanly.

## Reactions

Reactions can be defined per-community.  By default there are three (communities can create more):

- outdated
- works for me
- dangerous (which requires an accompanying comment)

Here on Meta we've turned off the latter two; it's hard to imagine a Meta discussion actually being _dangerous_, and aside from support questions or workarounds for bugs, "works for me" didn't seem helpful.  But now that you mention it, offering a "reactions" control but showing only a single option, with no indication that there could have been more, can be confusing.  I"m not sure what to do about that yet, but I want to acknowledge the problem.


## Comments

> Comments are discoverable without being intrusive. I like the idea of thread titles and that each post may have multiple comment threads. Nice that they seem to support full Markdown too. Maybe add a preview pane while I edit?

Yup -- [on our to-do list](https://github.com/codidact/qpixel/issues/1270).


## Posting

In the post editor:

> I'm not sure why some items are under the wrench/screwdriver button and I'm not sure why it's wrench/screwdriver rather than, say, the ellipsis icon (...). 

That is a good question.  I'm typing this in a browser on a desktop machine, where there's room for more buttons.  I wonder if this part isn't properly responsive and that's an accommodation for phones?  But we have responsive design elsewhere.  I will try to find out.  (Also, I just checked, and on my phone the buttons are in two rows.  So it's not that.)

"..." sure seems to have become the standard for "more stuff back here", so I think we should consider changing that, too.

> I think I like having a save button, but I can't tell if my work is autosaved as well?

Work is auto-saved, but if you've just typed some complicated MathJax or gotten that explanation _just right_, our thinking was that you might want to save it right now and not have to wait, just in case.

And speaking of auto-save:

> It took some time to work it out, but on my screen the "draft saved" message adds a line to the bar, which shifts the preview down by a line too. It's really distracting! If that message is going to be displayed, make sure to save the space so that the preview doesn't shift shortly after I stop typing.

Aiiieeeee.  Cannot unsee.  I wish my Javascript were good enough to fix this myself right now, but it's not so I've filed a [bug](https://github.com/codidact/qpixel/issues/1272).  I think this is an unintended consequence of another recent change and I'll ask the team about how to best fix it.

> I really like the countdown to know how many characters are needed to create a post, but the countup to 30,000 keeps grabbing my attention since it changes every time I type something.

Would it be better, when you're not near either end of the range, if we updated this less frequently?  Would it be ok if it still says "3750" when you're really at 3792, if it updates when you get to 3800?  If we were to take this sort of approach, what would be a good step value?  Assume that when you're under the minimum or within, say, 5% of the maximum, we'd still do live updates to reduce frustration from over/undershooting.

We considered not showing the number _at all_ unless you're near a boundary, but informal feedback suggested this would be frustrating.  We haven't done more stringent user testing.

> I know why there is an option to select a license for each post. Having a default per community seems reasonable. It's not clear to me what "category default" meant until I poked around and found the category list. Two defaults seems . . . extra complicated? Especially for my first post, this choice caused me to spend several minutes researching licenses, which is several minutes more than I needed to just accept the default.

I see your point.  In an effort to provide the flexibility our communities requested, we made things difficult for a newcomer to navigate.  And the license choice for a post is necessarily immutable, so we can't just say "you can fix it later".  (Letting people change a post to a more restrictive license after the fact seems to require more complexity in the UI than we thought was worth it.)

The category default was added so that a community that accepts original content -- photo contests or code reviews or writing challenges, for example -- could set a more restrictive default license for just those categories, protecting posters who don't realize they're about to release their work under a generous CC license.  *Most* of the time the community and category defaults are the same, and in that case maybe we can skip mentioning the category one at all.  Or maybe we should just show "default" and apply the most specific one.  Would it be confusing if, on the same community, you saw different defaults in the "challenges" category and the Q&A category?

> If you want to support someone who insists on CC0 or some other specific license, make that a per-user setting.

[Actually...](https://meta.codidact.com/users/me/preferences)


## Help

> I don't understand how the help page is organized. Oh wait! It's alphabetical by the title of the article. That's why "Advanced formatting help" comes before "Formatting Posts". 

By default, but we could do better on that.  It's possible to specify the ordering of topics.  We just...didn't.  Oops.

> I can sorta understand the difference between "Site Information" and "Guidance", but I'm not sure I understand why they should be separated. SE help is divided by function (ask, answer, review, etc.), which seems like a reasonable way to divide things.

We should revisit that now that our help has grown beyond the half-dozen or so topics we had originally.