Reply to Annotating Web Audio by Jon Udell

Annotating Web Audio by Jon UdellJon Udell (Jon Udell)
On a recent walk I listened to Unmasking Misogyny on Radio Open Source. One of the guests, Danielle McGuire, told the story of Rosa Parks’ activism in a way I hadn’t heard before. I wanted to capture that segment of the show, save a link to it, and bookmark the link for future reference.

Jon, this is certainly an awesome and interesting way to target audio on the web, which can be tremendously useful.

Given what you’ve got here, I suspect that you may be unaware of the W3C spec for media fragments which may make portions of what you’re attempting to do a bit easier (and also much more standardized). The spec is relatively broadly supported by most browsers, so it immediately makes things a tad easier from a plumbing perspective.

Some people will be somewhat familiar with the targeting technique as it’s similar to the one used by YouTube which lets users hot link to specific portions of video on their platform.

To summarize the concept, on most audio and video files one can add a #t=XXX the the end of a URL where XXX is the number in seconds into the file where one wants to start. One can target stretches of audio similarly with the pattern #t=XXX,YYY where XXX is the start and YYY is the stop time for the fragment, again in seconds.

As an example I can use it to specifically target the audio  on a particular standalone audio file like so:

https://media.martymcgui.re/70/d5/f1/77/975194c74454dc7a3ef71586bf98612a94bcb5685f7e7d3ca60dc183.mp3#t=269

With some clever JavaScript, one can go a step further and implement this at the level of targeting audio/video as embedded on a particular page which may contain a wealth of additional (potentially necessary) context. As an example of this, we can look at the audio above in its original context as part of a podcast using the same type of time fragment notation:

https://martymcgui.re/2017/10/29/163907/#t=269

As an added bonus, on this particular page with audio, you’ll notice that you can play the audio and if you pause it, the page URL in your browser should automatically refresh to indicate the particular audio timestamp for that particular position! Thus in your particular early example it makes things far easier to bookmark, save, or even share!

For use within Hypothesis, I suspect that one could use this same type of system to directly annotate the original audio file on the original page by using this scheme, potentially by using such JavaScript within the browser plugin for Hypothesis.

It would be nice if the user could queue up the particular audio segment and press pause, and then annotate the audio portion of the page using such a targeting segment. Then one could potentially share a specific URL for their annotation (in typical Hypothesis fashion) that not only targets the original page with the embedded audio, but it could also have that audio queued up to the correct portion (potentially with a page refresh to reset the audio depending on the annotation.)

The nice part is that the audio can be annotated within the page on which it originally lived rather than on some alternate page on the web that requires removing the context and causing potential context collapse. It also means one doesn’t have to host an intermediate page to have the whole thing work.

For more information on the idea, take a peek at the IndieWeb’s page on audio fragments which includes a few examples of people using it in the wild as well as a link to the JavaScript sample for doing the targeting within the page itself.

I’m curious if the scheme may make putting all the smaller loose pieces together even easier, particularly for use within Hypothesis? and while keeping more of the original context in which the audio was found?

I also suspect that these types of standards could be used to annotate audio in much the same way that the SoundCloud service handles their audio annotations, though in a much more open way. One would simply need to add on some additional UI to make the annotations on such audio present differently.

Just for fun, this type of sub-targeting on web pages also works visually for text as well with the concept of fragmention. As an example of this, I can target this specific paragraph with this link http://boffosocko.com/2018/01/07/reply-to-annotating-web-audio-by-jon-udell/#Just+for+fun, and a snippet of JavaScript on the page creates a yellow highlighting effect as well.

Syndicated copies to:

Mozilla Acquires Pocket | The Mozilla Blog

Mozilla Acquires Pocket (The Mozilla Blog)
We are excited to announce that the Mozilla Corporation has completed the acquisition of Read It Later, Inc. the developers of Pocket.

Continue reading “Mozilla Acquires Pocket | The Mozilla Blog”

Syndicated copies to:

Read posts nearly perfected!

Hoorah, hooray!

In a project which I started just before IndieWebCamp LA in November, I’ve moved a big step closer to perfecting my “Read” posts!

