Tags:
archive_me1Add my vote for this tag email1Add my vote for this tag publish1Add my vote for this tag create new tag
, view all tags
This capability is provided by MailPageAddOn.

It's tough to wean people off using email and onto TWiki - so what I'd like is a feature that lets me create or update a TWiki page, and include an email subject line and a 'CC list' of people who should be emailed the contents of this page (or maybe just a link). The idea is that you would write TWiki pages in response to emails (typically sent to a group of people), so it's important to be able to make the TWiki-generated email look somewhat like an email you'd normally send.

This is something of an alternative to InstantNotification through techniques such as TWikiSyndication - email is already heavily used, so why not fit in with this?

Here's a possible syntax - embed the following at the top of a page:

MailSubject: Re: Getting Foobar 2.1 to install on Windows 2000
MailCC: fred@example.com, techpeople@example.com

The rest of the page would be the message body. The headers are chosen not to be identical to email headers, to avoid generating emails by mistake after pasting the headers + body of an existing email.

TWiki would generate an email on saving, probably with full text HTML of the body (which would allow full use of TWiki formatting and linking features). Some environments might prefer to generate plain text, or just a short intro paragraph with a URL to the TWiki page - the latter would encourage people to reply on the TWiki page, or at least to summarise the consensus there.

Ideally, email replies would auto-update the TWiki page, which has been discussed elsewhere - see EmailNotificationEnhancements and MailInAddOn.

This is obviously most suitable for intranets (on the Internet it could give rise to too much spam), but given authenticated users I can't see a big security problem.

Some areas to think about include friendlier addressing (e.g. could use Net::LDAP, which works well against Exchange 5.x, and runs fine on Unix/Linux as well as Windows) - not all recipients will necessarily be registered on TWiki.

There is some overlap with existing email notification ideas, but this is intended more as a 'do group-wide email through TWiki' rather than as a notification technique.

What do people think? Would this be a license to spam? Should updates to the page generate new emails?

-- RichardDonkin - 13 Apr 2002

I think it is key that we should not be "trying to wean people off email and onto wiki". Wiki has its own problems. Wiki/Email/Newsgroups/RSS reader all fade into each other.

There apppears to be a cross-product of notification techniques that applies to email, RSS, etc. - I attempt to taxonomize them on the linked to page.

-- AndyGlew - 24 Jun 2003

I'm working this issue with my users.

Consensus so far: mailnotify sucks - produces too much useless email. Overall doubt that any periodic polling strategy is worth pursuing.

The hypothesis in my small user community is that it is sufficient to have the editor, the person creating or modifying a page, decide when it is worthwhile emailing the page out.

If they forget to, then (1) you chastize them, and (2) mailnotify running at a really low frequency (like, once a week) may catch such new but unnotified pages.

To this end, I am just putting email related links in my templates/skins:

  • Email a link of this page
    • to addresses the user will specify)
    • to standard addresses, such as a mailing list corresponding to the web
    • eventually to a WebNotify list
      • actually, I am not so sure about WebNotify - we already have plenty of tools mapping and managing mailing lists, such as UNIX groups and mailman - adding TWiki's own just adds yet another layer of complexity.

Now, I would like to email the actual text of the page, not just the link.

  • Reason:
    • Many of my users read email on airplanes, when not connected to the web. If they can't see the message, they will just ignore it.
      • These happen to be the users most likely to want to use email than wiki
      • They also happen to be more important in the company - VPs, Felllows, etc.
    • I have the same problem in a minor way: I read email on my bus commute.

Unfortunately, I cannot see a good way to get a copy sent to email.

  • mailto Body arguments need to be short
  • client side: I'd prefer the user to be able to edit the email in his or her prefered mailer.
  • I can send the email from the wiki server, but
    • this doesn't give the user the chance to edit it, change To list, etc.
    • the email comes from the wiki server user (apache webserver httpd user, e.g. www) not the user who initiated it.

I'd appreciate any hints as to how to do this. An insecure JavaScript?

-- AndyGlew - 25 Jun 2003

As you know, Andy, there is a posting by me in EmailThisPageLink that said we should allow a user to specify email addresses to forward a page to.

I now think the simplest way to fulfil both your requirement to allow a user to edit in their own email program and for EmailThisPageLink to mail a general list of users (via WikiName, WikiGroupName or list of email addresses) is to provide a web-based 'forward this page' facility (containing optionally the changes, the text or just a link to either) and remind the user that they can send the updated page to themselves and then forward it on to others. This would solve both of your last two issues.

There is a more generic problem of allowing users to subscribe to a page. Colas and WalterMundt have both been looking at this.

