Journal tags: copy

I’ve written quite a bit about how I’d like to see a declarative version of the Web Share API. My current proposal involves extending the type attribute on the button element to support a value of “share”.

Well, maybe a different attribute will end up accomplishing what I want! Check out the explainer for the “invokers” proposal over on Open UI. The idea is to extend the button element with a few more attributes.

The initial work revolves around declaratively opening and closing a dialog, which is an excellent use case and definitely where the effort should be focused to begin with.

But there’s also investigation underway into how this could be away to provide a declarative way of invoking JavaScript APIs. The initial proposal is already discussing the fullscreen API, and how it might be invoked like this:

button invoketarget="toggleFullsceen"

They’re also looking into a copy-to-clipboard action. It’s not much of a stretch to go from that to:

button invoketarget="share"

Remember, these are APIs that require a user interaction anyway so extending the button element makes a lot of sense.

I’ll be watching this proposal keenly. I’d love to see some of these JavaScript cowpaths paved with a nice smooth coating of declarative goodness.

I’ve been banging the drum for a button type="share" for a while now.

I’ve also written about other potential button types. The pattern I noticed was that, if a JavaScript API first requires a user interaction—like the Web Share API—then that’s a good hint that a declarative option would be useful:

The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have button type=”fullscreen” in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill.

There’s another “smell” that points to some potential button types: what functionality do browsers provide in their interfaces?

Some browsers provide a print button. So how about button type="print"? The functionality is currently doable with button onclick="window.print()" so this would be a nicer, more declarative way of doing something that’s already possible.

It’s the same with back buttons, forward buttons, and refresh buttons. The functionality is available through a browser interface, and it’s also scriptable, so why not have a declarative equivalent?

How about bookmarking?

And remember, the browser interface isn’t always visible: progressive web apps that launch with minimal browser UI need to provide this functionality.

Šime Vidas was wondering about button type="copy” for copying to clipboard. Again, it’s something that’s currently scriptable and requires a user gesture. It’s a little more complex than the other actions because there needs to be some way of providing the text to be copied, but it’s definitely a valid use case.

• button type="share"
• button type="fullscreen"
• button type="print"
• button type="bookmark"
• button type="back"
• button type="forward"
• button type="refresh"
• button type="copy"

Any more?

When I was speaking at conferences last year about service workers, I’d introduce the Cache API. I wanted some way of explaining the difference between caching and other kinds of storage.

The way I explained was that, while you might store stuff for a long time, you’d only cache stuff that you knew you were going to need again. So according to that definition, when you make a backup of your hard drive, that’s not caching …becuase you hope you’ll never need to use the backup.

But that explanation never sat well with me. Then more recently, I was chatting with Amber about caching. Once again, we trying to define the difference between, say, the Cache API and things like LocalStorage and IndexedDB. At some point, we realised the fundamental difference: caches are for copies.

Think about it. If you store something in LocalStorage or IndexedDB, that’s the canonical home for that data. But anything you put into a cache must be a copy of something that exists elsewhere. That’s true of the Cache API, the browser cache, and caches on the server. An item in one of those caches is never the original—it’s always a copy of something that has a canonical home elsewhere.

By that definition, backing up your hard drive definitely is caching.

Anyway, I was glad to finally have a working definition to differentiate between caching and storing.

Remember a while back I wrote about some odd behaviour with the Web Share API in Safari on iOS?

When the share() method is triggered, iOS provides multiple ways of sharing: Messages, Airdrop, email, and so on. But the simplest option is the one labelled “copy”, which copies to the clipboard.

Here’s the thing: if you’ve provided a text parameter to the share() method then that’s what’s going to get copied to the clipboard—not the URL.

That’s a shame. Personally, I think the url field should take precedence.

Tess filed a bug soon after, which was very gratifying to see.

Now Phil has put together a test case:

1. Share URL, title, and text
2. Share URL and title
3. Share URL and text

