Hey, Mastofriends, I'd like some help/feedback on a thing.
I'm building an open source platform for hosting web comics. I want it to be safe and usable by as many folks as possible, out of the box. But before I get too far into a rabbit hole of difficult-to-change design, I want to ensure I consider all the options users would actually appreciate in a community platform like this will be.
Linked below is my current list. Thoughts?
Here's a post about the new home I need to get before I can go live. Help me out and chime in?
@danhunsaker The only things I think are worth mentioning are: it's much better if it generates static pages for all of the viewable surface of the comic and its archives instead of GETs to programmatic endpoints, as this is not vulnerable to any obvious attack from the basic comic viewing standpoint.
All font weights are in ems instead of px values so they respect browser font size specifications.
Links Are Links and Buttons Are Buttons
@kelbesque Hmm. I'll have to investigate the static approach. Makes sense from here, other than aspects that need to care about who is logged in, such as commenting systems and the like.
I mean, _nothing_ should be in px on a decent site... Pretty sure it's in the W3C accessibility guidelines that I purloined for that section of the list, but I'll be sure it's explicit in the list itself.
As much as possible, yes! Otherwise, there are attributes in the standard for pointing out exceptions.
+1 to static approach. I was actually thinking about writing a similar thing when I was investigating different options for my https://glider.ink/
I think it would be great to support different possible layouts: strip, page, maybe loading whole-page images panel-by-panel to support responsive web design? That's still doable in static.
Many of the user safety and other community features rely on hitting a programmatic endpoint at some point, frequently _before_ loading the comic page itself. For example, some posts and pages won't be accessible to everyone. Others will need to avoid loading sections of the content to satisfy user-defined filters on content and such. Much of this _can_ be done with static pages, but relies on JS working properly to actually work.
The panel breakdown option is intriguing. I'll explore...
Forgot to mention, emphasis on the User Safety section, since most of the rest is covered by standards like OWASP and WCAG and all the stuff put out by the W3C I18n Activity. ☀
RSS Feeds are on the list! (They're easy to miss, though, at the very very top.)
Accessibility agrees that JS should be minimal, yeah. 🙂
Click to advance is one I'm a bit torn on, since there may be cases where click to enlarge might make more sense, but I'll probably make it configurable unless whatever UI/UX designer I bring on has a better idea. At the very least, pagination bars both above and below are already in!
Labeled sequentially? As in, by number? If so, done!