Thanks in large part to WordPressPressForward, friends and help on the IndieWeb site too numerous to count, and a little bit of elbow grease, I can now receive and read RSS feeds in my own website UI (farewell Feedly), bookmark posts I want to read later (so long Pocket, Instagram, Delicious and Pinboard), mark them as read when done, archive them on my site (and hopefully on the Internet Archive as well) for future reference, highlight and annotate them (I still love you hypothes.is, but…), and even syndicate (POSSE) them automatically (with emoji) to silos like Facebook, Twitter (with Twitter Cards), Tumblr, Flipboard, LinkedIn, Pinterest, StumbleUpon, Reddit, and Delicious among others.

Syndicated copies in the silos when clicked will ping my site for a second and then automatically redirect to the canonical URL for the original content to give the credit to the originating author/site. And best of all, I can still receive comments, likes, and other responses from the siloed copies via webmention to stay in the loop on the conversations they generate without leaving my site.

Here’s an example of a syndicated post to Twitter:

I’m now more resistant to a larger number of social media silos disappearing with my data. Huzzah!

What’s next?

 

Syndicated copies to:

I’ve discovered a spectacular tool for owning my own bookmarks and replacing Pocket and InstaPaper!

I’ve discovered a spectacular tool for owning my own bookmarks and replacing Pocket and InstaPaper!

  • It’s IndieWeb and POSSE friendly
  • Does link forwarding in a flexible/responsible manner
  • Allows for proper attributions
  • Keeps tons of metadata for analyzing reading behavior
  • Taggable
  • Allows for comments/commenting
  • Could be used easily as a linkblog
  • Archives the original article
  • Is searchable
  • Could be used for collaboration and curation
  • Has Readability integrated
  • Has a pre-configured browser bookmarklet
  • Is open source and well documented

Who could want more?! I want to experiment a bit with it, play with multiple configurations, and then document parts before rolling out–particularly as it wasn’t necessarily intended for this use case, but I’ll have some more details shortly.

Syndicated copies to:

Chris Aldrich is reading “Maybe the Internet Isn’t a Fantastic Tool for Democracy After All”

Maybe the Internet Isn’t a Fantastic Tool for Democracy After All by Max Read (Select All)
Fake news is the easiest of the problems to fix.

…a new set of ways to report and share news could arise: a social network where the sources of articles were highlighted rather than the users sharing them. A platform that makes it easier to read a full story than to share one unread. A news feed that provides alternative sources and analysis beneath every shared article.

This sounds like the kind of platforms I’d like to have. Reminiscent of some of the discussion at the beginning of This Week in Google: episode 379 Ixnay on the Eet-tway.

I suspect that some of the recent coverage of “fake news” and how it’s being shared on social media has prompted me to begin using Reading.am, a bookmarking-esqe service that commands that users to:

Share what you’re reading. Not what you like. Not what you find interesting. Just what you’re reading.

Naturally, in IndieWeb fashion, I’m also posting these read articles to my site. While bookmarks are things that I would implicitly like to read in the near future (rather than “Christmas ornaments” I want to impress people with on my “social media Christmas tree”), there’s a big difference between them and things that I’ve actually read through and thought about.

I always feel like many of my family, friends, and the general public click “like” or “share” on articles in social media without actually having read them from top to bottom. Research would generally suggest that I’m not wrong. [1] [2] Some argue that the research needs to be more subtle too. [3] I generally refuse to participate in this type of behavior if I can avoid it.

Some portion of what I physically read isn’t shared, but at least those things marked as “read” here on my site are things that I’ve actually gone through the trouble to read from start to finish. When I can, I try to post a few highlights I found interesting along with any notes/marginalia (lately I’m loving the service Hypothes.is for doing this) on the piece to give some indication of its interest. I’ll also often try to post some of my thoughts on it, as I’m doing here.

Gauging Intent of Social Signals

I feel compelled to mention here that on some platforms like Twitter, that I don’t generally use the “like” functionality there to indicate that I’ve actually liked a tweet itself or any content that’s linked to in it. In fact, I’ve often not read anything related to the tweet but the simple headline presented in the tweet itself.

