Tuesday, May 22nd, 2018
Thursday, February 16th, 2017
Teaching in Porto, day three
Day two ended with a bit of a cliffhanger as I had the students mark up a document, but not yet style it. In the morning of day three, the styling began.
Rather than just treat “styling” as one big monolithic task, I broke it down into typography, colour, negative space, and so on. We time-boxed each one of those parts of the visual design. So everyone got, say, fifteen minutes to write styles relating to font families and sizes, then another fifteen minutes to write styles for colours and background colours. Bit by bit, the styles were layered on.
When it came to layout, we closed the laptops and returned to paper. Everyone did a quick round of 6-up sketching so that there was plenty of fast iteration on layout ideas. That was followed by some critique and dot-voting of the sketches.
Rather than diving into the CSS for layout—which can get quite complex—I instead walked through the approach for layout; namely putting all your layout styles inside media queries. To explain media queries, I first explained media types and then introduced the query part.
I felt pretty confident that I could skip over the nitty-gritty of media queries and cross-device layout because the next masterclass that will be taught at the New Digital School will be a week of responsive design, taught by Vitaly. I just gave them a taster—Vitaly can dive deeper.
When (some event happens), then (take this action).
I did quick demo as a proof of concept (which, much to my surprise, actually worked first time), but I was at pains to point out that they didn’t need to remember the syntax or vocabulary of the script; it was much more important to have a clear understanding of the thinking behind it.
Friday, November 25th, 2016
It reminds me of the old jQuery philosophy: find something and do stuff to it.
Wednesday, June 29th, 2016
Third-party scripts can provide powerful functionality, but they also bring risks to privacy, security, performance, and page behavior.
Monday, March 7th, 2016
Sunday, November 15th, 2015
A great walkthrough of setting up a Service Worker for a blog. The code is here but more importantly, as Brandon says:
I wouldn’t be able to implement this myself if it wasn’t for some of the awesome people I mentioned earlier sharing their experience. So share, share, share!
Monday, April 13th, 2015
Thursday, March 12th, 2015
Wednesday, February 18th, 2015
Wednesday, December 17th, 2014
You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.
The tone is a bit too heavy-handed for my taste, but the code examples here are very handy if you’re weaning yourself off jQuery.
Wednesday, September 24th, 2014
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
Tuesday, July 1st, 2014
Wednesday, June 11th, 2014
Scott’s trying to find out the best ways to load critical CSS first and non-critical CSS later. Good discussion ensues.
Friday, March 7th, 2014
When I was talking about Async, Ajax, and animation, I mentioned the little trick I’ve used of generating a
progress element to indicate to the user that an Ajax request is underway.
I sometimes use the same technique even if Ajax isn’t involved. When a form is being submitted, I find it’s often good to provide explicit, immediate feedback that the submission is underway. Sure, the browser will do its own thing but a browser doesn’t differentiate between showing that a regular link has been clicked, and showing that all those important details you just entered into a form are on their way.
progress element is inserted at the end of the form …which is usually right by the submit button that the user will have just pressed.
While I’m at it, I also set a variable to indicate that a POST submission is underway. So even if the user clicks on that submit button multiple times, only one request is set.
You’ll notice that I’m attaching an event to each
form element, rather than using event delegation to listen for a
click event on the parent document and then figuring out whether that
click event was triggered by a submit button. Usually I’m a big fan of event delegation but in this case, it’s important that the event I’m listening to is the
submit event. A form won’t fire that event unless the data is truly winging its way to the server. That means you can do all the client-side validation you want—making good use of the
required attribute where appropriate—safe in the knowledge that the
progess element won’t be generated until the form has passed its validation checks.
If you like this particular pattern, feel free to use the code. Better yet, improve upon it.
Sunday, March 2nd, 2014
Async, Ajax, and animation
- First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request.
In fact, the only time you’d really notice a difference is when something goes wrong: in the Hijax model, everything just falls back to full-page requests but keeps on working. That’s the big difference between this approach and the current vogue for “single page apps” that do everything in the browser—when something goes wrong there, the user gets bupkis.
Pjax introduces an extra piece of the puzzle—which didn’t exist when I wrote Bulletproof Ajax—and that’s
pushState, part of HTML5’s History API, to keep the browser’s URL updated. Hence,
pushState + Ajax = Pjax.
What was fascinating though, was hearing why people were choosing to develop using Pjax. It isn’t necessarily that they care about progressive enhancement, robustness, and universal access. Rather, it’s often driven by the desire to stay within the server-side development environment that they’re comfortable with. See, for example, DHH’s explanation of why 37 Signals is using this approach:
So you get all the advantages of speed and snappiness without the degraded development experience of doing everything on the client.
A lot of James’s talk was focused on the user experience of the interfaces built with Hijax/Pjax/whatever. He had some terrific examples of how animation can make an enormous difference. That inspired me to do a little bit of tweaking to the Ajaxified/Hijaxified/Pjaxified portions of The Session.
Whenever you use Hijax to intercept a link, it’s now up to you to provide some sort of immediate feedback to the user that something is happening—normally the browser would take care of this (remember Netscape’s spinning lighthouse?)—but when you hijack that click, you’re basically saying “I’ll take care of this.” So you could, for example, display a spinning icon.
One little trick I’ve used is to insert an empty
progress element takes
value attributes to show how far along something has progressed:
<progress max="100" value="75">75%</progress>
But if you leave those out, then it’s an indeterminate progess bar:
The rendering of the progress bar will vary from browser to browser, and that’s just fine. Older browsers that don’t understand the
progress will display whatever’s between the opening and closing tags.
Voila! You’ve got a nice lightweight animation to show that an Ajax request is underway.
Thursday, January 30th, 2014
Don’t get me wrong: jQuery is great, but for a lot of projects, you might not need 90% of the functionality it provides. So try starting with vanilla JS and only pulling in jQuery if and when you need it.
Thursday, January 16th, 2014
Monday, December 9th, 2013
Another good ol’ rant from Tom. It’s a bit extreme but the underlying lamentation with the abandonment of progressive enhancement is well founded.
Wednesday, September 25th, 2013
The ghost of browsers past
We poked at the markup of the first ever website…
- What’s that
NEXTIDelement? Turns it out it’s something specific to the NeXT operating system.
- Why does the first iteration of HTML already contain
H6? It’s because they were lifted wholesale from a flavour of SGML—Standard Generalized Markup Language—that was already in use at CERN.
Then there was the story of the line-mode browser. It was created by Nicola Pellow, who was a student at CERN in 1990. She later worked on the Mac browser but her involvement with kickstarting the world wide web ended around 1993. She never showed up to any of the reunions.
We poked around in the (surprisingly short) source code of the line-mode browser. We found the lines that described how elements should be styled—the term “style sheet” appeared in a comment!
script tags in the
head of the document—gets rendered to the screen.
<!-- is functionally equivalent to
--> comment with a
I remember doing this when I first started making websites in the 90s. You can see it if you view source on the first version of this website.
Later on, we all switched to XHTML so we updated the syntax to make it valid XML.
type attribute of every
script element to
text/plain, effectively defusing them. Smart!