Rich has posted a sneak peek of one part of his book on Ev’s blog.
Tuesday, February 21st, 2017
Tetris in your browser. Visit it once and it works offline (if your browser supports service workers) so go ahead and add it to your home screen.
Send messages when you’re back online with Service Workers and Background Sync – Twilio Cloud Communications Blog
This example of using background sync looks like it’s specific to Twilio, but the breakdown of steps is broad enough to apply to many situations:
On the page we need to:
- Register a Service Worker
- Intercept the “submit” event for our message form
- Place the message details into IndexedDB, an in browser database
- Register the Service Worker to receive a “sync” event
Then, in the Service Worker we need to:
- Listen for sync events
- When a sync event is received, retrieve the messages from IndexedDB
- For each message, send a request to our server to send the message
- If the message is sent successfully, then remove the message from IndexedDB
And that’s it.
kamranahmedse/design-patterns-for-humans: Design Patterns for Humans™ - An ultra-simplified explanation
I’m crap at object-oriented programming (probably because I don’t get get enough practice), but I’ve had a quick read through this and it looks like a nice clear primer. I shall return and peruse in more depth next time I’m trying to remember how to do all this class-based stuff.
Monday, February 20th, 2017
I really enjoyed teaching in Porto last week. It was like having a week-long series of CodeBar sessions.
Whenever I’m teaching at CodeBar, I like to be paired up with people who are just starting out. There’s something about explaining the web and HTML from first principles that I really like. And people often have lots and lots of questions that I enjoy answering (if I can). At CodeBar—and at The New Digital School—I found myself saying “Great question!” multiple times. The really great questions are the ones that I respond to with “I don’t know …let’s find out!”
CodeBar is always a very rewarding experience for me. It has given me the opportunity to try teaching. And having tried it, I can now safely say that I like it. It’s also a great chance to meet people from all walks of life. It gets me out of my bubble.
I can’t remember when I was first paired up with Amber at CodeBar. It must have been sometime last year. I do remember that she had lots of great questions—at some point I found myself explaining how hexadecimal colours work.
I was impressed with Amber’s eagerness to learn. I also liked that she was making her own website. I told her about Homebrew Website Club and she started coming along to that (along with other CodeBar people like Cassie and Alice).
I’ve mentioned to multiple CodeBar students that there’s pretty much an open-door policy at Clearleft when it comes to shadowing: feel free to come along and sit with a front-end developer while they’re working on client projects. A few people have taken up the offer and enjoyed observing myself or Charlotte at work. Amber was one of those people. Again, I was very impressed with her drive. She’s got a full-time job (with sometimes-crazy hours) but she’s so determined to get into the world of web design and development that she’s willing to spend her free time visiting Clearleft to soak up the atmosphere of a design studio.
We’ve decided to turn this into something more structured. Amber and I will get together for a couple of hours once a week. She’s given me a list of some of the areas she wants to explore, and I think it’s a fine-looking list:
- I want to gather base, structural knowledge about the web and all related aspects. Things seem to float around in a big cloud at the moment.
- I want to adhere to best practices.
- I want to learn more about what direction I want to go in, find a niche.
- I’d love to opportunity to chat with the brilliant people who work at Clearleft and gain a broad range of knowledge from them.
Seeing as we’ll only have a couple of hours every week, this won’t be quite like the masterclass I just finished up in Porto. Instead I imagine I’ll be laying some groundwork and then pointing to topics to research. I guess it’s a kind of homework. For example, after we talked today, I set Amber this little bit of research for the next time we meet: “What is the difference between the internet and the World Wide Web?”
I’m excited to see where this will lead. I find Amber’s drive and enthusiasm very inspiring. I also feel a certain weight of responsibility—I don’t want to enter into this lightly.
I’m not really sure what to call this though. Is it mentorship? Or is it coaching? Or training? All of the above?
Whatever it is, I’m looking forward to documenting the journey. Amber will be writing about it too. She is already demonstrating a way with words.
Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an
h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.
This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.
If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.
Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”
Sunday, February 19th, 2017
A podcast chat in which I ramble on about web stuff.
Saturday, February 18th, 2017
Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.
Friday, February 17th, 2017
A useful tool to help you generate a manifest file, icons, and a service worker for your progressive web
Ever wondered what the most commonly used HTML elements are?
Teaching in Porto, day four
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:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
We did some URL design, figuring out what structures would make sense for straightforward
GET requests, like:
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.
Thursday, February 16th, 2017
Some proposed design principles for web developers:
- Focus on the User
- Focus on Quality
- Keep It Simple
- Think Long-Term (and Beware of Fads)
- Don’t Repeat Yourself (aka One Cannot Not Maintain)
- Code Responsibly
- Know Your Field
Wednesday, February 15th, 2017
A sweet CSS tutorial that Cassie put together for the Valentine’s Day Codebar.
Sunday, February 12th, 2017
A new media query that will help prevent you making your users hurl.
A nice straightforward introduction to web development for anyone starting from scratch.
Thursday, February 9th, 2017
The transcript of a really great—and entertaining—talk on performance by Wilto. I may have laughed out loud at points.
Wednesday, February 8th, 2017
Really good advice for anyone thinking of releasing a polyfill into the world.
Friday, February 3rd, 2017
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
Tuesday, January 31st, 2017
Joschi is documenting his commitment to “contribute at least one meaningful commit a day to a public Open Source project or a similar community effort.” So far it’s a really nice mix of coding and face-to-face activities.