Tags: apis

75

sparkline

Monday, June 12th, 2017

Design in the Era of the Algorithm | Big Medium

The transcript of Josh’s fantastic talk on machine learning, voice, data, APIs, and all the other tools of algorithmic design:

The design and presentation of data is just as important as the underlying algorithm. Algorithmic interfaces are a huge part of our future, and getting their design right is critical—and very, very hard to do.

Josh put together ten design principles for conceiving, designing, and managing data-driven products. I’ve added them to my collection.

  1. Favor accuracy over speed
  2. Allow for ambiguity
  3. Add human judgment
  4. Advocate sunshine
  5. Embrace multiple systems
  6. Make it easy to contribute (accurate) data
  7. Root out bias and bad assumptions
  8. Give people control over their data
  9. Be loyal to the user
  10. Take responsibility

Tuesday, May 23rd, 2017

Service Worker Security FAQ - The Chromium Projects

Got questions about the security of service workers? This document probably has the answer.

Tuesday, January 3rd, 2017

Exciting times: 2017 and the web - Tales of a Developer Advocate by Paul Kinlan

Paul takes a look at the year ahead on the web and likes what he sees. There’s plenty of new browser features and APIs of course, but more interesting:

The web reaching more people as they come online with Mobile. There is still a huge amount of potential and growth in India, Indonesia, China, Thailand, Vietnam, all of Africa. You name it, mobile is growing massively still and the web is accessible on all of these devices.

Friday, December 30th, 2016

Data on the Web Best Practices

This document provides Best Practices related to the publication and usage of data on the Web designed to help support a self-sustaining ecosystem. Data should be discoverable and understandable by humans and machines.

Monday, December 19th, 2016

The (Not So) Secret Powers Of The Mobile Browser – Smashing Magazine

A run-down of all the functionality that you get in browsers these days. One small quibble with the title: most of the features and APIs described here aren’t limited to mobile browsers. Still, this is a great reminder that you probably don’t need to create a native app to get the most out of a mobile device.

Friday, October 28th, 2016

Working with mobile technology - Digital Service Manual - GOV.UK

Excellent guidelines from GDS on providing services that work well on mobile. The watchwords are:

  • responsive design,
  • progressive enhancement,
  • open data, and
  • emerging technology (service workers, notifications, etc.).

Native and hybrid apps are rarely justified.

Saturday, May 28th, 2016

State of the gap

Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:

The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).

That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:

Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!

Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:

If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.

Friday, April 1st, 2016

simpl.info

This is a very handy resource—a collection of minimum viable implementations of HTML5 features and JavaScript APIs.

Thursday, March 24th, 2016

toddmotto/public-apis: A collective list of public JSON APIs for use in web development.

Remember mashups? Mashups were cool.

If you fancy partying like it’s nineteen ninety web 2.0, here’s a growing list of public APIs that return JSON.

Monday, March 14th, 2016

Web Progressions

This looks a good (free!) event in London all about the latest browser goodies, all wrapped in the “progressive apps” buzzword.

Alas, I’ll be making my way back from Indie Web Camp Düsseldorf the day this is on.

Saturday, December 5th, 2015

Native or Not? The Untapped Power of Web Apps | Viget

Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.

Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.

What Web Can Do Today

Visit this site using different browsers on different devices to get a feel for what you can do with web technologies.

Native will always be ahead, but the feature gap is closing impressively fast.

Monday, November 3rd, 2014

Just what is it that you want to do?

The supersmart Scott Jenson just gave a talk at The Web Is in Cardiff, which was by all accounts, excellent. I wish I could have seen it, but I’m currently chilling out in Florida and I haven’t mastered the art of bilocation.

Last week, Scott wrote a blog post called My Issue with Progressive Enhancement (he wrote it on Google+, which is why you might not have seen it).

In it, he takes to task the idea that—through progressive enhancement—you should be able to offer all functionality to all browsers, thereby foregoing the use of newer technologies that aren’t universally supported.