I don't know of a javascript solution but note that that would not work for webmail users.

-- MartinCleaver - 25 Jun 2003

A server-based email CGI program is what's needed - a bit like mailnotify but more controllable, e.g. using a form or the embedded headers listed above. This would allow the email addresses to be edited before the page is sent.

Getting the email to appear as if it is from the sending user not Apache/TWiki is easy - SMTP is not authenticated (typically) on intranets, so you just fake the From header as needed.

A form would also simplify providing more flexible addressing in future, e.g. so you can put in 'Fred Smith' and look up his address in Exchange's LDAP directory. This is quite important as an add-on, particularly where the sending user doesn't frequently email some of the recipients - if the user has to go into Outlook to check the addresses they may not bother.

About the 'weaning off' comment - I don't think anyone will stop using email, but the idea of this feature was to encourage people who currently only use email to get some interesting TWiki pages as email (which could also be thought of as emails which are also logged on TWiki), and then start participating on the TWiki site.

There are many uses of email for which TWiki is more appropriate, particularly technical discussions that are never summarised into a consensus and are left lurking in email inboxes - this sort of email is the dark matter of intranets, containing a great deal of valuable information that is invisible to most people. TWiki makes this 'dark matter' information visible and updatable, but a strategy to get email users involved is very important.

-- RichardDonkin - 25 Jun 2003

We've written such a server side email cgi script. I'm not posting it yet, because

  • I didn't write it - I want the author to post it
  • it needs to be cleaned up.
but you can contact me if you want it before we have gotten around to posting it.

However, a usage model note: it is infinitely more pleasant for the sender to use the client side "Email a link to this page" than it is to use the server side "Email the contents of this page". The only reason the latter exists is that "here documents" are much easier for the reader than links.

Having formed this opinion, based on a month or so of use, I want to go back and figure out if there is a better way to do client side email, even if less portable.

-- AndyGlew - 11 Aug 2003

The implementation does not look too difficult, but there are some social impalications; the "stickiness" of the web site decreases if you deliver content to the mail inbox. See JoelOnSoftware's article Building Communities with Software for an interesting reading.

-- PeterThoeny - 12 Aug 2003

I'm dubious about Joel's arguments here - he seems to make a lot of statements based on how he thinks people will react. I am virtually sure that increasing use of highly targetted email from TWiki sites (particularly on pages that people have been involved in) would increase the stickiness of the site. Amazon.com and many other successful sites use email updates (e.g. any books with Wiki in title) to bring in traffic, so I would like to see some real evidence that stickiness is reduced. Bugzilla does something very similar for different reasons.

If people remember to check a site frequently for comments they will participate more, but lots of people probably check a few times, don't see any updates, and then never check again, leading to TopicsThatDie.

-- RichardDonkin - 12 Aug 2003

This is a good point - combined with your Amazon comments. Email notification I've found rapidly becomes "filed" automatically by lots of people resulting in less feedback in later days than in the beginning when everything was new and fun.

In many respects the key problem collaboration on a Wiki has as opposed to an email is that the people who respond to comments on a page are rarely the original author - it will normally be these "frequent checkers". If you take TWiki.org as an example - how many bug reporters follow up when asked questions by either a core team member or another member of the community?