The majority of the time I’m liking/favoriting something on Twitter, it’s because I’m using an IFTTT.com applet which takes the tweets I “like” and saves them to my Pocket account where I come back to them later to read. It’s not the case that I actually read everything in my pocket queue, but those that I do read will generally appear on my site.

There are however, some extreme cases in which pieces of content are a bit beyond the pale for indicating a like on, and in those cases I won’t do so, but will manually add them to my reading queue. For some this may create some grey area about my intent when viewing things like my Twitter likes. Generally I’d recommend people view that feed as a generic linkblog of sorts. On Twitter, I far more preferred the nebulous star indicator over the current heart for indicating how I used and continue to use that bit of functionality.

I’ll also mention that I sometimes use the like/favorite functionality on some platforms to indicate to respondents that I’ve seen their post/reply. This type of usage could also be viewed as a digital “Thank You”, “hello”, or even “read receipt” of sorts since I know that the “like” intent is pushed into their notifications feed. I suspect that most recipients receive these intents as I intend them though the Twitter platform isn’t designed for this specifically.

I wish that there was a better way for platforms and their readers to better know exactly what the intent of the users’ was rather than trying to intuit them. It would be great if Twitter had the ability to allow users multiple options under each tweet to better indicate whether their intent was to bookmark, like, or favorite it, or to indicate that they actually read/watched the content on the other end of the link in the tweet.

In true IndieWeb fashion, because I can put these posts on my own site, I can directly control not only what I post, but I can be far more clear about why I’m posting it and give a better idea about what it means to me. I can also provide footnotes to allow readers to better see my underlying sources and judge for themselves their authenticity and actual gravitas. As a result, hopefully you’ll find no fake news here.

Of course some of the ensuing question is: “How does one scale this type of behaviour up?”

References

[1]
M. Gabielkov, A. Ramachandran, A. Chaintreau, and A. Legout, “Social Clicks: What and Who Gets Read on Twitter?,” SIGMETRICS Perform. Eval. Rev., vol. 44, no. 1, pp. 179–192, Jun. 2016 [Online]. Available: http://doi.acm.org/10.1145/2964791.2901462
[2]
C. Dewey, “6 in 10 of you will share this link without reading it, a new, depressing study says,” Washington Post, 16-Jun-2016. [Online]. Available: https://www.washingtonpost.com/news/the-intersect/wp/2016/06/16/six-in-10-of-you-will-share-this-link-without-reading-it-according-to-a-new-and-depressing-study/. [Accessed: 06-Dec-2016]
[3]
T. Cigelske  , “Why It’s OK to Share This Story Without Reading It ,” MediaShift, 24-Jun-2016. [Online]. Available: http://mediashift.org/2016/06/why-its-ok-to-share-this-story-without-reading-it/. [Accessed: 06-Dec-2016]
Syndicated copies to:

Chris Aldrich is reading “Instapaper is joining Pinterest”

Instapaper is joining Pinterest (blog.instapaper.com)
Today, we’re excited to announce that Instapaper is joining Pinterest. In the three years since betaworks acquired Instapaper from Marco Arment, we’ve completely rewritten our backend, overhauled our mobile and web clients, improved parsing and search, and introduced tons of great features like highlights, text-to-speech, and speed reading to the product.
Syndicated copies to:

A New Reading Post-type for Bookmarking and Reading Workflow

Thoughts on post types/kinds relating to reading within the Indieweb construct

This morning while breezing through my Woodwind feed reader, I ran across a post by Rick Mendes with the hashtags #readlater and #readinglist which put me down a temporary rabbit hole of thought about reading-related post types on the internet.

I’m obviously a huge fan of reading and have accounts on GoodReads, Amazon, Pocket, Instapaper, Readability, and literally dozens of other services that support or assist the reading endeavor. (My affliction got so bad I started my own publishing company last year.)

READ LATER is an indication on (or relating to) a website that one wants to save the URL to come back and read the content at a future time.

I started a page on the IndieWeb wiki to define read later where I began writing some philosophical thoughts. I decided it would be better to post them on my own site instead and simply link back to them. As a member of the Indieweb my general goal over time is to preferentially quit using these web silos (many of which are listed on the referenced page) and, instead, post my reading related work and progress here on my own site. Naturally, the question becomes, how does one do this in a simple and usable manner with pretty and reasonable UX/UI for both myself and others?

