Tags: sharing

210

sparkline

Wednesday, September 16th, 2020

A polyfill for button type=”share”

After writing about a declarative Web Share API here yesterday I thought I’d better share the idea (see what I did there?).

I opened an issue on the Github repo for the spec.

(I hope that’s the right place for this proposal. I know that in the past ideas were kicked around on the Discourse site for Web platform Incubator Community Group but I can’t stand Discourse. It literally requires JavaScript to render anything to the screen even though the entire content is text. If it turns out that that is the place I should’ve posted, I guess I’ll hold my nose and do it using the most over-engineered reinvention of the browser I’ve ever seen. But I believe that the plan is for WICG to migrate proposals to Github anyway.)

I also realised that, as the JavaScript Web Share API already exists, I can use it to polyfill my suggestion for:

<button type="share">

The polyfill also demonstrates how feature detection could work. Here’s the code.

This polyfill takes an Inception approach to feature detection. There are three nested levels:

  1. This browser supports button type="share". Great! Don’t do anything. Otherwise proceed to level two.
  2. This browser supports the JavaScript Web Share API. Use that API to share the current page URL and title. Otherwise proceed to level three.
  3. Use a mailto: link to prefill an email with the page title as the subject and the URL in the body. Ya basic!

The idea is that, as long as you include the 20 lines of polyfill code, you could start using button type="share" in your pages today.

I’ve made a test page on Codepen. I’m just using plain text in the button but you could use a nice image or SVG or combination. You can use the Codepen test page to observe two of the three possible behaviours browsers could exhibit:

  1. A browser supports button type="share". Currently that’s none because I literally made this shit up yesterday.
  2. A browser supports the JavaScript Web Share API. This is Safari on Mac, Edge on Windows, Safari on iOS, and Chrome, Samsung Internet, and Firefox on Android.
  3. A browser supports neither button type="share" nor the existing JavaScript Web Share API. This is Firefox and Chrome on desktop (and Edge if you’re on a Mac).

See the Pen Polyfill for button type=”share" by Jeremy Keith (@adactio) on CodePen.

The polyfill doesn’t support Internet Explorer 11 or lower because it uses the DOM closest() method. Feel free to fork and rewrite if you need to support old IE.

Tuesday, September 15th, 2020

A declarative Web Share API

I’ve written about the Web Share API before. It’s a handy little bit of JavaScript that—if supported—brings up a system-level way of sharing a page. Seeing as it probably won’t be long before we won’t be able to see full URLs in browsers anymore, it’s going to fall on us as site owners to provide this kind of fundamental access.

Right now the Web Share API exists entirely in JavaScript. There are quite a few browser APIs like that, and it always feels like a bit of a shame to me. Ideally there should be a JavaScript API and a declarative option, even if the declarative option isn’t as powerful.

Take form validation. To cover the most common use cases, you probably only need to use declarative markup like input type="email" or the required attribute. But if your use case gets a bit more complicated, you can reach for the Constraint Validation API in JavaScript.

I like that pattern. I wish it were an option for JavaScript-only APIs. Take the Geolocation API, for example. Right now it’s only available through JavaScript. But what if there were an input type="geolocation" ? It wouldn’t cover all use cases, but it wouldn’t have to. For the simple case of getting someone’s location (like getting someone’s email or telephone number), it would do. For anything more complex than that, that’s what the JavaScript API is for.

I was reminded of this recently when Ada Rose Cannon tweeted:

It really feels like there should be a semantic version of the share API, like a mailto: link

I think she’s absolutely right. The Web Share API has one primary use case: let the user share the current page. If that use case could be met in a declarative way, then it would have a lower barrier to entry. And for anyone who needs to do something more complicated, that’s what the JavaScript API is for.

But Pete LePage asked:

How would you feature detect for it?

Good question. With the JavaScript API you can do feature detection—if the API isn’t supported you can either bail or provide your own implementation.

There a few different ways of extending HTML that allow you to provide a fallback for non-supporting browsers.

You could mint a new element with a content model that says “Browsers, if you do support this element, ignore everything inside the opening and closing tags.” That’s the way that the canvas element works. It’s the same for audio and video—they ignore everything inside them that isn’t a source element. So developers can provide a fallback within the opening and closing tags.

But forging a new element would be overkill for something like the Web Share API (or Geolocation). There are more subtle ways of extending HTML that I’ve already alluded to.

