Tags: ews

133

sparkline

Tuesday, January 16th, 2018

How To Make A Drag-and-Drop File Uploader With Vanilla JavaScript — Smashing Magazine

A step-by-step guide to implementing drag’n’drop, and image previews with the Filereader API. No libraries or frameworks were harmed in the making of this article.

Thursday, November 30th, 2017

Jeremy Keith - Building Blocks of the Indie Web - YouTube

Here’s the talk I gave at Mozilla’s View Source event. I really enjoyed talking about the indie web, both from the big-picture view and the nitty gritty.

In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!

Jeremy Keith - Building Blocks of the Indie Web

Sunday, November 19th, 2017

How the BBC News website has changed over the past 20 years - BBC News

Two decades redesigning/realigning the BBC News home page.

Tuesday, October 3rd, 2017

An Epitaph for Newsvine » Mike Industries

Newsvine has closed. Mike reflects on what he built, with a particular eye to the current online news situation.

When we look at how the average person’s news and media diet has changed over the last decade or so, we can trace it directly back to the way these and other modern organizations have begun feeding us our news. Up until 10 or 15 years ago, we essentially drank a protein shake full of news. A good amount of fruits and vegetables, some grains, some dairy, some tofu, and then a little bit of sugar, all blended together. Maybe it wasn’t the tastiest thing in the world but it kept us healthy and reasonably informed. Then, with cable news we created a fruit-only shake for half the population and a vegetable-only shake for the other half. Then with internet news, we deconstructed the shake entirely and let you pick your ingredients, often to your own detriment. And finally, with peer-reinforced, social news networks, we’ve given you the illusion of a balanced diet, but it’s often packed with sugar, carcinogens, and other harmful substances without you ever knowing. And it all tastes great!

There’s also this interesting litmus test for budding entrepreneurs:

We didn’t know for sure if it was going to work, but the day we decided we’d be happy to have tried it even if it failed was the day we ended up quitting our jobs (incidentally, if you are thinking about leaving your job for a new risky thing, this is the acid test I recommend).

Wednesday, September 27th, 2017

Singapore

I was in Singapore last week. It was most relaxing. Sure, it’s Disneyland With The Death Penalty but the food is wonderful.

chicken rice fishball noodles laksa grilled pork

But I wasn’t just there to sample the delights of the hawker centres. I had been invited by Mozilla to join them on the opening leg of their Developer Roadshow. We assembled in the PayPal offices one evening for a rapid-fire round of talks on emerging technologies.

We got an introduction to Quantum, the new rendering engine in Firefox. It’s looking good. And fast. Oh, and we finally get support for input type="date".

But this wasn’t a product pitch. Most of the talks were by non-Mozillians working on the cutting edge of technologies. I kicked things off with a slimmed-down version of my talk on evaluating technology. Then we heard from experts in everything from CSS to VR.

The highlight for me was meeting Hui Jing and watching her presentation on CSS layout. It was fantastic! Entertaining and informative, it was presented with gusto. I think it got everyone in the room very excited about CSS Grid.

The Singapore stop was the only I was able to make, but Hui Jing has been chronicling the whole trip. Sounds like quite a whirlwind tour. I’m so glad I was able to join in even for a portion. Thanks to Sandra and Ali for inviting me along—much appreciated.

I’ll also be speaking at Mozilla’s View Source in London in a few weeks, where I’ll be talking about building blocks of the Indie Web:

In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!

‘Twould be lovely to see you there.

Friday, September 22nd, 2017

Idle Words: Anatomy of a Moral Panic

The real story in this mess is not the threat that algorithms pose to Amazon shoppers, but the threat that algorithms pose to journalism. By forcing reporters to optimize every story for clicks, not giving them time to check or contextualize their reporting, and requiring them to race to publish follow-on articles on every topic, the clickbait economics of online media encourage carelessness and drama.

Tuesday, July 11th, 2017

It’s Time to Make Code More Tinker-Friendly | WIRED

We don’t want the field to de-­democratize and become the province solely of those who can slog through a computer science degree.