If that were what progressive enhancement meant, I’d be with him all the way. But progressive enhancement is not about offering all functionality; progressive enhancement is about making sure that your core functionality is available to everyone. Everything after that is, well, an enhancement (the clue is in the name).

The trick to doing this well is figuring out what is core functionality, and what is an enhancement. There are no hard and fast rules.

Sometimes it’s really obvious. Web fonts? They’re an enhancement. Rounded corners? An enhancement. Gradients? An enhancement. Actually, come to think of it, all of your CSS is an enhancement. Your content, on the other hand, is not. That should be available to everyone. And in the case of task-based web thangs, that means the fundamental tasks should be available to everyone …but you can still layer more tasks on top.

If you’re building an e-commerce site, then being able to add items to a shopping cart and being able to check out are your core tasks. Once you’ve got that working with good ol’ HTML form elements, then you can go crazy with your enhancements: animating, transitioning, swiping, dragging, dropping …the sky’s the limit.

This is exactly what Orde Saunders describes:

I’m not suggesting that you try and replicate all your JavaScript functionality when it’s disabled, above all that’s just not practical. What you should be aiming for is being able to complete the basics - for example adding a product to a shopping cart and then checking out. This is necessarily going to be clunky as judged by current standards and I suggest you don’t spend much time on optimising this process.

Scott asked about building a camera app with progressive enhancement:

Here again, the real question to ask is “what is the core functionality?” Building a camera app is a means to an end, not the end itself. You need to ask what the end goal is. Perhaps it’s “enable people to share photos with their friends.” Going back to good ol’ HTML, you can accomplish that task with:

<input type="file" accept="image/*">

Now that you’ve got that out of the way, you can spend the majority of your time making the best damn camera app you can, using all the latest browser technologies. (Perhaps WebRTC? Maybe use a canvas element to display the captured image data and apply CSS filters on top?)

Scott says:

My point is that not everything devolves to content. Sometimes the functionality is the point.

I agree wholeheartedly. In fact, I would say that even in the case of “content” sites, functionality is still the point—the functionality would be reading/hearing/accessing content. But I think that Scott is misunderstanding progressive enhancement if he think it means providing all the functionality that one can possibly provide.

Mat recently pointed out that there are plenty of enhancements on the Boston Globe site that require JavaScript, but the core functionality is available to everyone:

Scott again:

What I’m chaffing at is the belief that when a page is offering specific functionality, Let’s say a camera app or a chat app, what does it mean to progressively enhance it?

Again, a realtime chat app is a means to an end. What is it enabling? The ability for people to talk to each other over the web? Okay, we can do that using good ol’ HTML—text and form elements—with full page refreshes. That won’t be realtime. That’s okay. The realtime part is an enhancement. Use Web Sockets and WebRTC (in the browsers that support them) to provide the realtime experience. But everyone gets the core functionality.

Like I said, the trick is figuring out what’s core functionality and what’s an enhancement.

Ethan provides another example. Let’s say you’re building a browser-based rich text editor, that uses JavaScript to do all sorts of formatting on the fly. The core functionality is not the formatting on the fly; the core functionality is being able to edit text:

If progressive enhancement truly meant making all functionality available to everyone, then it would be unworkable. I think that’s a common misconception around progressive enhancement; there’s this idea that using progressive enhancement means that you’re going to spend all your time making stuff work in older browsers. In fact, it’s the exact opposite. As long as you spend a little bit of time at the start making sure that the core functionality works with good ol’ fashioned HTML, then you can spend most of your time trying out the latest and greatest browser technologies.

As Orde put it:

What you are going to be spending the majority of your time and effort on is the enhanced JavaScript version as that is how the majority of your customers will be experiencing your site.

The other Scott—Scott Jehl—wrote a while back:

For us, building with Progressive Enhancement moves almost all of our development time and costs to newer browsers, not older ones.

Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.

Approaching browser support this way requires a different way of thinking. For everything you’re building, you need to ask “is this core functionality, or is it an enhancment?” and build accordingly. It takes a bit of getting used to, but it gets easier the more you do it (until, after a while, it becomes second nature).

