Journal tags: feed

16

The syndicate

Social networks come and social networks go.

Right now, there’s a whole bunch of social networks coming (Blewski, Freds, Mastication) and one big one going, thanks to Elongate.

Me? I watch all of this unfold like Doctor Manhattan on Mars. I have no great connection to any of these places. They’re all just syndication endpoints to me.

I used to have a checkbox in my posting interface that said “Twitter”. If I wanted to add a copy of one of my notes to Twitter, I’d enable that toggle.

I have, of course, now removed that checkbox. Twitter is dead to me (and it should be dead to you too).

I used to have another checkbox next to that one that said “Flickr”. If I was adding a photo to one of my notes, I could toggle that to send a copy to my Flickr account.

Alas, that no longer works. Flickr only allows you to post 1000 photos before requiring a pro account. Fair enough. I’ve actually posted 20 times that amount since 2005, but I let my pro membership lapse a while back.

So now I’ve removed the “Flickr” checkbox too.

Instead I’ve now got a checkbox labelled “Mastodon” that sends a copy of a note to my Mastodon account.

When I publish a blog post like the one you’re reading now here on my journal, there’s yet another checkbox that says “Medium”. Toggling that checkbox sends a copy of my post to my page on Ev’s blog.

At least it used to. At some point that stopped working too. I was going to start debugging my code, but when I went to the documentation for the Medium API, I saw this:

This repository has been archived by the owner on Mar 2, 2023. It is now read-only.

I guessed I missed the memo. I guess Medium also missed the memo, because developers.medium.com is still live. It proudly proclaims:

Medium’s Publishing API makes it easy for you to plug into the Medium network, create your content on Medium from anywhere you write, and expand your audience and your influence.

Not a word of that is accurate.

That page also has a link to the Medium engineering blog. Surely the announcement of the API deprecation would be published there?

Crickets.

Moving on…

I have an account on Bluesky. I don’t know why.

I was idly wondering about sending copies of my notes there when I came across a straightforward solution: micro.blog.

That’s yet another place where I have an account. They make syndication very straightfoward. You can go to your account and point to a feed from your own website.

That’s it. Syndication enabled.

It gets better. Micro.blog can also cross-post to other services. One of those services is Bluesky. I gave permission to micro.blog to syndicate to Bluesky so now my notes show up there too.

It’s like dominoes falling: I post something on my website which updates my RSS feed which gets picked up by micro.blog which passes it on to Bluesky.

I noticed that one of the other services that micro.blog can post to is Medium. Hmmm …would that still work given the abandonment of the API?

I gave permission to micro.blog to cross-post to Medium when my feed of blog posts is updated. It seems to have worked!

We’ll see how long it lasts. We’ll see how long any of them last. Today’s social media darlings are tomorrow’s Friendster and MySpace.

When the current crop of services wither and die, my own website will still remain in full bloom.

Subscribing to newsletters

I like reading RSS feeds. I’ve written before about how my feed reader feels different to my email client:

When I open my RSS reader to catch up on the feeds I’m subscribed to, it doesn’t feel like opening my email client. It feels more like opening a book. And, yes, books are also things to be completed—a bookmark not only marks my current page, it also acts as a progress bar—but books are for pleasure. The pleasure might come from escapism, or stimulation, or the pursuit of knowledge. That’s a very different category to email, calendars, and Slack.

Giles put it far better when described what using RSS feeds feels like :

To me, using RSS feeds to keep track of stuff I’m interested in is a good use of my time. It doesn’t feel like a burden, it doesn’t feel like I’m being tracked or spied on, and it doesn’t feel like I’m just another number in the ads game.

To me, it feels good. It’s a way of reading the web that better respects my time, is more likely to appeal to my interests, and isn’t trying to constantly sell me things.

That’s why I feel somewhat conflicted about email newsletters. On the one hand, people are publishing some really interesting things in newsletters. On the hand, the delivery mechanism is email, which feels burdensome. Add tracking into the mix, and they can feel downright icky.

But never fear! My feed reader came to the rescue. Many newsletter providers also provide RSS feeds. NetNewsWire—my feed reader of choice—will try to find the RSS feed that corresponds to the newsletter. Hurrah!

