Nothing Special   »   [go: up one dir, main page]

Tantek Çelik

inventor, connector, writer, runner, scientist, more.

💬 👏
  1. Came up with and tried a three phase pomodoro technique yesterday for working thru tasks and projects.

    This three phase pomodoro cycle repeats and resyncs hourly. The three phases I came up with:
    * physical tidying/cleaning
    * physical processing
    * digital processing

    This worked quite well and I got a lot of things done, tasks completed or significantly advanced in ~6 hours.

    Many of these were “annoying” or “boring” but often not immediately “necessary” tasks that I had left undone (procrastinated) for many weeks, especially with all the travel I have had in the past two months nevermind first two-thirds of this year.

    I took the basic idea of a pomodoro 20-minute timebox¹, figured three of those fit into an hour, and picked three things that were cognitively different enough that switching from one to the other would use different cognitive skills (perhaps different parts of my brain), thus allowing a form of cognitive rest (rather than fatigue, and giving one part of my brain a chance to rest, while using others).

    This eliminated the need to take “pomodoro breaks”, whether 5 minutes or 20-30 minutes and it felt nearly effortless (actually fun at times) to cycle through the three phases, repeatedly, for hours on end. Before I knew it six hours had gone by and many tasks had been completed.

    The three 20 minute phases have the advantage of quickly determining at any time which phase you should be in by checking your watch/phone for :00-:20, :20-:40, :40-:00. If you happened to be “out of phase”, e.g. “run over” because you were finishing something up, rather than stressing about it, switch to the in-progress phase and pick-up a new task accordingly.

    A 20 minute timebox also has the advantage that tasks are less annoying or boring when you know that in less than 20 minutes you will be able to set them down and switch to something else.

    There was an iterative sense of expectation of novelty. The expectation of even only a little novelty was enough to make things go more quickly in the present, and even provide a game-like encouragement of see how far I can get with this boring or annoying task in the little time remaining. Could I even complete this one task in less than 20 minutes?

    I think repeating three phase pomodoro cycles worked particularly well on a Saturday afternoon when I had very few external interrupts. I think that was key. It gave a sense of momentum, if actual flow², that itself felt like it gave me a source of energy to keep going. I’m not sure it would work during normal work hours in any highly or even partially collaborative environment.

    Interruptions for physical needs, moving around, drinking, eating etc. were something that I allowed at any time, and that removed any stress about those too.

    I rarely set any count-down timers. A few times when I recognized I was starting or picking up a task that I might get absolutely lost in (such as many digital processing tasks like email), I set an explicit count-down timer for the end of the phase. These timer alarms certainly helped to give me permission to put down that task (for now) and switch, rather than feeling compelled to “complete” it which I know from experience can often take much longer, and leave me feeling more tired, perhaps even too tired to do anything else.

    There was also a sense of relief in knowing that even if I didn’t finish a particular task by the end of a phase, I would have the opportunity to pick it right back up in 40 minutes. Or maybe by then I would have decided to work on a different task in that phase.

    This three phase pomodoro technique worked well for tasks that are not very cognitively engaging (hence boring or annoying). Such tasks have low context, and thus low context-switching costs, but still benefit from taking mental breaks and resets.

    In contrast, any deeply cognitively engaging, thinking, or creative tasks, like inventing, coding, writing, typically have a much higher context-switching costs, and in my experience work better when you can set aside a longer block of time to allow yourself build up all the context and then joyfully explore the depths of whatever it is you’re creating.

    That being said, I think some creative tasks (depending on the person) could benefit from time-boxing. Like having a constraint to write a short blog post in the morning before a workout or breakfast. Worth trying such one-off timeboxes or even formal pomodoros and seeing if they help complete some creative tasks faster (or more often) over time.

    #productivity #pomodoro #pomodoroTechnique #gtd #gettingThingsDone #Saturday

    References:

    ¹ Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique
    ² https://en.wikipedia.org/wiki/Flow_(psychology)

    on
  2. Tip: use the W3C Link Checker and fix any errors before federating with Bridgy Fed.

    https://validator.w3.org/checklink

    If you are using Bridgy Fed to federate your posts from your personal site, I highly recommend you first run the W3C Link Checker on a post, and verify there are no “red” errors (or fix any you find), before pinging Bridgy Fed to federate the post.

    The reason is that if your post contains broken links, especially broken https: links as part of an @-mention, a weird set of timeout interactions will occur between #BridgyFed and #Mastodon that will cause any Mastodon instances following your posts to drop your federated posts as if they had not been received.

    Further, those instances will also ignore any UPDATES to that post.

    More discussion here:
    * https://chat.indieweb.org/dev/2024-09-04#t1725421768496000
    More bug details here:
    * https://github.com/snarfed/bridgy-fed/issues/884#issuecomment-2327861883

    #IndieWeb #federate #fediverse #interoperability

    This is post 22 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
    → 🔮

    on
  3. ↳ In reply to hachyderm.io user thisismissem’s post @thisismissem@hachyderm.io we’ve tracked the bug down to one or more problems stemming from having a link in a post to an https: URL that fails to resolve or times out, in the context of an @-mention.

    Bridgy Fed is attempting to fetch it and times out. When a #fediverse instance fetches the AS2 version of a post, and Bridgy Fed attempts to fetch that post’s links to construct the AS2 for the post, Bridgy Fed times out, which then likely times out the original AS2 request, so #Mastodon instances never get the requested AS2 post.

    There are multiple possible problems:
    * content authoring errors (including bad links, links going bad)
    * Bridgy Fed attempting to retrieve every link in a post in order to construct the AS2 for a post, possibly with too long timeouts, so the overall AS2 construction takes too long
    * Mastodon timing out when requesting the AS2 for a post, then giving up and never trying again (e.g. even when it receives an UPDATE for the post)

    More discussion here:
    * https://chat.indieweb.org/dev/2024-09-04#t1725421768496000
    More details here:
    * https://github.com/snarfed/bridgy-fed/issues/884#issuecomment-2327861883

    #BridgyFed #atMention #ActivityStreams2

    on
  4. Twenty years ago this past February, Kevin Marks and I introduced #microformats in a conference presentation.

    Full post: https://tantek.com/2024/044/t1/twenty-years-microformats

    Aside: This is an even shorter summary of that post from ~200 days ago, which #Mastodon readers never got due to a Mastodon #federation bug (details in https://tantek.com/t5Yo1).

    Since early 2023, here are the top three updates & interesting developments in microformats:

    1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
     * Wikipedia, Threads, omg.lol
    2. Proposal to merge #microformats2 h-review into h-entry, since in practice (e.g. on #indieweb) reviews are just entries with a bit more.
    3. #metaformats adoptions, implementations, iteration

    on
  5. Twenty years ago this past February, @KevinMarks.com (@KevinMarks@xoxo.zone) and I introduced #microformats in a conference presentation.

    Full post: https://tantek.com/2024/044/t1/twenty-years-microformats

    Aside: This is a summary of a longer post from ~200 days ago¹, which #Mastodon readers never got due to a Mastodon #federation bug (instances returned 202 for post inbox delivery, but did not show post to followers or on local profiles, details in https://tantek.com/t5Yo1).

    I wrote a retrospective last year: https://tantek.com/2023/047/t1/nineteen-years-microformats

    Since then, here are the top three updates & interesting developments in microformats:

    1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
     * Wikipedia, Threads, omg.lol support
    2. A proposal to merge #microformats2 h-review into h-entry, since reviews are in practice (e.g. on the #indieweb) always entries with a bit more information.
    3. #metaformats adoptions, implementations, and iteration

    More details:
    ¹ https://tantek.com/2024/044/t1/twenty-years-microformats

    on
  6. Adventures in IndieWeb / ActivityPub (AP) bridging:

    While in general my posts are being successfully federated by https://fed.brid.gy/ #BridgyFed, most of my recent posts, and two more earlier this year, were delivered successfully to multiple #Mastodon instances AP inboxes (returned 202), however the posts do not show up if you look-up my profile on those instances (and thus followers never saw them).

    Update: workaround found: https://tantek.com/2024/247/t4/w3c-link-checker-before-federating

    These very recent posts:
    * https://tantek.com/2024/247/t2/twenty-years-microformats-shorter
    * https://tantek.com/2024/247/t1/twenty-years-microformats-summary
    * https://tantek.com/2024/245/t1/read-write-suggest-edit-web
    * https://tantek.com/2024/242/t1/indiewebcamp-portland
    * https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
    and these earlier this year:
    * https://tantek.com/2024/173/t1/years-posse-microformats-adoption
    * https://tantek.com/2024/044/t1/twenty-years-microformats

    were all delivered to over 300 instances, which returned "202" codes, however none of them show up in profile views on those instances, e.g.
    * https://indieweb.social/@tantek.com@tantek.com
    * https://mastodon.social/@tantek.com@tantek.com
    * https://social.coop/@tantek.com@tantek.com
    * https://w3c.social/@tantek.com@tantek.com
    (My most recent post on all of these is the same 2024-08-25 post starting with “All setup here at IndieWebCamp Portland!”)

    Why would a Mastodon instance respond with a 202 to an AP inbox delivery and then not show that post on the local profile view?

    GitHub tracking bug in case you can help narrow/track this down or have
    * https://github.com/snarfed/bridgy-fed/issues/884

    Let’s see if this post makes it to your Mastodon (or other #fediverse) reader/client.

    Update: ironically this very post itself (with plenty of links, including links to my domain) showed up so I’m quite confused why Mastodon is dropping some posts and not others.

    Update 2: it appears all the posts that Mastodon dropped on the floor have @-domain references, e.g. to @-KevinMarks-.-com (without the "-"s). When I changed that @-domain mention to just “Kevin Marks” in https://tantek.com/2024/247/t2/twenty-years-microformats-shorter, it got delivered and shown on Mastodon no problem, with a new slug of https://tantek.com/2024/247/t2/twenty-years-microformats-shorter2.

    Something about the ActivityStreams2 that BridgyFed is generating for hyperlinked @-domain mentions is causing Mastodon to choke and fail to show the post to followers and in a local profile.


    #indieweb #ActivityPub

    This is post 21 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/245/t1/read-write-suggest-edit-web
    https://tantek.com/2024/247/t4/w3c-link-checker-before-federating

    on
  7. ✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web.

    The consumer Infinite Scroll Web leaves us feeling empty.

    Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.

    A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.

    Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.

    We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.

    13 years ago I wrote²:

     “The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”

    Now I want the Read Write Suggest-Edit Accept-Edit Update Web.

    The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).

    Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.

    If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.

    Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?

    To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.

    There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
    * https://indieweb.org/edit

    Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.

    For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:

    ✏️ Suggest Edit

    and link it to an edit URL for the static file for the post.

    I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:

    https://tantek.com/github/cassis/edit/main/README.md

    This will start the process of creating a “pull request”, GitHub’s jargon for a “suggested edit”.

    After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.

    It’s an awkward interaction, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.

    We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.

    #readWriteWeb #editableWeb #suggestEdit #acceptEdit

    References:

    ¹ https://indieweb.social/@kevinmarks/113025295600067213
    ² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
    ³ https://indieweb.org/responses
    The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
    “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.

    This is post 20 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/242/t1/indiewebcamp-portland
    https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed

    on
  8. Had a great time at IndieWebCamp Portland 2024 this past Sunday — our 10th IndieWebCamp in Portland!

    https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k

    Being a one day #IndieWebCamp, we focused more on making, hacking, and creating, than on formal discussion sessions.

    Nearly everyone gave a brief personal site intro with a summary of how they use their #IndieWeb site and what they would like to add, remove, or improve.
    * https://indieweb.org/2024/Portland/Intros

    There were lots of informal discussions, some in the main room, on the walk to and from lunch, over lunch in the nearby outdoor patio, or at tables inside the lobby of the Hotel Grand Stark.

    We wrapped up with our usual Create Day¹ Demos session, live streamed for remote attendees to see as well. Lots of great demos of things people built, designed, removed, cleaned-up, documented, and blogged! Everyone still at the camp showed something on their personal site!
    * https://indieweb.org/2024/Portland/Demos

    Group photo and lots more about IndieWebCamp Portland 2024 at the event’s wiki page:
    * https://indieweb.org/2024/Portland

    Thanks to everyone who pitched in to help organize IndieWebCamp Portland 2024! Thanks especially to Marty McGuire (@martymcgui.re) for taking live notes during both the personal site intros and create day demos, to Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) for the IndieWebCamp live-tooting, and Ryan Barrett (@snarfed.org) for amazing breakfast pastries from Dos Hermanos.

    The experience definitely raised our hopes and confidence for returning to Portland in 2025.²


    References:

    ¹ https://indieweb.org/Create_Day
    ² https://indieweb.org/Planning#Portland

    This is post 19 of #100PostsOfIndieWeb. #100Posts #2024_238

    https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
    https://tantek.com/2024/245/t1/read-write-suggest-edit-web

    on
  9. Nice #IndieWebCamp discussion session with Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) on the topic of auto-linking¹.

    I’ve implemented an auto_link function² that handles quite a few use-cases of URLs (with or without http: or https:), @-name @-domain @-domain/path @-@-handles, hashtags(#), and footnotes(^).

    Much of it is based on what I’ve seen work (or implemented) on sites and software, and some of it is based on logically extending how people are using text punctuation across various services.

    It may be time for me to write-up an auto-link specification based on the algorithms I’ve come up with, implemented, and am using live on my site. All the algorithms work fully offline (none of them require querying a site for more info, whether well-known or otherwise), so they can be used in offline-first authoring/writing clients.

    I have identified three logical chunks of auto-linking functionality, each of which has different constraints and potential needs for local to the linking context information (like hashtags need a default tagspace). Each would be a good section for a new specification. Each is used by this very post.

    * URLs, @-s, and @-@-s
    * # hashtags
    * ^ footnotes

    #IndieWeb #autoLink #hashtag #hashtags #footnote #footnotes

    Previously, previously, previously:

    * https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
    * https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
    * https://tantek.com/2023/043/t1/footnotes-unicode-links
    * https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo


    References:

    ¹ https://indieweb.org/autolink
    ² https://github.com/tantek/cassis/blob/main/cassis.js


    This is post 18 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/238/t1/indiewebcamp-portland
    https://tantek.com/2024/242/t1/indiewebcamp-portland

    on
  10. ↳ In reply to issue 135 of GitHub project “Meetable” In addition, if an h-card lacks an icon, perhaps Meetable should re-fetch user info more frequently, in case someone just setup their personal site and then added their image later.

    One user-interactive work-around for this could be for Meetable to refetech someone’s h-card every time they sign-in, that way, a “user fix” for this could be signing out and signing back in to Meetable. Update: I see this was noted in https://github.com/aaronpk/Meetable/issues/122 already.

    Another more aggressive user-interactive work-around for this could be refetch someone’s h-card every time a signed-in user (re)loads a Meetable page, since Meetable obviously recognizes that the user is signed in (since it offers more UI options like RSVPing and editing).

    That way the UX would be:
    * signed-in user updates their h-card with a new icon
    * user reloads whatever Meetable page they are looking at
    * Meetable detects the user page reload (same URL requested by same IP within 1hr? or use a cookie to note last time page was loaded by the user)
    * Meetable goes out and re-fetches the user’s h-card

    That would feel more responsive and discoverable, since reloading a page to see an update is a very natural thing for a user to do.

    on
  11. All setup here at IndieWebCamp Portland!

    https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k

    Good crowd of participants from #XOXO #XOXOConf (@xoxofest.com @xoxo@xoxo.zone @xoxo) here to work on their personal website(s), domains, or other independent social media setups!

    As encouraged by Andy Baio (@waxy.org @andybaio@xoxo.zone @waxpancake)

    “Every one of you should have a home on the web not controlled by a billionaire.”

    If you’re in #Portland and want help, encouragement, or camaraderie in getting setup or doing more with your personal site, come on by! We’ll be having a mix of discussion sessions and create/hack sessions.

    Personal site and hack demos at 16:00 PDT!

    #indieweb #fediverse #ActivityPub #decentralized #socialMedia

    This is post 17 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/237/t1/people-over-protocols-platforms
    https://tantek.com/2024/238/t3/indiewebcamp-auto-linking

    on
  12. People over protocols over platforms.


    inspired by today’s #indieweb #fediverse #ActivityPub #decentralized #socialMedia lunch meetup at #XOXO #XOXOConf (@xoxo@xoxo.zone)

    This is post 16 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/173/t1/years-posse-microformats-adoption
    https://tantek.com/2024/238/t1/indiewebcamp-portland

    on
  13. New issue on GitHub project “explainers”

    [explainers] How should an Explainer describe out of scope aspects?

    Explainers start with a description of user problem(s) to be solved. Depending on the problem(s), the boundaries of what to solve or not may be unclear, or solutions for subset(s) of the problem(s) may be significantly simpler or more practical than solutions for the full possibilities of the problem(s).

    We should document a way (or ways) for Explainer authors to explicitly communicate what they consider out of scope for a particular Explainer, either by description or specific example(s).

    For example @martinthomson noted that currencies may not meet the documented criteria for solutions for the amount explainer.

    Here are a few ways to document such out of scope aspects:

    1. A brief “Out of scope: (inline list of examples and/or classes thereof).” sentence at the end of section 1, to explicitly communicate what problems the explainer is not trying to solve
    2. A brief "Out of scope: solutions that (inline list of undesired characteristics, dependencies, or classes thereof)" sentence or paragraph at the end of section 2, to explicitly communicate what kinds of solutions the explainer is not exploring
    3. Rephrasing the out of scope aspect as a caveat of a proposed solution, and adding that to section 8 caveats, shortcomings, etc.

    A good next step here would be some amount of experimenting with adding out of scope aspects to existing explainers in this repo, then commenting on this issue with those empirical examples. If good patterns emerge, we can document them as explicit guidance in our Explainers README.

    on
  14. 👍 to a comment on issue 202 of GitHub project “rfcs”

    on
  15. 👍 to a comment on issue 202 of GitHub project “rfcs”

    on
  16. finished the Skyline 21k (half marathon) trail race in 3:39:48! (official bib time)

    Went out with the goal to have fun and try for sub-4, finished with smiles and a sub 3:40.

    Superbly run event as always by @ScenaPerformance.com (@instagram.com/scenaperformance), race director Adam Ray, and all the great volunteers.

    So many things went well. Race write-up to follow.

    Previously:
    * 2023: DNS Skyline 50k because of a bad fever from a blood bacteria infection caught in Wakefield MA (that’s whole other story, never going back there)
    * 2022: 50k race PR at Skyline: https://tantek.com/2022/289/t1/hot-skyline50k-ultra-finish

    #Skyline #21k #halfMarathon #trailRace #trailRun

    on
  17. Good W3C SocialCG telcon yesterday morning.

    Minutes: https://www.w3.org/wiki/SocialCG/2024-08-02

    Appreciate working with @evan@cosocial.ca @dmitriz@mastodon.mit.edu @TallTed@mastodon.social @snarfed.org Lisa a @AaronNGray@fosstodon.org @bobwyman@mastodon.social @by_caballero@mastodon.social @j12t@j12t.social @steve@social.technoetic.com @thisismissem@hachyderm.io

    #W3C #SocialCG #20240802 #2024_215 #ActivityPub #ActivityStreams #relAuthor

    on
  18. Choosing Tools

    One of the biggest challenges with tools for making things, even specific to making web things, is there are so many tools to choose from. Nearly every tool has a learning curve to overcome before being able to use it efficiently. With proficiency, comes the ability to pursue more efficient use of tools, and find limitations, papercuts, or outright bugs in the tools. If it’s an open source tool or you know its creator you can file or submit a bug report or feature request accordingly, which might result in an improved tool, eventually, or not. You have to decide whether any such tool is good enough, with tolerable faults, or if they’re bad enough to consider switching tools, or so bad that you are compelled to make your own.

    This post is my entry for the 2024 July IndieWeb Carnival theme of tools, hosted by James G., and also syndicated to IndieNews.

    Criteria

    I have many criteria for how I choose the tools I use, but nearly all of them come down to maximizing trust, efficiency, and focus, while minimizing frustration, overhead, and distraction. Some of these are baseline criteria for whether I will use a tool or not, and some are comparative criteria which help me decide which tool I choose from several options.

    Trustworthy tools should be:

    • Predictable — it should be clear what the tool will do
    • Dependable — the tool should “just work” as close to 100% of the time as possible
    • Acting as you direct it — the tool should do exactly what you direct it to do, and not what other parties, such as its creator or service provider, direct it to do
    • Forgiving — if you make a mistake, you should be able to undo or otherwise correct your mistake
    • Robust enough to keep working even when not used for a while

    Efficient tools should:

    • Be quick and easy to start using
    • Be responsive, with as low a latency as possible, ideally zero perceptible latency
    • Reduce the work necessary to complete a task, or complete multiple tasks with same amount of work otherwise
    • Reduce the time necessary to complete a task, or complete multiple tasks in the same amount of time otherwise
    • Be quick and easy to shut down, or otherwise put away
    • Use little or no energy when not in use

    Focused and focusing tools should

    • Provide clear features for accomplishing your goals
    • Encourage or reinforce focusing on your tasks and goals
    • Never interrupt you when you are using the tool to accomplish a task

    Bad tools can have many sources of frustration, and nearly all of these involve inversions of the desirable qualities noted above. Frustrating tools are less predictable, work only some of the time, randomly do things because some other party directed them to (like auto-upgrade), ask you to confirm before doing actions because they have no capability to undo, or stop working for no particular reason.

    Inefficient tools take too long to be “ready” to use, are unresponsive of otherwise have a delay when you provide input before they respond, cause you more work to complete a task, or make you take more time than simpler older tools would, require waiting for them to shut down, or use energy even when you are not doing anything with them.

    Unfocused tools have many (nearly) useless features that have nothing to do with your goals, encourage or distract you with actions irrelevant to your tasks or goals, or interrupt you when you are working on a task.

    Baseline Writing Tools

    Examples of tools that satisfy all the above:

    • Pencil (with eraser) and paper
    • A typewriter (ideally with a whiteout band) and paper

    That’s it, those are the baseline. When considering an alternative tool for similar tasks, such as writing, see if it measures up to those.

    Tools I Like Using

    For myself, I prefer to use:

    Tools I Tolerate Using

    I do also use the iOS and MacOS “Notes” app notes to sometimes write parts of posts, and sync text notes across devices, both of which have unfortunately become just frustrating enough to be barely tolerable to use.

    iOS Notes (as of iOS 17.5) are buggy when you scroll them and try to add to or edit the middle of notes. MacOS Notes have a very annoying feature where it tries to autocomplete names of people in your contacts when you type even just the first letter of their name or an @-sign, when you rarely if ever want that. MacOS Notes also forces anything that starts with a # (hash or pound) sign into a weird auto-linked hashtag that is nearly useless and breaks text selection.

    There are no options or preferences to turn off or disable these annoying supposedly “helpful” automatic features.

    There’s definitely an opportunity for a simple, reliable, easy to sync across devices, plain text notes application to replace iOS and MacOS notes, that doesn’t require signing up to some third-party service that will inevitably shut down or sell your information to advertisers or companies training their LLMs or leak your information due to poor security practices.

    Similarly I also frequently use Gmail and Google Docs in my day-to-day work, and I’ve grown relatively used to their lagginess, limitations, and weird user interface quirks. I use them as necessary for work and collaboration and otherwise do my best to minimize time spent in them.

    Better Tools

    I have focused primarily on writing tools, however I have made many distinct choices for personal web development tools as well, from writing mostly directly in HTML and CSS, to bits in PHP and JavaScript, rather than frameworks that demand regular updates that I cannot trust to not break my code. I myself try to build tools that aspire to the criteria listed above.

    At a high level, new tools should provide at least one of three things:

    1. Higher efficiency and/or quality: tools should help you do what you already could do, but faster, better, cheaper, and more precisely
    2. Democratization: tools should help more people do what only a few could do before
    3. Novelty: tools should help you do new things that were either impossible before or not even imagined

    Mostly I prefer to focus on the first of those, as there are plenty of “obvious” improvements to be made beyond existing tools, and such improvements have much more predictable effects. While democratization of tools is nearly always a good thing, I can think of a small handful of examples that demonstrate that sometimes it is not. That’s worth a separate post.

    Lastly, tools that help accomplish novel tasks that were previously impossible or not even imagined perhaps have the greatest risks and uncertainty, and thus I am ok with postponing exploring them for now.

    I wrote a few general thoughts on what tools and innovations to pursue and considerations thereof in my prior post: Responsible Inventing.

    Referencing Articles

    Articles also written about this topic that reference this article.

    1. 2024-08-01 Tom Morris: A world run by tools
    on
  19. 👍 to a comment on issue 420 of GitHub project “strategy”

    on
  20. 👍 to a comment on issue 870 of GitHub project “process”

    on
  21. 👍 to issue 870 of GitHub project “process”

    on
  22. New issue on GitHub project “sustyweb”

    [charter] Custom Success Criteria for SustyWeb Interest Group and WSG Statement

    The proposed Working Group (WG) charter contains boiler-plate "Success Criteria" which though excellent for creating strictly technical specifications intended for interoperable implementations that users can choose and use, and are far more strict than necessary for the Web Sustainability Guidelines (WSG), and may instead have the unintended consequence of removing helpful guidance that otherwise cannot pass that high bar of interoperable implementations.

    Assuming that issue 105 is resolved to create an Interest Group (IG) instead of a WG, one subsequent necessary step is to define explicit Success Criteria for the WSG itself.

    The Success Criteria for the WSG need to be rewritten to encapsulate consensus goals for the WSG, e.g. having a maximally impactful WSG as soon as possible that can be iteratively improved.

    We’d like to see a broad spectrum of any and all possible sustainable web guidance in the guidelines, from known measurable highly impactful techniques, to ideas worth exploring for more sustainable adoption and use of existing web technologies. We leave it up to the editors and contributors to the charter to help define Success Criteria for publishing a WSG Statement that takes into account the goals of the WSG, and the broad spectrum nature of the WSG.

    Our hope is that an explicit Success Criteria for a WSG Statement will help guide and focus the IG, help the IG determine when the WSG Note is ready for an Advisory Committee (AC) poll to take it to Statement, as well as provide a methodology for the Advisory Committee (AC) to evaluate a WSG Note to help determine if it passes the criteria that was documented in advance.

    on
  23. New issue on GitHub project “strategy”

    [artifacts] [discoverability] Cross-link charters, their polls & results, feedback, disposition thereof, any diffs adopted & repoll results

    Problem statement: Currently it is very difficult if not impossible in some cases to discover from a Working Group charter:

    • what were the poll results that helped create that charter?
    • was there any feedback, or objections formal or otherwise?
    • how was any dissent handled?
    • what were the changes if any from the polled charter to the adopted charter?
    • was there any follow-up repolling of poll respondents and what were the results?

    This makes it difficult for W3C members, and especially difficult for newcomers to W3C, to understand the context and work that went into chartering a working group, why some things in a charter are the way they are, and a deeper understanding of how & why the working group was created.

    Proposed solution: A good way to provide transparent and historically discoverable paths to these artifacts of chartering working groups would be better cross-hyperlinking/discoverability (follow-your-nose style) explicit links from, to, and between the following:

    • Working Group (WG) charters (both current and all previous)
    • The Advisory Committee (AC) charter WBS poll (and results) that presumably approved each charter, with perhaps also links to prior charter polls that failed.
    • A brief document summarizing critical feedback (noted issues, requested changes, required (Formal Objection) changes) on each charter poll when it closed
    • A thorough document explaining how each item of critical charter feedback was handled. Charter proposals need a “Disposition of comments” similar to a Candidate Recommendation (CR) that is Proposed (PR) to transition to a Recommendation.
    • What precise changes (diffs) were made between a proposed (polled) and eventually adopted charter to handle each item of critical feedback
    • If any such changes were made between a polled and eventually adopted charter, when were the folks who voted on the proposed charter repolled with the modified proposed charter with those changes (dated permalink to modified proposed charter as of time of repolling)
    • What were the repolling responses both in aggregate (totals x for, y against, z abstain) and individually (explicit +1/-1, passive or active abstention), same granularity as the original proposed charter poll Results Page
    • When/where was the repolling result announced (permalink to email)

    cc: @ianbjacobs, @dontcallmedom

    on
  24. 👍 to a comment on issue 105 of GitHub project “sustyweb”

    on
  25. 👍 to a comment on issue 381 of GitHub project “PWETF”

    on
  26. 👍 to issue 381 of GitHub project “PWETF”

    on
  27. New issue on GitHub project “sustyweb”

    [charter] A SustyWeb IG would work better to publish a WSG Statement sooner

    Rather than a working group (WG), a Sustainable Web Interest Group (IG) with open participation would better enable the Web Sustainability Guidlines (WSG) to have a larger impact sooner, with broader support.

    Proposal: rewrite the current proposed SustyWeb charter as charter for a SustyWeb IG and provide a plan for publishing the WSG as a Note, rapidly iterating similar to how the Community Group is already iterating on the WSG Report, with the eventual goal of publishing an AC-approved W3C Statement to give it more formal standing.

    An IG would have less process than a WG. It would for example avoid things like patent-related procedures, disclosures, etc. which should be unnecessary for the WSG.

    The IG charter could also define custom success criteria for a WSG Statement that better reflects the varied needs of providing a broad spectrum of sustainability guidelines. A broad set of sustainability guidelines would better achieve sustainability goals than subsetting or restricting the guidelines to only those that pass a more precisely objective testability bar that is expected for purely technical specifications for interoperable independent implementations.

    At a high level the WSG is also more similar to the Ethical Web principles, which itself is destined (eventually) for a W3C Statement.

    cc: @ianbjacobs, @caribouW3

    on
  28. New issue on GitHub project “indiewebify-me”

    Feature request: IndieWebify should support rel=author validation

    Similar to its rel=me checking support (validator), IndieWebify should support parsing, checking, and advising how to improve any rel=author (https://microformats.org/wiki/rel-author) links found on a page.

    IndieWebify should look for and check both:

    <a rel="author" href="https://…">

    and

    <link rel="author" href="https://…">

    tags, and display a list of all of them found on a particular page, along with any additional information about each one (e.g. type=, title=, and hreflang= attributes).

    Ideally it should also check for a valid representative h-card at the destination of a rel=author link.

    This is worth implementing both as its own IndieWebify feature (especially so software & services like Mastodon could test an implementation), and as a building block towards implementing a complete authorship validator (issue #6).

    on
  29. New issue on GitHub project “indiewebify-me”

    Feature request: IndieWebify should support h-feed validation

    Similar to its h-entry checking support (validator), IndieWebify should support parsing, checking, and advising how to improve your h-feed (https://microformats.org/wiki/h-feed), ideally re-using the existing h-entry checking code to also validate all h-entry items found inside the h-feed.

    on
  30. Responsible Inventing

    I finally understand why Rambaldi may have hidden so many inventions.

    Forecast

    When you invent something, you should forecast the impact of your invention in the current cultural (social, political, economic, belief systems) context, and if it

    • poses non trivial existential risk
    • or is likely to cause more harm than good

    Shoulds

    Then you should stop, and:

    1. encrypt your work for a potentially better future context
    2. or destroy your notes, ideally in a way that minimizes risk of detection of their deliberate destruction
    3. and avoid any or any detectable use of your invention, because even the mere use of it may provide enough information for someone else to reinvent it who may not be as responsible.

    In Addition

    Insights and new knowledge are included in this meaning of “invention” and the guidance above.

    Forecasting should consider both whether your invention could directly cause risk or more harm, or if it could be incorporated as a building block with other (perhaps yet to be invented) technologies to create risk or more harm.

    Instead

    Instead of continuing work on such inventions, shift your focus to:

    1. work on other inventions
    2. and document & understand how & why that current cultural context would contribute to existential risk or more harm than good
    3. and work to improve, evolve that cultural context to reduce or eliminate its contribution to existential risk, and or its aspects that would (or already do) cause more harm than good

    Da Vinci

    The Should (1) provides a plausible explanation for why Da Vinci “encrypted” his writings in mirror script, deliberately making it difficult for others to read (and thus remember or reproduce). Per Should (2) he also wrote in paper mediums of the time that were all destroyable, and he may have been successful in destroying without detection, since no one has found any evidence thereof, although such a lack of evidence is purely circumstantial and he may just as likely never destroyed any invention notes.

    Methods & Precautions

    Learning from Da Vinci’s example within the context of the Shoulds, we can infer additional methods and precautions to take when developing inventions:

    • do not write initial invention notes where others (people or bots) may read them (e.g. most online services) because their ability to transcribe or make copies prevents Should (2). Instead use something like paper notes which can presumably be shredded or burned if necessary, or keep your notes in your head.
    • do not use bound notebooks for initial invention notes because tearing out a page to destroy may be detectable by the bound remains left behind. instead use individual sheets of paper organized into folders. perhaps eventually bind your papers into a notebook. Which apparently Da Vinci did!
      “These notebooks – originally loose papers of different types and sizes…”
    • consider developing a simple unique cipher you can actively use when writing which will at least inconvenience, reduce, or slow the readability of your notes. even better if you can develop a steganographic cipher, where an obvious reading of your invention writings provides a plausible but alternative meaning, thus hiding your actual invention writings in plain sight.

    Dream

    Many of these insights came to me in a dream this morning, so clearly that I immediately wrote them down upon waking up, and continued writing extrapolations from the initial insights.

    Additional Reading

    After writing down the above while it (and subsequent thoughts & deductions) were fresh in mind, and typing it up, I did a web search for “responsible inventing” for prior similar, related, or possibly of interest works and found:

    Invent The Future

    While this post encourages forecasting and other methods for avoiding unintended harmful impacts of inventions, I want to close by placing those precautions within an active positive context.

    I believe it is the ultimate responsibility of an inventor to contribute, encourage, and actively create a positive vision of the future through their inventions. As Alan Kay said:

    “The best way to predict the future is to invent it.”
    Comments

    Comments curated from replies on personal sites and federated replies that include thoughts, questions, and related reading that contribute to the primary topic of the article.

    1. Crul at :

      Also related: Paul Virilio's concept of "The integral accident": en.wikipedia.org/wiki/Paul_Virilio#The_integral_accident

    2. Roma Komarov at :

      If some invention can pose a risk, should it be treated as a vulnerability?

      Destroying/delaying an invention, in this case, could lead to it being re-invented and exploited in a different, less responsible, place.

      Obviously, it doesn't mean that invention should be unleashed. But if it poses a risk, wouldn't it be more responsible to work on finding a way to minimize it, and, ideally, not alone?

      There is probably no one good answer, and each case will be different.

    3. Lewis Cowles at :

      I am unsure if it is always practical or possible, for an inventor to understand all the characteristics of their inventions and their impact beyond a very slim set of hops.

      If things go well, I believe inventors can "believe their own hype", because they are human.

      Questions:
      Is it a free pass if you make something awful and can't take it back?
      Would that make Ignorance a virtue?

      This opens up many more problems, for both creators, and broader society.

    on
  31. Finished my second Broken Arrow #Skyrace 23k¹ yesterday in 6:52:44! #RingDasBell

    This year’s #BrokenArrowSkyrace² 23k was actually that distance! I ran 23.3km with 4557' vertical climb! In contrast, last year’s "23k" race³ was rerouted (due to weather conditions) last minute to two laps of the 11k course, where my actual distance was 18.87km with 4905' vert.

    I have been looking forward to this all year, to climbing the infamous "Stairway to Heaven" ladder to the top of Washeshu Peak (8885'/2692m elevation) for the first time (since last years’s race had to skip it).

    This year’s Broken Arrow is the start of the Mountain Running World Cup. It’s a rare sports event opportunity to compete with the best in the sport, to literally run the same trails they do, on the same day, with the same start (there are no waves), and finish line.

    Lots to write-up, for now, I’m grateful for the experience and accomplishment.

    Super grateful for everyone who came out to cheer and especially my coach whose training and guidance got me here.

    A few notes:

    Great lining up with so many friends.

    Hot day. Filled my ice bandana at the first aid station (Snow King) which made the rest possible.

    Steady hydration & fueling.

    Fueling timeline notes (times are my H:MM race clock times from the start)

    0:00 start
    1:45 ate Picky Bar
    2:00 finished Tailwind in 500ml bottle
    2:08 Snow King aid station, refilled bottles one with water and the other with mandarin Tailwind, filled ice bandana with ice, picked up a few Spring Energy gels
    3:15 ate Awesome Sauce gel
    3:45 ate Awesome Sauce gel
    ~4:30 left Siberia aid station with refilled ice bandana, bottles, a few Spring Snacks, ate potato chips, a watermelon slice, salt+nuun add to one water bottle, mandarin Tailwind in the other
    5:05 ate Awesome Sauce gel
    5:35 (-13:39) left Julia aid station with another Spring Energy gel
    6:03 ate Awesome Sauce gel
    6:52:44 finish

    Lots of incredible views along the way. The air was clean and quite breathable even nearing 9000'. Felt a bit slower but kept going within my capacity.

    Kept an eye on the time remaining before cut-off compared to my distance and vert climbing remaining and pushed steadily when I could.

    Finished with just over 7 minutes to spare before the official cut-off, to friends cheering on all sides. Saw and hugged my coach after ringing the bell at the finish.

    What an experience.

    #BrokenArrowSkyrace #trailRace #trailRun #trailRunner #runner #running #trailRunning

    ¹ https://www.brokenarrowskyrace.com/23k
    ² https://ultrasignup.com/register.aspx?did=106489
    ³ https://tantek.com/2023/178/t1/june-trailrunner-ultrarunner
    https://worldathletics.org/news/preview/mountain-running-world-cup-2024-opens-broken-arrow

    on