The same applies to reorganisation, whoseobject is merely to substitute superior for inferior control oradequate for inadequate control.
Substituting what Kaiser calls "superior for inferior control" which he defines as "reorganization" is a path which allows for the ideas behind the progressive enhancement of raw (fleeting) notes to commonplacing, to indexing, to a Luhmann-artig zettelkasten to work for a broad variety of people. Not everyone will require the same level of organization.
@chrisaldrich thank you for this detailed response about your use of Obsidian and organization for digital Zettelkasten. I am not sure if this is the current forum or discussion to ask this but I would be curious to see how you have integrated or coordinated your analog Zettelkasten and notetaking with what you describe here. I've followed your posts about the use of index cards for a long time. I'd love to see how you use the very different affordances of these environments together.
reply to u/wtagg at https://www.reddit.com/r/Zettelkasten/comments/16wgq4l/comment/k356507/?utm_source=reddit&utm_medium=web2x&context=3
Perhaps the easiest way to frame things is that I use my digital note taking as scaffolding in the learning and research process and the zettels in the digital space are the best filtered outcomes from some of that. If you compare my practice to that of Luhmann's one might consider most of my digital practice to be equivalent to his ZKI. Most of my analog practice is more highly focused and deliberate and is more closely limited to a small handful of topics related to my specific areas of research on memory, orality, intellectual history, Indigenous studies, education, anthropology, and mathematics (and is potentially more like Luhmann's ZK II). As a result, in hindsight—thanks for asking—, I'm simultaneously building my ZK I and ZK II instead of switching mid-career the way Luhmann did. But to be clear, a lot of my ZKII material filters (or digests, if you prefer that analogy) its way through the ZKI process along the way.
By dropping or reducing or postponing the least importantparts, we can unblock ourselves and move forward even when timeis scarce.
When working on a project, to stave off potential procrastination on finishing, one should focus on the minimum viable version and finish that. They can then progressively enhance portions and add on addition pieces which may be beneficial or even nice to have.
Spending too much time on the things that sound nice or that one "might want to have" in the future will be the death of the thing.
link to: - you ain't gonna need it - bikeshedding for procrastination
questions: - Does the misinterpreted-effort hypothesis play a role in creating our procrastination and/or lead to decision fatigue?
makes your app inaccessible to users if JavaScript fails or is disabled (which happens more often than you probably think).
Build a baseline email experience for subscribers using email apps with limited support for HTML and CSS—such as Outlook and Gmail—before enhancing your email for other clients. Progressive enhancement should not create suboptimal experiences for other users.
An escalator is a great example of progressive enhancement and graceful degradation in real life. The late comedian Mitch Hedberg joked, “An escalator can never break: it can only become stairs. You should never see an Escalator Temporarily Out Of Order sign, just Escalator Temporarily Stairs. Sorry for the convenience.” Regardless of its environment, an escalator maintains its functionality.
The main focus of his talk was on progressive enhancement, which involves providing advanced functionality in environments where its supported. He also emphasized the importance of graceful degradation. Graceful degradation means that if your subscriber’s email client doesn’t support a certain functionality, you’ll still provide them with a pleasant experience.
there are bugs aplenty with ie's, the way to address them is by complimenting your otherwise sound html/css with fail safe code, rather than degenerating your sound html into hacky html for ie's sake.
And that just leaves the Word Outlooks (and their ever-aligning web based equivalents), and a few lesser used (for us) regional clients. Here, our div based layout reverts back to every story being on a new line. For #EmailWeekly, we’re ok with that.
Therefore client side validation should always be treated as a progressive enhancement to the user experience; all forms should be usable even if client side validation is not present.
Überblick tut Geschichte und den wichtigsten Texten zu Progressive. Enhancement. Tolle Links!
There’s an important wrinkle when it comes to animating the menu away. When the user closes the menu, it will always disappear instantly, because the open attribute is, by default, removed immediately when the user clicks that summary element. In order to gracefully animate your menu out when it closes, we need some JavaScript. Here we can listen for clicks on the details element, and call preventDefault() on the click event, then use setTimeout() to determine exactly when that open attribute should be removed. This gives us time to trigger the closing animation with CSS. This click event listener will also fire when a keyboard user hits space or enter while the element is focused, which means no further listeners are needed for keyboard actions!
If you're creating an actual, informational web page, stick to frameless HTML, CSS and unobstrusive JavaScripts and keep in mind that the page should still be usable with scripting disabled.
JavaScript is more brittle than we care to admit. <a> elements function even if JavaScript breaks. Using anchors for your download means that a person can access what they need, even in suboptimal situations.
It is important to notice that if you are planning on making your application a PWA, you don’t have to rewrite all the logic.
The great thing about having our function in Promise form is that we don't actually need to "make it an async/await version" if we don't want to. When we call/execute the function, we can simply use the async/await keyword
We do know that, just like iMessage, this new approach will failover to SMS/MMS if a user cannot receive the encrypted variant or if bandwidth is insufficient on either end.
A couple of years after WhatsApp, Apple jumped into the game with iMessage—its obvious drawback, that senders and recipients had to be using iPhones, was overcome by integration with the standard SMS platform on those phones. If a recipient was not on iMessage or was offline, the message would revert to SMS.
Adopting TypeScript is not a binary choice, you can start by annotating existing JavaScript with JSDoc, then switch a few files to be checked by TypeScript and over time prepare your codebase to convert completely.
First proposed as a somewhat less unwieldy catchall phrase to describe the delicate art of "separating document structure and contents from semantics, presentation, and behavior"
In progressive enhancement (PE) the strategy is deliberately reversed: a basic markup document is created, geared towards the lowest common denominator of browser software functionality, and then the designer adds in functionality or enhancements to the presentation and behavior of the page, using modern technologies such as Cascading Style Sheets, Scalable Vector Graphics (SVG), or JavaScript.
graceful degradation
Library (originally from Mozilla) for building components based on the W3C Web Components specs
A Web Component that can be used to pull fragments of HTML from the server and replace some placeholder content in the page once the fragment loads.
Framework for fast PE-navigation by updating just sections of a page that change during navigation, rather than reloading the whole page.
An experimental performance comparison of client and server-side templating on desktop and mobile, focusing on time to first paint and time to last paint metrics.
The server is written in Go. The client is the simplest possible client-side templating you can do (using a <template> element and a few DOM API calls), so no frameworks involved.
Some takeaways:
Server-rendered markup can be progressively enhanced as element definitions are registered and upgraded by the browser.
Question - How is the server-rendering done and in what language?
I came across this from a post reflecting on the last Chrome summit.
The splash pages which appear to be basic static content with little interactivity load a 1.5MB JS bundle (500KB gzipped). Flipping back and forwards between pages feels sluggish in Firefox. My initial hypothesis is that letting the client's side router tear down the DOM for the current route and build up the DOM for the new route might be slower than just relying on the browser's back/forwards cache as a set of boring static pages would do.
Hardly a scientific survey, but the answers on Twitter and offline have been surprisingly consistent: server-side React for graceful degradation, jQuery and possibly shared templates (e.g. Mustache) for progressive enhancement
Good article on progressive enhancement. Jake Archibald now works for Google, I'm not sure if that was the case at the time.
This picture
... could also mention the Ether way. Or offline. Or graceful degradation / progressive enhancement depending on connectivity.