I get to read newsletters without being tracked, which is nice for me. But I also think it would be nice to let the authors of those newsletters know that I’m reading. So here’s a list of some of the newsletters I’m currently subscribed to in my feed reader:

The Whippet by McKinley Valentine:

A newsletter for the terminally curious.

Sentiers by Patrick Tanguay:

A carefully curated selection of articles with thoughtful commentary on technology, society, culture, and potential futures.

The Fitzwilliam:

Policy, ethics and applied rationality with an Irish slant.

The Science Of Fiction:

How science shapes stories about the future and how stories about the future shape science.

Adjacent Possible by Steven Johnson:

Exploring where good ideas come from—and how to keep them from turning against us.

Faster, Please! by James Pethokoukis:

Discovering, creating, and inventing a better world through technological innovation, economic growth, and pro-progress culture.

undefended / undefeated by Sara Hendren:

Ideas at the heart of material culture—the everyday stuff in all our lives

Today in Tabs by Rusty Foster:

Your favorite newsletter’s favorite newsletter.

Ten episodes of the Web History podcast

For over a year now I’ve been recording the audio versions of Jay Hoffman’s excellent Web History series on CSS Tricks.

We’re up to ten chapters now. The audio version of each chapter is between 30 and 40 minutes long. That’s around 400 minutes of my voice: a good six and a half hours of me narrating the history of the web. That’s like an audio book!

The story so far covers:

  1. Birth
  2. Browsers
  3. The Website
  4. Search
  5. Publishing
  6. Web Design
  7. Standards
  8. CSS
  9. Community
  10. Browser Wars

…with more to come.

The audio is available as a podcast. You can subscribe to the RSS feed. It’s also available from Apple and Spotify.

That’ll give you plenty to listen to while you wait for the next season of the Clearleft podcast.

Reader

I’ve written before about how I don’t have notifications on my phone or computer. But that doesn’t stop computer programmes waving at me, trying to attract my attention.

If I have my email client open on my computer there’s a red circle with a number in it telling me how many unread emails I have. It’s the same with Slack. If Slack is running and somebody writes something to me, or @here, or @everyone, then a red circle blinks into existence.

There’s a category of programmes like this that want my attention—email, Slack, calendars. In each case, emptiness is the desired end goal. Seeing an inbox too full of emails or a calendar too full of appointments makes me feel queasy. In theory these programmes are acting on my behalf, working for me, making my life easier. And in many ways they do. They help me keep things organised. But they also need to me to take steps: read that email, go to that appointment, catch up with that Slack message. Sometimes it can feel like the tail is wagging the dog and I’m the one doing the bidding of these pieces of software.

My RSS reader should, in theory, fall into the same category. It shows me the number of unread items, just like email or Slack. But for some reason, it feels different. When I open my RSS reader to catch up on the feeds I’m subscribed to, it doesn’t feel like opening my email client. It feels more like opening a book. And, yes, books are also things to be completed—a bookmark not only marks my current page, it also acts as a progress bar—but books are for pleasure. The pleasure might come from escapism, or stimulation, or the pursuit of knowledge. That’s a very different category to email, calendars, and Slack.

I’ve managed to wire my neurological pathways to put RSS in the books category instead of the productivity category. I’m very glad about that. I would hate if catching up on RSS feeds felt like catching up on email. Maybe that’s why I’m never entirely comfortable with newsletters—if there’s an option to subscribe by RSS instead of email, I’ll always take it.

I have two folders in my RSS reader: blogs and magazines. Reading blog posts feels like catching up with what my friends are up to (even if I don’t actually know the person). Reading magazine articles feels like spending a lazy Sunday catching up with some long-form journalism.

I should update this list of my subscriptions. It’s a bit out of date.

Matt made a nice website explaining RSS. And Nicky Case recently wrote about reviving RSS.

Oh, and if you want to have my words in your RSS reader, I have plenty of options for you.

The Web History podcast

From day one, I’ve been a fan of Jay Hoffman’s project The History Of The Web—both the newsletter and the evolving timeline.

