126 karma · joined February 26, 2018
I think my path was more like...
GoLive Cyberstudio -> BBEdit -> Dreamweaver -> BBEdit -> TextMate -> BBEdit -> Coda -> BBEdit -> Sublime Text -> BBEdit -> Atom -> BBEdit -> VS Code -> BBEdit
I keep trying to change but BBEdit still, to this very day, keeps doing exactly what I want. So I just keep coming back to it.
1. There isn't a clear distinction between accessible and inaccessible. It's a spectrum - much like you can never truly make something completely "secure", but can only ever make it "_more_ secure". You can't just sprinkle accessibility on top at the end of a project and there's no single point at which you've gone from inaccessible to accessible. Your last line makes it sound as though you already have this in mind, but just highlighting it.
2. Things are accessible by default. Every thing you change potentially has ramifications. This starts with the obvious things like color contrast, typography, etc. but becomes very important as you start getting into behavior. Keyboard navigation is one key example which is vital for many folks with motor or visual impairments and often serves as a handy sniff test for "have I accidentally broken the thing that was automatically accessible by default?".
---
[1] You could reach a point at which you've ensured you've met or exceeded every WCAG criteria for a given conformance level, but that's not quite identical to to the goal of "completing accessibility".
That should really help distinguish yourself in this hotly contested market space.
https://github.com/google/fonts
Since the browser hands font rendering off to the operating system, however, the most pertinent browser-specific adjustment would be updating the (configurable) defaults (Serif, Sans-serif, etc...) for each supported platform - Georgia instead of Times for a default, for example.
Seconding this. I did not pick up on that at all.
That being said, I'm one of the folks who have to choose how to add spices when I cook based upon what I remember working together in the past. As I understand it, some (perhaps only a talented few and perhaps including some unimodal aphants) are able to use the same part of their brain that processes taste and smell to imagine the taste and smell of new combinations of flavors.
Another quirk: I don't think I get songs stuck in my head in the same way as others. I may have a particular verse or rhythm on my mind... but I'm pretty sure that I'm lucking out in this regard.
In all the cases mentioned, I'm reasonably capable of predicting or extrapolating outcomes based upon past experiences (I don't stick my hand on many hot stoves, for example). But my brain just doesn't seem to run through the process of recreating sensations to get there.
The underlying concept - checking user level information and comparing against network information - is an interesting and valuable way to think about it. This is a nice, simple illustration of that idea. Thanks for sharing it.
> He attributes [his severely deficient autobiographical memory] to his inability to form mental images. Although he recognizes familiar things when he sees them, he cannot call up images of them afterward in his head: he cannot visualize even so simple an image as a flag; he cannot, when he is away, recall his wife’s face. (This condition is rare but not unheard of; it has been proposed that it is more common in people who think in abstractions.)
That article was from 2011, before the term aphantasia was coined in 2015[2] and (arguably) popularized in 2016[3]. Most folks also assume that everyone uses their visual cortex to process memories while that idea sounds absolutely implausible to some relatively small percentage of the population.
[1] https://news.ycombinator.com/item?id=22037240
[2] https://www.sciencedirect.com/science/article/pii/S001094521...
[3] https://www.facebook.com/notes/blake-ross/aphantasia-how-it-...
https://stackoverflow.com/questions/1732348/regex-match-open...
The syntactic sugar that we're adding to make our own jobs easier is arguably making things disproportionately more difficult for anyone who doesn't already have the same baseline level of knowledge. That includes those who are trying to learn to do our jobs after we've all moved on. That would notably have also included all of us, earlier in our careers.
I'm just suggesting that it's worth considering whether that seems sustainable in the long run.
[1] ... for relatively simple tasks. Complex tooling happens to be a very good tool for complex tasks, like the sort of professional work that you seem to be referring to. No matter how good our hammer may be, however, not every task always wants to be a nail. create-react-app and parcel are examples of excellent hammers.
While less of a consideration for established teams, it dramatically raises the barrier to entry for those who are learning as well as those who currently have much simpler requirements. Those are the future members of that established team. Adding hurdles to the process of learning will, in the long run, result in a smaller, more homogeneous pool of experienced developers to draw upon. It's a self-perpetuating cycle - making folks learn by using complex build scripts will result in experienced developers who then create further complexity because they've self-selected to be those who happen to think in that mode.
That's not intended to suggest that progress is bad. Rather that it's a bit short-sighted of us, as an industry, not to consider the ramifications of enforcing a workflow that happens to be trivial from the limited perspective of long time front end developers.
{ Edit to try to make the last paragraph sound less accusatory. Sorry! That wasn't my intention. }
That's not a consideration for everyone, admittedly, but an incredibly important one for those who _do_ have to take it into account.
... "easier-to-read", to an arbitrary precision.
https://www.vincit.fi/en/blog/software-development-450-words...