So we need new tools that let everyone see, understand, and remix today’s web. We need, in other words, to reboot the culture of View Source.

Wednesday, May 31st, 2017

HN PWA - Hacker News readers as Progressive Web Apps

Of all the sites to pick to demo progressive web apps, we get the cesspit that is Hacker News …I guess it is possible to polish a turd.

Anyway, here are some examples of using frameworks to create alternative Hacker News readers. So the challenge here is to display some text to read..

Four of them render absolutely no content without JavaScript.

In the Hall of Shame we have React, Preact, Angular, and Polymer.

In the Hall of Fame, we have the ones doing it right: React, Vue, and Viper.

That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.

Tuesday, May 16th, 2017

Article Performance Leaderboard

Oh, I like this! A leaderboard of news sites, ranked by performance.

I’d love to see something like this for just about every sector …including agency websites.

Tuesday, April 25th, 2017

The Washington Post cuts off ad tech vendors slowing its site - Digiday

I’d love to see other publishers take a firm stand against the shoddy ad tech from data brokers slowing down their sites.

We go to our partners and say, ‘This is how fast things need to be executed; if you don’t hit this threshold, we can’t put you on the site.’

(I mean, I’d really like to see publishers take a stand against invasive tracking via ads, but taking a stand on speed is a good start.)

Thursday, April 13th, 2017

Digital Assistants, Facebook Quizzes, And Fake News! You Won’t Believe What Happens Next | Laura Kalbag

A great presentation from Laura on how tracking scripts are killing the web. We can point our fingers at advertising companies to blame for this, but it’s still developers like us who put those scripts onto websites.

We need to ask ourselves these questions about what we build. Because we are the gatekeepers of what we create. We don’t have to add tracking to everything, it’s already gotten out of our control.

Saturday, April 1st, 2017

AMP: breaking news | Andrew Betts

A wide-ranging post from Andrew on the downsides of Google’s AMP solution.

I don’t agree with all the issues he has with the format itself (in my opinion, the fact that AMP pages can’t have script elements is a feature, not a bug), but I wholeheartedly concur with his concerns about the AMP cache:

It recklessly devalues the URL

Spot on! And as Andrew points out, in this age of fake news, devaluing the URL is a recipe for disaster.

It’s hard to avoid the idea that the primary objective of AMP is really about hosting publisher content inside the Google ecosystem (as is more obviously the objective of Facebook Instant Articles and Apple News).

Friday, March 24th, 2017

Code (p)reviews

I’m not a big fan of job titles. I’ve always had trouble defining what I do as a noun—I much prefer verbs (“I make websites” sounds fine, but “website maker” sounds kind of weird).

Mind you, the real issue is not finding the right words to describe what I do, but rather figuring out just what the heck it is that I actually do in the first place.

According to the Clearleft website, I’m a technical director. That doesn’t really say anything about what I do. To be honest, I tend to describe my work these days in terms of what I don’t do: I don’t tend to write a lot of HTML, CSS, and JavaScript on client projects (although I keep my hand in with internal projects, and of course, personal projects).

Instead, I try to make sure that the people doing the actual coding—Mark, Graham, and Danielle—are happy and have everything they need to get on with their work. From outside, it might look like my role is managerial, but I see it as the complete opposite. They’re not in service to me; I’m in service to them. If they’re not happy, I’m not doing my job.

There’s another aspect to this role of technical director, and it’s similar to the role of a creative director. Just as a creative director is responsible for the overall direction and quality of designs being produced, I have an oversight over the quality of front-end output. I don’t want to be a bottleneck in the process though, and to be honest, most of the time I don’t do much checking on the details of what’s being produced because I completely trust Mark, Graham, and Danielle to produce top quality code.

But I feel I should be doing more. Again, it’s not that I want to be a bottleneck where everything needs my approval before it gets delivered, but I hope that I could help improve everyone’s output.

Now the obvious way to do this is with code reviews. I do it a bit, but not nearly as much as I should. And even when I do, I always feel it’s a bit late to be spotting any issues. After all, the code has already been written. Also, who am I to try to review the code produced by people who are demonstrably better at coding than I am?

