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
