Live data from Hacker News

I spent some time exploring how to improve the UX of code blocks on the web

ped.ro

21–30 of 68 posts

Re: I spent some time exploring how to improve the UX of code blocks on the web

#23
Possible bug? The `hover me` seems to be implying that hovering that text should highlight something in the code sample, but nothing is happening. I assume that's the goal anyway - mouse over sections of explaining-text to see the highlighted-code that's relevant. (both "highlight word" and "highlight lines" could be handy here. tbh I'd probably use "highlight lines" more often)

Ignoring that: this is pretty nice looking, both the explanation (clear and with good examples) and the component itself. Good work!

Re: I spent some time exploring how to improve the UX of code blocks on the web

#24
For the highlighted code, you’ve made unhighlighted lines look more like comments than merely deemphasised lines. One alternative style that I’ve found effective in such situations is to reduce the opacity and partially desaturate:

  -.sx5jq50 .highlight-line[data-highlighted="false"], .sx5jq50 .highlight-line[data-highlighted="false"] * {
  -  color: var(---fadedLines);
  -}
  +.sx5jq50 .highlight-line[data-highlighted="false"] {
  +  opacity: 0.5;
  +  filter: grayscale(0.6);
  +}
But I have always found adding a yellow background to the line to be by far the most effective (that is, the most likely to be read and understood correctly without explanation), most likely combined with opacity reduction and/or desaturation. And yes, specifically yellow will normally yield the best results. (There may be cultural factors to weigh against this recommendation, but there’s also some actual colour science supporting it. I’d definitely avoid red and green for normal highlighting in western culture, though it’s great for removed and added lines in diffs—but do remember the colourblind and not make colour the only indication.)

Re: I spent some time exploring how to improve the UX of code blocks on the web

#25

It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.

Agreed, soft wrap exists in editors and could be added here.

Re: I spent some time exploring how to improve the UX of code blocks on the web

#26

It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.

I hard wrap at I have three huge monitors, but long lines just makes most of the right-hand side of an editor window wasted.

Text files (source) are documents, and documents are much taller than they are wide: portrait orientation, like letter or A4. My two side monitors and oriented in portrait mode for this reason, and their quadrants (also portrait) are where I put editors.

I made this comment not to show my age, but to overcome the loudness bias of trends. There are plenty of us out here who still do it the old way, because the new way isn't better.

Re: I spent some time exploring how to improve the UX of code blocks on the web

#27

It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.

Even 80 characters could be too long for some screens / font size. Long lines could be broken (like white-space: pre-wrap does), with an indicator that the line has been broken at the beginning of the continued lines. This is what Kate does and I think it is a good default, better than having to scroll horizontally.

Re: I spent some time exploring how to improve the UX of code blocks on the web

#28
The best feature for me is that it works well without JavaScript. The document is still a document.

Except for collapsed code blocks. I would suggest collapsing them using JavaScript, so they are fully readable without. They are currently unavailable to someone who does not run JavaScript.

Re: I spent some time exploring how to improve the UX of code blocks on the web

#29

It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.

Could be interesting to explore using media queries to change the code layout itself, like setting indent levels and line break placements (in listing method parameters, for example). Maybe even variable/class/method name collapsing.

Re: I spent some time exploring how to improve the UX of code blocks on the web

#30

It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.

[deleted]
Post reply on HN