tantek.com

t

  1. Deep blue sky with a gradient to purple then to orange at the horizon just above the ocean, gentle small waves, glistening sand reflecting light gray to darker blue gray.Very dark blue sky with a gradient to a very bright orange at the horizon just above crashing ocean waves, the water also glowing orange, above wet sand reflecting a light to dark gradient.#Sunset #gradients at the #beach tonight
    1. 🌅+17min #deepblue to #purple #yellow #orange above #bluegray wet sands
    2. 🌅+30min #nightblue to fiery orange lighting up the #surf

    #SanFrancisco #OceanBeach #clearSky #wallpaper #background #noFilter

    on

  2. Local First, Undo Redo, JS-Optional, Create Edit Publish

    on

    For a while I have brainstormed designs for a user experience (UX) to create, edit, and publish notes and other types of posts, that is fully undoable (like Gmail’s "Undo Send" yet generalized to all user actions) and redoable, works local first, and lastly, uses progressive enhancement to work without scripts in the extreme fallback case of not being installed, and scripts not loading.

    I’d like to be able to construct an entire post on a mobile device, like a photo post with caption, people tags, location tag etc. all locally, offline, without any need to access a network.

    This is like how old email applications used to work. You could be completely offline, open your email application (there was no need to login to it!), create a message, add attachments, edit it etc., click "Send" and then forget about it. Eventually it synced to the network but you didn’t worry or care about when that step would happen, you just knew it would eventually work without you having to tend to it or watch it.

    I want to approach this from user-experience-first design perspective, rather than a bottom-up protocol/technology/backend first perspective. For one, I don’t know if any existing protocols actually have the necessary features to support such a UX.

    Micropub has a lot of what’s needed, and I won’t know what else is needed until I build the user flows I want, and then use those to drive any necessary Micropub feature additions. I absolutely do not want to limit my UX by what an existing protocol can or cannot do (essentially the software design version of the tail wags dog problem).

    Local First

    I wrote up a brief stub article on the IndieWeb wiki on local first. I see local first as an essential aspect of an authoring experience that is maximally responsive to user input, and avoids any and all unnecessary ties to other services.

    I want a 100% local first offline capable creating / editing / posting workflow which then “auto-syncs” once the network shows up. The presence / absence of internet access should not affect user flow at all. Network presence or absence should only be a status indicator (e.g. whether / how much a post has been sent to the internet or not, any edits / updates etc.). It should never block any user actions. I’ll say it again for emphasis:

    The absence or presence of network access must not block any user actions. Ever. Any changes should be effective locally immediately, with zero data loss.

    Nearly no one actually builds apps like that today. Even typical mobile “native” apps fail without network access (a few counter-examples are the iOS built-in Notes & Photos apps, as well as the independent maps.me 100% offline mapping program). Some “offline first” apps get close. But even those, especially on mobile, fail in both predictable (like requiring logging into a website or network service, just to edit a local text document) and strange ways.

    Full Undo Redo

    Every such user action should be undoable and redoable, again, without waiting for the network (it’s reasonable to apply some time limits for some actions, e.g. Gmail Undo can be configured to work for 30 seconds). Now imagine that for any user action, especially any user action that creates, edits, or deletes content or any aspects thereof (like name, tags, location etc.).

    JS-Optional

    In the case where a web application has not yet been installed, I also want it to be 100% capable without depending on loading any external scripts. This JS-Optional approach is more broadly known as progressive enhancement, which does require that you have at least some connection, enough for a browser to submit form requests and retrieve static HTML (and preferably though not required, static CSS and image files too).

    Once you are connected and are running at least a Service Worker for the site, local first requires execution of some scripts, though even then dependencies on any external scripts should be minimized and preferably eliminated.

    Incremental Progress

    I believe aspects of this experience can be built and deployed incrementally, iterating over time until the full system is built.

    I’ve got a handful of paper sketches of local-first undoable/redoable user flows. I have a Service Worker deployed on my site that allows offline browsing of previously visited pages, and I have a form submission user interface that handles part of publishing. There are many more aspects to design & implement. As I think of them I’m capturing them in part of my “Working On” list on the IndieWeb Wiki, iteratively reprioritizing and making incremental progress at IndieWebCamps.

    One building block at a time, collaboratively.

    Thanks to J. Gregory McVerry, Grant Richmond, and Kevin Marks for reviewing drafts of this post.

    on

  3. I read and re-checked the Explainer, and frankly given the repeated past
    Contacts API failures and zero mention of them in the Explainer, I’m going to deem this proposal not worth taking the time to thoroughly evaluate until the Explainer at a minimum:

    1. Documents previous Contacts API standards attempts (see https://tantek.com/2020/026/t2/ for some links to start)
    2. Provides summary explanations for their failures
    3. Describes how the current proposal is different from previous proposals in such a way as to at least avoid those failures (i.e. there should be a logical chain of reasoning from identifying key differences and how those either cause or prevent different outcomes from prior attempts).

    I think we should go ahead and publish a position of "defer", since a similar request to number 3 was made a whole year ago (https://github.com/w3ctag/design-reviews/issues/337#issuecomment-460555385) without any subsequent respective additions to the Explainer.

    Also given the critical comments in that discussion, especially from https://github.com/torgo, and knowing how much more abusive social network/media "apps" have become with aggressive sign-up, spam, user-acquisition tactics in recent years, I’m leaning towards expecting an eventual "harmful" evaluation.

    If the purely markup-only approaches were separated out into another proposal, I’d be more optimistic of more quickly evaluating those, and expecting browsers could implement those simpler (fewer ways to use/abuse) feature(s) in such a way that could be "worth prototyping".

    on

  4. Consider support for Bridgy Publish to Micropub servers

    on

    Per and as promised in my reply to issue 796 (comment on #796), it may be of some value to add Micropub as a generic Bridgy Publish destination, that is, Bridgy Publish acting as a Micropub client to post to Micropub servers.

    One possible use-case would be Bridgy Publish to silo.pub, and thus potentially enabling use of Webmention to Bridgy Publish as a method to gain access to any additional destinations that silo.pub itself supports. I.e.:

    indiewebsite --Webmention-> Bridgy Publish --Micropub-> silo.pub --❄️API-> silo

    Label: publish.

    on