Hi Joaquin, Thanks very much for the comments.
I'm too buried in short-term issues to participate further in this discussion at the moment, but I'm glad that you're thinking in the way that you are. I hope that more people will participate in this discussion. Pine On Mon, Jul 18, 2016 at 7:04 AM, Joaquin Oltra Hernandez < jhernan...@wikimedia.org> wrote: > Hi Pine, > > I personally enjoyed your comments, you are looking ahead and want the > platforms to move forward in terms of user experiences and interaction, and > that is great. > > I was thinking along similar lines as Stuart, using OSM to navigate and >> encouraging users to take photos of landmarks and other buildings where >> that's permitted by FOP. Landmarks for which we have only small photos, old >> photos (more than about 3 years), or no photos could be prioritized. >> > This is very interesting, and a great contribution mechanic for mobile > users. Right now I'd visualize this as a native apps only feature, given > the need to do location background checks and notifications usage. This use > case in particular is possible as of lately in modern browsers too with > service workers I believe, but the technologies are still not widely > adopted by all vendors. > > What's your opinion on standalone focused experiences vs integrating this > sort of features into the other bigger products like the Wikipedia native > apps or the Wikimedia sites? > > Personally I believe that this sort of things would be better served by > standalone applications/websites that could be linked and interoperate with > the others, but everything has tradeoffs and that would make them have a > lot less exposure to users (which is sometimes a good thing). > > Regarding the case of mobile uploads, from what we learned from the mobile > web implementation some time ago, the feature set has to be well designed > and tested with real users, otherwise there's an inflow of vandalism (for > example via selfies) that is very damaging. In that case, the solution was > to disable the thing because that's the way to make sure that editors > wouldn't be overloaded. > > Also, for readers, how about showing the readers an OSM view of the world >> and noting which nearby features have Wikipedia articles as the users >> navigate on the map? >> > > This is something we're closer to being able to do. The Discovery Maps > team is working hard on getting OSM maps ready for wide usage ( > https://maps.wikimedia.org/#3/43.64/-38.14), and the Discovery Search > team has recently (like last week) enabled a geosearch endpoint that allows > you to search within the radius of a location (per iOS app team's request) > that enables this use case you just mentioned. > > All great work, I can't wait to see what the apps teams do with it. > > Finally, > > > I was going to comment on the next paragraph, but there is not much to > say. I completely agree and I feel the same way. Greatly put: > > >> I'd like users to have emotionally rewarding experiences when exploring >> our content, as well as creating new content or editing existing content. >> Editing is painful on mobile, and even on desktop in VE there are bugs >> which are frustrating. I'd like our tools to work properly, fast, and >> intuitively. I realize that WMF has a limited budget, but our interface is >> a ways from being a smooth and enjoyable experience, both on VE and on >> wikitext. And for readers, I'd like to have robust multimedia search and >> interactive features. We are far behind in our interfaces compared to sites >> and apps that others provide, and I hope that we can close that gap within >> the next two to three years. If WMF does not improve its interfaces >> rapidly, this leaves the door open for competitors to remix our content >> with better interfaces, and also encourages potential contibutors to leave >> Wikimedia for places that provide nice, modern designs and user experiences. >> > > Really ^, 10/10 IMO. > > Aside from the resource problem, I'd be keen in hearing other thoughts on >> how to accelerate WMF progress on design and features so that we can have >> some of the features that I mentioned above as well as have intuitive, >> fast, robust interfaces that our readers and contributors enjoy using. > > > What are your thoughts on this last paragraph? I have some of my own that > I'll share now, but it'd be great to know what you think. > > My take is that for accelerating progress on innovation on design and > features, you need and want to move fast, and be directly involved with > early adopters (engaged, adventurous, and in the target user space). > > To go fast, it is known that you need small teams, and to innovate and > make progress you need capable forward-thinking people. > > To get early adopters you need a pool of people to engage with long term > to drive the development of such projects, which the wikimedia community > has, if enough effort was put into involving people in such projects. > > With that in place, you can benefit of early feedback over working > prototypes, on which you can iterate and pivot, with less communication > overhead, and full sense of ownership of the work produced which usually > yields high engagement both from the development teams and the early users. > > Before answering the question, there's another thing to take into account, > what happens after a bunch of prototypes have become working products that > survived. There needs to be a clear life-cycle in place for the projects > once they get to a certain point, talking about how to integrate it into > existing offerings, drive users to benefit of this other project, or > finally sunset/get rid of it if it is not worth it later on. This part is > very important to increase reach and usefulness of the projects, and avoid > zombie projects lingering in limbo for a long time. > > So, how do you accelerate WMF progress on design and features so that we > can have some of the features mentioned above as well as have intuitive, > fast, robust interfaces that our readers and contributors enjoy using? > > My take is create small experimental teams with laser focus and tight > collaboration with early adopters, and shape those outputs into broader use > once they reach a critical point where it is clear they are a good idea, or > bury lingering projects quickly. > > I believe that the foundation has resources to at the very least try the > approach, but there are a few factors that are hard to overcome some times: > Accepting risks and saying no to safer, more conservative bets, believing > on bigger results later on. And trusting people you appoint to do this to > do a great job. > > One obstacle is that *Nobody ever got fired for choosing IBM* :p as they > say, and taking risks is hard. > > Also, this I just talked about is (as asked) *WMF progress on design and > features.* There are also awesome contributors that make very forward > thinking experiments where WMF could help via funding or resources, and > that may be the better way to go for WMF. > > Anyways these are my thoughts, looking forward to hearing other opinions. > > > On Fri, Jul 15, 2016 at 4:59 AM, Pine W <wiki.p...@gmail.com> wrote: > >> Sorry, I think that last paragraph sounded a bit like a rant. I think >> some of the problem here is that WMF lacks the financial resources to >> deploy many hundreds or thousands of researchers, designers and engineers >> like Google and Microsoft can. I'd like to see that resource problem >> solved. To be fair, even with all of their resources, Microsoft in >> particular has had problems (Windows 8 and Windows Vista come to mind). >> However, I do wonder, if WMF was able to borrow 500 researchers, designers, >> and engineers from other companies for a year or two, if WMF could make >> serious progress at the usability and features deficits between Wikimedia >> platforms and other major sites. >> >> Aside from the resource problem, I'd be keen in hearing other thoughts on >> how to accelerate WMF progress on design and features so that we can have >> some of the features that I mentioned above as well as have intuitive, >> fast, robust interfaces that our readers and contributors enjoy using. >> >> Pine >> >> On Thu, Jul 14, 2016 at 7:22 PM, Pine W <wiki.p...@gmail.com> wrote: >> >>> I was thinking along similar lines as Stuart, using OSM to navigate and >>> encouraging users to take photos of landmarks and other buildings where >>> that's permitted by FOP. Landmarks for which we have only small photos, old >>> photos (more than about 3 years), or no photos could be prioritized. >>> >>> Also, for readers, how about showing the readers an OSM view of the >>> world and noting which nearby features have Wikipedia articles as the users >>> navigate on the map? >>> >>> Finally, I'd like users to have emotionally rewarding experiences when >>> exploring our content, as well as creating new content or editing existing >>> content. Editing is painful on mobile, and even on desktop in VE there are >>> bugs which are frustrating. I'd like our tools to work properly, fast, and >>> intuitively. I realize that WMF has a limited budget, but our interface is >>> a ways from being a smooth and enjoyable experience, both on VE and on >>> wikitext. And for readers, I'd like to have robust multimedia search and >>> interactive features. We are far behind in our interfaces compared to sites >>> and apps that others provide, and I hope that we can close that gap within >>> the next two to three years. If WMF does not improve its interfaces >>> rapidly, this leaves the door open for competitors to remix our content >>> with better interfaces, and also encourages potential contibutors to leave >>> Wikimedia for places that provide nice, modern designs and user experiences. >>> >>> Pine >>> On Jul 14, 2016 15:03, "Stuart A. Yeates" <syea...@gmail.com> wrote: >>> >>>> A game built on a travel-photograph-upload loop would be a great way to >>>> build our depth of imagery. >>>> >>>> cheers >>>> stuart >>>> >>>> -- >>>> ...let us be heard from red core to black sky >>>> >>>> On Fri, Jul 15, 2016 at 9:52 AM, Toby Negrin <tneg...@wikimedia.org> >>>> wrote: >>>> >>>>> Hi Pine -- did you have any specific ideas? I spent some time in the >>>>> gaming industry and am familiar with Ingress, the game that Pokeman Go is >>>>> based on, as well as the theories behind mechanics/compulsion loops that >>>>> mobile games use. >>>>> >>>>> I'll share one general thought -- the research-edit-publish loop is a >>>>> great mechanism -- it's quick and easy and very gratifying, especially >>>>> combined with a google search. >>>>> >>>>> However, we've generally found that the notion that we use gaming >>>>> mechanics to encourage people to read or edit wikipedia does not have >>>>> broad >>>>> support in our communities. >>>>> >>>>> -Toby >>>>> >>>>> >>>>> >>>>> On Thu, Jul 14, 2016 at 2:26 PM, Pine W <wiki.p...@gmail.com> wrote: >>>>> >>>>>> Hi WMF Mobile and Research, >>>>>> >>>>>> I'm wondering if we (mostly meaning "you" but perhaps with external >>>>>> collaborators) have considered how the Wikipedia mobile apps, Wikipedia >>>>>> mobile web, the Wikidata game, and/or the Commons app could borrow some >>>>>> design ideas or features from Pokémon Go to make Wikimedia offerings more >>>>>> appealing, particularly to younger audiences. This would apply to content >>>>>> consumption and contribution, as well as community aspects of Wikimedia >>>>>> experiences, particularly on mobile platforms. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Pine >>>>>> >>>>>> _______________________________________________ >>>>>> Mobile-l mailing list >>>>>> Mobile-l@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Wiki-research-l mailing list >>>>> wiki-researc...@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Wiki-research-l mailing list >>>> wiki-researc...@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l >>>> >>>> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> >
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
