Some small updates over the past week
A decent number of smaller changes have been implemented over the past week, and while I don't think any of them individually were worth devoting a post to, I figured it would probably still be good to let people know. If you're interested in following Tildes's development more directly, you can always keep an eye on the commits on GitLab (an RSS feed is available as well). I try to write good commit titles/descriptions, so anyone should be able to follow what's being changed without needing to be able to understand the actual code.
Anyway, here are some recent updates:
- Last week, I tried to add a "back to top" button on mobile and broke the site for a lot of people. I reverted it and haven't tried to re-implement it again, since it seemed like a lot of people didn't like it anyway. I'd be interested in hearing feedback about whether that's still something that many people want.
- @what added a new dark theme called "Atom One Dark". It's pretty nice, give it a try if you like dark themes.
- @wirelyre fixed the very first issue ever created on the Tildes repo. Markdown includes support for embedding images with a syntax almost exactly like a link, except with an exclamation point in front:
. However, since Tildes doesn't allow people to embed images, anyone attempting this would end up with an escaped<img>tag inside their post. It's fixed now so that it just treats an attempt to embed an image as a link to the image instead. - As requested, I added the ability to "quick quote" when you're going to post a comment reply. If you select some text from a comment before clicking the "Reply" button, the reply form will start out with the selected text already quoted for you.
- Subsequent quotes in comments are now merged by default. Previously, if you were quoting two or more paragraphs by putting
>in front of them and you had a blank line in between them, you would end up with a separate quote block for each paragraph unless you also put a>on the blank line. This behavior was clearly unexpected most of the time and people ended up with longer quotes broken up into many quote blocks for no reason. I've now changed it so that it will automatically merge subsequent quote blocks into a larger one, but you can still force them to be separated by putting at least two blank lines between them (or other methods like using a horizontal rule between quotes). Info about this was added to the Text Formatting docs page. - For about the last month, we've been showing domain names for link topics and usernames for text topics in the listings, but some people (rightfully) pointed out that this isn't very good for groups like ~creative where it's important to be able to see who's posting a link. I've updated it now so that I can change this behavior on a per-group basis, and for now, both ~creative and ~music will always show the submitter's name, even on link topics.
I've topped everyone back up to 10 invite codes again as well. With the site being publicly visible now, I know that some people are getting requests for invites and have been using them fairly often, so always just let me know if you need some more. You can get your invite links from here: https://tildes.net/invite
Let me know if you have any feedback or notice any issues with any of the things I listed above (or anything else). Thanks as always, it's been nice to see the site's activity level moving up again lately.
The new dark theme is awesome! Much prefer it to the default one. Great work @what
I agree! It's the theme I use for coding and in my terminal as well. Stoked to have it on Tildes!
It's definitely interesting. It makes me feel like there's a white layer with very low transparency over a dark site (sorry, photoshop experience bleeding into my description), but that's not necessarily a bad thing. Photographers use it to add a "haze" to images in certain cases. I like the lower contrast between text and background, and I like the vibrant highlight colors.
Sorry if this is a silly question but how do I enable the dark theme
Yep! Instant favorite
Glad to hear people like the Atom One Dark theme! I only used Atom for a short amount of time, but it's theme has stuck with me for a long time in my terminal, Vim, VS Code, etc. I really like the contrast between the text and background - readable, but easy on the eyes, and I love the vibrant highlight colours (make sure you check out the comment label colours!).
Also thanks @Deimos for making some fixes to the theme, looks much better now!
I found it useful in the very brief time it was available. :)
Nice. I haven't got into the habit of using this again yet, but I remember it well from Reddit.
Cool.
I still think the submitter's name should be visible in all groups. <shrug>
Ah, that quote block change is very nice. I've always had issues with that in markdown.
Regarding recent changes, I still feel that approximate reading time would be a better metric than word count next to articles. Has there been any further consideration on that issue?
I'll be trying out the new dark theme to see how it suits me.
edit: I've decided I like it!
People can read at pretty different speeds so I don't think I'd want to display a reading time by default. That just ends up with everyone having to do their own personal adjustments to it in a different way ("I read faster than it uses, so 10 minutes means 8 minutes" kind of stuff).
It would be pretty easy to allow users to set a reading speed (in words/minute) in their settings and display an individualized reading time based on that, but I don't know if that's in enough demand to be worth implementing.
I think the mental conversion that you mentioned really isn't so different than the current situation. With a word count, you still need to convert that into a personalized time (eg. 12,000 words == X minutes). I suspect dealing with smaller numbers (8 minutes) is much easier and faster to convert while skimming headlines.
I've written a whole lot of refutations to these sorts of arguments here, there's lots of workable solutions that won't result in the sort of complaints you're expecting.
I personally find that estimated reading times are way off for me; I'm an unfortunately slow reader. It's not a big deal either way but I find it nice to see the word count.
Yeah, the way it was supposed to work (which is related to the reason it broke) was that it would only show up once you had scrolled down at least two whole screen-heights from the top of the page. Short pages wouldn't have enough scrolling for that to even be possible, and the threshold could probably be set higher than that.
On the technical side, I implemented that by using a not-fully-supported browser capability called the "Intersection Observer API". I added an invisible element to the site that was two screen-heights tall, and used this API to say, "whenever this element isn't on the screen, make the 'back to top' button appear". So it would only show up when you scrolled down far enough to be past that element, and would disappear again if you scrolled back up inside its area again. However, since some browsers like mobile Safari don't support that API (and I wasn't checking for support before trying to use it), it just ended up breaking the site's Javascript for those browsers entirely.
You can use a reactive polyfill to add support of newer features. I used it recently when developing a scrollspy feature for a website. It checks your user agent and only provides the polyfill code when it's necessary, with decent support (down to IE9? gotta check).
Insert this into the page code:
<script src="https://polyfill.io/v3/polyfill.min.js?features=IntersectionObserver"></script>(and also, yeah, check polyfill.io for support depth)
It's CDN-tier speed, so loading time isn't going to be an issue when put against the comfort of the feature.
EDIT: also,
200vhon mobile is, maybe, 600 pixels. Your garden-variety up-button appears past 100 pixels at best.It's a neat service, but Tildes doesn't use third-party scripts/assets.
No problem. You can host your own approximation of the polyfill conditionally, as well, based on the user agent. ("You don't know what a
Node.addEventListeneris? What a goddamn shame. Here, let me tell you!..") The "conditional" part ensures the low cost of the script for the user, since they don't have to load everything just because their browser is months-old – or is IE.Right, overall the way that I'm trying to think about it has generally been "how do we identify the source of the content?"
Like you said, in a lot of cases the site (via the domain name) is the main indicator people use for this. The specific author that wrote the article for that site often feels a level too deep for me—I expect that most people probably can't name more than one or two writers for even popular sites, but there are certainly exceptions (again, like you mentioned in your other comment, this is often just for the most famous names).
I definitely want to keep trying to do more with it though. For example, on sites like YouTube and Twitter, the domain name alone is pretty meaningless. Domain names like that are effectively so "general" that all they really tell you is what type of content it is (video, tweet, etc.). In that case, we really do need to go a level deeper and include the name of the account posting the content there (and you can see for most YouTube videos, people tend to include that in the title).
I think there's a lot of potential for being able to display information like that, but like @Whom said, we'll need to be careful with it. The more varied the information we're displaying for "source", the harder it gets to understand quickly, since it loses its uniformity.
Scientific papers have authors' names on them. Scientific posts have authors' name on them. Science divulgation articles have authors' names of them. All of these might have the names of editors, translators, cover designers, illustrators, and those of many people the authors may want to say thanks to. News reports have reporters' names attached to them.
Making a post here is some kind of authorship/newsreporting. If it was not for the poster, we wouldn't have the post here. So the OP is definitely significant. And I don't see why we would deny people the recognition, however minute it is. And if we are going to do it somehow, what concrete benefit is there to doing it obscurely?
I generally don't like hiding OPs' names anywhere. No scientific discussion is anonymous people speaking into an abyss of no-ones.
I would call it "curating". Like the curators of a museum or an art gallery, who scour the world looking for suitable exhibits, and then decide which ones to show in their museum/gallery.
And, I agree that the curator of the content is important. @Deimos and @cfabbro talk about "taste" being important with regard to music, but there's also a "taste" with regard to news and science and other categories of content.
Well... for example, I'm more likely to post articles about astronomy and biology than geology and mathematics. And, I'm more likely to find an article from a science journal than from a pop-sci website.
I like freeing up the way we're thinking about this, but on the other end this gets really messy really fast. Changing what info goes in a spot like adding an artist name turns into a big mess that's hard to manage. Hell, we just have two different states things can be in based on group (showing submitter name or not), and I think that's already something that needs to be explained and isn't super intuitive. Adding more gets weird.
...but differentiating groups and being willing to morph the site to suit them and let them take on lives of their own far more than was possible on Reddit is one of the most important things I think Tildes can do, so maybe it's a worthwhile sacrifice in the long run. If Tildes is designed toward a uniform experience on the frontpage, people will continue to think of it as one front page feed and that will cause issues when future features come into play.
I don't have a point really, just throwing those things out there so we remember what goals contradict each other. I'd rather have OP names everywhere for the way I use the site right now, but maybe this is a place to try something radical.
Sorry. Dumb with tech. From your first point there is a mobile option? Is it an app or just the site itself? (cant close out well) My dog will be 10 years old April 1st.
It's all just one website, no app. On mobile the website just sees you're on a phone and adjusts screen size accordingly, plus some extra buttons.
Thanks for info, this moron will tune in here and there when out n about. Sorry about the dumb question.
It's not a dumb question at all! Most people aren't familiar with how web tech works, and most people don't need to be familiar with it.
But hey, here's a quick crash course: The visual portions of a website are usually constructed using two tools, HTML and CSS. The HTML is just a bunch of containers that you stuff content into. There's nearly no styling applied to them whatsoever. CSS is what makes things colorful, lined up in the right places, and basically just way prettier.
Check out this example of a website that has only HTML. Garbage, right? Now, add some CSS and it looks way better! You just define a few simple rules for your web browser to follow and the website is styled according to those rules. For example, you can add a rule that basically means "add a few pixels of margin on the sides of the screen" so you don't have your content hugging right up against the edges.
With that in mind, in CSS there are some fancy little rules that allow you to change the styling based on the width of your screen. Maybe you want your buttons smaller on a desktop because you don't want them taking up a lot of space, but maybe you want them bigger on a mobile device because your fingers are fatter and meatier than a mouse pointer and they need something bigger to target so you don't make a mistake and tap "Cancel" when you really wanted to tap "Post comment". Those fancy CSS rules make that kind of thing possible (although I don't believe that particular example is in use here on Tildes).
That's about all you need to know unless you intend to write your own CSS :)
Thanks for the write up, I have seen those websites posted about but I just didn't get the humor involved from the other commenters. Thanks to you I sort of get it. Also glad to hear ya got a laugh from my username awhile back.
No problem! And yeah, the humor in those websites is definitely a little dry and esoteric.
As for your username, it still gets a bit of a chuckle out of me now and then :)
re: Subsequent quotes... thank you so much for closing this out! Its the first issue I've ever posted to any repo :)
Concerning the back-to-too button:
Should you do decide to implement then at least make it toggable. Using iOS, I can just tab the top of the screen to achieve the same thing, so for me at least a dedicated button on the page would just add visual clutter.
And when using a desktop, I can use the home key to achieve the same thing. Personally I feel like a back-to-the-top button is something the browser should implement not the webpage.
Okay, so what I'm seeing here is the dissonance between Markdown-to-HTML conversion and user experience.
The way I understand it, Markdown converts every block of right angle brackets into their own paragraph-sorted
<blockquote>– which is reasonable. If you want a longer quote, you make longer boundries for it – i.e., insert the empty angle brackets.But now, with that change, you see multiple blocks of quotes converted to a single one of they follow each other, correct? How, then, does one make separate quotes one after the other?
The very next sentence:
Welp... Bad morning for reading, I guess.
Thanks.