Luis writes: > For what it is worth, I think the current mobile app is pretty good and I regularly finding pleasant surprises
Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. *Galder* - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your later comment on the ability to "*write simultaneously ... upload videos ...** autosave*", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing <https://bluespice.com/mediawiki-visualeditor/> (resolving attribution and revision history for multiparty edits), video uploading <https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to note the original upload if we only save a transcode), and drafts <https://phabricator.wikimedia.org/T39992> (rallying support behind a specific client-side use case to realize). 2.* Jonathan* - "[In my new sw company] we have the autonomy to make the changes in the first place, see what happens, and then build from there..." "WMF product teams work in an environment where [...] one set of end users (editors) has a great deal of both *soft* and *hard* power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)." --> These comments highlight a common misframing, about autonomy and curation of the reading experience, worth addressing. (Likely deserves its own thread!) Much of the friction and tension in our movement stems from different understandings of autonomy; and the impedance mismatch <https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch> of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent. Most active editors and curators are not "end users" of the site, any more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates <https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geocodes_to_articles> and article status indicators <https://www.mediawiki.org/wiki/Help:Page_status_indicators>, they should feel they are on the same team: improving the site skin together. This is a solved problem in some corners, but the solutions are not evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [*The article always ends on the wrong version <https://meta.wikimedia.org/wiki/The_Wrong_Version>; confusion is always due to the other person* :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus. Wishing all a beautiful week's end, SJ
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/FFSRH4GTMJACZJQURGNWHK5X6MTR3WSE/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
