Ciao!
What comes to your mind when you read the word designer?
Recently, I enjoyed The Design Of Everyday Things. In the book, the author highlights the seven fundamental design principles:
-
Discoverability. It is possible to determine what actions are possible and the current state of the device.
-
Feedback. There is full and continuous information about the results of actions and the current state of the product or service. After an action has been executed, it is easy to determine the new state.
-
Conceptual model. The design projects all the information needed to create a good conceptual model of the system, leading to understanding and a feeling of control. The conceptual model enhances both discoverability and evaluation of results.
-
Affordances. The proper affordances exist to make the desired actions possible (e.g., a touch screen affords you to touch anywhere on the surface).
-
Signifiers. Effective use of signifiers ensures discoverability and that the feedback is well communicated and intelligible (e.g., on a touch screen you can be signalled to touch a specific area to achieve a result).
-
Mappings. The relationship between controls and their actions follows the principles of good mapping, enhanced as much as possible through spatial layout and temporal contiguity (e.g., position of the burners and position of their controls in a kitchen stove).
-
Constraints. Providing physical, logical, semantic, and cultural constraints guides actions and eases interpretation.
Not so long ago, I found out that math could improve my code dramatically. And it did.
Now, I'm looking forward to design opening my eyes to a whole new perspective.
Plus, it comes in all shapes and sizes and you can pick the one you like the most. It can be math-y too. Thank you Ryan, the way you synthesize all that knowledge together is inspiring!
Elsewhere on the Web
Strict null checking Visual Studio Code by Matt Bierner
In this post, I'd like to share a major engineering effort that the VS Code team recently completed: enabling TypeScript's strict null checking in our codebase. We believe this work will allow us to both move faster and to ship a more stable product. Enabling strict null checking was motivated by understanding bugs not as isolated events but as symptoms of larger hazards in our source code.
Using strict null checking as a case study, I'm going to discuss what motivated our work, how we came up with an incremental approach to addressing the problem, and how we went about implementing the fix. This same general approach to identifying and reducing hazards can be applied to any software project.
(Riccardo: Given how widespread TypeScript is and its default of giving you a foot-gun loaded with nulls, this shows how to migrate a legacy project to strict null checks.)
The Misunderstood Roots of FRP Can Save Programming by Steve Krouse
For many years I been searching for the perfect paradigm for programming user interfaces. Like many others, I fell in love with FRP with the rise of ReactJS and spent a few years searching for the perfect reactive model. Eventually, I found my way back to the original work on FRP by Conal Elliott. It took me almost a year to make sense of it.
This essay attempts to make Conal’s vision more understandable to less mathematically-oriented programmers, and also show how this perspective could be the foundation for a new era of programming, not just with user interfaces, but also multi-node computing, storage, machine learning, etc.
(Riccardo: Wow, the idea of moving low-level abstractions inside the implementation of a language is such an interesting point. What do you think?)
Tackling Concurrency Bugs with TLA+ by Hillel Wayne
Concurrency is hard. How do you test your system when it's spread across three services and four languages? Unit testing and type systems only take us so far. At some point we need new tools.
Enter TLA+. TLA+ is a specification language that describes your system and the properties you want. This makes it a fantastic complement to testing: not only can you check your code, you can check your design, too! TLA+ is especially effective for testing concurrency problems, like stalling, race conditions, and dropped messages.
(Riccardo: I should definitely give TLA+ a go!)
In the last PinkLetter, I said Elm stands for ELementary Mathematics. I was wrong.
Thanks Andy for pointing out that Elm is an acronym for Entry Level Mathematics.