Making a new element is a lot of work. Making a new attribute could also be a lot of work. But making a new attribute value might hit the sweet spot. That’s why I suggested something like input type="geolocation" for the declarative version of the Geolocation API. There’s prior art here; this is how we got input types for email, url, tel, color, date, etc. The key piece of behaviour is that non-supporting browsers will treat any value they don’t understand as “text”.

I don’t think there should be input type="share". The action of sharing isn’t an input. But I do think we could find an existing HTML element with an attribute that currently accepts a list of possible values. Adding one more value to that list feels like an inexpensive move.

Here’s what I suggested:

<button type=”share” value=”title,text”>

For non-supporting browsers, it’s a regular button and needs polyfilling, no different to the situation with the JavaScript API. But if supported, no JS needed?

The type attribute of the button element currently accepts three possible values: “submit”, “reset”, or “button”. If you give it any other value, it will behave as though you gave it a type of “submit” or “button” (depending on whether it’s in a form or not) …just like an unknown type value on an input element will behave like “text”.

If a browser supports button type="share”, then when the user clicks on it, the browser can go “Right, I’m handing over to the operating system now.”

There’s still the question of how to pass data to the operating system on what gets shared. Currently the JavaScript API allows you to share any combination of URL, text, and description.

Initially I was thinking that the value attribute could be used to store this data in some kind of key/value pairing, but the more I think about it, the more I think that this aspect should remain the exclusive domain of the JavaScript API. The declarative version could grab the current URL and the value of the page’s title element and pass those along to the operating system. If you need anything more complex than that, use the JavaScript API.

So what I’m proposing is:

<button type="share">

That’s it.

But how would you test for browser support? The same way as you can currently test for supported input types. Make use of the fact that an element’s attribute value and an element’s property value (which 99% of the time are the same), will be different if the attribute value isn’t supported:

var testButton = document.createElement("button");
testButton.setAttribute("type","share");
if (testButton.type != "share") {
// polyfill
}

So that’s my modest proposal. Extend the list of possible values for the type attribute on the button element to include “share” (or something like that). In supporting browsers, it triggers a very bare-bones handover to the OS (the current URL and the current page title). In non-supporting browsers, it behaves like a button currently behaves.

Monday, September 14th, 2020

15 years of blogging (and 3 reasons I keep going) - Austin Kleon

Why keep blogging? For me, there are at least 3 good reasons:

  1. To leave a trace.
  2. To figure out what I have to say.
  3. Because I like it.

Friday, July 31st, 2020

ongoing by Tim Bray · Meta Blog

But aren’t blogs dead? · Um, nope. For every discipline-with-depth that I care about (software/Internet, politics, energy economics, physics), if you want to find out what’s happening and you want to find out from first-person practitioners, you end up reading a blog.

Dense information from real experts, delivered fast. Why would you want any other kind?

Friday, July 17th, 2020

Why you should have a blog (and write in it) | Leticia Portella

Having your independent blog is an excellent way to share what you think in a decentralized way, independent of any major company that may add a paywall to it (Medium, I am looking at you).

Friday, June 12th, 2020

What was it like? (Phil Gyford’s website)

Congratulations and kudos to Phil for twenty years of blogging!

Here he describes what it was like online in the year 2000. Yes, it was very different to today, but…

Anyone who thinks blogging died at some point in the past twenty years presumably just lost interest themselves, because there have always been plenty of blogs to read. Some slow down, some die, new ones appear. It’s as easy as it’s ever been to write and read blogs.

Though Phil does note:

Some of the posts I read were very personal in a way that’s less common now, in general. … Even “personal” websites (like mine) often have an awareness about them, about what’s being shared, the impression it gives to strangers, presenting a public face, maybe a feeling of, “I’m just writing personal nonsense but, why, yes, I am available for hire”.

Maybe that’s why I’m enjoying Robin’s writing so much.

Sunday, June 7th, 2020

There’s a voice inside your head that prevents you from sharing ideas—punch it in the face. - Airbag Industries

When I challenge the idea of topics—especially when I suggest writing about a design topic—the “I don’t know what to write about” excuse goes to level two: Someone has already written about [design topic]. And that might be true, but by Great Gutenberg’s Ghost, if that was a hard requirement for publishing, we’d have one newspaper, a few magazines, and maybe a thousand books. Hollywood would be a ghost town because we got to the end of all of the movie tropes by 1989. We’d have seventy-five songs with lyrics, but re-recorded in every music style and everyone would still hate Yanni. The point is you can’t let the people who have come before you be the excuse to stop you from writing or, frankly, creating.