But if you’re thinking about progressive enhancement as “devolving” down—as Scott Jenson describes in his post—then I think you’re on the wrong track. Instead it’s about taking care of the core functionality quickly and then spending your time “enhancing” up.

Scott asks:

Shouldn’t we be allowed to experiment? Isn’t it reasonable to build things that push the envelope?

Absolutely! And the best and safest way to do that is to make sure that you’re providing your core functionality for everyone. Once you do that, you can go nuts with the latest and greatest experimental envelope-pushing technologies, secure in the knowledge that you don’t even need to worry about the fact that they don’t work in older browsers. Geolocation! Offline storage! Device APIs! Anything you can think of, you can use as a powerful enhancement on top of your core tasks.

Once you realise this, it’s immensely liberating to use progressive enhancement. You can have the best of both worlds: universal access to core functionality, combined with all the latest cuting-edge technology too.

Thursday, November 14th, 2013

Laying The Groundwork For Extensibility—Smashing Coding

The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.

There’s a lot to like here, with some practical examples of where we’ve seen a disconnect between JavaScript APIs and declarative HTML (looking at you, Geolocation).

Wednesday, July 3rd, 2013

Lockdown – Marco.org

A superb piece by Marco Arment prompted by the closing of Google Reader. He nails the power of RSS:

RSS represents the antithesis of this new world: it’s completely open, decentralized, and owned by nobody, just like the web itself. It allows anyone, large or small, to build something new and disrupt anyone else they’d like because nobody has to fly six salespeople out first to work out a partnership with anyone else’s salespeople.

And he’s absolutely on the money when he describes what changed:

RSS, semantic markup, microformats, and open APIs all enable interoperability, but the big players don’t want that — they want to lock you in, shut out competitors, and make a service so proprietary that even if you could get your data out, it would be either useless (no alternatives to import into) or cripplingly lonely (empty social networks).

I share his anger.

Well, fuck them, and fuck that.

Monday, June 3rd, 2013

The State Of Responsive Web Design on Smashing Mobile

A comprehensive look at the current state of things in the world of responsive design, with a look to possible future APIs.

Friday, May 31st, 2013

Exquisite Tweets from @genmon, @kellan, @anildash

I need to get Matt to an Indie Web Camp.

Wednesday, March 27th, 2013

Google Keep? It’ll probably be with us until March 2017 - on average

Charles Arthur analyses the data from Google’s woeful history of shutting down its services.

So if you want to know when Google Keep, opened for business on 21 March 2013, will probably shut - again, assuming Google decides it’s just not working - then, the mean suggests the answer is: 18 March 2017. That’s about long enough for you to cram lots of information that you might rely on into it; and also long enough for Google to discover that, well, people aren’t using it to the extent that it hoped.

Thursday, December 13th, 2012

The Web We Lost - Anil Dash

Oh, my! This excellent, excellent post from Anil Dash is a great summation of what has changed on the web, and how many of today’s big-name services are no longer imbued with the spirit of the web.

Either you remember how things used to be and you’ll nod your head vigorously in recognition and agreement …or you’re too young to remember this, and you won’t quite believe that is how things worked.

This isn’t some standard polemic about “those stupid walled-garden networks are bad!” I know that Facebook and Twitter and Pinterest and LinkedIn and the rest are great sites, and they give their users a lot of value. They’re amazing achievements, from a pure software perspective. But they’re based on a few assumptions that aren’t necessarily correct. The primary fallacy that underpins many of their mistakes is that user flexibility and control necessarily lead to a user experience complexity that hurts growth. And the second, more grave fallacy, is the thinking that exerting extreme control over users is the best way to maximize the profitability and sustainability of their networks.

Monday, December 10th, 2012

APIs First « Just Getting Started

The best “Mobile First” strategy is an “API First” strategy:

“Mobile first” companies really are just a front end selection accessing a solid API driven backend infrastructure.

I think Luke would agree. He built a command line interface for Bagcheck, for example, before there was even a UI—mobile or otherwise.