There are few things I hate more than dealing with images on computers.
Even a simple thing like emailing a screenshot or adding a photo to a
blogpost OR A WIKIPEDIA ARTICLE
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live
[ Sorry, sent prematurely ]
There are few things I hate more than dealing with images on computers.
Even a simple thing like emailing a screenshot or adding a photo to a
blogpost OR A WIKIPEDIA ARTICLE is torture to me.
The only thing of this kind that is NOT torture is taking a photo with my
pho
Hello Mobile fans :)
Florian and and myself earlier created a draft for a Mobile Newsletter:
https://www.mediawiki.org/wiki/Mobile/Newsletter -- it is currently a bit
outdated since it has been around for a while. Given the comments on phab
ticket. https://phabricator.wikimedia.org/T93529, it is
Who is the target audience?
If I understand correctly, the target audience for the weekly Tech news and
the monthly VE news is experienced active editing Wikipedians (I don't know
if it was ever designated, but I am making an educated guess of the actual
practice).
But what is it for the mobile n
Sounds very reasonable. A lot of changes happen in mobile, some are
tangent to desktop experiences, and pro-actively sharing those updates
while in planning or early stage, is a good practice. In addition, keeping
the community updated and aware of what is happening in mobile, helps
present the b
Because Commons is afraid of the massive influx of selfies that will then
have to be deleted, binding admin time and upsetting the uploader (who is,
likely, not aware of the Commons policies).
As was said before in this thread, some filtering at the source
(smartphone) will have to be implemented
Yes but we had a terrific app that worked the other way: Wherever you are
standing, you could see the things that Wikipedia wants a picture of (via
the WLM lists). The community voted that the 'easy uploader button" would
also result in too many pictures of the same things. So it's not just
selfies
One can Assume Good Faith and extrapolate from Instagram at the same time
:-)
On Wed, Apr 15, 2015 at 11:42 AM Jane Darnell wrote:
> Yes but we had a terrific app that worked the other way: Wherever you are
> standing, you could see the things that Wikipedia wants a picture of (via
> the WLM lis
On 15.04.2015 05:36, Dan Garry wrote:
On 14 April 2015 at 16:47, Shankar mailto:notnara...@gmail.com>> wrote:
Without spending too much time can someone point me to a rationale
why the app was sunset in the first place.
https://www.mail-archive.com/mobile-l@lists.wikimedia.org/msg02586
> An Android Commons mobile app is probably the mandatory catalisator for
hundreds of millions of people to participate to Commons. If you have only
300 unique users a month with an official Commons app, IMO the only thing
it tells you is: the app is not good enough!
Muggles (no offense, honestly)
Hey y'all,
As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team
picked up a spike to investigate what data, if any, we were logging around
site speed [0], given the existence of the mobile graphs over at WMF stats
[1].
After a little poking around I found that all of the Naviga
I don't see many advantages between the sub-module approach and just
leaving it in MobileFrontend and have Gather depend passively on a part of
MobileFrontend. I mean, the isolation can make us think that they are
decoupled but in reality they will still be highly coupled, and we'll need
to be as c
There seems to be two things in conflict when dealing with anything upload
related.
1) uploading from a mobile phone is easy - that's a good thing
2) uploading useful content to commons is difficult for most people
Remember we made it super easy on web and we even limited who could see it
but peop
I agree with Joaquin. What are the benefits of decoupling?
On Wednesday, April 15, 2015, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:
> I don't see many advantages between the sub-module approach and just
> leaving it in MobileFrontend and have Gather depend passively on a part of
>
>
> Because Commons is afraid of the massive influx of selfies that will then
> have to be deleted, binding admin time and upsetting the uploader (who is,
> likely, not aware of the Commons policies).
>
As was said before in this thread, some filtering at the source
> (smartphone) will have to be
:)
https://blog.wikimedia.org/2015/04/15/new-release-wikipedia-app-ios/
Great work everyone.
-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
If we open the image upload in the mobile app people will upload selfie and
their other images which might not useful at all. At present there are ways
to upload them via web browser and few people are doing so.
on the other hand we will get a lots of useful images if there is a option
available v
It would be good to get desktop and mobile in the same graph so we can
compare the two.
If I'm reading correctly this is all rather depressing - we are pretty
much the same as desktop despite being an environment which should
explicitly do better?
On Wed, Apr 15, 2015 at 7:02 AM, Sam Smith wrote
In beta on enwiki, there were 400 clicks on watchlist compared to 587
on collections since we launched it. It will be interesting how it
holds out, as I suspect it is "new feature curiosity" but it adds more
value to the idea that people use the watchlist for things other than
editing. It's even mo
Thanks Jon,
Just for clarity: Is this clicks on watch list links "in general" (mobile
and desktop), clicking on the watchlist button on mobile or clicking on
watchlist links on mobile? (or something else)
James Alexander
Community Advocacy
Wikimedia Foundation
(415) 839-6885 x6716 @jamesofur
On
Given that your target audience for this project right now is Wikipedia
readers, what are the advantages to those users of removing the
MobileFrontend dependency from Gather? I'm unclear on this point right now.
Dan
On 13 April 2015 at 12:10, Jon Robson wrote:
> I did a quick spike [1] to work
On Wed, Apr 15, 2015 at 9:05 AM, Brian Gerstle wrote:
>> Because Commons is afraid of the massive influx of selfies that will then
>> have to be deleted, binding admin time and upsetting the uploader (who is,
>> likely, not aware of the Commons policies).
>>
>>
>>
>> As was said before in this thr
This is clicks on English Wikipedia in the beta version of mobile web
within the 'hamburger menu' (the menu accessed by clicking on the 3
line icon in the top left corner). We've seen lots of data on mobile
web that suggest people use the watchlist in this way.
If we look at watchlist behaviour, a
I think it is a technical detail Moiz and Dan, no decoupling from the
wikipedia ecosystem.
The idea (I think) is to make Gather more independent of Mobile frontend so
that it can work seamlessly in Desktop when the time comes and in the way
extract valuable common code into library/core so that ot
I find that site super slow to load (the graphs and images) and a bit hard
to interpret. Can somebody give a little explanation about what we are
seeing and what the different variables measured mean?
On Wed, Apr 15, 2015 at 7:27 PM, Jon Robson wrote:
> It would be good to get desktop and mobile
Perhaps some serious thought should go into guiding the user in what an
appropriate upload is rather than just make it super easy to upload the
very first time? Didn't mobile web have around ~80% {{speedy}} and ~10%
rightfully successful deletion requests?
If I understand correctly Wikigrok will n
Very interesting, thanks for sharing Jon.
On Wed, Apr 15, 2015 at 8:25 PM, Jon Robson wrote:
> This is clicks on English Wikipedia in the beta version of mobile web
> within the 'hamburger menu' (the menu accessed by clicking on the 3
> line icon in the top left corner). We've seen lots of data
If these numbers grow for collections maybe we can make a case for rolling
Watchlist into Collections altogether.
On Wed, Apr 15, 2015 at 2:36 PM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:
> Very interesting, thanks for sharing Jon.
>
> On Wed, Apr 15, 2015 at 8:25 PM, Jon Robson
On 15 Apr 2015 11:34 am, "Jan Ainali" wrote:
>
> Perhaps some serious thought should go into guiding the user in what an
appropriate upload is rather than just make it super easy to upload the
very first time?
We tried. This is a very very hard problem. Explaining copyright law is
difficult and no
Jan,
You make a very good point with creating a staging area and having some
level of voting etc before uploads are committed.
This does has a fair share of backend work + notifications, that come with
it.
We have much better means of preventing failure on native apps - with face
detection, exif
>
> This does has a fair share of backend work + notifications, that come with
> it.
Doesn't mean we shouldn't hack something together to prove it's worth
doing—which I think it might be.
On Wed, Apr 15, 2015 at 3:25 PM, Vibha Bamba wrote:
> Jan,
>
> You make a very good point with creating a
On Wed, Apr 15, 2015 at 11:16 AM, Jon Robson wrote:
> Our communities reaction seems to be to push back on
> influxes of new edits which makes me feel we should be spending more
> time on moderation tools - but so far I don't see any hint that this
> will become a focus.
>
+1
I'll add that tradi
2015-04-15 20:51 GMT+02:00 Jon Robson :
>
> On 15 Apr 2015 11:34 am, "Jan Ainali" wrote:
> >
> > Perhaps some serious thought should go into guiding the user in what an
> appropriate upload is rather than just make it super easy to upload the
> very first time?
> We tried. This is a very very har
Sorry Joaquin, I should've also included a link to the NavigationTiming
schema, which provides good documentation for all of the things that the
extension captures: https://meta.wikimedia.org/wiki/Schema:NavigationTiming.
It might also be prudent to include this documentation alongside the graphs…
Not to silence ideas (which are great), but similar to the "image cropping
in gather" thread, can we figure out what the extent of this problem is and
decide whether or not we want to solve it? Designing a solution for this
should involve prototyping anyway, IMO. Put another way:
- What's the
Exactly. Purely technical. From an outsiders perspective it makes
little difference - the feature will still look and behave the same..
To be honest the easiest thing to do would be to package our code and
put it in core, which is what VisualEditor did with oojs ui - but
having two libraries side
If we could store images in a safe temporary place - e.g. a draft
namespace or similar, I could imagine harnessing Wikigrok to crowd
source the moderation problem.
Is this image a copyright violation?
Yes / No / No idea.
On Wed, Apr 15, 2015 at 1:05 PM, Brian Gerstle wrote:
> Not to silence i
[errr my email is being weird... the first time I sent this I got a
"bounce" email from google saying that no mail was sent because of an error
and the 2nd time it only went to Jon Katz... so if anyone got multiple
copies I'm sorry...
On Wed, Apr 15, 2015 at 12:33 PM, Jon Katz wrote:
>
> On Wed,
38 matches
Mail list logo
