1. ⁘  ⁘  ⁘
  2. ⁘  ⁘  ⁘
  3. Abo, Akinori 9
  4. aesthetics 19
  5. agile 30
  6. Albers, Josef 17
  7. Alexander, Christopher 135
  8. Alexander, Scott 5
  9. Allsopp, John 4
  10. Ammer, Ralph 6
  11. Anderson, Gretchen 7
  12. anxiety 9
  13. Appleton, Maggie 5
  14. Aptekar-Cassels, Wesley 5
  15. Arango, Jorge 4
  16. architecture 110
  17. art 86
  18. Asimov, Isaac 5
  19. attention 17
  20. Auping, Michael 6
  21. Aurelius, Marcus 14
  22. Bachelard, Gaston 12
  23. Baker, Nicholson 10
  24. beauty 58
  25. Behrensmeyer, Anna K. 7
  26. Bjarnason, Baldur 8
  27. Blake, William 5
  28. blogging 22
  29. body 11
  30. Boeing, Geoff 7
  31. boredom 9
  32. Botton, Alain de 38
  33. Brand, Stewart 4
  34. Bringhurst, Robert 16
  35. Brooks, Frederick P. 22
  36. Broskoski, Charles 6
  37. brutalism 7
  38. building 16
  39. bureaucracy 12
  40. Burnham, Bo 9
  41. business 15
  42. Byron, Lord 14
  43. Cagan, Marty 8
  44. Calvino, Italo 21
  45. Camus, Albert 13
  46. care 6
  47. Carruth, Shane 15
  48. Cegłowski, Maciej 6
  49. Cervantes, Miguel de 7
  50. chance 11
  51. change 16
  52. Chiang, Ted 4
  53. childhood 6
  54. Chimero, Frank 17
  55. choice 8
  56. cities 51
  57. Clark, Robin 3
  58. Cleary, Thomas 8
  59. Cleary, J.C. 8
  60. code 20
  61. collaboration 18
  62. collections 31
  63. color 23
  64. commonplace 11
  65. communication 31
  66. community 7
  67. complexity 11
  68. connection 24
  69. constraints 25
  70. construction 9
  71. content 9
  72. Corbusier, Le 13
  73. Coyier, Chris 4
  74. craft 66
  75. creativity 59
  76. crime 9
  77. Critchlow, Tom 5
  78. critique 10
  79. Cross, Nigel 12
  80. Cross, Anita Clayburn 10
  81. css 11
  82. culture 13
  83. curiosity 11
  84. cycles 7
  85. Danielewski, Mark Z. 4
  86. darkness 28
  87. Darwin, Will 10
  88. data 8
  89. death 38
  90. Debord, Guy 6
  91. decisions 10
  92. design 131
  93. details 31
  94. Dickinson, Emily 9
  95. Dieste, Eladio 4
  96. discovery 9
  97. doors 7
  98. Dorn, Brandon 11
  99. drawing 23
  100. Drucker, Peter F. 15
  101. Duany, Andres 18
  102. Eatock, Daniel 4
  103. economics 13
  104. efficiency 7
  105. Eisenman, Peter 8
  106. Eliot, T.S. 14
  107. emotion 8
  108. ending 14
  109. engineering 11
  110. Eno, Brian 4
  111. ethics 14
  112. euphony 38
  113. Evans, Benedict 4
  114. evolution 9
  115. experience 14
  116. farming 8
  117. fashion 11
  118. features 25
  119. feedback 6
  120. flaws 10
  121. Flexner, Abraham 8
  122. food 16
  123. form 19
  124. Fowler, Martin 4
  125. Franklin, Ursula M. 30
  126. friendship 6
  127. fun 7
  128. function 31
  129. games 13
  130. gardens 26
  131. Garfield, Emily 4
  132. Garfunkel, Art 6
  133. geography 8
  134. geometry 18
  135. goals 9
  136. Gombrich, E. H. 4
  137. goodness 12
  138. Graham, Paul 37
  139. graphics 13
  140. Greene, Erick 6
  141. Hamming, Richard 45
  142. happiness 17
  143. Harford, Tim 4
  144. Harper, Thomas J. 15
  145. Hayes, Brian 28
  146. heat 7
  147. Heinrich, Bernd 7
  148. Herbert, Frank 4
  149. Heschong, Lisa 27
  150. Hesse, Herman 6
  151. history 13
  152. Hoffman, Yoel 10
  153. Hofstadter, Douglas 6
  154. home 15
  155. Hoy, Amy 4
  156. Hoyt, Ben 5
  157. html 11
  158. Hudlow, Gandalf 4
  159. humanity 16
  160. humor 6
  161. Huxley, Aldous 7
  162. hypermedia 22
  163. i 18
  164. ideas 21
  165. identity 33
  166. images 10
  167. industry 9
  168. information 42
  169. infrastructure 17
  170. innovation 15
  171. interaction 10
  172. interest 10
  173. interfaces 37
  174. intuition 8
  175. invention 10
  176. Irwin, Robert 65
  177. Isaacson, Walter 28
  178. Ishikawa, Sara 33
  179. iteration 13
  180. Ive, Jonathan 6
  181. Jackson, Steven J. 14
  182. Jacobs, Jane 54
  183. Jacobs, Alan 5
  184. Jobs, Steve 20
  185. Jones, Nick 5
  186. Kahn, Louis 4
  187. Kakuzō, Okakura 23
  188. Kaufman, Kenn 4
  189. Keith, Jeremy 6
  190. Keller, Jenny 10
  191. Keqin, Yuanwu 8
  192. Ketheswaran, Pirijan 6
  193. Kingdon, Jonathan 5
  194. Kitching, Roger 7
  195. Klein, Laura 4
  196. Kleon, Austin 13
  197. Klinkenborg, Verlyn 24
  198. Klyn, Dan 20
  199. knowledge 29
  200. Kohlstedt, Kurt 12
  201. Kramer, Karen L. 10
  202. Krishna, Golden 10
  203. Kuma, Kengo 18
  204. language 20
  205. learning 30
  206. life 59
  207. light 31
  208. loneliness 12
  209. love 26
  210. Lovell, Sophie 16
  211. Lupton, Ellen 11
  212. Luu, Dan 8
  213. Lynch, Kevin 12
  214. MacIver, David R. 8
  215. MacWright, Tom 5
  216. Magnus, Margaret 12
  217. making 77
  218. management 14
  219. Manaugh, Geoff 27
  220. Markson, David 16
  221. Mars, Roman 13
  222. material 39
  223. math 16
  224. McCarter, Robert 21
  225. meaning 33
  226. media 16
  227. melancholy 52
  228. memory 29
  229. metaphor 10
  230. metrics 19
  231. microsites 49
  232. Miller, J. Abbott 10
  233. Mills, C. Wright 9
  234. minimalism 10
  235. Miyazaki, Hayao 30
  236. Mod, Craig 15
  237. modularity 6
  238. Mollison, Bill 31
  239. morality 8
  240. Murakami, Haruki 21
  241. music 16
  242. Müller, Boris 7
  243. Naka, Toshiharu 8
  244. names 11
  245. Naskrecki, Piotr 5
  246. nature 51
  247. networks 15
  248. Neustadter, Scott 3
  249. Noessel, Christopher 7
  250. notetaking 35
  251. novelty 11
  252. objects 16
  253. order 10
  254. ornament 9
  255. Orwell, George 7
  256. Ott, Matthias 4
  257. ownership 6
  258. Pallasmaa, Juhani 41
  259. Palmer, John 8
  260. patterns 11
  261. Patton, James L. 9
  262. Pawson, John 21
  263. perception 22
  264. perfection 7
  265. performance 17
  266. Perrine, John D. 9
  267. Petroski, Henry 24
  268. philosophy 6
  269. photography 20
  270. physics 6
  271. Pinker, Steven 8
  272. place 14
  273. planning 15
  274. Plater-Zyberk, Elizabeth 18
  275. poetry 13
  276. politics 9
  277. Pollan, Michael 6
  278. practice 10
  279. problems 31
  280. process 22
  281. production 7
  282. productivity 12
  283. products 21
  284. programming 9
  285. progress 16
  286. Pye, David 42
  287. quality 26
  288. questions 8
  289. Radić, Smiljan 20
  290. Rams, Dieter 16
  291. Rao, Venkatesh 14
  292. reading 16
  293. reality 13
  294. Reichenstein, Oliver 5
  295. religion 11
  296. Rendle, Robin 12
  297. repair 28
  298. research 17
  299. Reveal, James L. 4
  300. Richards, Melanie 3
  301. Richie, Donald 10
  302. Rougeux, Nicholas 4
  303. Rowe, Peter G. 10
  304. Rupert, Dave 4
  305. Ruskin, John 5
  306. Satyal, Parimal 9
  307. Saval, Nikil 13
  308. Sayers, Dorothy 32
  309. Schaller, George B. 7
  310. Schwulst, Laurel 5
  311. science 17
  312. seeing 36
  313. Sennett, Richard 45
  314. senses 11
  315. Seuss, Dr. 14
  316. Shakespeare, William 4
  317. Shorin, Toby 8
  318. silence 9
  319. Silverstein, Murray 33
  320. Simms, Matthew 19
  321. Simon, Paul 6
  322. simplicity 14
  323. Singer, Ryan 12
  324. skill 17
  325. Sloan, Robin 5
  326. Smith, Cyril Stanley 29
  327. Smith, Justin E. H. 6
  328. Smith, Rach 4
  329. socializing 7
  330. society 23
  331. software 68
  332. solitude 12
  333. Somers, James 8
  334. Sorkin, Michael 56
  335. sound 14
  336. space 20
  337. Speck, Jeff 18
  338. spirit 10
  339. streets 10
  340. structure 13
  341. Strunk, William 15
  342. Ström, Matthew 13
  343. style 30
  344. Sun, Chuánqí 15
  345. symbols 12
  346. systems 18
  347. Sōetsu, Yanagi 34
  348. Sōseki, Natsume 8
  349. Tanaka, Tomoyuki 9
  350. Tanizaki, Jun'ichirō 15
  351. taste 10
  352. Taylor, Dorian 16
  353. teaching 21
  354. teamwork 17
  355. technology 41
  356. texture 7
  357. thinking 31
  358. Thoreau, Henry David 8
  359. time 54
  360. Tolkien, J.R.R. 6
  361. tools 32
  362. touch 8
  363. transportation 16
  364. Trombley, Nick 44
  365. truth 15
  366. Tufte, Edward 31
  367. Turrell, James 6
  368. typography 25
  369. understanding 32
  370. urbanism 68
  371. ux 100
  372. Victor, Bret 9
  373. Viollet-le-Duc, Eugène 4
  374. vision 7
  375. visualization 34
  376. Voltaire 4
  377. wabi-sabi 8
  378. walking 23
  379. Wallace, David Foster 33
  380. Wang, Shawn 6
  381. war 7
  382. waste 12
  383. Watterson, Bill 4
  384. Webb, Matt 14
  385. Webb, Marc 3
  386. Weber, Michael H. 3
  387. Wechler, Lawrence 37
  388. whimsy 11
  389. White, E.B. 15
  390. Wirth, Niklaus 6
  391. wisdom 20
  392. Wittgenstein, Ludwig 7
  393. Woolf, Virginia 11
  394. words 35
  395. work 81
  396. writing 55
  397. Wurman, Richard Saul 18
  398. www 88
  399. Yamada, Kōun 5
  400. Yamashita, Yuhki 4
  401. Yudkowsky, Eliezer 17
  402. zen 38
  403. ⁘  ⁘  ⁘
  404. About
  405. RSS Feed
  406. Source