Recently Jay started publishing essays on web history over on CSS Tricks:

  1. Birth
  2. Browsers
  3. The Website
  4. Search

Round about that time, Chris floated the idea of having people record themselves reading blog posts. I immediately volunteered my services for the web history essays.

So now you can listen to me reading Jay’s words:

  1. Birth
  2. Browsers
  3. The Website
  4. Search

Each chapter is round about half an hour long so that’s a solid two hours or so of me yapping.

Should you wish to take the audio with you wherever you go, I’ve made a podcast feed for you. Pop that in your podcatching software of choice. Here it is on Apple Podcasts. Here it is on Spotify.

And if you just can’t get enough of my voice, there’s always the Clearleft podcast …although that’s mostly other people talking, thank goodness.

Unobtrusive feedback

Ten years ago I gave a talk at An Event Apart all about interaction design. It was called Paranormal Interactivity. You can watch the video, listen to the audio or read the transcript if you like.

I think it holds up pretty well. There’s one interaction pattern in particular that I think has stood the test of time. In the talk, I introduce this pattern as something you can see in action on Huffduffer:

I was thinking about how to tell the user that something’s happened without distracting them from their task, and I thought beyond the web. I thought about places that provide feedback mechanisms on screens, and I thought of video games.

So we all know Super Mario, right? And if you think about when you’re collecting coins in Super Mario, it doesn’t stop the game and pop up an alert dialogue and say, “You have just collected ten points, OK, Cancel”, right? It just does it. It does it in the background, but it does provide you with a feedback mechanism.

The feedback you get in Super Mario is about the number of points you’ve just gained. When you collect an item that gives you more points, the number of points you’ve gained appears where the item was …and then drifts upwards as it disappears. It’s unobtrusive enough that it won’t distract you from the gameplay you’re concentrating on but it gives you the reassurance that, yes, you have just gained points.

I think this a neat little feedback mechanism that we can borrow for subtle Ajax interactions on the web. These are actions that don’t change much of the content. The user needs to be able to potentially do lots of these actions on a single page without waiting for feedback every time.

On Huffduffer, for example, you might be looking at a listing of people that you can choose to follow or unfollow. The mechanism for doing that is a button per person. You might potentially be clicking lots of those buttons in quick succession. You want to know that each action has taken effect but you don���t want to be interrupted from your following/unfollowing spree.

You get some feedback in any case: the button changes. Maybe the text updates from “follow” to “unfollow” accompanied by a change in colour (this is what you’ll see on Twitter). The Super Mario style feedback is in addition to that, rather than instead of.

I’ve made a Codepen so you can see a reduced test case of the Super Mario feedback in action.

See the Pen Unobtrusive feedback by Jeremy Keith (@adactio) on CodePen.

Here’s the code available as a gist.

It’s a function that takes two arguments: the element that the feedback originates from (pass in a DOM node reference for this), and the contents of the feedback (this can be a string of text or it can be HTML …or SVG). When you call the function with those two arguments, this is what happens:

  1. The JavaScript generates a span element and puts the feedback contents inside it.
  2. Then it positions that element right over the element that the feedback originates from.
  3. Then there’s a CSS transform. The feedback gets a translateY applied so it drifts upward. At the same time it gets its opacity reduced from 1 to 0 so it’s fading away.
  4. Finally there’s a transitionend event that fires when the animation is over. Once that event fires, the generated span is destroyed.

When I first used this pattern on Huffduffer, I’m pretty sure I was using jQuery. A few years later I rewrote it in vanilla JavaScript. That was four years ago so I wonder if the code could be improved. Have a go if you fancy it.

Still, even if the code could benefit from an update, I’m pleased that the underlying pattern still holds true. I used it recently on The Session and it’s working a treat for a new Ajax interaction there (bookmarking or unbookbarking an item).

If you end up using this unobtrusive feedback pattern anyway, please let me know—I’d love to see more examples of it in the wild.

Feeds

A little while back, Marcus Herrmann wrote about making RSS more visible again with a /feeds page. Here’s his feeds page. Here’s Remy’s.

Seems like a good idea to me. I’ve made mine:

adactio.com/feeds

