MZMcBride's email about emails reminded me that every automated email from Wikimedia servers looks like a bunch of programming code.
The first idea was that it would be better to have some better formatted emails with some more information (for example, I would like to see diff inside of my email when I get notification about changing my talk page).
But, then I've realized that we don't have a designer. By "designer" I mean a person who is employed by WMF and who is constantly working on improving MediaWiki look and feel.
While a lot of us may be completely fine with reading Wikipedia articles through links, there are people who care about look and feel.
-------- Original Message -------- Subject: [Foundation-l] Better user experience and retention through e-mail notifications Date: Tue, 19 Apr 2011 01:55:10 -0500 From: MZMcBride z@mzmcbride.com Reply-To: Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org To: Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org
Hi.
I'm not sure about other people, but one of the primary reasons I get on Facebook is that Facebook reminds me to get on. It sends notification e-mails about a Wall post or a comment or whatever. Without these, I wouldn't check it more than once every few days.
There's been a lot of talk about getting new editors and keeping them. I would think something like working e-mail notifications would be a high priority. There are plenty of features and enhancements that could improve the user experience and user retention/return, but this piece of fruit seems particularly low-hanging.
Even on some Wikimedia wikis, it's the e-mail notifications that get me to go back to the site. I only ever visit strategy.wikimedia.org when someone edits my talk page, as it triggers an e-mail notification to me. The smaller sites have had these types of notifications for a long time. The notification system is built in to MediaWiki, it's just not enabled on larger sites such as the English Wikipedia. It's being tracked by bug https://bugzilla.wikimedia.org/show_bug.cgi?id=5220.
MZMcBride
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Tue, Apr 19, 2011 at 10:38 AM, Milos Rancic millosh@gmail.com wrote:
MZMcBride's email about emails reminded me that every automated email from Wikimedia servers looks like a bunch of programming code.
The first idea was that it would be better to have some better formatted emails with some more information (for example, I would like to see diff inside of my email when I get notification about changing my talk page).
But, then I've realized that we don't have a designer. By "designer" I mean a person who is employed by WMF and who is constantly working on improving MediaWiki look and feel.
While a lot of us may be completely fine with reading Wikipedia articles through links, there are people who care about look and feel.
Indeed. As the rest of the web gets prettier and prettier, MediaWiki risks starting to look like an ugly duckling...
On 19 April 2011 11:59, Chris Keating chriskeatingwiki@gmail.com wrote:
On Tue, Apr 19, 2011 at 10:38 AM, Milos Rancic millosh@gmail.com wrote:
MZMcBride's email about emails reminded me that every automated email from Wikimedia servers looks like a bunch of programming code.
The first idea was that it would be better to have some better formatted emails with some more information (for example, I would like to see diff inside of my email when I get notification about changing my talk page).
But, then I've realized that we don't have a designer. By "designer" I mean a person who is employed by WMF and who is constantly working on improving MediaWiki look and feel.
While a lot of us may be completely fine with reading Wikipedia articles through links, there are people who care about look and feel.
Indeed. As the rest of the web gets prettier and prettier, MediaWiki risks starting to look like an ugly duckling...
This, and more general external trends, is what the WMF's "product whitepaper" talks about here: http://strategy.wikimedia.org/wiki/Product_Whitepaper#External_Trends which concludes:
"We can hypothesize that users who started editing Wikipedia during the 2001-2006 time period were accustomed to a very different web environment than users who start to edit Wikipedia today. There simply weren’t easy, yet powerful, WYSIWYG editors to enable the types of publishing that are present today, and in general, web applications were less intuitive, less social, and less responsive.... Today's Internet users have many more ways to contribute and interact on the web than they did 5 and 10 years ago. A deeper understanding of how Wikimedia sits within this "competitive" environment is likely an important step in understanding editor trends."
-Liam
On 19/04/11 19:38, Milos Rancic wrote:
MZMcBride's email about emails reminded me that every automated email from Wikimedia servers looks like a bunch of programming code.
The first idea was that it would be better to have some better formatted emails with some more information (for example, I would like to see diff inside of my email when I get notification about changing my talk page).
The main problem is that they are plain text instead of HTML. You don't really need a designer to make that change, all our developers know how to use HTML.
But, then I've realized that we don't have a designer. By "designer" I mean a person who is employed by WMF and who is constantly working on improving MediaWiki look and feel.
Actually we have two: Brandon Harris and Parul Vora.
-- Tim Starling
Glad you guys brought this question up as I am working on rewriting one of the things right now. See further discussioner here:
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Welcome_...
All suggestions and tweaks are welcome.
Best wishes,
Lennart
On Apr 19, 2011 8:20 AM, "Tim Starling" tstarling@wikimedia.org wrote:
On 19/04/11 19:38, Milos Rancic wrote:
MZMcBride's email about emails reminded me that every automated email from Wikimedia servers looks like a bunch of programming code.
The first idea was that it would be better to have some better formatted emails with some more information (for example, I would like to see diff inside of my email when I get notification about changing my talk page).
The main problem is that they are plain text instead of HTML.
This is most certainly /not/ a problem. What would be a problem would be if MediaWiki chose to jump on the bandwagon of embedding huge external images in emails to users. Bandwidth? Tracking? Smaller screens (mobile)? Text interfaces?
--Dan
On Mon, Apr 25, 2011 at 5:37 PM, Dan Collins en.wp.st47@gmail.com wrote:
On Apr 19, 2011 8:20 AM, "Tim Starling" tstarling@wikimedia.org wrote:
On 19/04/11 19:38, Milos Rancic wrote:
MZMcBride's email about emails reminded me that every automated email from Wikimedia servers looks like a bunch of programming code.
The first idea was that it would be better to have some better
formatted
emails with some more information (for example, I would like to see
diff
inside of my email when I get notification about changing my talk
page).
The main problem is that they are plain text instead of HTML.
This is most certainly /not/ a problem. What would be a problem would be if MediaWiki chose to jump on the bandwagon of embedding huge external images in emails to users. Bandwidth? Tracking? Smaller screens (mobile)? Text interfaces?
Every HTML email should come with an embedded plaintext version which will display in the event the HTML is unrenderable. Explanation here: http://kb.mailchimp.com/article/why-bother-with-plain-text-emails/
Looking at my most recent email from LinkedIn, it provides a list of updates from the people I know, each illustrated with a thumbnail picture of them, along with new connections which have been made in my network and posts people have made. The marketing reason for this is to get people to interact with the site by telling them interesting things that have happened.
That is actually almost identical to a selection of changes to watched pages, new pages, and watched talk pages. We also have quite a powerful reason to remind people to get involved with our projects - we know new editors are unlikely to come back. So should we take a leaf from LinkedIn's book here?
Chris (User:The Land)
On 26/04/11 02:37, Dan Collins wrote: [...]
The main problem is that they are plain text instead of HTML.
This is most certainly /not/ a problem. What would be a problem would be if MediaWiki chose to jump on the bandwagon of embedding huge external images in emails to users. Bandwidth? Tracking? Smaller screens (mobile)? Text interfaces?
It's true that moving to multi-part plain text and HTML will offend that tiny camp who still support exclusive plain text communication. I think that's a fair price to pay.
The problem with plain text email is not just that it's written in plain text. Plain text email has line breaks added by the sender at around 75 columns, meaning that it's difficult to display it on small screens, and it can't take advantage of large screens.
Plain text email is problematic to use with bidirectional languages such as Hebrew, since unlike everything else on the Internet, it uses visual order by default, instead of logical order. MediaWiki does not support visual order.
Plain text email is conventionally displayed in a monospace font. This, and the lack of other useful formatting, makes it difficult to read for dyslexics.
So even when you're just sending plain text, you're better off with HTML. But if we add support for HTML email for MediaWiki's notification emails, we can also add useful features like embedding HTML diff pages in change notification emails.
As for bandwidth: it requires a lot of patience to edit Wikipedia via dialup. The articles are huge and more image-rich than ever, and the discussion pages are huge too. By contrast, our notification emails are currently 2-3 KB each. We could increase them to 50KB each, and they would still be insigificant compared to the other things that editors have to download in the course of their work.
-- Tim Starling
wikimedia-l@lists.wikimedia.org