Monday, June 1st, 2020

The Curse of Knowledge · Matthias Ott – User Experience Designer

A great explanation of the curse of knowledge …with science!

(This, by the way, is the first of 100 blog posts that Matthias is writing in 100 days.)

Friday, May 29th, 2020

Reading in the dark

I keep coming back to this remarkable piece of writing by Cassie. Honest, resonant, and open, centred around a perfect analogy.

Tuesday, May 26th, 2020

Responsive web design turns ten. — Ethan Marcotte

2010 was quite a year:

And exactly three weeks after Jeremy Keith’s HTML5 For Web Designers was first published, “Responsive Web Design” went live in A List Apart.

Nothing’s been quite the same since.

I remember being at that An Event Apart in Seattle where Ethan first unveiled the phrase and marvelling at how well everything just clicked into place, perfectly capturing the zeitgeist. I was in. 100%.

Wednesday, May 13th, 2020

Why does writing matter in remote work? — Tim Casasola

Some good writing advice in here:

  • Spell out your acronyms.
  • Use active voice, not passive voice.
  • Fewer commas. More periods.

Friday, April 10th, 2020

Web Share API test

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.

Wednesday, April 1st, 2020

Indoor Voices 🤫🤫🤫

A group blog by a whole bunch of people who are staying at home.

It’s hard to believe, but there was a time where the internet was just full of casual websites posting random stuff. And you’d go to them maybe even multiple times a day to see if they had posted any new stories. It was something we all did when we were bored at our desks, at our jobs. Now there are no more desks. But there are still blogs.

Friday, March 27th, 2020

Let a website be a worry stone

I find myself thinking about writing more than usual at the moment. This is partially because I am inspired by more people sharing their own thoughts and stories, but also because I want to record how I’m feeling, and what’s happening on a day-to-day basis.

Tuesday, March 24th, 2020

Scatternotes - QuirksBlog

Jeremy is right. Writing helps. I feel better already.

See?

Monday, March 23rd, 2020

“Making Design Systems Public,” an article from SuperFriendly

Is making your design system public worth the effort? In short: yes, it is.

I agree with Dan. But I wish that more people would make their design system mistakes and misteps public, like Robin talked about.

Wednesday, March 18th, 2020

Cameron Moll | Don’t call it a comeback. I been here for years.

Cameron’s blog is back, and very nicely redesigned/aligned it is too!

Wednesday, February 5th, 2020

Design systems roundup

When I started writing a post about architects, gardeners, and design systems, it was going to be a quick follow-up to my post about web standards, dictionaries, and design systems. I had spotted an interesting metaphor in one of Frank’s posts, and I thought it was worth jotting it down.

But after making that connection, I kept writing. I wanted to point out the fetishism we have for creation over curation; building over maintenance.

Then the post took a bit of a dark turn. I wrote about how the most commonly cited reasons for creating a design system—efficiency and consistency—are the same processes that have led to automation and dehumanisation in the past.

That’s where I left things. Others have picked up the baton.

Dave wrote a post called The Web is Industrialized and I helped industrialize it. What I said resonated with him:

This kills me, but it’s true. We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it. We operate more like Taylor and his stopwatch and Gantt and his charts, maximizing effort and impact rather than focusing on the human aspects of product development.

But he also points out the many benefits of systemetising:

At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.

Emphasis mine. I think that’s a key phrase: “a willing team.”

Ethan tackles this in his post The design systems we swim in:

A design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.

But a design system need not be a constraining straitjacket—a means of enforcing consistency by keeping creators from colouring outside the lines. Used well, a design system can be a tool to give creators more freedom:

Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?

This is key. A design system is the product of an organisation’s culture. That’s something that Brad digs into his post, Design Systems, Agile, and Industrialization:

I definitely share Jeremy’s concern, but also think it’s important to stress that this isn’t an intrinsic issue with design systems, but rather the organizational culture that exists or gets built up around the design system. There’s a big difference between having smart, reusable patterns at your disposal and creating a dictatorial culture designed to enforce conformity and swat down anyone coloring outside the lines.

Brad makes a very apt comparison with Agile:

Not Agile the idea, but the actual Agile reality so many have to suffer through.

Agile can be a liberating empowering process, when done well. But all too often it’s a quagmire of requirements, burn rates, and story points. We need to make sure that design systems don’t suffer the same fate.

