This morning I was thinking about the fact that these emails often makes changes look more extensive than they actually. I got one this morning for example that provided 11 lines of context for the addition of one space. I didn’t know it was so minor until I followed the link. I’m wondering how much this is discouraging page subscribers from actually reviewing pages.
Have you guys considered other ways of presenting changes in notification emails?
This is a really interesting point. I don’t know what if any other options we’ve considered for presenting changes, in email in particular. I do suspect we could be smarter about how we present cases like this one specifically, where the changes are simply a matter of whitespace, although there are ways whitespace can be abused too. Hm. This is definitely worth thinking about.
Sheppy
I hesitated to suggest answers since your framework for sending these emails (kuma?) may be limited in ways I know nothing about.
It’s really just a matter of what we decide to do. It’s not enormously complicated code that builds the emails, IIRC.
The here are a few suggestions:
jmedley, can you share some more information? What page changed, and what revision was it that caused the change? A screenshot of the email would work, or there may be a link to view the revision in the email.
As much as historically I despite HTML in email, I think page changed messages may be a solid candidate for an exception. Being able to use a little color and possibly even some boxes of various types could really help to clarify these things.
Might be a good idea to mock up some ideas for what it could look like to make it better, @jmedley.
Sheppy
This is not about a specific email. This is a general discussion.
I’ll put it on my list.
If I might add my 2 cents to this: having a word-wise diff view might be very useful to distinguish between copy edits (e.g. fixing 2 typos) and deeper edits
(in regards to this discussion, this applies to emails but this might as well benefit the diffing view on the editor)