Very handy! The results (using the “copy” to clipboard action) are somewhat like rock, paper, scissors:

• URL beats title,
• text beats URL,
• nothing beats text.

So it’s more like rock, paper, high explosives.

I implemented the Web Share API over on The Session back when it was first available in Chrome in Android. It’s a nifty and quite straightforward API that allows websites to make use of the “sharing drawer” that mobile operating systems provide from within a web browser.

I already had sharing buttons that popped open links to Twitter, Facebook, and email. You can see these sharing buttons on individual pages for tunes, recordings, sessions, and so on.

I was already intercepting clicks on those buttons. I didn’t have to add too much to also check for support for the Web Share API and trigger that instead:

if (navigator.share) {
  navigator.share(
    {
      title: document.querySelector('title').textContent,
      text: document.querySelector('meta[name="description"]').getAttribute('content'),
      url: document.querySelector('link[rel="canonical"]').getAttribute('href')
    }
  );
}

That worked a treat. As you can see, there are three fields you can pass to the share() method: title, text, and url. You don’t have to provide all three.

Earlier this year, Safari on iOS shipped support for the Web Share API. I didn’t need to do anything. ‘Cause that’s how standards work. You can make use of APIs before every browser supports them, and then your website gets better and better as more and more browsers add support.

But I recently discovered something interesting about the iOS implementation.

When the share() method is triggered, iOS provides multiple ways of sharing: Messages, Airdrop, email, and so on. But the simplest option is the one labelled “copy”, which copies to the clipboard.

Here’s the thing: if you’ve provided a text parameter to the share() method then that’s what’s going to get copied to the clipboard—not the URL.

That’s a shame. Personally, I think the url field should take precedence. But I don’t think this is a bug, per se. There’s nothing in the spec to say how operating systems should handle the data sent via the Web Share API. Still, I think it’s a bit counterintuitive. If I’m looking at a web page, and I opt to share it, then surely the URL is the most important piece of data?

I’m not even sure where to direct this feedback. I guess it’s under the purview of the Safari team, but it also touches on OS-level interactions. Either way, I hope that somebody at Apple will consider changing the current behaviour for copying Web Share data to the clipboard.

In the meantime, I’ve decided to update my code to remove the text parameter:

if (navigator.share) {
  navigator.share(
    {
      title: document.querySelector('title').textContent,
      url: document.querySelector('link[rel="canonical"]').getAttribute('href')
    }
  );
}

If the behaviour of Safari on iOS changes, I’ll reinstate the missing field.

By the way, if you’re making progressive web apps that have display: standalone in the web app manifest, please consider using the Web Share API. When you remove the browser chrome, you’re removing the ability for users to easily share URLs. The Web Share API gives you a way to reinstate that functionality.

For a while now, The Session has had some little on-boarding touches to make sure that new members are eased into the culture of this traditional Irish music community.

First off, new members are encouraged to add a little bit about themselves so that there’s some context when they start making contributions.

Secondly, new members can’t kick off a brand new discussion straight away.

Likewise, they can’t post a comment straight away. They need to wait an hour between signing up and posting their first comment. Instead of seeing a comment form, they see a countdown.

Finally, when they do make their first submission—whether it’s a discussion, an event, a session, or a tune—the interface displays a few extra messages of encouragement and care.

But I realised that all of these custom messages were very one-sided. They were always displayed to the new member. It’s equally important that existing members treat any newcomers with respect.

Now on some discussions, an extra message is displayed to existing members right before the comment form. The logic is straightforward:

1. If this is a discussion added by a new member,
2. who hasn’t yet added any comments anywhere,
3. and this discussion has no responses so far,
4. and anyone other than that member is viewing the page,
5. then display a message asking for help making this new member feel welcome.

It’s a small addition, but it makes a difference.

No intricate JavaScript; no smooth animations; just some words on a screen encouraging a human connection.

