Arbital community input

by Alexei Andreev Dec 19 2015 updated Aug 5 2016

Do you have ideas about how to improve Arbital which you think the community should discuss?

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.


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


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

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 , and having audio/video support would be very good for the long term, but these seem less vital to me than something we can use to make tables.

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:

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 . Root threads may be in separate cards, but nested comments are rendered as parts of the whole with implied boundaries.

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.

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:

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

Links to blank articles will appear the same as links to non-existent articles

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.

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

Eric Bruylant

Feedback system / incentivising valuable criticism and productive response

Partly inspired by Brienne's post (and Eliezer's reply/the thread following it).

The trick to preventing flame wars when stating criticisms publicly is to always provide an alternative method for regaining status.

Or you could just send the message via PM. To first order and with obvious exceptions, you can classify Bad/troll/statusseeker anyone publicly pointing out something in a push-downy way who also publicly claims to only be concerned about you, and classify 'Good' anyone who points out exactly the same thing in a private message.

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