[HN Gopher] How type influences readability
___________________________________________________________________
How type influences readability
Author : marban
Score : 56 points
Date : 2022-12-12 11:47 UTC (11 hours ago)
(HTM) web link (fonts.google.com)
(TXT) w3m dump (fonts.google.com)
| jbverschoor wrote:
| I dunno, but I just looked at the pictures, got the gist of it,
| and closed the tab.
| macrael wrote:
| Since we read code more than we write code, I highly suggest you
| try out a variable width font in your editor. I've been using a
| slightly tweaked Avenir for years and I love it. Fixed width
| fonts were a hack to make displaying code on terminals easier 40
| years ago, we've long outgrown any need for them.
| codeflo wrote:
| I had a similar thought once, and while I still think the idea
| is correct, I just haven't found any variable width font for
| which this works for me. Most fonts have very narrow
| punctuation symbols. That makes sense for the visual flow of
| natural language text. But in code, symbols need to stand out
| just as much as letters. Monospace fonts achieve this
| perfectly, even if mostly by accident.
|
| (BTW this is also the reason why I don't use "code ligatures"
| -- mashing symbols together is the opposite of what I want to
| read code clearly.)
| giraffe_lady wrote:
| I'm fine with this in theory and have spent plenty of time
| running variable width fonts in code editors. In practice their
| non-alphanumeric symbols like brackets and carets aren't
| designed and set correctly for the significance those
| characters have in code. In prose they are meant to be clear
| enough but unobtrusive, with a fair bit of play between the
| tradeoffs in either direction being acceptable.
|
| It's not an insurmountable problem, probably any skilled
| typographer could do a great job at it on a given typeface.
| Probably even just a committed amateur with fontforge could do
| an acceptable job in a weekend. But I'm neither and I don't
| know of any "code variant" variable-width fonts yet.
|
| Plus the last few years this problem more or less resolved
| itself for me. There are a number of incredibly high quality
| code-specific fonts now, plus there are now fixed-width fonts
| so tightly designed with this in mind they aren't even
| obviously fixed-width unless you have a practiced eye for
| typesetting. You can get very close to the same result without
| giving up aligned columns, which is one advantage that is still
| fairly relevant.
| jrm4 wrote:
| Seems like "languages" have evolved within a monospace world,
| or more accurately, as human being design programming
| languages, few, if any, have done so with proportional fonts in
| mind, which is likely to make adoption difficult?
| efortis wrote:
| In summary, because it can create distinctive word boundary
| shapes.
|
| Related: Here's a programming font (non-monospaced) that adds
| extra padding to the left of the capital letters for faster
| reading of camelCase.
|
| https://ericfortis.com/portfolio/design#-verdana-camel
| huydotnet wrote:
| This looks interesting, do you have a plan to open up this font
| for the public to download at somepoint?
| random314 wrote:
| Suggestion - halve the whitespace
| kruxigt wrote:
| yamtaddle wrote:
| Yeah, I thought that was a neat idea until I looked at it. It
| shouldn't be so wide it looks like there's an actual space
| character there.
| breakds wrote:
| After reading the title, I was thinking "Agreed, adding type to
| your code definitely make it more readable".
| pjmorris wrote:
| Exactly. I was wondering if someone had done a study comparing
| readability of static vs. dynamic typing.
| IshKebab wrote:
| I haven't seen one for readability, ease of maintenance and
| so on, since those are hard to objectively measure. There is
| one where they added Typescript and Flow annotations to
| JavaScript projects to see if it would have detected known
| bugs. It found about 15% of them.
| layer8 wrote:
| Explicit vs. implicit typing may be more useful. A
| statically-typed language with full type inference may look
| identical to a dynamically-typed language.
| loloquwowndueo wrote:
| A quick glance at the url fonts.google.com might have suggested
| that this was about typography instead :)
| lucideer wrote:
| *Caveat
|
| For me, typed code is more readable than untyped code. As
| someone who writes & is very used to typed code.
|
| Thinking back to a previous iteration of myself, learning
| C/C++, Javascript & (old, hint-less) PHP in my early 20s, typed
| code looked alien. Sure, if I'd applied myself a little to the
| reading, I guess I could've figured it out pretty easily, but I
| wasn't inclined to because it _appeared_ impenetrable to me. In
| a similar way to regex or terse perl (though not as bad
| obviously).
|
| TL;DR: It needs the advocacy because the readability gains
| aren't obvious/implicit.
| User23 wrote:
| I find Haskell to be strongly typed and hard to read.
| lucideer wrote:
| Same argument re: familiarity really.
|
| The question is: if there were a weakly typed haskell
| (same/similar syntax & conventions, no strong typings),
| which one would a person familiar with haskell find easier
| to read?
|
| Effective readability has two components: familiarity, &
| actual readability. We'll automatically find everything
| unfamiliar to be less readable, but once we're familiar
| with all options, which is most readable then?
| hoosieree wrote:
| I love how this thread is making a type error about the
| word "type".
|
| I upgraded my keyboard from Cherry Red to Blue, so my
| Haskell is now strongly typed.
| lucideer wrote:
| Ah! The third type of type!
| layer8 wrote:
| Maybe more a category error, in the Haskell context. ;)
| gnicholas wrote:
| I was surprised the diagrammed sentence had a three-way split at
| the top, instead of noun phrase and predicate phrase (which would
| have been subdivided into the verb and the preposition phrase).
| We never diagrammed sentences when I grew up -- I only ever did
| it in linguistics classes in college. Is it normal to have three-
| way splits in sentence diagramming?
| gizmo686 wrote:
| At least it is a tree. In grade school, I learned to make
| diagrams along the lines of
| https://classicalteachersjournal.com/tag/sentence-diagrams/ .
|
| I think a 3 way split is a good compromise to favor
| communication over theoretical purity under a linguistic model.
| Sure, they could show it as a tense phrase that takes an NP and
| T' as children, with a T and VP child of T'.
|
| But, if you are targeting a general purpose audience, striving
| for that level of theoretical correctness just hurts
| readability for no benefit.
| adrian_b wrote:
| In the tree in which a sentence is decomposed, some of the
| groupings of the branches are purely conventional, not based on
| any objective criteria.
|
| Around any verb there are several phrases with distinct roles:
| agent (subject of transitive verb), patient (direct object),
| subject of intransitive verb, subject of predicate linked by
| copula, instrument, beneficiary (indirect object),
| nominal/adjectival predicate, various kinds of circumstances
| (manner, place, time, direction, cause, purpose and many
| others).
|
| Especially in the case of the transitive verbs, where
| frequently many of these roles are simultaneously present,
| there are no good reasons for grouping some of the roles
| together with the verb into a "predicate phrase".
|
| The useful decomposition is into a verb and a list of roles,
| some of which may be implicit. This is like parsing a procedure
| invocation in a programming language, into a procedure name and
| a list of arguments, some of which may be implicit.
|
| There is also little benefit in splitting first a "noun phrase"
| with one of the three roles that are usually called "subject",
| but which do not have much in common, except that they are more
| frequently the topic of a sentence than other roles, and
| because of that in many languages the verb agrees with them
| (which is a redundancy that does not add information, even if
| it may aid in correcting errors).
| digitalengineer wrote:
| A nice read. Now, let's make the Google Fonts GDPR compliant by
| not sending IP's of each vistor and put them on your local
| server, shall we?
| tacone wrote:
| We may just need to have them collapsible in the editor to get
| the best of both worlds.
| taeric wrote:
| I always find these arguments overstated. Obviously, there are
| ways to make things hard to read based on the type. It is rarely
| the long pole.
|
| This article is odd, in that every bad example is just purposely
| bad. Yes, having characters overlap each other will make it
| harder to read. Also yes, putting too much space between
| characters will make it harder to read. No, this does not imply
| that there is a set proper space between characters or words that
| will help.
| gnicholas wrote:
| > _No, this does not imply that there is a set proper space
| between characters or words that will help._
|
| There isn't one 'right' setting for readability -- the best
| choice is to let the user decide via options. Not all
| apps/websites have enough text to warrant having dedicated
| readability options. But those with large amounts of text
| should have some way of doing this. IIRC the Nook app does a
| very good job with this, offering even more text options than
| the Kindle app.
| taeric wrote:
| Right, this was what I meant by it not implying there is a
| correct answer.
|
| And I don't think it isn't something that should be studied.
| I just find articles like this way overstated. They are using
| what I would call strawman arguments for most of the "bad"
| things they show. Or with odd pictures of eyeballs and angles
| for what appears to be sophistry.
|
| I'm sympathetic to the idea that oO0 all look almost too
| similar in many type faces. I'm... actually less convinced
| that is a problem for most places than is often put forward.
| (Yes, I remember "passwords" on old video games being a
| nightmare when you didn't realize this was the case. I,
| oddly, don't remember a single time since then that this has
| been a problem.)
| trap_goes_hot wrote:
| The article doesn't really answer the 'how', but just list
| various things that CAN affect readability. Practically speaking
| more importantly than can is how much. I suspect that this is a
| very difficult problem to solve in the general case with varying
| cultures, contexts, learning styles, etc.
|
| Also.. another thing that improves readability - no ads :)
| whalesalad wrote:
| This is a personal opinion, but I find Google Sans to be terrible
| so this is quite ironic.
| [deleted]
| kibwen wrote:
| One of the images suggests that the presence of
| ascenders/descenders makes lowercase easier to read at a glance
| than all-uppercase, due to differing word shapes. But the text
| doesn't seem to elaborate further; does anyone know of any
| studies that support this? I'd be curious to see how the
| potential for "distinct shapes" affects readability across
| scripts, considering not just English but also Arabic,
| Davanagari, East Asian ideograms, etc.
| dottedmag wrote:
| A personal data point: lowercase Cyrillic is not more
| pleasant/expedient to read than uppercase. Lowercase letters in
| Cyrillic are mostly squashed down uppercase.
|
| Latin lowercase is much more pleasant in comparison.
___________________________________________________________________
(page generated 2022-12-12 23:01 UTC)