You never forget your first DMCA takedown notice. In my case it was the Perfect Pitch incident, in which an incompetent business was sending out automatic takedown notices to Google for any website that contained a combination of the words Burge Pitch Torrent. That situation, which affected The Session, was resolved with an apology from the offending party.

Now I’ve received my second DMCA takedown notice. Or rather, my hosting company has. This time it involves Huffduffer.

When I created Huffduffer, I thought about offering hosting for audio files. One of the reasons I decided not to is because of the potential legal pitfalls. As it stands, Huffduffer is pretty much entirely text—it just links to audio files elsewhere on the web. That’s basically what an RSS enclosure is: another form of hypertext.

Linking is simply the act of pointing to a resource, and apart from a few extreme cases, it isn’t illegal.

Now it could be argued that pointing to an audio file on another site through a Flash player (or HTML5 audio element) is more like hotlinking with an img element than regular linking through an a element. The legal status of hotlinking isn’t quite as clear cut as plain ol’ linking, as explained on the Chilling Effects site:

When people complain about inline images, they are most often complaining about web pages that include graphics from external sources. The legal status of inlining images without permission has not been settled.

So the situation with inline audio is similarly murky.

Here’s the threatening email that was sent to the hosting company:

Notice of Copyright Infringement. {Our ref: [$#121809/228552]}

Sender: Robert Nichol
AudioGO Ltd
The Home of BBC Audiobooks
St James House, The Square, Lower Bristol Road
Bath
BA2 3BH
Phone number not available

Recipient: Rackspace Hosting

RE: Copyright Infringement.

This notice complies with the Digital Millennium Copyright Act (17 U.S.C. §512(c)(3))

I, Robert Nichol, swear under penalty of perjury that I am authorised to act on behalf of AudioGO Ltd, the owner(s) of the copyright or of an exclusive licence in the work(s) The Moving Finger by Agatha Christie BBC Audio.

It has come to my attention that the website huffduffer.com is engaged in the electronic distribution of copies of these works. It is my good faith belief that the use of these works in this manner is not authorised by the copyright owner, his agent or the law. This is in clear violation of United States, European Union, and International copyright law, and I now request that you expeditiously remove this material from huffduffer.com, or block or disable access to it, as required under both US and EU law.

The works are The Moving Finger by Agatha Christie BBC Audio.

The following URLs identify the infringing files and the means to locate them.

https://huffduffer.com/TimesPastOTR/68635 (IP: 67.192.7.4)

The information in this notice is accurate and I request that you expeditiously remove or block or disable access to all the infringing material or the entire site.

/Robert Nichol/
Robert Nichol

Wednesday April 18, 2012

Initially, my hosting company rebutted Robert Nichol’s claim but he’s not letting it go. He insists that the offending URL be removed or he will get the servers taken offline. So now I’ve been asked by my host to delete the relevant page on Huffduffer.

But the question of whether audio hotlinking counts as copyright infringement is a moot point in this case…

Go to the page in question. If you try to play the audio file, or click on the “download” link, you will find yourself at a 404 page. Whatever infringing material may have once been located at the end of the link is long gone …and yet AudioGO Ltd are still insisting that the Huffduffer page be removed!

Just to be clear about this, Robert Nichol is using the Digital Millennium Copyright Act—and claiming “good faith belief” while doing so—to have a site removed from the web that mentions the name of a work by his client, and yet that site not only doesn’t host any infringing material, it doesn’t even link to any infringing material!

It seems that, once again, the DMCA is being used in a scattergun approach like a machine-gun in the hands of a child. There could be serious repercussions for Robert Nichol in abusing a piece of legislation in this way.

If I were to remove the page in question, even though it just contains linkrot, it would set a dangerous precedent. It would mean that if someone else—like you, for instance—were to create a page that contains the text “Agatha Christie — The Moving Finger” while pointing to a dead link …well, your hosting company might find themselves slapped with a takedown notice.

In that situation, you wouldn’t be able to copy and paste this markup into your blog, Tumblr, Facebook, or Google+ page:

<a href="http://dc436.4shared.com/img/892695085/b3c907d3/dlink__2Fdownload_2FaKhc8m9b_3Ftsid_3D20120318-72646-b4a59ab0/preview.mp3">Agatha Christie — The Moving Finger</a>

Remember: that link does not point to any infringing material. It points to nothing but a 404 page. There’s absolutely no way that you could have your site taken offline for pointing to a file that doesn’t exist, right?

That would be crazy.

I’m on my way from Florida to the Pacific Northwest. I don’t mean I’m about to set out. I mean, right now I’m in a plane flying across North America from Orlando to Seattle. This in-flight WiFi lark is quite wonderful.

There are some other technological inventions that make long journeys more bearable. There’s podcasts, of course. I’m catching up on all the audio I’ve been huffduffing and there’s some truly wonderful stuff in there.

Then there’s the Kindle. Having a choice of reading material packed into a small but comfortable to read device is extremely convenient. Mind you, for take off and landing, you’ll still need a nice slim non-electronic book, such as Erin’s marvelous The Elements of Content Strategy.

But for all of its convenience, some things about the Kindle really stick in my craw.

First of all, there’s the DRM. It’s utterly, utterly pointless and may even be infringing copyright by violating the right of first sale—remember kids, copyright isn’t just about protecting the rights of the content producer; it’s about the rights of the consumer too.

Then there’s the pricing. There are some books I’d really like to buy right now. I’ve got my credit in my hand, ready to hand my money over to Amazon, but then I see that the Kindle edition costs more than the paperback. Often, the Kindle edition is closer in price to the hardback. That’s just not right—or even if it is “right” for economic and legal reasons, it doesn’t intuitively feel right to me, the potential customer.

Kevin Kelly figures that electronic books will cost about a dollar within five years. Sounds about right to me. He also extrapolated that Kindles could be free by November.

The ludicrous asking price for DRM’d electrons is even more galling when the publishers clearly put no effort whatsoever into the production of the work. I really wanted to buy Surface Detail, the latest Culture novel from Iain M. Banks, but when I found reviews bemoaning the conversion quality, I put my credit card away:

I read the Kindle version, and the Kindle version has been lazily put together, I’m guessing from an earlier manuscript version. It has missing or half completed paragraphs. Very frustrating.

Jessica had already bought The City And The City by China Miéville—another book I really want to read—but she had to get a refund because the formatting was so awful.

Phil Gyford, speaking in the context of shoddily-printed physical books, sums up my frustration with the way publishers are treating Kindle editions:

I want to love books, but if the publisher treats them merely as interchangeable units, where the details don’t matter so long as the bits, the “content”, is conveyed as cheaply as possible, then we may be falling out of love.

Cennydd doesn’t even bother with the book-reading aspect of the Kindle, using it instead as an interface onto Instapaper.

The Kindle is a great lightweight reading device that’s particularly handy for travelling with—and the 3G version provides an almost miraculous permanent internet connection without any monthly contract—but the Kindle ecosystem, for all its Whispernet wonderment, is kind of nasty.

Now Amazon have decided that this ecosystem will not include third-party additions like Lendle. Even nastier.

The past

These talking machines are going to ruin the artistic development of music in this country. When I was a boy…in front of every house in the summer evenings, you would find young people together singing the songs of the day or old songs. Today you hear these infernal machines going night and day. We will not have a vocal cord left. The vocal cord will be eliminated by a process of evolution, as was the tail of man when he came from the ape.

—John Philip Sousa

The present

The future

The International Convention on Performing Rights is holding a third round of crisis talks in an attempt to stave off the final collapse of the WIPO music licensing regime. On the one hand, hard-liners representing the Copyright Control Association of America are pressing for restrictions on duplicating the altered emotional states associated with specific media performances: As a demonstration that they mean business, two “software engineers” in California have been kneecapped, tarred, feathered, and left for dead under placards accusing them of reverse-engineering movie plot lines using avatars of dead and out-of-copyright stars.

On the opposite side of the fence, the Association of Free Artists are demanding the right of perform music in public without a recording contract, and are denouncing the CCAA as being a tool of Mafiya apparachiks who have bought it from the moribund music industry in an attempt to go legit. FBI Director Leonid Kuibyshev responds by denying that the Mafiya is a significant presence in the United States. But the music biz’s position isn’t strengthened by the near collapse of the legitimate American entertainment industry, which has been accelerating ever since the nasty noughties.

—Accelerando by Charles Stross

It has been said before but I’ll say it again: copy is interface. Josh sums it up nicely in his post Writing Microcopy:

The fastest way to improve your interface is to improve your copy-writing.

The canonical online example is Moo.com with its adorably anthropomorphised Little Moo robot personality. An oft-cited offline paragon is Innocent Smoothies with their cheeky little packaging easter egg delighters.

My favourite meatspace exemplar is right here in Brighton. The Earth and Stars pub has an outside chalkboard with a distinct personality. Over the past two years, I’ve been chronicling its announcements on Flickr.

Some samples:

Why does everyone always look at me? I know I’m a chalkboard and that’s my job, I just wish people would ask before staring at me. Sometimes I don’t have anything to say.

All the chalkboards inside think they’re so special! They seem to forget that I was here first! If I can see off the English weather, then I can certainly see off those punks!

I’m the unluckiest chalkboard in Brighton. Summer’s coming and this side of the building is always in the shade. Please come inside and tell them to move me to the western wall.

What are you looking at? I’ve told you before that it’s rude to stare! Be warned… I’m the chalkboard Kung Fu champion and not afraid to use my skills.

So bored of this job. I don’t want to be a chalkboard anymore. I wish I’d paid more attention in woodwork, I could have been a skateboard or a sun-lounger… at least I’m not a chopping board.

Stop looking at me like I’m a waste of space! I’m not just a chalkboard you know! I’m also a supporting wall. I provide shelter from wild beasts and tropical storms. Go inside so I don’t have to see you!

And my favourite:

Help me.

Walking past the chalkboard this week, I was pleased to see that it had been updated. Taking out my camera, I read the latest message:

Call me paranoid but I’m sure someone’s watching me, some are even taking pictures. I’m not sure of my rights as a chalkboard, but I feel violated. I’ll be watching you Mr. Keith!

I’m being cyberstalked by a paranoid existentialist chalkboard.

Made me smile.

This week, when I’m not battling the zombies of the linkrot apocalypse with a squirrel, I’m preparing my presentation for Bamboo Juice. I wasted far too much time this morning watching the ancillary material from the BBC’s The Speaker in the vain hope that it might help my upcoming public speaking engagement.

My talk is going to be a long zoom presentation along the lines of Open Data and The Long Web. I should concentrate on technologies, standards and file formats but I find myself inevitably being drawn in to the issue of copyright and the current ludicrous state of things.

If you feel like getting as riled up as I am, be sure to listen to James Boyle as he speaks at the RSA or is interviewed on CBC. Or you could just cut to the chase and read his book, The Public Domain. If you want to try before you buy, you can read the entire book online in PDF or HTML format—I recommend reading that version with the help of the fantastic Readability bookmarklet.

As if any proof were needed that this is an important, current, relevant issue, Tom reminds me that the future of our culture is under threat again tomorrow. I have duly written to some of my MEPs. Fortunately, I have a most excellent representative:

We’re talking about a gigantic windfall for a few multinational companies, taking millions of pounds from the pockets of consumers and giving it to the record labels. Also, the artistic cost of making songs from the last 50 years public property, thus allowing endless sampling by DJs and other artists, must be taken into consideration.

The UK Greens are committed to a system known as Creative Commons, which offers a flexible range of protections and freedoms for authors and artists. We want to encourage innovation and prevent large corporations from controlling and benefitting from our cultural legacy.