As well as linking to the usual RSS feeds (blog posts, links, notes), it’s also got an explanation of how you can subscribe to a customised RSS feed using tags.

Then, earlier today, I was chatting with Matt on Twitter and he asked:

btw do you share your blogroll anywhere?

So now I’ve added another URL:

adactio.com/feeds/subscriptions

That’s got a link to my OPML file, exported from my feed reader, and a list of the (current) RSS feeds that I’m subscribed to.

I like the idea of blogrolls making a comeback. And webrings.

Links, tags, and feeds

A little while back, I switched from using Chrome as my day-to-day browser to using Firefox. I could feel myself getting a bit too comfortable with one particular browser, and that’s not good. I reckon it’s good to shake things up a little every now and then. Besides, there really isn’t that much difference once you’ve transferred over bookmarks and cookies.

Unfortunately I’m being bitten by this little bug in Firefox. It causes some of my bookmarklets to fail on certain sites with strict Content Security Policies (and CSPs shouldn’t affect bookmarklets). I might have to switch back to Chrome because of this.

I use bookmarklets throughout the day. There’s the Huffduffer bookmarklet, of course, for whenever I come across a podcast episode or other piece of audio that I want to listen to later. But there’s also my own home-rolled bookmarklet for posting links to my site. It doesn’t do anything clever—it grabs the title and URL of the currently open page and pre-populates a form in a new window, leaving me to add a short description and some tags.

If you’re reading this, then you’re familiar with the “journal” section of adactio.com, but the “links” section is where I post the most. Here, for example, are all the links I posted yesterday. It varies from day to day, but there’s generally a handful.

Should you wish to keep track of everything I’m linking to, there’s a twitterbot you can follow called @adactioLinks. It uses a simple IFTTT recipe to poll my RSS feed of links and send out a tweet whenever there’s a new entry.

Or you can drink straight from the source and subscribe to the RSS feed itself, if you’re still rocking it old-school. But if RSS is your bag, then you might appreciate a way to filter those links…

All my links are tagged. Heavily. This is because all my links are “notes to future self”, and all my future self has to do is ask “what would past me have tagged that link with?” when I’m trying to find something I previously linked to. I end up using my site’s URLs as an interface:

At the front-end gatherings at Clearleft, I usually wrap up with a quick tour of whatever I’ve added that week to:

Well, each one of those tags also has a corresponding RSS feed:

…and so on.

That means you can subscribe to just the links tagged with something you’re interested in. Here’s the full list of tags if you’re interested in seeing the inside of my head.

This also works for my journal entries. If you’re only interested in my blog posts about frontend development, you might want to subscribe to:

Here are all the tags from my journal.

You can even mix them up. For everything I’ve tagged with “typography”—whether it’s links, journal entries, or articles—the URL is:

The corresponding RSS feed is:

You get the idea. Basically, if something on my site is a list of items, chances are there’s a corresponding RSS feeds. Sometimes there might even be a JSON feed. Hack some URLs to see.

Meanwhile, I’ll be linking, linking, linking…

Navigating Team Friction by Lara Hogan

It’s day two of An Event Apart Seattle (Special Edition). Lara is here to tell us about Navigating Team Friction. These are my notes…

Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.

Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:

  1. Forming. The group is coming together. There is excitement.
  2. Storming. This is when we start to see some friction. This is necessary.
  3. Norming. Things start to iron themselves out.
  4. Performing. Now you’re in the flow state and you’re shipping.

So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.

An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.

Brains

The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.

Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.

We have six core needs that are open to being threatened (leading to an amygdala hijacking):

  1. Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
  2. Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
  3. Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
  4. Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
  5. Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
  6. Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.

Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?

We value those needs differently. Knowing your core needs is valuable.

Desk Moves

Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.

We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:

  1. Doubt. People double-down on the status quo; they question the decision.
  2. Avoidance. Avoiding the problem; too busy to help with the situation.
  3. Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
  4. Bonding. Finding someone else who is also threatened and grouping together.
  5. Escape-route. Avoiding the threat by leaving the company.