The idea of pages (or better context diffs - they're essentially good mail netiquette) being emailed out to the participants in the page (easy enough to do after all) and any other interested parties is a good thing IMO (essentially making dynamic threadmode based mini-mailing lists).

To ensure that people come back and refactor stuff rather than just do threadmode however is to have the only "reply" mechanism being an edit button in the HTML means that the website is updated and treated like a wiki page (hopefully rather than threadmode), and that it terms of immediacy it's more like email - increasing usage. (This could actually be quite an app thinking about it...)

This approach gives you the convenience and effectiveness of an Amazon spam, but the flexibility of a wiki. (hopefully of both email & wiki).

-- MichaelSparks - 13 Aug 2003

What about an idea of requiring people to renew thir email subscriptions every 30 days or so by going to the TWiki? Users get an automated email notification that their subscription is about to expire and provides a link to renew. This should not require rescribing to every detail if there is a provision for subscribing by topic/web/site.

-- DavidLeBlanc - 13 Aug 2003

  • What about an idea of requiring people to renew thir email subscriptions every 30 days or so by going to the TWiki? DavidLeBlanc
    • Please, no! TWiki already requires far too much clicking around. I often find that I am inactive on a wiki for months, and then see a topic fly by that interests me, at a time that I have the freedom and net.connectivity to reply.

  • MichaelSparks
    • Email notification ... rapidly becomes "filed" automatically
    • how many bug reporters follow up when asked questions?
      • I've fallen short here... mainly because it's a hassle, a pull, to go and read your old bug reports
      • mailnotify is much too noisy. To promote conversations, it must be too frequent.
      • Placing "emal a link to this page" on the templates has helped my group a lot. "Emal a copy of this page" would also help... actually, it does help... but "email a copy of this page" on server side is too much hassle for pointers.
      • the search script for "interesting pages" has helped a lot. I'm going to start trying to use that, via a cron job and wget, to poll twiki.org
      • twiki.org seems to fall into thread mode much more often than Ward's wiki. Dunno why.
        • I've thought about this a lot. I think it's because signatures direct thoughts towards pronouns (me, I) which in turn pretty much requires thread mode -- MattWilkie 14 Aug 2003

-- AndyGlew - 14 Aug 2003

Here is one approach that I would like to document for general benefit:

Key idea: Model the store as IMAP folder. i.e. RCS should use IMAP calls to access the topics.

Advantages:

  • Laptop users will have information available offline, accessible via familiar email.
  • Various connectors can independently manipulate information and do value add. For e.g. database plugin may refresh a table populated from database completely independent of twiki. (Browser users will do a simple 'refresh'.)

How will each mail look like?

  • From: Whoever edited.
  • To: Whoever should be the recipients through topic notification. Can be a list of users, group in twiki, or none.
  • Subject: [Companywiki.CodingGuidelines/1.0] New coding guidelines uploaded ...
  • Body: text/plain, or MIME formatted to include the attachments. (We can make it multipart, and include a HTML version as well so email users can view it easily.)

Every new save will produce a new version of file. yes, the content will be replicated - including attachments.. If necessary, there can be some macros which will say "Delete after x days", and the interface will delete the older versions after saving the new draft.

Disk storage will be a cache of latest copy. (Just like what RCS does today.)

Standard operations:

  • Viewing: The latest copy will always reside on the disk, and that is what would be viewed.
  • Search: Will use copy on the disk.
  • Diff: Will have to be implemented. (Perhaps it already exists in included RCS.pm.)

And ...

  • Lots of storage required. Thankfully, it is not an issue at all.
  • Access controls on email will, by default, not be available. But some IMAP servers, such as cyrus, support access control. We will have to implement synch logic between sync twiki and cyrus.
  • Imap servers will work well on search for only few headers. We will have to optimize that part properly.
  • Being able to update topic from within email: In theory, this should be feasible. But not trivial.

So, this could be quite a feasible option.

-- VinodKulkarni - 02 Dec 2003

This IMAP idea is interesting, but I'm not sure if it would really be practical to duplicate content so much - keeping IMAP folders as a loosely synchronised cache of a TWiki might be more feasible. Also, IMAP normally implies online storage not offline, at least in most setups that I've seen (see Donkin:IMAP for some links) - people use additional tools or specific email clients to get offline storage. Anyway, let's put this discussion in TWikiUsingIMAPStorage or similar.

-- RichardDonkin - 02 Dec 2003

Done.

-Vinod

We've been using the server side script to email the actual text of a page, in addition to the client side mailto that emails a link, for several months now and I am afraid that I have to say:

  • the server side "email a copy of this page" is easier for the mail reader, i.e. the recipient of the mail.
    • in particular, better for offline reading
  • however, the server side script is just plain annoying to use...
    • because it is not your native mailer, just a web page form that approximatesd a mailer.
    • because the mail appears to be from someone other than the sender

I've fallen into the habit of cutting and pasting text from the wiki page into my mailer. It ends up poorly formatted, but at least I can use my standard mailer.

I continue to think that this is one of the biggest obstacles to getting wiki into wide use. Client side emailing of the actual text, rather than a link to the text, is needed.

-- AndyGlew - 29 Dec 2003

I've created an add-on that offers the choice to 1) send topic content in body of an html email, 2) send html topic as attachment to email, or 3) just send a link to the topic. As soon as I get permission for repackaging the perl script that I used in the add-on from the script's author (I can't find him at present), I will post it on TWiki.org. In the mean time, you can see a demo of it at http://skyloom.com/Demo/MailPageAddOnDemo. I also have a pre-release version of the add-on package available on my site.

-- LynnwoodBrown - 31 Jan 2005

Is this ready?

-- MartinCleaver - 08 Apr 2006

It works fine. It's packaged up in MailPageAddOn and works fine with Dakar.

-- LynnwoodBrown - 08 Apr 2006

Edit | Attach | Watch | Print version | History: r24 < r23 < r22 < r21 < r20 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r24 - 2006-04-08 - WillNorris
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.