Veritula – Meta
#2753·Benjamin Davies revised 6 months agoIdea: Veritula Articles
Currently, Veritula is a discussion website. I believe it could one day do what Wikipedia and Grokipedia do, but better.
A step towards that would be enabling users to produce ‘articles’ or something similar.
An ‘Articles’ tab would be distinct from the ‘Discussions’ tab, featuring explanatory documents similar to encyclopedia entries, and perhaps also blogpost-like content.
Articles focus on distilling the good ideas created/discovered in the discussions that occur on Veritula.
Forget the term ‘article’ for a second. It sounds like you want the ability to post ideas without having to associate them with a discussion, is that right?
#2783·Benjamin Davies revised 6 months agoThese are not standalone pages in the sense that a Wikipedia page is a standalone page.
Articles would have the same ‘page’ status as the discussion pages that currently exist. (Forgive my lack of technical vocabulary.)
A possible counter-factual that may or may not be relevant to the goals of Veritula: An article with title metadata ‘Boron’ would presumably be much more search engine-friendly than a top-level ideas for Boron where the metadata title is ‘#[ID]’ and the actual desired title is merely included as the first line of the body text, while it is effectively a subpage of a discussion of another name.
‘page’ status
What is a page status? How did you determine that an idea’s page status is not the same as a Wikipedia article’s?
#2783·Benjamin Davies revised 6 months agoThese are not standalone pages in the sense that a Wikipedia page is a standalone page.
Articles would have the same ‘page’ status as the discussion pages that currently exist. (Forgive my lack of technical vocabulary.)
A possible counter-factual that may or may not be relevant to the goals of Veritula: An article with title metadata ‘Boron’ would presumably be much more search engine-friendly than a top-level ideas for Boron where the metadata title is ‘#[ID]’ and the actual desired title is merely included as the first line of the body text, while it is effectively a subpage of a discussion of another name.
As far as search engines are concerned, every idea page is already a standalone page. Not an SEO expert but I cannot imagine search engines penalize URLs containing an ID.
Done as of a12ffb3, see eg https://veritula.com/discussions/veritula-meta/activities and the new link to ‘Activity’ at the top of each discussion.
I could simply give the footer the same background color as the rest of the page.
I could simply give the footer the same background color as the rest of the page. There’s a discrepancy between light and dark mode anyway. And on horizontal overscroll, the difference in background is painful.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black gap underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black gap underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear; seems to be a Brave quirk.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.
#2793·Dennis HackethalOP, 6 months agoI could simply give the footer the same background color as the rest of the page.
That wouldn’t remove the gap.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black gap underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.
#2791·Dennis HackethalOP revised 6 months agoIn Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the
htmlelement, which becomes apparent with scroll inertia on the bottom of the page.
I could prevent vertical overscroll.
#2791·Dennis HackethalOP revised 6 months agoIn Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the
htmlelement, which becomes apparent with scroll inertia on the bottom of the page.
I could simply give the footer the same background color as the rest of the page.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.
On iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.
On iPad, the footer doesn’t extend all the way to the bottom of the page.
On iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer.
#2700·Dennis HackethalOP, 6 months agoI can still reproduce the issue by clicking on the button to collapse/expand an idea.
Fixed as of 0178828.
#2626·Dennis HackethalOP, 6 months agoChanging the query on the search page moves the cursor to the start of the query input. It should move to the end or, ideally, keep its position.
Done as of 765ba05.
typo
These are not standalone pages in the sense that a Wikipedia page is a standalone page.
Articles would have the same ‘page’ status as the discussion pages that currently exist. (Forgive my lack of technical vocabulary.)
A possible counter-factual that may or may not be relevant to the goals of Veritula: An article with title metadata ‘Boron’ would presumably be much more search engine-friendly than a top-level ideas for Boron where the metadata title is ‘#[ID]’ and the actual desired title is merely included as the fist line of the body text, while it is effectively a subpage of a discussion of another name.
These are not standalone pages in the sense that a Wikipedia page is a standalone page.
Articles would have the same ‘page’ status as the discussion pages that currently exist. (Forgive my lack of technical vocabulary.)
A possible counter-factual that may or may not be relevant to the goals of Veritula: An article with title metadata ‘Boron’ would presumably be much more search engine-friendly than a top-level ideas for Boron where the metadata title is ‘#[ID]’ and the actual desired title is merely included as the first line of the body text, while it is effectively a subpage of a discussion of another name.
#2768·Dennis HackethalOP, 6 months agoRight now, to get a good sense of an idea on Veritula, a user often has to study a branching discussion, which can take a lot of work depending on how the discussion played out.
While this is true for most existing discussions, it’s not a fundamental limitation of discussions in general. For example, ‘How Does Veritula Work?’ has several long-form posts without much discussion. It just depends on what kinds of posts people want to submit.
I think it is worth noting that I am much more excited to publish standalone articles than to drop top-level ideas into discussion topics.
I am not marking this as a criticism, as my personal desires in this respect may be irrelevant to the goals of Veritula.
#2766·Dennis HackethalOP, 6 months agoTop-level ideas in a discussion thread are not standalone pages.
Every idea (including every top-level one) has a separate, linkable page. You can reach it by clicking the link starting with the # sign.
These are not standalone pages in the sense that a Wikipedia page is a standalone page.
Articles would have the same ‘page’ status as the discussion pages that currently exist. (Forgive my lack of technical vocabulary.)
A possible counter-factual that may or may not be relevant to the goals of Veritula: An article with title metadata ‘Boron’ would presumably be much more search engine-friendly than a top-level ideas for Boron where the metadata title is ‘#[ID]’ and the actual desired title is merely included as the fist line of the body text, while it is effectively a subpage of a discussion of another name.