Tags: urls

97

sparkline

Tuesday, April 10th, 2018

Think like it’s 1995; code like it’s 2035 - Grayscale

This is such a great write-up of the workshop I did in Hong Kong!

Jeremy, it was a pleasure to work with you and you are always welcome here in Hong Kong!

If you fancy having this one-day workshop at your company, get in touch.

Wednesday, April 4th, 2018

Brendan Dawes - I Heart URLs

When I’m asked to give an example of a beautiful piece of design, perfect in form and function, I often respond with “the URL.”

I love every word of this beautifully-written love letter from Brendan.

Monday, February 12th, 2018

Eventually, every app builds for the web. Here’s why.

Sharing an experience without asking you to install software is something only the web can do.

Thursday, December 21st, 2017

Extended Validation is Broken

How a certificate with extended validation makes it easier to phish. But I think the title could be amended—here’s what’s really broken:

On Safari, the URL is completely hidden! This means the attacker does not even need to register a convincing phishing domain. They can register anything, and Safari will happily cover it with a nice green bar.

Monday, October 9th, 2017

FriendChip Beacons - With support of Eddystone and Physical Web

I quite like the idea of broadcasting my URL from a friendchip bracelet.

Thursday, August 24th, 2017

Malte Ubl on Twitter: “🙏🏿 to @sebabenz for testing that this isn’t an AMP special case. Safari now defaults to sharing the canonical URL 👏🏾

If Safari is updating its “share” functionality to look for canonical URLs, then that should work not just for AMP pages, but also Medium posts that include a canonical URL (like the ones created by posting to the Medium API, which is what I’m doing).

Thursday, July 13th, 2017

URLs are UI - Scott Hanselman

So many folks spend time on their CSS and their UX/UI but still come up with URLs that are at best, comically long, and at worst, user hostile.

Sunday, April 16th, 2017

Phishing with Unicode Domains - Xudong Zheng

Domains registered with punycode names (and then given TLS certificates) are worryingly indistinguishable from their ASCII counterparts.

Can you spot the difference between the URLs https://adactio.com and https://аdаctіо.com?

Sunday, April 2nd, 2017

Balance

This year’s Render conference just wrapped up in Oxford. It was a well-run, well-curated event, right up my alley: two days of a single track of design and development talks (see also: An Event Apart and Smashing Conference for other events in this mold that get it right).

One of my favourite talks was from Frances Ng. She gave a thoroughly entertaining account of her journey from aerospace engineer to front-end engineer, filled with ideas about how to get started, and keep from getting overwhelmed in the world of the web.

She recommended taking the time to occasionally dive deep into a foundational topic, pointing to another talk as a perfect example; Ana Balica gave a great presentation all about HTTP. The second half of the talk was about HTTP 2 and was filled with practical advice, but the first part was a thoroughly geeky history of the Hypertext Transfer Protocol, which I really loved.

While I’m mentoring Amber, we’ve been trying to find a good balance between those deep dives into the foundational topics and the hands-on day-to-day skills needed for web development. So far, I think we’ve found a good balance.

When Amber is ‘round at the Clearleft office, we sit down together and work on the practical aspects of HTML, CSS, and (soon) JavaScript. Last week, for example, we had a really great day diving into CSS selectors and specificity—I watched Amber’s knowledge skyrocket over the course of the day.

But between those visits—which happen every one or two weeks—I’ve been giving Amber homework of sorts. That’s where the foundational building blocks come in. Here are the questions I’ve asked so far:

  • What is the difference between the internet and the web?
  • What is the difference between GET and POST?
  • What are cookies?

The first question is a way of understanding the primacy of URLs on the web. Amber wrote about her research. The second question was getting at an understanding of HTTP. Amber wrote about that too. The third and current question is about state on the web. I’m looking forward to reading a write-up of that soon.

We’re still figuring out this whole mentorship thing but I think this balance of research and exercises is working out well.

Wednesday, February 22nd, 2017

Long betting

It has been exactly six years to the day since I instantiated this prediction:

The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.

It is exactly five years to the day until the prediction condition resolves to a Boolean true or false.

If it resolves to true, The Bletchly Park Trust will receive $1000.

If it resolves to false, The Internet Archive will receive $1000.

Much as I would like Bletchley Park to get the cash, I’m hoping to lose this bet. I don’t want my pessimism about URL longevity to be rewarded.

So, to recap, the bet was placed on

02011-02-22

It is currently

02017-02-22

And the bet times out on

02022-02-22.

Friday, February 17th, 2017

Teaching in Porto, day four

Day one covered HTML (amongst other things), day two covered CSS, and day three covered JavaScript. Each one of those days involved a certain amount of hands-on coding, with the students getting their hands dirty with angle brackets, curly braces, and semi-colons.

Day four was a deliberate step away from all that. No more laptops, just paper. Whereas the previous days had focused on collaboratively working on a single document, today I wanted everyone to work on a separate site.