Software & Digital Products

Close
  • You and your user are one

    In the case of the seeming egalitarianism and beneficence of the voice from the cloud that says “You Are Not Your User,” what I hear in that voice is the ringing of a cash register, and the creaking of the crank on the side of a box that software development efforts disappear into, and that money comes out of.

    A mechanism that would seize up instantly if some still small voice were to propose the opposite of what the thunder says: that you and your user are one.

    Dan Klyn, Sermon for WIAD Bristol 2021
    understandinggroup.com
    1. ​​My job is simply to design gadgets that I like​​
    2. ​​Reversibility of perspectives​​
    • ux
    • software
  • A late change in requirements is a competitive advantage

    A Quote by Mary Poppendieck
    1. ​​The State of Agile Software in 2018​​
    2. ​​Yagni​​
    3. ​​Complete and consistent requirements​​
    4. ​​Welcome changing requirements​​
    • agile
    • software
    • design
  • Make the change easy

    A Tweet by Kent Beck
    twitter.com

    For each desired change:

    1. Make the change easy (warning: this may be hard)
    2. Make the easy change
    1. ​​The State of Agile Software in 2018​​
    • change
    • software
    • refactoring
  • Software often feels inevitable

    Software often feels inevitable because its backstory is often invisible. We click a download link, run an installer, and suddenly have a new tool to use. Yet this conceals years of human decisions, experiences, and constraints shaping software outcomes that are in no way pre-destined.

    Geoff Boeing, The Right Tools for the Job
    • software
  • Growing in the correct way

    It often feels like Are.na itself has its own needs and desires—that Are.na has its own personal intuition. And that we (you and I) are figuring out what it wants to be together. We (the organization that works on Are.na) have a very defined sense of how things should be done and why building Are.na is important, but we try not to be overly dogmatic about what exactly it should evolve into.

    …We’ve long had the sense that it’s possible to cultivate an experience on the Internet that is more calm, thoughtful, and introspective. And we’ve long had the view that this is possible not from a technology-oriented approach, but from an approach that is more soft, more personal, and more intuitive.

    …If we are the blade, what is the shield? I think it’s speed: The dominant model for online platforms (especially social platforms) is speed and scale at all costs. But to us, growing Are.na in the correct way is more important than growing it quickly.

    Charles Broskoski, On Motivation
    • software
    • www
  • It begins with craft

    Something strange is happening in the world of software: It’s slowly getting worse. Not all software, but a lot of it. It’s becoming more sluggish, less responsive, and subtly less reliable than it was a few years ago.

    In some ways this is hyperbole. Objectively, we’ve never been able to do so much, so easily with our smartphones and laptops and tablets. We’ve never pushed more data between more places more readily. But while the insidious “worseness” I mention falls only in part on the engineering side of things, it falls harder on the more subjective, craft side of things, making it all the more worrisome.

    Why should we care about this? Because the majority of our waking hours take place within the confines of applications. A truth recently amplified by the covid pandemic.

    And I believe software used by millions (if not billions) has a moral duty to elevate the emotional and intellectual qualities of its users. That elevation begins with craft.

    Craig Mod, Brilliant Hardware in the Valley of the Software Slump
    craigmod.com
    1. ​​Apps Getting Worse​​
    • performance
    • craft
    • software
  • So insufficiently palimpsestic

    I worry that unlike Kahn's process and tools, the processes and tools we use are aimed at helping us satisfy the demand for moving fast and breaking things, not to be good, or to better ensure the doing of good work.

    My son Gerrit told me about a YouTube video from a conference where the presenter asked for a show of hands from video game developers in the audience who could produce or successfully compile their own code from the previous quarter. Or from the previous year. Or from two years ago. And by that time the point had been made: nobody had their hand in the air.

    Dan Klyn, Ruins, Rub-outs, and Trash
    understandinggroup.com
    • tools
    • software
  • Spatial software references

    Image from darkblueheaven.com on 2020-10-04 at 11.39.08 AM.png
    1. Figma
    2. Muze
    3. Animal Crossing: New Horizons
    4. Online Town
    5. Nototo
    John Palmer, Spatial Software
    darkblueheaven.com
    1. ​​Nototo​​
    • software
  • A great painting has to be better than it has to be

    This sounds like a paradox, but a great painting has to be better than it has to be. For example, when Leonardo painted the portrait of Ginevra de Benci in the National Gallery, he put a juniper bush behind her head. In it he carefully painted each individual leaf. Many painters might have thought, this is just something to put in the background to frame her head. No one will look that closely at it.

    Not Leonardo. How hard he worked on part of a painting didn't depend at all on how closely he expected anyone to look at it. He was like Michael Jordan. Relentless.

    Relentlessness wins because, in the aggregate, unseen details become visible. When people walk by the portrait of Ginevra de Benci, their attention is often immediately arrested by it, even before they look at the label and notice that it says Leonardo da Vinci. All those unseen details combine to produce something that's just stunning, like a thousand barely audible voices all singing in tune.

    Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too.

    Paul Graham, Hackers and Painters
    1. ​​All the way through​​
    • art
    • software
    • craft
  • That which requires caring

    Today's real world of technology is characterized by the dominance of prescriptive technologies.

    The temptation to design more or less everything according to prescriptive and broken-up technologies is so strong that it is even applied to those tasks that should be conducted in a holistic way. Any tasks that require caring, whether for people or nature, any tasks that require immediate feedback and adjustment, are best done holistically. Such tasks cannot be planed, coordinated, and controlled the way prescriptive tasks must be.

    Prescriptive technologies eliminate the occasions for decision-making and judgment in general and especially for the making of principled decisions. Any goal of the technology is incorporated a priori in the design and is not negotiable.

    Ursula M. Franklin, The Real World of Technology
    1. ​​Holistic and prescriptive technologies​​
    2. ​​The Nature and Art of Workmanship​​
    3. ​​The Nature and Aesthetics of Design​​
    • agile
    • software
    • process
  • Jacked in

    In digital design, products and services are frequently imagined and implemented placelessly: as if the consumer were jacked into The Matrix, and considering this product or that product from among an infinite set of choices at an infinitely-provisioned mercantile. The things we make are good, by this way of reasoning, if they fit the market’s demand.

    Dan Klyn, Einmal Ist Keinmal
    • design
    • software
  • Losing meaning

    The people who’ve proven that they can make very good individual products with the radical focus of a spotlight seem to be pushed ever further from making good ecosystems.

    Products are being made “consistent” with the application of so-called “design patterns,” and rather than bringing coherence to these various touch-points, the painting-on of interface standards and interaction patterns did something far less valuable.

    Rote consistency, in the way many seem to be going about it (Material Design being just one example), is at odds with making things be good. It simplifies what needs to remain complex.

    Always, when simplification is underway, meaning is being lost.

    Dan Klyn, What Good Means
    • complexity
    • software
  • Penn Station

    In the same way that physical architecture can affect a mind, so too can software. Slower, less reliable software is like Penn Station: Sure, you can catch a transfer from one train to another but the dreary lowness of the place, the lack of sunlight or sensible wayfinding will make you feel like a rat, truculent and worthless, and worse: You’ll acclimate to that feeling and accept it as a norm.

    Craig Mod, Brilliant Hardware in the Valley of the Software Slump
    • software
    • transportation
  • The Design of Design

    A Book by Frederick P. Brooks, Jr.
    www.goodreads.com
    1. ​​Design process models: A summary argument​​
    2. ​​The spiral model​​
    3. ​​A grossly obese set of requirements​​
    4. ​​Requirements proliferation​​
    5. ​​The architectural contracting model​​
    1. ​​Design System as Style Manual With Web Characteristics​​
    • design
    • software
    • architecture
    • making
    • style
  • Visualizing Algorithms

    An Article by Mike Bostock
    bost.ocks.org
    • software
    • visualization
    • code
  • Manifesto for Agile Software Development

    A Definition
    agilemanifesto.org

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    That is, while there is value in the items on the right, we value the items on the left more.

    1. ​​Deliver early and continuously​​
    2. ​​Welcome changing requirements​​
    3. ​​Self-organizing teams​​
    4. ​​Technical excellence and good design​​
    5. ​​Agility and sustainability​​
    • agile
    • process
    • software
  • Stop Drawing Dead Fish

    A Talk by Bret Victor
    worrydream.com
    • interaction
    • making
    • touch
    • software
  • The Future of Programming

    A Talk by Bret Victor
    worrydream.com
    • programming
    • code
    • technology
    • interaction
    • software
  • Ensuring Excellence

    An Article by Marty Cagan
    www.svpg.com

    …in so many of the best product companies there is an additional dimension that goes beyond individual empowered product teams, and even goes beyond achieving business results.

    It has to do with ensuring a level of what I’ll refer to here as “excellence” although that is clearly a very ambiguous term.

    Over the years, this concept has been referred to by many different names, always necessarily vague, but all striving to convey the same thing: “desirability,” “aha moments,” “wow factor,” “magic experiences,” or “customer delight,” to list just a few.

    The concept is that an effective product that achieves results is critical, but sometimes we want to go even beyond that, to provide something special.

    Maybe it’s because we believe this is needed to achieve the necessary value. Maybe it’s because the company has built its brand on inspiring customers.

    Often this dimension shows up most clearly in product design, where functional, usable but uninspiring designs can often achieve our business results, but great design can propel us into this realm of the inspiring.

    1. ​​Do they really need it?​​
    • quality
    • craft
    • products
    • software
  • On online collaboration and our obligations as makers of software

    An Essay by Baldur Bjarnason
    www.baldurbjarnason.com

    Is it the notetaking system that’s helping you think more clearly? Or is it the act of writing that forces you to clarify your thoughts?

    Is it the complex interlinked web of notes that helps you get new ideas? Or is it all the reading you’re doing to fill that notetaking app bucket?

    Is all of this notetaking work making you smarter? Or is it just indirectly forcing you into deliberate, goalless practice?

    1. ​​Towards a crap decision​​
    2. ​​So much knowledge not being applied​​
    • notetaking
    • blogging
    • software
    • thinking
    • commonplace
  • In Search of Organic Software

    An Article by Pirijan Ketheswaran
    pketh.org

    Two different kinds of farms can grow vegetables. One is a factory farm built for scale, and the other takes the time to grow more expensive but healthier plants without pesticides.

    Will everyone appreciate the difference? Of course not, but the latter plants are labelled ‘organic’ to give us the information and the choice, so that those of us who do care can make better decisions.

    So maybe we should have ‘organic’ software as well, made by companies that:

    • Are not funded in such a way where the primary obligation of the company is to 🎡 chase funding rounds or get acquired (so bootstrapping, crowdfunding, grants, and angel investment are okay)
    • Have a clear pricing page
    • Disclose their sources of funding and sources of revenue
    • software
    • business
    • farming
  • Reflections on Software Performance

    An Article by Nelson Elhage
    blog.nelhage.com
    • Performance is a feature
    • Performance changes how users use software
    • Performance needs effort throughout a project’s lifecycle
    • Architecture strongly impacts performance
    • Performance isn’t just about hot spots
    • Performant foundations simplify architecture

    …we underrate performance when designing and building software. We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.

    • performance
    • software
  • Undoing the Toxic Dogmatism of Digital Design

    An Essay by Lisa Angela
    lisa-angela-fftv.medium.com
    1. Design educators and industry leaders have never reached a consensus about what comprises a “good enough” foundational education for digital design.
    2. We do not properly retire methods (or ways of conducting them) that have been shown to be ineffective.
    3. Design team seniority levels are meaningless.
    4. We’ve collectively lost the safety (and subsequently the desire) to explore and fail.
    5. We afford well-known design leaders too much power to dictate how design is discussed and conducted.
    6. We have no ethical standards.
    7. Inclusive design and accessibility are afterthoughts — both in design education and in practice.
    1. ​​Design Discourse is in a State of Arrested Development​​
    2. ​​Waking up from the dream of UX​​
    3. ​​Sermon for WIAD Bristol 2021​​
    4. ​​On Design Thinking​​
    • ethics
    • ux
    • software

    I don't agree with all of these points, but the main message of the article is important and worth remembering. Khoi Vinh's linked article expresses a similar unease with our industry.

  • The things that you’re meant to do

    A Quote by Josh Wardle
    slate.com

    I used to work in Silicon Valley, and I’m aware of the things that, especially with games, you’re meant to do with people’s attention. You’re trying to capture as much of people’s attention as you can. So that involves things like endless play, or sending them push notifications, or asking them for sign-up information.

    And philosophically, I enjoy doing the opposite of all those things, doing all the things that you are not meant to do, which I think has bizarrely had this effect where the game feels really human and just enjoyable. And that really resonates with where we’re at right now in the world and with COVID, and then also we’re trying to figure out, what is tech? What has tech become? I think that really resonates with people, and no ads—well, no monetization. People ask me a lot about these things, and it was like, I was literally just making a game for my partner, and I made some decisions that we would like.

    • attention
    • games
    • software
    • design
  • I don’t believe in Zoom fatigue

    An Article by Matt Webb
    interconnected.org

    It’s not Zoom fatigue, it’s Zoom whiplash.

    It’s a hunch. I can’t prove this.

    The trick to get around this is to move smoothly up and down the gradient of social interaction intensity, never dropping below a basic floor of presence: the sense that there are other people in the same place as you.

    Instead of having two modes, “in a call” and “on my own,” we need to think about multiple ways of being together which, minimally, could be:

    • In a video call
    • In an anteroom to a video call, hearing the sound of others
    • In a doc together
    • On my desktop but with the sense that colleagues are around

    And the job of the designer is to ensure that their software ensures the existence of these different contexts, instead of having the binary on-a-call/not-on-a-call, and to design the transitions between them.

    • communication
    • work
    • transitions
    • software
  • Spatial Software

    An Article by John Palmer
    darkblueheaven.com
    1. ​​A world within its interface​​
    2. ​​Social apps and COVID-19​​
    3. ​​Spatial software references​​
    1. ​​Spatial Interfaces​​
    2. ​​Spatial Web Browsing​​
    • software
    • interfaces
    • dimension

    A follow-up essay to Spatial Interfaces, 7 months later.

  • Scales of cities, scales of software

    An Article by Linus the Sephist
    linus.coffee

    American cities seem like a product of industrial processes where older European cities seem like a product of human processes. This is because most American cities were built after and alongside the car and the industrial revolution – the design of cities took into account what was easily possible, and that guided the shape and scale of everything.

    Software has similar analogues. There are software codebases that feel much more industrially generated than hand written, and they’re usually written in automation-rich environments fitting into frameworks and other orchestrating code.

    …But despite the availability of cars, I still much prefer the scale and ambiance of European, human-scale cities, because ultimately cities are places humans must inhabit and understand. In the same way, I still much prefer the scale and ambiance of hand-written codebases even in the presence of heavy programming tooling, because ultimately codebases are places humans must inhabit.

    • urbanism
    • software
    • scale
    • industry
  • Driving engineers to an arbitrary date is a value destroying mistake

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2021-11-17 at 6.15.52 PM.jpeg

    What happens when you apply date pressure to software engineers working on high value software projects? The engineers will focus on delivering Something™ by the Date™! This fatal flaw results in delivery of a Something™ full of chaos and features that nobody really wants or needs.

    1. ​​The Thing-deadline calculus​​
    2. ​​The value-destroying effect of arbitrary date pressure on code​​
    3. ​​Deadlines are bullshit​​
    • planning
    • agile
    • software

    "Whether it takes 2 rounds or 10 rounds of estimate squashing, most teams eventually capitulate and figure out what date is politically acceptable. They do this so they can go back to work and stop trying to predict the future with insufficient information."

  • How can we develop transformative tools for thought?

    A Research Paper by Andy Matuschak & Michael Nielsen
    numinous.productions
    Image from numinous.productions on 2021-11-05 at 8.05.31 AM.svg

    Conventional tech industry product practice will not produce deep enough subject matter insights to create transformative tools for thought.

    ...The aspiration is for any team serious about making transformative tools for thought. It’s to create a culture that combines the best parts of modern product practice with the best parts of the (very different) modern research culture. You need the insight-through-making loop to operate, whereby deep, original insights about the subject feed back to change and improve the system, and changes to the system result in deep, original insights about the subject.

    • making
    • thinking
    • tools
    • design
    • feedback
    • research
    • cognition
    • technology
    • software
  • Software Engineering as a Craft

    An Article by Thomas Wilson
    thomaswilson.xyz

    The decreasingly tangible product of code, i.e. that all we have are files on a hard-drive, may make it easy to forget that writing software produces a thing. If you produce a wonky chair or an overly long fork, it’s easy to see the quality of work was not great. By calling for a perception of software as a craft, we fight against that ability to forget or not notice the final quality of the product. You could watch two software engineers with different levels of experience, or in different domains, and it wouldn’t necessarily be so easy to guess which is which, at least from a distance.

    So maybe there is something to be said for the value of software as a craft, for sometimes focusing on the practice of making better, or at least different, software just for the sake of it.

    • craft
    • software
  • Why Scrum is killing your product

    An Article by Henry Latham
    uxdesign.cc
    1. ​​Product owner vs. product manager​​
    2. ​​We optimize what we measure​​
    1. ​​Beware SAFe, an Unholy Incarnation of Darkness​​
    • agile
    • management
    • software
    • products
  • Deadlines are bullshit

    An Article
    contrariantruth.substack.com

    In software development deadlines are a necessary evil. It is important to understand when they are necessary, and it is important to understand why they are evil.

    1. ​​External vs. internal deadlines​​
    2. ​​Why are internal deadlines evil?​​
    3. ​​Engineers who love their work​​
    1. ​​Hofstadter's Law​​
    2. ​​The Thing-deadline calculus​​
    3. ​​Never enough time​​
    4. ​​Driving engineers to an arbitrary date is a value destroying mistake ​​
    • bureaucracy
    • software
    • process
    • work
  • Software developers have stopped caring about reliability

    An Article by Drew DeVault
    drewdevault.com

    Of all the principles of software engineering which has fallen by the wayside in the modern “move fast and break things” mentality of assholes modern software developers, reliability is perhaps the most neglected, along with its cousin, robustness. Almost all software that users encounter in $CURRENTYEAR is straight-up broken, and often badly.

    • software
    • principles
  • The Rise Of User-Hostile Software

    An Essay by Den Delimarsky
    den.dev
    Image from den.dev on 2021-09-17 at 8.19.44 PM.png

    We are truly living in an era of user-hostile software, and when I say “user-hostile” I mean it as “software that doesn’t really care about the needs of the user but rather about the needs of the developer.”

    I personally do not know anyone who asked for an online account requirement before they can use a keyboard; however, some product lead somewhere decided that it’s important to better “understand the customer” and “maximize marketing reach” through some weekly “Hey, we have a new keyboard!” newsletter.

    1. ​​Against an Increasingly User-Hostile Web​​
    • software
    • ux
  • Minimum Awesome Product

    An Article by Carlos Beneyto
    theuxblog.com
    Image from theuxblog.com on 2021-02-23 at 10.26.25 AM.png

    Users are accustomed to a minimum of quality, and they expect that of all new products.

    If our product does not [meet basic expectations of quality], people will automatically believe that it is a bad product and they will not take it seriously. It is not what they expect.

    Hence my suggestion that the MVP has died and the MAP: Minimum Awesome Product was born.

    1. ​​Understanding the Kano Model​​
    2. ​​Don't Serve Burnt Pizza​​
    3. ​​What happens to user experience in a minimum viable product?​​
    • quality
    • ux
    • features
    • software
  • Traditional companies are losing because they mismanage software engineers

    An Article by Emma Watterson
    ewattwhere.substack.com

    Innovation is messy, and frankly Anti-Steve [Jobs] can’t figure out why you wouldn’t just tell people the right thing to build and skip all the trial and error that comes with innovation. Anti-Steve and his board of directors that keep him in place fundamentally believe that they know what needs to be built. Or at least that they can hire the messiah that will come down off the mountain and tell everyone what to build. There is no such messiah.

    1. ​​Steve Jobs​​
    • innovation
    • software
    • agile
    • management
  • Research, empathy, simplicity, speed

    An Article by Matthew Ström
    matthewstrom.com

    As Nosrat provides a simple list of essential ingredients for any great meal, can we describe a simple list of essential components for digital products?

    Here are four elements that I believe are the foundation of great digital products: Research, Empathy, Simplicity and Speed.

    1. ​​Salt, Fat, Acid, Heat​​
    • design
    • software
    • products
    • balance

    The key, Ström observes, is not simply to deploy these elements, but to find the correct balance in each case between too much and not enough.

  • Craft and Material in Digital Design

    An Article
    1. ​​A little bit more about the stone​​
    2. ​​It is how we come to understand our medium​​
    • craft
    • material
    • software

    I saved this brief essay to my notes a while ago. The source has since been taken down, so I will not name the author or provide other details, but the message is worth preserving. If you wrote this and prefer I remove it from the site, please contact me and let me know.

  • Product Design Resources

    A Reference Work by Brandon Dorn
    www.notion.so

    Things I‘ve read, people I‘ve tried to learn from, and things I‘ve done to become a better designer. This is an idiosyncratic list reflecting what has helped me along the way, rather than an exhaustive list of design classics.

    Though the list leans toward theory — principles are more durable than technique — I offer a few ideas further down about how to practice design. It also leans toward information design, because the task of presenting rich, dense information in an accessible way is ultimately the task of any digital product.

    • design
    • information
    • software
    • collections
  • Functional Prototyping. A Missed Opportunity in Web Design

    An Essay by Chuánqí Sun
    medium.com

    Prototyping allows engineers in various industries to “fail fast, fail cheap”, “select the best from the pool”, and “bring in the reality”.

    • prototypes
    • software
  • Apps Getting Worse

    An Article by Tim Bray
    www.tbray.org

    Too often, a popular consumer app unexpectedly gets worse: Some combination of harder to use, missing features, and slower. At a time in history where software is significantly eating the world, this is nonsensical. It’s also damaging to the lives of the people who depend on these products.

    ...Maybe we ought to start promoting PMs who are willing to stand pat for an occasional release or three. Maybe we ought to fire all the consumer-product PMs. Maybe we ought to start including realistic customer-retraining-cost estimates in our product planning process.

    We need to stop breaking the software people use. Everyone deserves better.

    1. ​​It begins with craft​​
    • ux
    • software
    • products
  • Feature parity

    An Article
    martinfowler.com

    Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business.

    Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'.

    • software
    • features
    • repair
  • The return of fancy tools

    An Article by Tom MacWright
    macwright.com

    Technology is seeing a little return to complexity. Dreamweaver gave way to hand-coding websites, which is now leading into Webflow, which is a lot like Dreamweaver. Evernote give way to minimal Markdown notes, which are now becoming Notion, Coda, or Craft. Visual Studio was “disrupted” by Sublime Text and TextMate, which are now getting replaced by Visual Studio Code. JIRA was replaced by GitHub issues, which is getting outmoded by Linear. The pendulum swings back and forth, which isn’t a bad thing

    • complexity
    • simplicity
    • tools
    • software
    • technology
    • notetaking
  • On Design Engineering: I think I might be a design engineer...

    An Article by Trys Mudford
    www.trysmudford.com

    Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimise product development and innovation.
    — Natalya Shelburne

    • software
    • ux
  • Websites are not living rooms and other lessons for information architecture

    An Essay by Sarah R. Barrett
    medium.com

    While there is a lot that IA can learn from actual architecture or city planning, websites aren’t buildings or cities, and they don’t have to work like them. Instead, they should be designed according to the same principles that people’s brains expect from physical experiences.

    • information
    • software
    • metaphor
  • Software that nobody wants

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2020-08-17 at 9.31.09 AM.jpeg

    Finding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.

    What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:

    • Not wanted - Company specified a solution to a problem that customers don't actually have
    • No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
    • Incorrect Packaging - Customers need a website, but the company created an iOS app instead
    • Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
    1. ​​The 'date scrum' anti-pattern​​
    • software
    • agile
    • products
    • features
  • Guidebook: Graphical User Interface Gallery

    A Website
    guidebookgallery.org

    Guidebook is a website dedicated to preserving and showcasing Graphical User Interfaces, as well as various materials related to them.

    • ux
    • software
    • interfaces

    Sadly, guidebook has not been updated since 2006, but the site is still alive as of 2020!

  • A Mindful Mobile OS

    An Article by Clo S.
    thistooshallgrow.com

    I read and loved Potential's "iOS 15, Humane" proposition. Published earlier in June by co-founders Welf and Oliver, it tackles how iOS could help us better protect our attention.

    As a designer who cares about and writes about digital wellness, I'm profoundly aligned with their suggestions.

    1. Persuasive design
    2. Disclosure requirement
    3. From infinite feeds to pages
    4. Was this time well spent?
    5. Regret tax
    6. Conditions of use
    • morality
    • ethics
    • ux
    • software
    • design
  • Clues for software design in how we sketch maps of cities

    An Article by Matt Webb
    interconnected.org

    Given there’s an explosion in software to accrete and organise knowledge, is the page model really the best approach?

    Perhaps the building blocks shouldn’t be pages or blocks, but

    neighbourhoods
    roads
    rooms and doors
    landmarks.

    Or rather, as a knowledge base or wiki develops, it should - just like a real city - encourage its users to gravitate towards these different fundamental elements. A page that starts to function a little bit like a road should transform into a slick navigation element, available on all its linked pages. A page which is functioning like a landmark should start being visible from two hops away.

    1. ​​The Image of the City​​
    • urbanism
    • cities
    • software
    • understanding
  • Fast Software, the Best Software

    An Essay by Craig Mod
    craigmod.com

    I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.

    Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.

    • performance
    • software
    • ux
  • A Plea for Lean Software

    An Essay by Niklaus Wirth
    cr.yp.to

    Software's girth has surpassed its functionality, largely because hardware advances make this possible. The way to streamline software lies in disciplined methodologies and a return to the essentials.

    1. ​​Measured by the number of its features​​
    2. ​​Essential vs. nice to have​​
    3. ​​Dependence is more profitable than education​​
    4. ​​The most rewarding iterations​​
    5. ​​Never enough time​​
    1. ​​A grossly obese set of requirements​​
    2. ​​Features and complexity​​
    • software
    • performance
    • function
  • Speed is a feature

    An Article by Nikita Prokopov
    tonsky.me

    Millions of programs have that unfulfilled potential of becoming your second nature, something you don’t even think about when interacting with. They’re waiting to be enabled to “click”. Speed is a feature.

    1. ​​Page weight matters​​
    2. ​​Performance and people​​
    3. ​​Features and complexity​​
    • software
    • performance
  • The Great Divide

    An Article by Chris Coyier
    css-tricks.com
    Image from css-tricks.com on 2021-02-17 at 10.52.57 AM.png

    On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

    On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

    1. ​​Front-of-the-front-end and back-of-the-front-end web development​​
    • code
    • software
    • html
    • css

    A seminal essay on the nature of modern front-end software development.

  • The care and feeding of software engineers (or, why engineers are grumpy)

    An Article by Nicholas Zakas
    humanwhocodes.com

    We do say “no” very quickly, not just to designs, but to everything. That led me into thinking about the psychology of software engineers and what makes us the way we are.

    • software
    • making
    • process
  • Web Brutalism, seamfulness, and notion

    An Essay by Brandon Dorn
    uxdesign.cc

    How a tool for sensemaking reconciles two distinct software design ideologies.

    1. ​​Seamful vs. seamless​​
    2. ​​Reveling in infrastructure​​
    3. ​​The brilliance of notion​​
    4. ​​How our understanding is working​​
    1. ​​Usability is not the most important thing on earth​​
    2. ​​The split personality of brutalist web development​​
    • brutalism
    • www
    • tools
    • software
  • Dear Microsoft

    An Essay
    slack.com
    Image from slack.com on 2020-12-22 at 2.26.45 PM.jpeg

    We realized a few years ago that the value of switching to Slack was so obvious and the advantages so overwhelming that every business would be using Slack, or “something just like it,” within the decade. It’s validating to see you’ve come around to the same way of thinking. And even though — being honest here — it’s a little scary, we know it will bring a better future forward faster.

    However, all this is harder than it looks. So, as you set out to build “something just like it,” we want to give you some friendly advice.

    1. ​​It's not the features that matter​​
    2. ​​An open platform is essential​​
    3. ​​You've got to do this with love​​
    1. ​​How Microsoft crushed Slack​​
    2. ​​What's love got to do with it?​​
    • software
    • competition

    Dear Microsoft is an open letter from Slack on the occasion of Microsoft's launch of their business communication platform, Teams. It was originally published as an advertisement in the November 2, 2016 edition of the New York Times.

  • How Microsoft crushed Slack

    An Article
    www.theverge.com

    ...and why the era of worker-centered work tools may be over.

    1. ​​What's love got to do with it?​​
    1. ​​Dear Microsoft​​
    • software
    • business
    • competition
  • Technical debt as a lack of understanding

    An Article by Dave Rupert
    daverupert.com

    "If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.” — Ward Cunningham

    • software
    • process
    • code
  • People expect technology to suck because it actually sucks

    An Article by Nikita Prokopov
    tonsky.me
    Screenshot of tonsky.me on 2020-09-25 at 9.46.16 AM.png

    I decided to record every broken interaction I had during one day.

    If I decided to invest time into thinning this list down, I could theoretically...reduce this list from 27 down to 24. At least 24 annoyances per day I have to live with. That’s the world WE ALL are living in now. Welcome.

    • technology
    • software
    • ux

    A response to People expect technology to suck.

  • Why Software is Slow and Shitty

    An Article by Pirijan Ketheswaran
    pketh.org
    1. ​​Roman empire military​​
    2. ​​Building is never a straight line​​
    3. ​​Conversations, not commandments​​
    1. ​​Planning doesn't make for better software​​
    • software
    • performance
  • Planning doesn't make for better software

    A Fragment by Robin Rendle
    www.robinrendle.com

    My own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it.

    Watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me.

    After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64.

    Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.

    1. ​​Why Software is Slow and Shitty​​
    • planning
    • software
    • agile

    This article is a direct response to pketh's.

  • Figma's Engineering Values: Craftsmanship

    An Article
    www.figma.com

    Craftsmanship is about thoughtfulness and care in the work we do. It means being deliberate about what we build and how possible it will be to maintain and extend in the future. A solution that will require revisiting in a month — because it’s not scaling, because it has a ton of bugs, because it doesn’t support all the use cases it needs to — is not useful to us and ultimately will generate pain for our users.

    What we trade off by living this value is (sometimes) day-to-day speed. It’s easy to imagine an engineering team that emphasizes moving fast over keeping things stable and bug-free -- like a team building a product that isn’t responsible for important user data and doesn’t support anyone’s livelihood. But given the role the Figma product plays in the lives of our users, we feel it’s worth it to ensure we hold a high quality bar for them. And in the long run, being thoughtful about how we build often reduces the complexity of ongoing development and new features regardless.

    • craft
    • software
    • quality
  • On the "Building" of Software and Websites

    An Essay by Dorian Taylor
    doriantaylor.com

    I’m beginning to suspect that software, and more conspicuously the Web, is fundamentally the wrong shape for the archetype of the construction project.

    1. ​​You are agreeing to make a Thing​​
    2. ​​The Thing-deadline calculus​​
    3. ​​Trees and graphs​​
    4. ​​Content as value​​
    1. ​​The Battle for the Life and Beauty of the Earth​​
    2. ​​Hofstadter's Law​​
    • software
    • building
    • www
    • construction
  • Yagni

    A Definition by Martin Fowler
    martinfowler.com

    Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

    1. ​​A late change in requirements is a competitive advantage​​
    2. ​​Requirements proliferation​​
    • software
    • agile
    • features
    • planning
  • The State of Agile Software in 2018

    A Talk by Martin Fowler
    martinfowler.com

    On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects).

    1. ​​How we can do better​​
    2. ​​Taylorism in software​​
    1. ​​A late change in requirements is a competitive advantage​​
    2. ​​Make the change easy​​
    • agile
    • software
  • Product vs. Feature Teams

    An Article by Marty Cagan
    svpg.com

    This article is certain to upset many people.

    1. ​​Empowered product teams​​
    2. ​​Viability, usablity, feasibility​​
    3. ​​What went wrong?​​
    • features
    • software
    • agile
  • Silicon Valley Product Group

    A Website by Marty Cagan
    svpg.com

    The best companies go about building great products differently. Silicon Valley Product Group (SVPG) was created to share lessons learned and best practices about how to build innovative products customers love

    • software
    • leadership
  • Like, just a post complaining that screens should be better

    An Article by Matt Webb
    interconnected.org

    It’s been 19 years since Pixar released Monsters, Inc. with all that CGI hair. Where are my hairy icons? Ones that get all long and knotted as the notifications number goes up.

    Why can’t I feel my phone? I found that paper from 2010 (when I was complaining about keyboards) about using precision electrostatics to make artificial textures on touchscreens.

    I should be able to run my thumb over my phone while it’s in my pocket and feel bumps for apps that want my attention. Touching an active element should feel rough. A scrollbar should *slip. Imagine the accessibility gains. But honestly I don’t even care if it’s useful: 1.5 billion smartphone screens are manufactured every year. For that number, I expect bells. I expect whistles.

    1. ​​A Brief Rant​​
    • interaction
    • software
    • interfaces
    • devices

