Hacker News new | ask | show | jobs
by unclesaamm 2165 days ago
This article talks about formatting and other superficial stylistic issues.

The main challenge of writing a technical post is deeper: who is your audience? And how much do you assume they already know?

The temptations are to take extremes: either you have to reexplain everything in the universe, or you assume you're talking to someone who already knows everything.

I've found this surprisingly hard to balance. In the end, though, I decided it's always better to err on the side of comprehensibility. This is true even for highly technical writing like scholarly articles.

One way that I've found works is to first write it out, stream of consciousness. Invariably this will be too technical. That will be obvious after waiting a day or two and revisiting it. Then build a bridge between where you are now and where the article is, with a more general introduction, and revise the body to flow with that new introduction. It's okay to push details to a supplement or appendix or footnote if necessary.

5 comments

> This article talks about formatting and other superficial stylistic issues.

On that note though, there is one thing that people have been doing for the past 5 or so years, maybe a bit more, with the formatting when they write online. In particular I see it often on Medium.com

They use blockquote to highlight some piece of their text. But the text in the blockquote is not a quote. Neither from elsewhere nor from their own text.

This annoys me.

AFAIK, blockquote has a history in the printed press of being used to catch your eye when you flick through a newspaper, so that you would want to buy the paper and read the article on that page. And the text in the blockquote was extracted from the text itself. Often from a part of it where a person that was interviewed said something that the editors found interesting. At least, that’s how I remember it.

Another type of use it is suitable for is to distinguish something quoted from elsewhere from the rest of the text.

But the way that it is being used now, it confuses and annoys my brain every time.

You're thinking of pull quotes, which can be confusingly similar to block quotes but are a different thing:

> It seems that many people (myself included) confuse blockquotes and pull quotes.

> The main purpose of a blockquote is to separate a large section of text — quoted from an outside source — that is relevant to the source material at hand.

> A pull quote is a section of the article pulled out of its context and repeated to give either emphasis, or to aid the reader in scanning the article.[0]

Unfortunately HTML doesn't provide a pull quote element so you have to make do with applying some CSS to a <blockquote>, or <p>, or whatever to get the desired visual effect.

[0]: https://www.studiopress.com/how-to-use-block-quotes/

I think a pull-quote might be one of the intended uses of <aside>.

(Though really, I don’t think HTML “likes“ pull-quotes — they’re a denormalization of the information conveyed by the markup. The ideal from WHATWG’s perspective would likely be some sort of intra-document transclusion reference, such that the pull-quote could “sample” the text out of where it already is on the page, without mirroring it.)

I'll add to that the writers who bold many words throughout the article.
A lot of people don't seem to like to use the web for what it was invented for -- hyperlinking. The beauty of writing an article online is that if there is something that requires a lot of background, you can give a one sentence summary and then link to a whole page with details if the person needs that.
And then that page will have a 50% chance of being unavailable after a year. I usually link to (creating, if necessary) a Wayback snapshot of any page instead.
Rather than linking to another page, you can link elsewhere within the same page, using fragment URI-refs. Write your asides as long footnotes, and then link to the footnotes.

(Or, go further, and split your article into a set of related articles all on the same page, with one “main” article and then several “supporting” articles that you can read or ignore. A non-editable Tiddlywiki, basically.)

(Or you could go even further and make your article into a Twine game. But that’s just getting silly.)

https://developer.mozilla.org/docs/Web/HTML/Element/aside

Consider using this mark-up and displaying the document portion in the margin, or as a float inset into the article. Footnotes inhibit the flow of reading because they require navigating away from where the reader's eyes were.

I've found this extremely frustrating writing tutorials. Let's say I have 40 of them. Every few days someone will jump into #35 and complain they don't get it even though it lists right at the start that to understand it you need to read #21, #25, and #31. And #21 will say to understand first read #5, #6, #7 etc... But they'll skip all of that and then get upset that not everything was explained. It's very frustrating.

I don't think anyone would jump to chapter 35 of a textbook and be upset it requires reading previous chapters but in HTML they apparently do get upset about it all the time.

Maybe you should call your posts chapters too?
> The main challenge of writing a technical post is deeper: who is your audience? And how much do you assume they already know?

It's impossible to write for everyone. So, you either write in a context which gives you a ballpark target, or you decide what your target is.

That's better IMO than trying to please as much people as possible which will completely dilute your communication.

I wrote https://skorokithakis.github.io/expounder/ to help with this. I'm a mediocre writer but I think that it helps more than having a one-size-fits all approach.