Chris Aldrich

UI: Duration doesn't make sense in Read post kind · Issue #65 · dshanske/indieweb-post-kinds https://github.com/dshanske/indieweb-post-kinds/issues/65

When making a "Read" post in which data exists in the "time" tab for published dt and updated dt, the output displays more like one would anticipate with a music post type (or jam, listen, play, watch, travel) using start/end vocabulary instead and outputting a "Duration".

Duration may make sense if one were doing a start/end time for their reading, but then the scraper shouldn't be automatically pulling in the publish/update dates/times. Personally I'd prefer to let the publication time of my post indicate when the thing was read and have Post Kinds indicate the publication of the original piece I was reading.

Possibly better would be an if/then statement to differentiate types and for Read types outputting a date/time for the original publication and/or potentially an updated date/time if it exists.

At present, the issue is most common on New York Times posts for which the scraper pulls in the correct metadata.

Example: http://boffosocko.com/2016/11/14/chris-aldrich-is-reading-facebook-restores-iconic-vietnam-war-photo-it-censored-for-nudity/
![duration](https://cloud.githubusercontent.com/assets/5882943/20466247/6e5f67aa-af24-11e6-9d57-f83c3928163f.PNG)

For a small portion of IndieWeb sites, the scraper is returning data in these fields that are identical for both the published and updated fields which returns an odd duration result as well. (See: http://boffosocko.com/2016/11/11/chris-aldrich-is-reading-fragmentions-for-poets/) Perhaps if the date/time in both fields are identical, there could be some error checking to prevent a spurious output since published shouldn't equal updated.

About/FAQ missing reference to webmention-endpoint? · Issue #673 · snarfed/bridgy

I'm always a fan of instructions being built intuitively into the UI flow, to guide new users along, especially if they have a solid idea of what they're getting into in the first place. In this particular instance, the reference to the HTML was a tad too nebulous and may confuse many -- especially those who begin reading rather than jumping right in.

Shortly the indieweb will be so big that totally tyro users with no facility with code will be on the doorstep and will need better explanations/instructions. Perhaps I'll take some time in the coming months to put together simple walk thrus for the handful of major platforms? If you think it's worthwhile, can you let me know, based on the current userbase (or even recent growth in the past 6months-year), how you'd rank them in order of priority so we can help the biggest groups first? Or perhaps it's worth starting at the lowest hurdle for the least technical users (Tumblr/Blogger?) and building toward the more technical (WordPress.com)? (I'd presume most above this level are okay with most of what exists now).

I'm presuming that Brid.gy was originally meant as a "code" bridge to connect activity on silos, but I can also see it as taking on a secondary meaning in providing the initial value and impetus to bridge users into to the bigger IndieWeb movement.

Chris Aldrich

Checked into Toy's #6