All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.

Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:

  • What do you think folks are liking or disliking about this so far?
  • I wanted to get your take on X. What might go wrong? What do you think might be good about it?
  • What feels most upsetting about this?

You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.

This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.

Communication ✨

Listen with compassion, kindness, and awareness.

  • Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
  • Elevate the conversation. Meet transparency with responsibility.
  • Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
  • Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!

This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.

Feedback

Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.

We can get better at giving and receiving feedback.

Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.

GeneralSpecific and Actionable
Positive Feedback
Negative Feedback

The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).

observation + impact + question/request

Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.

Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.

Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.

You’ll start to notice when your amygdala or pre-frontal cortex is taking over.

Prevention

Talking one-on-one is the best way to avoid team friction.

Retrospectives are a great way of normalising of talking about Hard Things and team friction.

It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.

Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.

What if you disagree with what management says? The absence of trust is at the centre of most friction.

DisgreeAgree
CommitMature and TransparentEasiest
Don’t CommitAcceptable but ToughBad Things

Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.

But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.

Remember, storming is natural. You are now well-equipped to weather that storm.

See also:

Posting to my site

I was idly thinking about the different ways I can post to adactio.com. I decided to count the ways.

Admin interface

This is the classic CMS approach. In my case the CMS is a crufty hand-rolled affair using PHP and MySQL that I wrote years ago. I log in to an admin interface and fill in a form, putting the text of my posts into a textarea. In truth, I usually write in a desktop text editor first, and then paste that into the textarea. That’s what I’m doing now—copying and pasting Markdown from the Typed app.

Directly from my site

If I’m logged in, I get a stripped down posting interface in the notes section of my site.

Notes posting interface

Bookmarklet

This is how I post links. When I’m at a URL I want to bookmark, I hit the “Bookmark it” bookmarklet in my browser’s bookmarks bar. That pops open a version of the admin interface tailored specifically for links. I really, really like bookmarklets. The one big downside is that they don’t work on mobile.

Text message

This is something I knocked together at Indie Web Camp Brighton 2015 using the Twilio API. It’s handy for posting notes if I’m travelling somewhere and data is at a premium. But I don’t use it that often.

Instagram

Thanks to Aaron’s OwnYourGram service—and the fact that my site has a micropub endpoint—I can post images from Instagram to my site. This used to happen instantaneously but Instagram changed their API rules for the worse. Between that and their shitty “algorithmic” timeline, I find myself using the service less and less. At this point I’m only on their for the doggos.

Swarm

Like OwnYourGram, Aaron’s OwnYourSwarm allows me to post check-ins and photos from the Swarm app to my site. Again, micropub makes it all possible.

OwnYourGram and OwnYourSwarm are very similar and could probably be abstracted into a generic service for posting from third-party apps to micropub endpoints. I’d quite like to post my check-ins on Untappd to my site.

Other people’s admin interfaces

Thanks to rel="me" and IndieAuth, I can log into other people’s posting interfaces using my own website as the log-in, and post to my micropub endpoint, like this. Quill is a good example of this. I don’t use it that much, but I really should—the editor interface is quite Medium-like in its design.

Anyway, those are the different ways I can update my website that I can think of right now.

Syndication

In terms of output, I’ve got a few different ways of syndicating what I post here:

Just so you know, if you comment on one of my posts on Facebook, I probably won’t see it. But if you reply to a copy of one of posts on Twitter or Instagram, it will show up over here on adactio.com thanks to the magic of Brid.gy and webmention.

Making progress

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.

Here’s the JavaScript I use. It’s fairly simplistic, and I’m limiting it to POST requests only. At the moment that a form begins to submit, a 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.

Feed reading

There are some great pieces of software out there dedicated to reading RSS, each with their own take on the task. As a Mac user, I’m spoiled for choice with NetNewsWire, NewsFire and Shrook to choose from.

Then there are the myriad online feed readers like Bloglines, Newshutch and Google Reader. They’re all pretty slick as long as you’ve got a relatively well-specced machine with a JavaScript-capable browser.

But I’ve never found an RSS reader that I’ve been completely satisfied with. I find all too often that the experience reminds of using an email client. Reading email can be an enjoyable activity but more often than not, it’s all about getting the unread count in your inbox down to zero, right?

