Live data from Hacker News

Common bugs in writing (2021)

cs.columbia.edu

41–50 of 99 posts

Re: Common bugs in writing (2021)

#41
post #5

I'm a little perplexed as to why professors and other academic staff have routinely hard to read websites. Yes I'm aware I can bump up the font size, but especially on mobile that gets annoying. It's one thing if they don't have a stylesheet what so ever, it's a fully another thing to intentionally make things hard to read: font-family: arial,verdana,sans-serif; font-size: small; From an article that expressly advoca…

You're saying this on a website that I need to manually zoom in to 200% in order to remotely read the text.

HN uses a font size of 14px, that's only slightly smaller than most browser's baseline of 16px (Vs. 12px for small). By any chance are you reading it on a 4K display?

In my opinion, HN and most websites, shouldn't be setting a baseline font size at all (least of all in pixels). Medium/default should be the baseline then large/larger etc should be used as-needed.

Re: Common bugs in writing (2021)

#42

Earlier quoted context omitted.

You're saying this on a website that I need to manually zoom in to 200% in order to remotely read the text.

HN uses a font size of 14px, that's only slightly smaller than most browser's baseline of 16px (Vs. 12px for small). By any chance are you reading it on a 4K display? In my opinion, HN and most websites, shouldn't be setting a baseline font size at all (least of all in pixels). Medium/default should be the baseline then large/larger etc should be used as-needed.

it's smaller than most other websites and for me on a 1080p display top level comments don't wrap until ~200 characters at the default zoom level which makes it even worse

edit: also for me the font size is set to 12, not 14

Re: Common bugs in writing (2021)

#43
post #5

I'm a little perplexed as to why professors and other academic staff have routinely hard to read websites. Yes I'm aware I can bump up the font size, but especially on mobile that gets annoying. It's one thing if they don't have a stylesheet what so ever, it's a fully another thing to intentionally make things hard to read: font-family: arial,verdana,sans-serif; font-size: small; From an article that expressly advoca…

the font size isn't ideal, but I find the line width to be a far larger problem.

a traditional book will have around 70 characters per line [1]. by contrast, on my screen (13" M1 macbook air at default screen resolution and browser zoom), suggestion 5 has 231 (!!) characters on its first line.

[1] https://en.wikipedia.org/wiki/Line_length

Re: Common bugs in writing (2021)

#44
post #22
post #5

I'm a little perplexed as to why professors and other academic staff have routinely hard to read websites. Yes I'm aware I can bump up the font size, but especially on mobile that gets annoying. It's one thing if they don't have a stylesheet what so ever, it's a fully another thing to intentionally make things hard to read: font-family: arial,verdana,sans-serif; font-size: small; From an article that expressly advoca…

"Internet Explorer is a popular web browser. The current version number is 5.0." might explain it.

Hmm. IE 5.0 and IE 5.5 were released in 1999, so perhaps the first version was written then. I also see a citation from 2015, which is a strong signal this was edited in or after 2015.

Font size looks fine to me on Firefox/Android.

Re: Common bugs in writing (2021)

#46

> If you find yourself saying "In other words," it means you didn't say it clearly enough the first time. Go back and rewrite the first attempt. Sometimes, particularly in didactic material, it helps to explain things in more than one way, as different people may find different explanations helpful.

I agree, often I write first sentence in technical language to introduce the reader to the existing discussion and then say "In other words" to paraphrase the technical language into more familiar but less precise vocabulary.

I agree, but even in those cases, “in other words” is just throat-clearing. Like “simply put” or “that is to say”, these are noise words that only hurt the clarity of writing.

If two examples help, use two examples. There’s no need to call out that the second one is another example; people will get that.

At least that’s how I see it after a lifetime of trying to stamp out this kind of filler language in my own writing.

Re: Common bugs in writing (2021)

#47
post #22

Earlier quoted context omitted.

"Internet Explorer is a popular web browser. The current version number is 5.0." might explain it.

Hmm. IE 5.0 and IE 5.5 were released in 1999, so perhaps the first version was written then. I also see a citation from 2015, which is a strong signal this was edited in or after 2015. Font size looks fine to me on Firefox/Android.

The first version on the Internet Archive is from 2001, where the design made sense more or less, and it hasn’t changed much since then.

https://web.archive.org/web/20011225094629/https://www.cs.co...

Re: Common bugs in writing (2021)

#50

> If you find yourself saying "In other words," it means you didn't say it clearly enough the first time. Go back and rewrite the first attempt. Sometimes, particularly in didactic material, it helps to explain things in more than one way, as different people may find different explanations helpful.

It's a good rule for general information presentation. Tell them what you are going to tell them. Tell them what you want to tell them. Tell them what you just told them.

Ugh that "rule" has resulted in more terrible PowerPoint presentations than any other.

"Hi, today I'm going to tell you about 1+1... 1+1=2... So what have we talked about? I started by telling you that 1+1=2."

So much waffle.

The best presentations I've heard don't do that at all. Yes they start by setting the context and goal of the presentation, and they end with a solid conclusion. But they don't have a table of contents at the start that people tediously read and then exactly the same thing again at the end.

You might argue that that's not what it's meant to mean, but that is what people hear so it's bad advice.

The best advice I've ever heard for presenting was from a stand up comedian who was teaching how to present well. His basic advice was to follow the classic Hero's Tale. Set the stage. Something goes wrong. You triumphantly overcome it.

You might think that doesn't apply to technical presentations but you'd be surprised how often you can fit your story into that framework.

Post reply on HN