See also:
  1. agile
  2. ux
  3. design
  4. performance
  5. craft
  6. process
  7. products
  8. features
  9. making
  10. code
  11. technology
  12. tools
  13. interaction
  14. interfaces
  15. planning
  16. www
  17. quality
  18. complexity
  19. management
  20. business
  21. competition
  22. ethics
  23. information
  24. work
  25. urbanism
  26. notetaking
  27. thinking
  28. transportation
  29. touch
  30. architecture
  31. style
  32. programming
  33. visualization
  34. devices
  35. leadership
  36. change
  37. refactoring
  38. building
  39. construction
  40. art
  41. dimension
  42. brutalism
  43. collections
  44. bureaucracy
  45. html
  46. css
  47. function
  48. cities
  49. understanding
  50. metaphor
  51. morality
  52. simplicity
  53. repair
  54. prototypes
  55. material
  56. balance
  57. innovation
  58. principles
  59. feedback
  60. research
  61. cognition
  62. scale
  63. industry
  64. communication
  65. transitions
  66. attention
  67. games
  68. farming
  69. blogging
  70. commonplace
  1. Dan Klyn
  2. Craig Mod
  3. Matt Webb
  4. Marty Cagan
  5. Nikita Prokopov
  6. Bret Victor
  7. Gandalf Hudlow
  8. Martin Fowler
  9. Pirijan Ketheswaran
  10. John Palmer
  11. Brandon Dorn
  12. Ursula M. Franklin
  13. Frederick P. Brooks
  14. Jr.
  15. Mike Bostock
  16. Henry Latham
  17. Mary Poppendieck
  18. Kent Beck
  19. Dorian Taylor
  20. Paul Graham
  21. Robin Rendle
  22. Geoff Boeing
  23. Dave Rupert
  24. Lisa Angela
  25. Nicholas Zakas
  26. Chris Coyier
  27. Trys Mudford
  28. Carlos Beneyto
  29. Niklaus Wirth
  30. Sarah R. Barrett
  31. Clo S.
  32. Tom MacWright
  33. Tim Bray
  34. Chuánqí Sun
  35. Matthew Ström
  36. Charles Broskoski
  37. Emma Watterson
  38. Den Delimarsky
  39. Drew DeVault
  40. Andy Matuschak
  41. Michael Nielsen
  42. Thomas Wilson
  43. Linus the Sephist
  44. Josh Wardle
  45. Nelson Elhage
  46. Baldur Bjarnason