I gave up on feed readers for quite a while and just started reading the few feeds I’ve gathered together at Adactio Elsewhere. But this doesn’t keep track of what I’ve already read.

I quite like the way the “favorites”(sic) feature on Technorati works. Here, the freshness of the post takes precedent over the author. Everyone’s posts are mixed up into one river of news. It feels more like reading through a single blog.

I didn’t think there was any new way to catch up on RSS feeds until James set me straight.

We have weekly Monday morning meetings at Clearleft at which everyone is encouraged to offer up a “lightbulb moment”—an insight or revelation that’s useful or just cool. This week’s meeting didn’t happen until Wednesday (we’re not the best clockwatchers). For his lightbulb moment, James pointed out a nice little feature now offered by Google Reader.

If you go to Settings and then look under the Goodies tab, you’ll see a bookmarklet marked “Next” that you can drag to your bookmarks bar. Clicking on this bookmarklet (or favelet, if you will) takes you to the next unread post in your river of news.

I really like this way of reading. Like the Technorati solution, the order is determined by date rather than author. But the authorship is very relevant in that you view the entry in its original context; on that person’s website rather than in a feed reader (something that I know a lot of my designer friends have strong feelings about).

This little bookmarklet manages to bring RSS reading back into the browser in a completely different way than simply emulating a desktop feed reader. Whenever I want to read something new, I click the “Next” link in my bookmarks bar. I don’t know exactly what I’m going to get but I know that it will something that I haven’t read before, it will be written by someone I enjoy reading and it will be fresh.

This solution manages to straddle the fine line between the convenience of RSS (pull rather than push notification) with the tyranny of RSS (a daunting list of feeds to read through). And I don’t need to keep opening new tabs or windows—something that’s hard to avoid with regular feed readers be they on the desktop or in the browser.

I’m thinking of creating an OPML file that consists of nothing but del.icio.us links (or quicklinks or blogmarks or whatever) from people whose taste I trust. Then clicking on that “Next” button would have a lovely touch of serendipity, constantly finding something new and fresh, landing me on a web page for no other reason than someone I know thought it was worth bookmarking.

It kind of reminds me of what it was like to surf the Web back in the old pre-RSS days before information overload overwhelmed us all. If you’ve got a Google Reader account, give the bookmarklet a whirl and see what you think. It might change the way you think about reading RSS.

Comments on comments

Right before I set off on my antipodean adventure, hell froze over and I opened up comments. There was a twist, of course. I wanted to solicit feedback but discourage conversation so, to foster independence of opinion, comments were not immediately published. Instead, all the comments were published together once the ability to add comments had been switched off. In this case, that was a period of one week.

The post received quite a few comments, some more interesting than others.

Quite a few people were sidetracked by the issue of spam and assumed that I would simply be inundated with comment spam. Spam was something I deliberately didn’t mention in the original post as it is tangential to the matter at hand. As it happens, the Akismet API — which I’m using to filter comments — does a great job of keeping comment spam out.

The original post was prompted by Mike mentioning the lack of comments on my site at the Future of Web Apps summit. The audio of Mike’s talk is now available and I highly recommend you listen to it. It’s an excellent presentation chock full of ideas about community, participation and social interaction. Mike also weighed in on my post, saying:

In my view, comments can significantly raise the quality of experience on most sites but cannot significantly lower it.

Now, this is interesting because I disagree almost 100%. In my experience, coming across pointless, lame, nasty or redundant comments attached to a blog post can lower the quality of the document as a whole. I think Mike has managed to crystalise why others are willing to put up with the downsides of comments, while I find the trade-off unacceptable.

Bradley Wright says:

I’m curious as to how comments that no one else can see will foster good feedback.

Well, that goes back to the whole wisdom of crowds thing I was talking about: independence is one of the defining factors.

He continues:

Sometimes the best leaps I’ve seen in online “conversations” come from the back and forth, which is helpful for some people to help crystallise their thoughts.

I agree. But I haven’t found those conversations happening very often in comments. Instead, I find them happening blog to blog. People tend to post more well-thought responses on their own blogs than they do in the comments to someone else’s blog post.