Instead I think it will be more useful for me to stick my oar in before a line of code has been written; to sit down with someone and talk through how they’re going to approach solving a particular problem, creating a particular pattern, or implementing a particular user story.

I suppose it’s really not that different to rubber ducking. Having someone to talk out loud with about potential solutions can be really valuable in my experience.

So I’m going to start doing more code previews. I think it will also incentivise me to do more code reviews—being involved in the initial discussion of a solution means I’m going to want to see the final result.

But I don’t think this should just apply to front-end code. I’d also like to exercise this role as technical director with the designers on a project.

All too often, decisions are made in the design phase that prove problematic in development. It usually works out okay, but it often means revisiting the designs in light of some technical considerations. I’d like to catch those issues sooner. That means sticking my nose in much earlier in the process, talking through what the designers are planning to do, and keeping an eye out for any potential issues.

So, as technical director, I won’t be giving feedback like “the colour’s not working for me” or “not sure about those type choices” (I’ll leave that to the creative director), but instead I can ask questions like “how will this work without hover?” or “what happens when the user does this?” as well as pointing out solutions that might be tricky or time-consuming to implement from a technical perspective.

What I want to avoid is the swoop’n’poop, when someone seagulls in after something has been designed or built and points out all the problems. The earlier in the process any potential issues can be spotted, the better.

And I think that’s my job.

Movies with Mikey

I know it’s just a landing page for YouTube channel of movie reviews but I really like the art direction and responsiveness of this.

Thursday, March 23rd, 2017

Need to Catch Up on the AMP Debate? | CSS-Tricks

Funnily enough, I led a brown bag lunch discussion about AMP at work just the other day. A lot of it mirrored Chris’s thoughts here. It’s a complicated situation that has lots of people worried.

Thursday, February 9th, 2017

The History of the Web - The best stories from the web’s history

What a great project! A newsletter that focuses on stories from the web’s history, each one adding to an ongoing timeline (a bit like John’s hypertext history).

Wednesday, February 1st, 2017

The Loyal Opposition by Adrian Hon & more

A weekly list of short, concrete actions to defend the weak, rebuild civic institutions, and fight right-wing extremism. For UK people.

Subscribed.

Thursday, January 5th, 2017

What AMP (Maybe) Means for News Developers - Features - Source: An OpenNews project

So if AMP is useful it’s because it raises the stakes. If we (news developers) don’t figure out faster ways to load our pages for readers, then we’re going to lose a lot of magic.

A number of developers answered questions on the potential effects of Google’s AMP project. This answer resonates a lot with my own feelings:

AMP is basically web performance best practices dressed up as a file format. That’s a very clever solution to what is, at heart, a cultural problem: when management (in one form or another) comes to the CMS team at a news organization and asks to add more junk to the site, saying “we can’t do that because AMP” is a much more powerful argument than trying to explain why a pop-over “Like us on Facebook!” modal is driving our readers to drink.

But the danger is that AMP turns into a long-term “solution” instead of a stop-gap:

So in a sense, the best possible outcome is that AMP is disruptive enough to shake the boardroom into understanding the importance of performance in platform decisions (and making the hard business decisions this demands), but that developers are allowed to implement those decisions in standard HTML instead of adding yet another delivery format to their export pipeline.

The ideal situation looks a lot more like Tim’s proposal:

I would be much more pleased with AMP if it was a spec for Google’s best-practice recommendations rather than effectively a new non-standard format. By using standard HTML/CSS/JS as the building blocks, they’re starting on the right foot, but the reliance on a Google-decreed AMP JavaScript library, use of separate AMP-specific URLs, and encouragement to use a Google-provided CDN are all worrying aspects.

Tuesday, January 3rd, 2017

What I Read in 2016 - TimKadlec.com

Tim’s book recommendations have always been solid. Here’s his year-end list. I’m honoured that he not only read Resilient Web Design but also gave it all the stars.

Wednesday, December 28th, 2016

SF Mistressworks | women science fiction writers

Reviews of twentieth century science fiction novels and anthologies by women writers.