Re: [WikimediaMobile] watchlist removal on mobile web
/me raises hand I put the watch star there so I can say it was developers intuition. My reasoning was it should be easy to undo the action. If we were to delete the row from the watchlist, there is no easy way to get it back. It's also tied to the page watchstar. On a page that watch star doesn't disappear so this is consistent with that. I only did it this way as that was the easiest way to implement this but I'm sure there are better ways - e.g. maybe showing a link to undo on the notification instead. On Tue, Aug 26, 2014 at 11:22 PM, Amir E. Aharoni wrote: > Hi, > > A user in the Hebrew Wikipedia pointed out to me that it's uncomfortable to > her that after removing a page from the watchlist it is still displayed > there. It is gone after refreshing the watchlist, but she says that for her > it would make more sense if it disappeared immediately. > > This is a design question more than a bug, so I'm asking here: what do the > designers think? > > I can see pros and cons in both ways and I wonder how was the current > behavior decided: design and user testing or only the developers' intuition? > > Thank you! > > -- > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי > http://aharoni.wordpress.com > “We're living in pieces, > I want to live in peace.” – T. Moore > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] Standardising icons across projects
Since we had the luxury of having several people in the office, Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat down to talk about the problem we currently have of having no standard way to create icons. Here is my write up of this meeting, again, if you attended please add/correct me on anything and if you were not please ask for clarification where needed. Currently we have two modes of creating icons in MediaWiki 1) Using a font 2) Using SVGs with PNG fallbacks and the markup varies depending on what extension you look at. We discussed both approaches and advantages and disadvantages of each. One of the major disadvantages of the WikiFont is the additional HTTP request it creates to download the font and cannot be embedded in the stylesheet using data uris like SVGs can (due to URL size restrictions). One of the major advantages of WikiFont is you can design a grayscale icon, and style it using font colour. Shahyar was happy to move Flow to using SVG based fonts if we could build grayscale SVGs and change their colours using ResourceLoader. One concrete example is when you have an icon used in a constructive anchor. The icon needs to be green, but when hovered over a lighter green. Another advantage brought up by May was that currently she finds it much easier to build icons in this way, and that having to maintain separate coloured versions of the SVGs is a pain point to her. We decided that we should push towards using SVGs that can be built into fonts for the purpose of the app. As next steps 1) Monte to explore using SVGs in the Wikipedia apps. He will create font from SVGs. He will work with May to ensure her workflow is as easy as before. 2) Trevor is going to look into how we can automatically generate different colour versions of SVGs and automatically create PNGs from them. 3) I am going to aim to agree on a standard icon HTML markup for mediawiki ui. We still have an issue with the fact that everyone is using different HTML markup to create icons. After reviewing all our current approaches [1] it was clear that we were relatively closely aligned and that it simply is a case of agreeing on class names. We aim to get all the above done by Sept 15th, 2014 so please poke us on the mailing list if you haven't had a follow up then. Full disorganised notes can be found here [2]. [1] https://www.mediawiki.org/wiki/Icon_standardisation [2] http://etherpad.wikimedia.org/p/Icon_standardisation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Standardising icons across projects
Just to note - it is only the iOS app that uses the font. The android one has always just used SVGs. -- Yuvi Panda T http://yuvi.in/blog ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Wikitech-l] The future of skins
Someone in one of our meetings mentioned that Twig is a PHP implementation of Mustache. This doesn't seem to be the case though. We need a templating solution that works both on the server and the client. On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal wrote: > Thanks for summarizing the meeting Jon. > > So, let's get Twig/Swig into core then, eh? :) > > - Trevor > > > On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson wrote: >> >> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and >> talked about the future of skins. Hopefully this mail summarises what >> we talked about and what we agreed on. Feel free to add anything, or >> ask any questions in the likely event that I've misinterpreted >> something we talked about or this is unclear :) >> >> Specifically we talked about how we are unhappy with how difficult it >> currently is for developers to create a skin. The skin class involves >> too many functions and does more than a skin should do e.g. manage >> classes on the body, worry about script tags and style tags. >> >> Trevor is going to create a base set of widgets, for example a list >> generator to generate things like a list of links to user tools. The >> widgets will be agnostic to how they are rendered - some may use >> templates, some may not. >> >> We identified the new skin system will have two long term goals: >> 1) We would like to get to the point where a new skin can be built by >> simply copying and pasting a master template and writing a new css >> file. >> 2) Should be possible for us in future to re-render an entire page via >> JavaScript and using the modern history push state re-render any page >> via the API. (Whether we'd want to do this is another consideration >> but we would like to have an architecture that is powerful enough to >> support such a thing) >> >> As next steps we agreed to do the following: >> >> 1) Trevor is going to build a watch star widget on client and server. >> We identified that the existing watch star code is poorly written and >> has resulted in MobileFrontend rewriting it. We decided to target this >> as it is a simple enough example that it doesn't need a template. It's >> small and contained enough that we hope this will allow us to share >> ideas and codify a lot of those. Trevor is hoping to begin working on >> this the week of the 2nd September. >> >> 2) We need a templating system in core. Trevor is going to do some >> research on server side templating systems. We hope that the >> templating RFC [1] can get resolved however we are getting to a point >> that we need one as soon as possible and do not want to be blocked by >> the outcome of this RFC, especially given a mustache based templating >> language can address all our current requirements. >> >> [1] >> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library >> >> ___ >> Wikitech-l mailing list >> wikitec...@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-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
Re: [WikimediaMobile] [Wikitech-l] The future of skins
Someone in the meeting also claimed that Swig and Twig were compatible, and that does appear to be generally true, but I think there are some deviations. - Trevor On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera wrote: > Someone in one of our meetings mentioned that Twig is a PHP > implementation of Mustache. This doesn't seem to be the case though. > We need a templating solution that works both on the server and the > client. > > On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal > wrote: > > Thanks for summarizing the meeting Jon. > > > > So, let's get Twig/Swig into core then, eh? :) > > > > - Trevor > > > > > > On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson > wrote: > >> > >> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and > >> talked about the future of skins. Hopefully this mail summarises what > >> we talked about and what we agreed on. Feel free to add anything, or > >> ask any questions in the likely event that I've misinterpreted > >> something we talked about or this is unclear :) > >> > >> Specifically we talked about how we are unhappy with how difficult it > >> currently is for developers to create a skin. The skin class involves > >> too many functions and does more than a skin should do e.g. manage > >> classes on the body, worry about script tags and style tags. > >> > >> Trevor is going to create a base set of widgets, for example a list > >> generator to generate things like a list of links to user tools. The > >> widgets will be agnostic to how they are rendered - some may use > >> templates, some may not. > >> > >> We identified the new skin system will have two long term goals: > >> 1) We would like to get to the point where a new skin can be built by > >> simply copying and pasting a master template and writing a new css > >> file. > >> 2) Should be possible for us in future to re-render an entire page via > >> JavaScript and using the modern history push state re-render any page > >> via the API. (Whether we'd want to do this is another consideration > >> but we would like to have an architecture that is powerful enough to > >> support such a thing) > >> > >> As next steps we agreed to do the following: > >> > >> 1) Trevor is going to build a watch star widget on client and server. > >> We identified that the existing watch star code is poorly written and > >> has resulted in MobileFrontend rewriting it. We decided to target this > >> as it is a simple enough example that it doesn't need a template. It's > >> small and contained enough that we hope this will allow us to share > >> ideas and codify a lot of those. Trevor is hoping to begin working on > >> this the week of the 2nd September. > >> > >> 2) We need a templating system in core. Trevor is going to do some > >> research on server side templating systems. We hope that the > >> templating RFC [1] can get resolved however we are getting to a point > >> that we need one as soon as possible and do not want to be blocked by > >> the outcome of this RFC, especially given a mustache based templating > >> language can address all our current requirements. > >> > >> [1] > >> > https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library > >> > >> ___ > >> Wikitech-l mailing list > >> wikitec...@lists.wikimedia.org > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-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
Re: [WikimediaMobile] [Wikitech-l] The future of skins
I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and post these in the next couple days. On Wed, Aug 27, 2014 at 2:26 PM, Trevor Parscal wrote: > Someone in the meeting also claimed that Swig and Twig were compatible, > and that does appear to be generally true, but I think there are some > deviations. > > - Trevor > > > On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera > wrote: > >> Someone in one of our meetings mentioned that Twig is a PHP >> implementation of Mustache. This doesn't seem to be the case though. >> We need a templating solution that works both on the server and the >> client. >> >> On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal >> wrote: >> > Thanks for summarizing the meeting Jon. >> > >> > So, let's get Twig/Swig into core then, eh? :) >> > >> > - Trevor >> > >> > >> > On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson >> wrote: >> >> >> >> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and >> >> talked about the future of skins. Hopefully this mail summarises what >> >> we talked about and what we agreed on. Feel free to add anything, or >> >> ask any questions in the likely event that I've misinterpreted >> >> something we talked about or this is unclear :) >> >> >> >> Specifically we talked about how we are unhappy with how difficult it >> >> currently is for developers to create a skin. The skin class involves >> >> too many functions and does more than a skin should do e.g. manage >> >> classes on the body, worry about script tags and style tags. >> >> >> >> Trevor is going to create a base set of widgets, for example a list >> >> generator to generate things like a list of links to user tools. The >> >> widgets will be agnostic to how they are rendered - some may use >> >> templates, some may not. >> >> >> >> We identified the new skin system will have two long term goals: >> >> 1) We would like to get to the point where a new skin can be built by >> >> simply copying and pasting a master template and writing a new css >> >> file. >> >> 2) Should be possible for us in future to re-render an entire page via >> >> JavaScript and using the modern history push state re-render any page >> >> via the API. (Whether we'd want to do this is another consideration >> >> but we would like to have an architecture that is powerful enough to >> >> support such a thing) >> >> >> >> As next steps we agreed to do the following: >> >> >> >> 1) Trevor is going to build a watch star widget on client and server. >> >> We identified that the existing watch star code is poorly written and >> >> has resulted in MobileFrontend rewriting it. We decided to target this >> >> as it is a simple enough example that it doesn't need a template. It's >> >> small and contained enough that we hope this will allow us to share >> >> ideas and codify a lot of those. Trevor is hoping to begin working on >> >> this the week of the 2nd September. >> >> >> >> 2) We need a templating system in core. Trevor is going to do some >> >> research on server side templating systems. We hope that the >> >> templating RFC [1] can get resolved however we are getting to a point >> >> that we need one as soon as possible and do not want to be blocked by >> >> the outcome of this RFC, especially given a mustache based templating >> >> language can address all our current requirements. >> >> >> >> [1] >> >> >> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library >> >> >> >> ___ >> >> Wikitech-l mailing list >> >> wikitec...@lists.wikimedia.org >> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-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 > > ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] [Mobile web] Important: putting the mobile web upload features on ice
*tl;dr: * The Mobile Web team has decided to hide the uploads features (upload & add to article + upload from left nav) on the mobile site until we have the time/resources to rebuild them into a more productive contribution stream. *Background:* Before wikitext or VE editing, the mobile web team built an upload-to-Commons pipeline as the first proof-of-concept of mobile contribution. When we first launched the two upload features (upload and add to article + upload to Commons via the left nav) ~2 years ago, we saw a high ratio of these images being deleted (because they were copyright violations, test images, selfies, etc.). Since then, we've continued to make incremental improvements to address these issues: we added interactive tutorials and instruction screens, and also gradually increased the permission levels required to see these features (from everyone –> logged-in-only –> autoconfirmed only –> 10+ edits). However, despite all these changes, the ratio of kept to deleted uploads has not changed significantly; though the absolute number of uploads per month has gone down,[1] 70-80% of these files still get deleted.[2] This is both a crappy experience for the end-user and a major headache for the team – in addition to the pure engineering effort of continuing to adjust the parameters of the feature, every incremental change to the workflow requires a browser test rewrite, analysis time to figure out if the improvements have actually made a difference, and lengthy back-and-forth communication with a very unhappy set of Commons admins on Bugzilla. And none of the changes to date seemed to have made much of a difference. In trying to address these issues, we've shifted from focusing on the new user persona to the power user... but we're not explicitly revisiting the interactions, messaging, or feature set, because we don't have the bandwidth to make larger changes. I.e., despite the fact that the feature is now not even being shown to brand-new users, we still show a tutorial targeted at people who've never contributed before. I think we've reached diminishing marginal returns on incremental improvements at this point. If we want uploads to succeed, we need to start from scratch: decide who the persona we want to target is and then build the set of features that this user is going to need. But rethinking how to instruct newbies (since tutorials don't seem to work) or coming up with a whole new workflow aimed at experienced users isn't something the team can take on at this point. It requires dedicated product and design attention and quite a bit of engineering work, none of which we have the resources for. Since our focus for the year is new active editors and uploads are not part of our annual targets, I recommended to the team that we hide the mobile web uploading features for now and revisit them either later this year or next fiscal year. The team agreed to this at today's planning meeting, and we'll be making this change in the coming days. I know it's not a great feeling when the software we create isn't a rousing success, but I think it's really important to be upfront (with ourselves as much as with the community) when we see that a feature just isn't doing what we want it to do. Lila has been talking a lot lately about how it seems like we've been trying to do! all! the things! in WMF engineering – which comes at the cost of fragmenting our attention and making it hard to really excel at any one of those things. I think she's totally right, and I'd like to see our team lead by example and strive for more focus and rigor in terms of what we work on and how :) As always, if you have questions/concerns, feel free to voice them here. I'll probably communicate this more broadly sometime early next week. 1. http://mobile-reportcard.wmflabs.org/graphs/unique-uploaders 2. http://mobile-reportcard.wmflabs.org/graphs/deleted-uploads -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