Guy Carberry brings up an important issue:

I have got some very useful information from the comments of a post.

This is true. This is also something that Andy said to me when we were discussing blogs and comments. Well, with my system of comments, this will still be true. Once comments are displayed, there is a greater chance that they will contain only useful information rather than a mixture of information and conversation. The google dance usually takes a while anyway, so if someone is looking for information on a topic and they end up at one of my blog posts, the ability to add comments will probably be disabled and all comments will be displayed. That person gets the information in the original post along with any feedback sent in via a comment. In fact, I would argue that my comment system will prove more valuable for long-term information search.

But how long is long? For how long should the ability to add a comment be available? For the inaugural post, I chose one week. I figured that would be a nice length of time to allow everyone to have their say. As it turned out, the vast majority of comments were submitted in the first few days. Clearly, a week is a long time on the web. I think two to four days might be a better length of time to keep the comment form available.

Pete Lambert commented on the need for some way of tracking when comments get published:

My only issue with it is that I would have to remember to come back and check the comments after whatever arbitrary quarantine period you define.

This is clearly something I need to work on. I still think some form of email notification would work best. Another option would be to actually publish the comments in my RSS feed as well as on the site. With a little jiggery-pokery, this could be flagged up as unread in most RSS readers. But this could just end up pissing off the people who don’t care when comments are published.

Here’s another point:

I suspect what you are going to wind up with is a long list of the same comment over and over again.

Surprisingly, this didn’t turn out to be the case. I actually received a fairly wide range of ideas from people.

That’s not crowd wisdom at all. If your blog was a multiple choice quiz, then fine, but it’s not.

That’s a good point: the wisdom of crowds does seem to work best with multiple choice questions (or “guess how much this weighs” questions). I opened up comments on another entry, where I was soliciting opinions on things to do in Melbourne. I personally thought that this would be a better test of my commenting system. The aggregate results should have given me a good independent overview of recommendations.

As is turned out, I shot myself in the foot by

  1. restricting the crowd to people who know anything about Melbourne and
  2. also encouraging feedback via my contact form.

Still, my point above about the added value of comments via findability still stands: somebody googling for restaurants in Melbourne will not just find my original post, but also the (one) useful comment about places to eat. The fact that the comments was originally hidden during the submission process doesn’t affect the long-term usefulness. I can see the commenting system working well for less tightly focused questions.

Based on the inaugural post with comments, I’m pretty pleased with the results. Clearly I need to work on a better notification system and I also need to figure out the sweet spot of how long to allow comments to be submitted but overall, this little experiment has yielded some pretty tasty fruit.

I was all set to start allowing more comments when I came across a post by Robert Nyman entitled A blog without comments isn’t really a blog.

Oh, brother! Here we go again.

After all these years of trying to define what a blog is, who knew that someone blogging for a year and a half would stumble upon the answer?

Forgive my sarcasm, but I get pretty fed up of being judged based on how I set up my personal site. I said as much in a comment on Robert’s post.

In his post, Robert has this advice for people who don’t have comments enabled:

Then you shouldn’t blog.

At the same time, he claims to love the openness of the web. I’m seeing a disconnect here. In his reply to my comment, Robert says:

I’m glad that I have comments here so everyone can read your and my opinions on this, and also have the possibility to contribute with what they think. That’s what I like about the web: the openness.

That’s a pretty narrow view of openness. I don’t think it’s very open to have all responses in a single document.

Here’s what I like about the web: openness through hypertext. I can link to any resource on the Web and comment on it here on my own website. Conversely, anyone is free to link to this document and comment on it on their own site (or a third-party site like Newsvine). That’s openness. Demanding that everyone post their thoughts together on the originating document is a closed system.

So, just as I was ready to start experimenting more with feedback mechanisms, I’m confronted with a “my way or the highway” ultimatum about what I’m allowed do on my own site. It’s enough to make me give up on the whole idea.

But I won’t. I’ll keep opening up the occasional post for comments, although I’m also really interest in using tags and pings for tracking responses, hence the Del.icio.us, Technorati, and Flickr links at the end of each post.