Current Use

Currently I primarily use a Pocket bookmarklet to save things (mostly newspaper articles, magazine pieces, blog posts) for reading later and/or the like/favorite functionality in Twitter in combination with an IFTTT recipe to save the URL in the tweet to my Pocket account. I then regularly visit Pocket to speed read though articles. While Pocket allows downloading of (some) of one’s data in this regard, I’m exploring options to bring in the ownership of this workflow into my own site.

For more academic leaning content (read journal articles), I tend to rely on an alternate Mendeley-based workflow which also starts with an easy-to-use bookmarklet.

I’ve also experimented with bookmarking a journal article and using hypothes.is to import my highlights from that article, though that workflow has a way to go to meet my personal needs in a robust way while still allowing me to own all of my own data. The benefit is that fixing it can help more than just myself while still fitting into a larger personal workflow.

Brainstorming

A Broader Reading (Parent) Post-type

Philosophically a read later post-type could be considered similar to a (possibly) unshared or private bookmark with potential possible additional meta-data like: progress, date read, notes, and annotations to be added after the fact, which then technically makes it a read post type.

A potential workflow viewed over time might be: read later >> bookmark >> notes/annotations/marginalia >> read >> review. This kind of continuum of workflow might be able to support a slightly more complex overall UI for a more simplified reading post-type in which these others are all sub-types. One could then make a single UI for a reading post type with fields and details for all of the sub-cases. Being updatable, the single post could carry all the details of one’s progress.

Indieweb encourages simplicity (DRY) and having the fewest post-types possible, which I generally agree with, but perhaps there’s a better way of thinking of these several types. Concatenating them into one reading type with various data fields (and the ability of them to be public/private) could allow all of the subcategories to be included or not on one larger and more comprehensive post-type.

Examples
  1. Not including one subsection (or making it private), would simply prevent it from showing, thus one could have a traditional bookmark post by leaving off the read later, read, and review sub-types and/or data.
  2. As another example, I could include the data for read later, bookmark, and read, but leave off data about what I highlighted and/or sub-sections of notes I prefer to remain private.

A Primary Post with Webmention Updates

Alternately, one could create a primary post (potentially a bookmark) for the thing one is reading, and then use further additional posts with webmentions on each (to the original) thereby adding details to the original post about the ongoing progress. In some sense, this isn’t too far from the functionality provided by GoodReads with individual updates on progress with brief notes and their page that lists the overall view of progress. Each individual post could be made public/private to allow different viewerships, though private webmentions may be a hairier issue. I know some are also experimenting with pushing updates to posts via micropub and other methods, which could be appealing as well.

This may be cumbersome over time, but could potentially be made to look something like the GoodReads UI below, which seems very intuitive. (Note that it’s missing any review text as I’m currently writing it, and it’s not public yet.)

Overview of reading progress
Overview of reading progress

Other Thoughts

Ideally, better distinguishing between something that has been bookmarked and read/unread with dates for both the bookmarking and reading, as well as potentially adding notes and highlights relating to the article is desired. Something potentially akin to Devon Zuegel‘s “Notes” tab (built on a custom script for Evernote and Tumblr) seems somewhat promising in a cross between a simple reading list (or linkblog) and a commonplace book for academic work, but doesn’t necessarily leave room for longer book reviews.

I’ll also need to consider the publishing workflow, in some sense as it relates to the reverse chronological posting of updates on typical blogs. Perhaps a hybrid approach of the two methods mentioned would work best?

Potentially having an interface that bolts together the interface of GoodReads (picture above) and Amazon’s notes/highlights together would be excellent. I recently noticed (and updated an old post) that they’re already beta testing such a beast.

Kindle Notes and Highlights are now shoing up as a beta feature in GoodReads
Kindle Notes and Highlights are now shoing up as a beta feature in GoodReads

Comments

I’ll keep thinking about the architecture for what I’d ultimately like to have, but I’m always open to hearing what other (heavy) readers have to say about the subject and the usability of such a UI.

Please feel free to comment below, or write something on your own site (which includes the URL of this post) and submit your URL in the field provided below to create a webmention in which your post will appear as a comment.

Syndicated copies to: