[HN Gopher] I spent some time exploring how to improve the UX of...
___________________________________________________________________
I spent some time exploring how to improve the UX of code blocks on
the web
Author : lovelydrop
Score : 128 points
Date : 2021-05-06 12:16 UTC (1 days ago)
(HTM) web link (ped.ro)
(TXT) w3m dump (ped.ro)
| blunte wrote:
| Viewer attention is increasingly limited these days, so avoiding
| small mistakes which limit your audience is recommended.
|
| Dark mode content such as TFA is practically unreadable outside
| in bright light. Your reader will need to remember to return to
| your page some other time when they can see it, but chances are
| they will not return.
| carlosperate wrote:
| This is pretty good! One thing I wasn't able to trigger (or
| understand) was the "hover me" part from the "Interact with the
| content" section.
| coldtea wrote:
| There's not much to it. Ignore the "hover me" label, and just
| hover over the highlighted parts of the code. They change color
| on hover.
| marcusbuffett wrote:
| Looks great! I'd add a Copy to Clipboard button somewhere, since
| that's such a common use case when showing code
| macando wrote:
| The date on this article is _June 02, 2021_
|
| Other than that, a great write-up.
| lovelydrop wrote:
| loool, ooops. fixed, thank you
| o_____________o wrote:
| Great job! Would be nice to see a docusaurus plugin for this.
| AlexeyMK wrote:
| This is super well done & polished. Will try out for future blog
| posts.
|
| Thank you!
| lovelydrop wrote:
| thank you <3
| chrismorgan wrote:
| 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.)
| sergkop wrote:
| Nice! Here is another collection of ideas on improving code
| blocks https://co-pilot.dev/docs-code-block
| milliams wrote:
| I wish the "Click a highlighted word to navigate to a different
| page" was just an <a> tag rather than a JavaScript onclick
| handler.
| uberswe wrote:
| I agree, I like to see where I'm going
| lovelydrop wrote:
| great idea! implemented, and updated the article. thank you.
| carlosperate wrote:
| It's also not easy to quickly identify it's a link, as the
| word highlight is the same as the previous examples.
|
| Maybe adding an underlines or something to make it slightly
| different might help with that.
| SamBam wrote:
| Right, or a small "outgoing link" symbol (usually a box
| with an arrow coming out the top-right corner) next to
| it.
| extra88 wrote:
| Yes, don't disable link underlines within the code
| blocks, let the default be. It's not like there's a
| competing convention for underlining within code blocks.
| Silhouette wrote:
| It might also be worth having those links opening in new
| tabs as an option. Right now, at least on iOS, following a
| link and then going back leaves you at the top of the
| original page again, not where you were up to before you
| clicked the link.
| extra88 wrote:
| In general, it's better for sites to not take away from
| the user the choice of opening a link in a new tab or
| not. When I follow a link on my iPhone, when I use the
| Back button, the page is still scrolled to where it was
| before, which is my typical experience in mobile Safari.
| zalo wrote:
| Would be nice to see Intellisense-style hover tooltips on code-
| blocks someday (via referencing a `.d.ts` or `.ts` file).
|
| There might be some minimalist way to get Monaco into read-only
| mode for it...
| eyelidlessness wrote:
| This exists! But with a slightly different set of libraries
| than the highlighter used by the post author: remark-shiki-
| twoslash[1]. Shiki tokenizes using the same language
| definitions as VSCode, Twoslash uses the same language service.
|
| 1: https://www.npmjs.com/package/remark-shiki-twoslash
| metalrain wrote:
| 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.
| briankelly wrote:
| 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.
| sneak wrote:
| If two people look at the same webpage with different size
| monitors, they see different code.
|
| Probably not the best solution.
| briankelly wrote:
| Certainly getting out of the scope of the orignal
| discussion here, but you would think people should be able
| to have their code layout and style to their own preference
| suited for their device. There are problems with that to
| overcome certainly, for e.g. referring to line numbers, but
| they seem fairly solveable.
|
| But commenters here suggesting the 80 char limit, inherited
| from IBM punchcards and typewriters before that, for
| diplaying code on smart phones half a century later is a
| little hilarious to me.
| sneak wrote:
| 80 characters is a widely-agreed-upon standard, and
| standards with lots of buy-in are useful for a variety of
| reasons, regardless of origin.
|
| Units of precisely 20 feet is also a standard, used
| mostly in countries that use SI. It doesn't diminish the
| value or utility of containerization.
| xixixao wrote:
| Agreed, soft wrap exists in editors and could be added here.
| extra88 wrote:
| In mobile Safari, you can reduce the text size to 75% to fit
| more in the viewport but on the posted page, there's a max-
| width set that still makes horizontal scrolling necessary.
|
| What you'd probably rather have is for the `<pre>` element's
| default styling of `white-space: pre` to be changed to `white-
| space: normal`, that would make the text wrap as it does in
| paragraphs and such. It's easy to tell when such wrapping is
| happening in the code block styling that includes line numbers.
| blondin wrote:
| thank you! mobile is my biggest issue as well.
|
| to add to what you wrote, mobile web has this nasty bug with
| code sections with a horizontal scrolling bar inside a page
| that already has a horizontal scrolling bar. these two don't
| play well.
| Tronno wrote:
| I use 80 character limits, and suggest corrections to that
| effect during code reviews. I feel it helps readability.
|
| Is it becoming a tend to have longer limits?
| throwaway3699 wrote:
| My workplace has a C++ character limit of 80. A lot of people
| complain but I can have three code windows side-by-side plus
| a source tree so I think it's great.
| [deleted]
| lecarore wrote:
| I guess one could use prettier with different max line lengths
| on the same code, then hide irrelevant versions with a media
| query. Feels a bit overengineered TBH
|
| Alternatively, on a mobile device, you could try to display the
| "desktop view" and put your phone in landscape mode.
| inbx0 wrote:
| That's... actually a brilliant idea, in my opinion.
| Overengineered? Idk, seems like something you'd have to
| implement once with like 100 lines of glue code for different
| libraries and then it could just work. And it could seriously
| benefit mobile viewers. Personally I read a lot of
| programming blogposts on my phone while commuting etc.
| eyelidlessness wrote:
| It may be possible to use `<wbr>` in a single representation,
| assuming the indentation is solvable.
| sneak wrote:
| I hard wrap at <=80 columns, and enforce those standards in
| codebases and in CI. Prettier's default is 80, and I don't
| change it.
|
| 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.
| jraph wrote:
| 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.
| l0b0 wrote:
| Excellent work, although the "hover me" doesn't do anything in
| Firefox 88 on Linux.
| Groxx wrote:
| 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!
| randomfool wrote:
| Does anyone know if there's a trick to avoid the trailing newline
| when double-clicking a line to copy/paste it elsewhere?
|
| This always annoys me for single-line commands. I'd love a CSS
| solution but can only think of some ugly JS approaches.
| alpaca128 wrote:
| I hate that too, and it seems to be a very common default
| behaviour of text selection. Even Vim does it when you copy a
| whole line.
|
| It's one of those little UI annoyances that refuse to
| disappear. Just like blinking cursors in unfocused input fields
| & windows.
| arthur2e5 wrote:
| It probably ties into the whole "line ending not newline"
| philosophy of requiring files to end with an EOL character.
| Someone wrote:
| I think that's because, if you follow selection of a full
| line by a backspace/delete/cut, you expect the new line to
| disappear.
|
| Apart from undo state, you also want _cut_ to be equivalent
| to _copy_ ; _backspace_.
| jraph wrote:
| 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.
___________________________________________________________________
(page generated 2021-05-07 23:00 UTC)