Jeremy’s thoughts on industrialization definitely struck a nerve. Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.

Matthew Ström weighed in with a beautifully-written piece called Breaking looms. He provides historical context to the question of automation by relaying the story of the Luddite uprising. Automation may indeed be inevitable, according to his post, but he also provides advice on how to approach design systems today:

We can create ethical systems based in detailed user research. We can insist on environmental impact statements, diversity and inclusion initiatives, and human rights reports. We can write design principles, document dark patterns, and educate our colleagues about accessibility.

Finally, the ouroboros was complete when Frank wrote down his thoughts in a post called Who cares?. For him, the issue of maintenance and care is crucial:

Care applies to the built environment, and especially to digital technology, as social media becomes the weather and the tools we create determine the expectations of work to be done and the economic value of the people who use those tools. A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.

Well-trodden territory indeed. Back in 2015, Travis Gertz wrote about Design Machines:

Designing better systems and treating our content with respect are two wonderful ideals to strive for, but they can’t happen without institutional change. If we want to design with more expression and variation, we need to change how we work together, build design teams, and forge our tools.

Also on the topic of automation, in 2018 Cameron wrote about Design systems and technological disruption:

Design systems are certainly a new way of thinking about product development, and introduce a different set of tools to the design process, but design systems are not going to lessen the need for designers. They will instead increase the number of products that can be created, and hence increase the demand for designers.

And in 2019, Kaelig wrote:

In order to be fulfilled at work, Marx wrote that workers need “to see themselves in the objects they have created”.

When “improving productivity”, design systems tooling must be mindful of not turning their users’ craft into commodities, alienating them, like cogs in a machine.

All of this is reminding me of Kranzberg’s first law:

Technology is neither good nor bad; nor is it neutral.

I worry that sometimes the messaging around design systems paints them as an inherently positive thing. But design systems won’t fix your problems:

Just stay away from folks who try to convince you that having a design system alone will solve something.

It won’t.

It’s just the beginning.

At the same time, a design system need not be the gateway drug to some kind of post-singularity future where our jobs have been automated away.

As always, it depends.

Remember what Frank said:

A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement.

The reasons for creating a design system matter. Those reasons will probably reflect the values of the company creating the system. At the level of reasons and values, we’ve gone beyond the bounds of the hyperobject of design systems. We’re dealing in the area of design ops—the whys of systemising design.

This is why I’m so wary of selling the benefits of design systems in terms of consistency and efficiency. Those are obviously tempting money-saving benefits, but followed to their conclusion, they lead down the dark path of enforced compliance and eventually, automation.

But if the reason you create a design system is to empower people to be more creative, then say that loud and proud! I know that creativity, autonomy and empowerment is a tougher package to sell than consistency and efficiency, but I think it’s a battle worth fighting.

Design systems are neither good nor bad (nor are they neutral).

Addendum: I’d just like to say how invigorating it’s been to read the responses from Dave, Ethan, Brad, Matthew, and Frank …all of them writing on their own websites. Rumours of the demise of blogging may have been greatly exaggerated.

Monday, February 3rd, 2020

s08e05: There’s only one rule that I know of, babies - Things That Have Caught My Attention

A global communications network now exists that’s cheap enough or in some cases even free to access, offering a pseudonymous way for people to feel safe enough to share a private experience with complete strangers? I give Facebook and Twitter a bunch of shit for their rhetoric about a global community (no, Facebook’s billions of users are no more a community than the television-watching global community) and creating authentic connection, but I will very happily admit that this, this particular example with people sharing what it is like to be me and learning what is it like to be you is the good.

This is the thing that makes free, open, networked communication brilliant. This is the thing that brings down silos and creates common understanding and humanizes us all, that creates empathy and the first steps towards compassion.

That someone can read about this insight and have a way to react to it and share their perspective and not even know who else might read it, but feel safe in doing so and maybe even with the expectation that this sharing is a net good? That is good. That is what we should strive for.

Wednesday, January 29th, 2020

Thoughts on Writing: What They Say · Matthias Ott – User Experience Designer

We all want to create successful work. We want our voices to be heard. We all want to be recognized or, at least, respected. But instead of trying to please everyone, you should deep down inside of you accept the fact that it is not yours to decide if others like your work. This will give you immense freedom. Suddenly, you can start to just write, without worrying whether your readers like what you’re saying or how you are saying it.

Strong agree.