Last modified: 2014-02-12 23:45:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26359, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24359 - Add "e-mail to friends" functionality to MobileFrontend
Add "e-mail to friends" functionality to MobileFrontend
Status: RESOLVED WONTFIX
Product: MobileFrontend
Classification: Unclassified
Feature requests (Other open bugs)
unspecified
All All
: Normal enhancement
: ---
Assigned To: Nobody - You can work on this!
: easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-13 09:37 UTC by Michael
Modified: 2014-02-12 23:45 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael 2010-07-13 09:37:34 UTC
Someone suggested adding a link that allows you to e-mail interesting articles to a friend.
Comment 1 Mark A. Hershberger 2011-08-17 17:19:18 UTC
WONTFIX b/c we don't want mobile-only features that we won't have on the main site.
Comment 2 MZMcBride 2011-08-17 17:38:35 UTC
(In reply to comment #1)
> WONTFIX b/c we don't want mobile-only features that we won't have on the main
> site.

This isn't a valid WONTFIX rationale. It doesn't make any sense on multiple levels. Re-opening.
Comment 3 Mark A. Hershberger 2011-08-17 18:24:10 UTC
Seems the same rationale for closing Bug #227 should work here.

*** This bug has been marked as a duplicate of bug 227 ***
Comment 4 MZMcBride 2011-08-17 20:01:49 UTC
Re-opening this (with a bit of consensus, for a change!).

There's no real principle that mobile features need to match non-mobile features in MediaWiki development. And the reality is that mobile browsers' feature sets don't match of those of their non-mobile counterparts. That's an important consideration.

The justification for WONTFIXing bug 227 doesn't apply here (and in my opinion, is a bit dubious for bug 227 as well).
Comment 6 Mark A. Hershberger 2011-08-17 22:02:54 UTC
To avoid the problem of spamming, there should be some control be put in place so that a user cannot edit or create and article and then send it to someone.

We should also allow people to opt-out of getting these emails.  If your Aunt Sue starts sending you every article she finds in Wikipedia, you may quickly get annoyed.  So we should maintain a list of people who've gotten the email and then said they don't want any more.

Finally (and this is really more of an Ops issue), we should hook into Feedback Loops (See AOLs for example: http://postmaster.aol.com/Postmaster.FeedbackLoop.php but other large providers like Yahoo, Hotmail and Comcast use them as well) so that when someone marks the email as spam their provider can notify us that they don't want to get the emails any more.
Comment 7 p858snake 2011-08-17 22:40:09 UTC
We don't need to reinvent the email cycle here, we could just have a button that loads the local client with email then its up the user to send it. That way we don't really have spam issues to deal with being sent from our end.

I don't really see how X sending how many emails to Y is really a issue for us to consider unless we decide to go down the route to setting up our own email gateway/system to send these.
Comment 8 Casey Brown 2011-08-18 00:39:58 UTC
(In reply to comment #7)
> We don't need to reinvent the email cycle here, we could just have a button
> that loads the local client with email then its up the user to send it. That
> way we don't really have spam issues to deal with being sent from our end.
> 
> I don't really see how X sending how many emails to Y is really a issue for us
> to consider unless we decide to go down the route to setting up our own email
> gateway/system to send these.

+1

I was thinking the same thing where we just give an easy mailto: link that prefills everything (like subject, body, etc.) but uses the the person's own e-mail client.

I think Mark was imagining a system where we managed the sending ourselves through our server, but I don't think that's needed. An easy button that fills out the e-mail for you would be good enough.
Comment 9 Mark A. Hershberger 2011-08-18 17:42:45 UTC
(In reply to comment #8)
> I think Mark was imagining a system where we managed the sending ourselves
> through our server, but I don't think that's needed. An easy button that fills
> out the e-mail for you would be good enough.

Agreed.  And it would avoid the having to deal with the whole mess I talked about in comment #6.
Comment 10 Jon 2012-02-15 13:52:46 UTC
I'm not sure about this. As an Android user I'm perfectly content with holding down my finger on the address bar, clicking share and then making use of android intents to either share the link by e-mail or twitter or any other app I have installed.

This aside I realise that not all phones have a similar mechanism.

If we did want to pursue this I'd encourage encompassing more than email (e.g. twitter, facebook etc) and would recommend keeping a close eye on the WebIntents [1] which the Mozilla Lab and Chrome teams are working together on in particular the webintents share intent [2]. This way "we don't need to reinvent the email cycle"

[1] http://www.w3.org/wiki/WebIntents
[2] http://webintents.org/share
Comment 11 Max Semenik 2012-12-16 00:52:30 UTC
Not much interest in it, and not in mobile team's plans.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links