I was thinking of opening comments on this very post, but I think most of the salient points have been gathered from the initial post. If you would like to respond to this, you can write a blog post of your own and it will appear through the Technorati link (I really wish Trackback worked better but spam has effectively killed that off). If you have any feedback, there’s always email and IM.

Webstock podcast

Over an after-work beer with Andy yesterday evening, he told me about some of the great presentations he had been listening to from the Webstock conference held in New Zealand earlier this year.

I didn’t even realise there was audio (and video!) available, but there is. Strangely though, there are no RSS feeds. That means you have to go in and manually download each presentation you want to listen to. How quaint.

It doesn’t make it very easy to get the audio from the website to your computer to your iPod. This sounds like a job for a podcast.

I’ve put together a feed of the presentations from Webstock. You can subscribe to the feed in iTunes and listen to the presentations at your leisure.

The weird thing is that podcasts were promised but never delivered. I wonder if perhaps there was some confusion between the terms “podcast” and “audio file”.

Anyway, grab the feed here and get an earful of the great speakers:

Webstock 2006 Podcast

Fixtorati

Technorati has been redesigned, or realigned if you prefer. It’s gone a bit gradient happy but overall, it’s quite a pleasing visual aesthetic.

For some reason though, they’ve chosen to lock the pages into a fixed width of 1024 pixels.

Now, I understand the reasoning behind fixed-width layouts. I can see the justification for wide fixed-width layouts on content-heavy sites like A List Apart (even if I disagree with it). But forcing users of what is fundamentally a web app to set their browser to a certain width seems counterproductive to me.

The content on Technorati is user-generated. Usually, that user is me. It has my favourites, my watchlist, and my search terms. I should be able to interact with that content in my way.

This is something that, as with so many things, del.icio.us gets just right. Upcoming is on the right track too. These sites allow me to interact with my data without putting me in a straitjacket.

Flickr is still avowedly fixed but the image-based, rather than text-based, nature of the data I store there makes this somewhat understandable.

Now, don’t misconstrue this as a tirade against 1024 pixel wide layouts. The problem would still exist in an 800 pixel wide design. Choosing an arbitrary number of pixels in which to serve up user-generated content is the issue here. On the one hand, Technorati is a very Web 2.0 sort of site, based on user-generated distributed content and collective wisdom. On the other hand, its visual design is grounded in a very Web 1.0 idea of top-down control and inflexibility.

I like Technorati a lot. It’s come on in leaps and bounds in the past couple of years. I’d like to use it every day. I’m even willing to put up with the oversize ads. But I resent the feeling that I should adjust my browsing environment to the needs of the site, rather than the other way around.

Further comment

My thoughts on comments were cause for some debate in certain circles. I’m not the only one grappling with this issue.

I managed to lure Dunstan out of his self-imposed exile long enough for him to point to some ideas he had for a more heavily moderated commenting system where only useful additions appear with a post. This is somewhat along the lines of the BBC’s website where occasionally feedback is solicited but it’s more along the lines of letters to the editor: comments enter a queue and only representative selections are published.

For a very interesting take on the comments question, I highly recommend listening to this interview with David Sifry posted on the Podleaders podcast. Responding to the question of whether Technorati has any plans to begin indexing comments, he points out that whereas blog posts have a certain level of accountability, comments are more like the (often anonymous) throwaway remarks that polluted Usenet and chat rooms, preventing those technologies from scaling past a certain point:

One of the reasons I think blogging is very different from bulletin boards or chat rooms is that it fundamentally enforces a level of accountability.

I find that that level accountability tends to create, or enforce, a certain amount of thoughtfulness… a willingness to think twice before someone says nasty things.

The problem I have with many commenting systems on blogs [is that they] do not enforce any level of accountability.

That’s exactly what I was getting at in my original post when I said:

The best online conversations I’ve seen have been blog to blog: somebody posts something on their blog; somebody else feels compelled to respond on their own blog. The quality of such a response is nearly always better than a comment on the originating blog for the simple reason that people care more about what appears on their own site than on someone else’s.

Then the tricky bit is tracking those conversations. And that’s where services like Technorati come in.