The sites were generated randomly. I made five cards with types of sites on them: news, social network, shopping, travel, and learning. Another five cards had subjects: books, music, food, pets, and cars. And another five cards had audiences: students, parents, the elderly, commuters, and teachers. Everyone was dealt a random card from each deck, resulting in briefs like “a travel site about food for the elderly” or “a social network about music for commuters.”

For a bit of fun, the first brainstorming exercise (run as a 6-up) was to come with potential names for this service—4 minutes for 6 ideas. Then we went around the table, shared the ideas, got feedback, and settled on the names.

Now I asked everyone to come up with a one-sentence mission statement for their newly-named service. This was a good way of teasing out the most important verbs and nouns, which led nicely into the next task: answering the question “what is the core functionality?”

If that sounds familiar, it’s because it’s the first part of the three-step process I outlined in Resilient Web Design:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

We did some URL design, figuring out what structures would make sense for straightforward GET requests, like:

  • /things
  • /things/ID

Then, once it was clear what the primary “thing” was (a car, a book, etc.), I asked them to write down all the pieces that might appear on such a page; one post-it note per item e.g. “title”, “description”, “img”, “rating”, etc.

The next step involved prioritisation. They took those post-it notes and put them on the wall, but they had to put them in a vertical line from top to bottom in decreasing order of importance. This can be a challenge, but it’s better to solve these problems now rather than later.

Okay. I know asked them to “mark up” those vertical lists of post-it notes: writing HTML tag names by each one. By doing this before doing any visual design, it meant they were thinking about the meaning of the content first.

After that, we did a good ol’ fashioned classic 6-up sketching exercise, followed by critique (including a “designated dissenter” for each round). At this point, I was encouraging them to go crazy with ideas—they already had the core functionality figured out (with plain ol’ client/server requests and responses) so they could all the bells and whistles they wanted on top of that.

We finished up with a discussion of some of those bells and whistles, and how they could be used to improve the user experience: Ajax, geolocation, service workers, notifications, background sync …the sky’s the limit.

It was a whirlwind tour for just one day but I think it helped emphasise the importance of thinking about the fundamentals before adding enhancements.

This marked the end of the structured masterclass lessons. Tomorrow I’m around to answer any miscellaneous questions (if I can) and chat to the students individually while they work on their term projects.

Friday, February 3rd, 2017

The Problem With AMP | 80x24

The largest complaint by far is that the URLs for AMP links differ from the canonical URLs for the same content, making sharing difficult. The current URLs are a mess.

This is something that the Google gang are aware of, and they say they’re working on a fix. But this post points out some other misgivings with AMP, like its governance policy:

This keeps the AMP HTML specification squarely in the hands of Google, who will be able to take it in any direction that they see fit without input from the community at large. This guise of openness is perhaps even worse than the Apple News Format, which at the very least does not pretend to be an open standard.

Tuesday, November 8th, 2016

How the internet works?

A really clear introduction to the pieces of a URL by Vera, who is setting out on her career as a front-end developer.

Wednesday, November 2nd, 2016

The Javascript Wars • cssence.com

Some more food for thought, following on from Shaun’s post about HTML as the foundation of web development:

There is another building block for the web, one that is more important than HTML, CSS and JavaScript combined. It all starts with URLs. Those things uniquely identify some piece of information on the web.

Monday, September 19th, 2016

Physical Web Beacons - Snook.ca

Jonathan takes a look at the physical web. Like me, he’s excited by the possibilities. Although he says:

Sadly, my mind quickly devolved into the annoyance of numerous notifications, like popup windows and other distracting adverts, vying for my attention.

This is a common worry with the physical web, but it’s unfounded. All a beacon does is broadcast a URL. You have to actively look for the URLs being broadcast—they can’t send notifications.

It all just feels like QR codes. They’ll be all over the place and most of them won’t be very useful.

I understand this concern, but whereas QR codes are completely opaque to humans, at least URLs can—and should—be human-readable …so, unlike QR codes, a URL can give you some idea of what awaits.

Tuesday, August 9th, 2016

The History of the URL: Path, Fragment, Query, and Auth - Eager Blog

Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the input element, triggered by the old isindex element.

Friday, July 15th, 2016

The History of the URL: Domain, Protocol, and Port - Eager Blog

From the ARPANET to the internet, this is a great history of the Domain Name System:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Wednesday, July 6th, 2016

Building Web Applications that Work Everywhere

The second book in Adam Scott’s series on ethical web development is a nice quick read, covering URL design, Service Workers, and performance.

Persistent Domains by Tim Berners-Lee

This sixteen year old cool URI has not changed. I think this idea of domains entering an archive state is worth pursuing.

Also, I love the science fictional footnote “Note for readers after 2100”.

Wednesday, June 22nd, 2016

Dev.Opera — Making progressive web apps even better: ambient badging and “pop into browser”

Andreas demoed these ideas yesterday. Proper ambient badging and a way of getting at URLs even if a progressive web app is running in fullscreen or standalone mode. Great stuff!