We want to hear what readers and editors have to say! Many great suggestions and future features have come from the community. This is the place for you to speak your mind about what you want to see from Arbital. Anything goes: feature requests, policy suggestions, UI changes, strategy advice, etc…
Recommended use: create a comment or child page.
Another way to submit feedback is privately through the Feedback button in the Quick Menu, or to visit #features on the Arbital Slack.
Comments
Eric Bruylant
Recent Changes / Edit Review system
On traditional wikis the recent changes page is a hub for contributors, often the first visit of the day for an editor checking what's new, or a potential editor checking the pulse/health of a wiki they may get involved in. Alongside it are the patrol systems, essentially checking over various changes which may require attention, and attempting to filter out vandalism.
For arbital to be vandal-resistant, we will need something which fulfils the same functions, most importantly making sure damaging edits don't slip under the radar. Additionally I suspect their systems could be dramatically improved upon. The main changes which come to mind right now are:
Eric Bruylant
Citations
Making citations easy to create and maintain will cause more people to use them. Arbital may be less citation-centric than WP, but they're still very valuable. MediaWiki's system is the only one I know much about and works pretty well, but there are other approaches (blog post on markdown citations).
Eric Bruylant
Transclusion / Template system
Templates and Scribunto power most of the strucured information across Wikimedia (exception: Wikidata), most notably the infoboxes, links to related pages, and notice templates, but also a huge number of other specific functions. They are an incredibly flexible tool which makes it possible for users to create and maintain things that would never be done if each page had to be updated by hand, and hides complexity from less technical users who can easily include them in pages by copying existing examples.
This is not an easy feature to get right, but something which fills their function is essential to attract editors from any existing mediawiki wiki.
MW started off with basic transclusion+parameters, then added various parser functions in a way which turned out to be ugly and inefficient to the point where they were forced to add (limited) lua scripting.
(WIP, will come back to this with more thoughts)
Eric Bruylant
Seems like there's main two parts:
How do we make it intuitive for editors
Displaying template parameters in the text scales badly, is not a natural way of entering information, and generally scares away editors. My current best idea for solving this is copying TemplateData's method (click on the infobox template, it lets you open a form to edit template parameters), but have the template call code highlighted in source editor (), and make clicking that bring up a form to edit the parameters.
A bonus is storing the parameters separately makes it much easier to reuse the structured information.
What features does it need to be handle the major use cases
Essential:
Important
Would be good:
Wishlist:
Eric Bruylant
(This part was written first, but the conclusion/outline seemed more valuable than this background thought) I realized why I'm struggling to come up with good ideas for this one: I only really know much about MW's system.
So, did a bit of research into how it's done on other software. They mostly do similar things, and all major wiki software includes some form of templating, but many have different takes on the core idea (e.g. Cofluence is clearly optimized for non-technical users).
Misc thoughts/findings:
Some other links:
Eric Bruylant
Allow (slightly) more HTML
This engine does allow a subset of HTML, but it's extremely limited. This makes some sense for a QA site, but not being able to use either tables or divs will be really annoying for a blog/wiki, and rules out user-created WP style infoboxes, sortable tables of data, and a lot of other things. I imagine you'd need to alter the whitelist to allow the tags (and certain safe attributes?), perhaps ordinary title would check implementation/advise? And for sortable tables you'd need to pick some table sorting .js. Alternatively there are extensions of markdown which allow tables, but that seems likely to be more complex to implement.
There are other tags which would be nice to have access to such as and
Alexei Andreev
I think it's inevitable that we'll need to build our own editor. I'm not at all sure what that will look like yet, and it'll be a huge undertaking, so for now we are stuck with hacking on top of the current editor.
Eric Bruylant
After discussion, allowing a few pre-defined classes and adding table to the whitelist would capture most of the value of full styleable tables (though in the long term styling would be good, either as an extension of this editor or in our own editor).
Classes should give the ability to create something akin to this and this (preferably including both optional sorting and colored backgrounds with a decent collection of available colors), as well as handling simple infoboxes and image containers (a border and slightly tinted background is fine).
Eric Bruylant
Posted date on blog pages
It's often important to know when a blog post was made. The originally posted date should be shown somewhere, possibly next to Owner, possibly under the title?
M Yass
Tree-Structured Comment Sections
Currently the comment system seems to be limited to one level of indentation. Although one level of indentation is very good, full nesting would be better. I guess it might be argued that full nesting wont be needed here, but I wouldn't bet on that. Full threading has its own implementation challenges though. Eventually comments will hit the right side of the page and become unreasonably compressed. I can think of two solutions:
The more straightforward solution: render comments at the deepest displayable depth with their subthreads hidden, then serve comment permalinks as separate pages, where the subject comment is rendered as a root thread. To read replies to comments at the depth limit, the user goes to their parent's page.
Something I havn't seen done: Comments just keep going right, but they don't compress. Comment views will have to be horizontally scrollable.
If you were going to increase the depth limit, you'd probably want to rethink the gratuitous consumption of whitespace that's going on in the current style. I'm more partial to the way reddit's material design themes tend to do things https://i.imgur.com/6dHto8n.png . Root threads may be in separate cards, but nested comments are rendered as parts of the whole with implied boundaries.
M Yass
lol I can like my own comments. Dunno if that should be fixed or not. A user liking their own comment.. it is is information, which might mean something, though one gets the sense that it's usually going to be dishonest information, that doesn't mean what it appears to mean, which probably makes it an anti-pattern
Alexei Andreev
Thanks for the feedback. :)
Yeah, there is a lot left to do on the comment side. That's going to be the next area of improvement.
Yeah, you can like your own comment and pages. The reason is that indeed it is a valuable signal. We are going to end up treating likes somewhat differently than most platforms, so this will come in handy.
Eric Bruylant
I'm skeptical of infinite nesting. It does help in some cases, but disrupts the vast bulk of threads visually and adds a complicating decision to replying. Longer chains with branching are horrible to navigate, and the replies get shifted ever rightwards. This puts a limit on the effective number of replies (even if you subthread it like lesswrong, having to click through is clunky inconvenience), which is much worse than the problems caused by lack of nesting imo.
You can gain much of the advantage of infinite nesting without any of the major costs by creating a "reply in new thread" option for those cases where it really is important to reply to different parts of a post separately, which creates a post linking to the new thread.
Having strong norms of "one topic per top level comment" (possibly mod-action splitting posts for a while, or having a way to give feedback suggesting it easily) would also reduce the need for heavy nesting, and organize discussion more neatly.
Emile Kroeger
I, for one, am fine with the current, simple comment system. It's close to what's on Stack Overflow (which also has two layers with extra constraints on replies to comments), which seems to work fine.
Eric Bruylant
Uncategorized Pages Page
This, combined with a good way of navigating tagged/categorized content, would make Arbital's content more discoverable. Importantly, it would make it easier to keep track of pages which may otherwise fall through the cracks and not get noticed/interlinked with other content/correctly categorized.
Alexei Andreev
Yes! That's going to be the major priority in the upcoming months.
Eric Bruylant
Navigation for the tree of information
Implementing something like MediaWiki's CategoryTree, but making it a bit more well designed/intuitive/flexible would give a powerful tool for making Arbital's content easy to explore which would be maintained mostly automatically by tags and subtags.
Brainstorm for improvements:
Alexei Andreev
Funny enough we had something like that in an older version. We'll definitely bring it back. One way it would be super useful is for refactoring tags & parents.
Eric Bruylant
Cool, show me the designs/plans when that moves near the top of your list for feedback?
Alexei Andreev
It's super standard explorer type look (but obviously much larger).
Eric Bruylant
nods, seems pretty similar to MW's CategoryTree? It's good to have, but it could be much more awesome with attention. Especially if tags cause complex trees, it'll allow smoother content discovery with a more optimized setup.
What's the plan for navigation back up the tree? If the top level tags are always exposed things could get very messy (a bunch of layers, and possibly multiple paths back to them, since unlike a file tree each page can have multiple direct ancestors, unless you only include parent/child relations.), and if not you need another way to step back up.
Edit: I asked about the name of the UI I'm talking about on StackExchange. Some possibly helpful comments there.
Edit2: It seems like it's allowing multiple parents that breaks the normal navigation things. Maybe some hybrid would work.. I'll do a mockup of what I'm imagining at some point. The UX people are not familiar with it. Probably complex+no third party drop in, so probably quite far down the wish list, even if it would be awesome.
Alexei Andreev
Sounds good, I'd love to see a mockup. Eliezer Yudkowsky, might have ideas about this.
Eric Bruylant
Import from Mediawiki XML
This would make moving other wikis here significantly easier. It's probably best to do the EA Wiki by hand anyway, so not urgent, but it will be required for bringing larger wikis on board.
Eric Bruylant
Pure Wiki Deletion (page blanking creates redlinks)
Handling deletion on wikis is delicate, since it renders user generated content hidden from the user and the world. Wikipedia handles this poorly, but their users did come up with a beautiful solution (which never got implemented):
This removes a large part of the need for administrator intervention (providing some barrier to detached bureaucracies forming, and giving editors the power to remove their own content from view without requesting admin intervention), while making deletion transparent, open, and reversible. The normal deletion mechanism would stay, but only be used for illegal or banned content. The page linked has detailed reasoning about pros and cons.
Alexei Andreev
People can already delete their pages on Arbital. You can bring it back by reverting to a previous edit.
We won't make the page appear blank, because there is no reason to reuse an existing id. You can remove the alias from the old page, create a new page, and assign it the alias.
Eric Bruylant
Ah, okay, current arbital deletion already corresponds to this. Good :). (tests), deleting a page in my group made it inaccessible? I can still access the edit screen/reverse if I know the url though. Maybe having deleted pages show a "this page has been deleted, click here to view the edit history" thing would be better?
Also, if all deletion is soft/reversible by everyone, there's no tool to actually remove things from public view, which may be problematic on rare occasions where making it hard to find is not enough (e.g. illegal content), so eventually there would need to be another layer of deletion which renders it visible only to staff. Probably low priority though.
Alexei Andreev
Yeah, that's a bug.
Yes, hard delete will be a thing too.
Eric Bruylant
Blog header
Blog pages kind of feel like just normal pages. Having a header which is placed either above page title (and usually large) or below replacing the parent line (and small) would go a good way towards fixing this. Maybe having both available would be best? The header could be defined on the main blog page in a similar way to summaries.
Mockup (includes post authorship), Mockup (text), Mockup (banner).
Alexei Andreev
Agreed. Blogging will be one of the major areas we focus on after the announcement. (He keeps saying.) Jessica Greenwalt.
Eric Bruylant
Feedback system / incentivising valuable criticism and productive response
Partly inspired by Brienne's post (and Eliezer's reply/the thread following it).
Some form of negative feedback seems necessary, but most I've seen arguably do significant harm, while not appearing well-optimized for improving users conduct.
Major classes of negative feedback:
All fail to offer a good way of regaining status, and the only options which are private require valuable staff-time to evaluate reports.
We can do better, I think. My first draft proposal is:
Allow feedback on any edit or comment. This is non-public, but viewable by users with sufficiently high karma. Give the user the option to reply (with reply also viewable by high karma users), and mark the feedback as valuable or not valuable. Reward users who give feedback judged as valuable with karma (with limits on how much you get per person to avoid trading feedback). Possibly make feedback marked as valuable (optionally?) viewable to more users, more transparency would help good norms be shared, and it needing to be approved/replied to first means there's less feeling of attack/status hit than otherwise.
This way there's:
Caleb Withers
Is there merit (I imagine the main trade-off would be in UX/added complexity) in allowing two responses: one that accounts for others' views and those that don't? When I respond to a claim, I'll often see people whose views I held in higher esteem than my own initial views, and largely adjust towards them. However, if everyone's doing this, there's a missed opportunity to refine the community's underlying world-models by picking up when someone would strongly diverge from consensus in the absence of 'meta-modesty'.