EE

ee@lists.wikimedia.org

502 discussions

Echo regression - new users are not getting notifications
by Jon Robson 29 Aug '14

29 Aug '14

Good news - Echo has a working browser test suite Bad news - we broke something (but this is why we now have browser tests and why they are a good thing :-)) Now if a user registers they get no notification - see https://bugzilla.wikimedia.org/show_bug.cgi?id=70139 I will leave S and Danny to work out how important this is to fix, or hopefully a patch will come from the community :-).

4 3

Re: [EE] [Design] Standardising icons across projects
by James Forrester 29 Aug '14

29 Aug '14

On 28 August 2014 11:22, Max <max(a)koehler-kn.de> wrote: > You're welcome. Do you guys have a grunt workflow set up? I'd love to help > out. > Yes, here for OOjs UI <http://git.wikimedia.org/blob/oojs%2Fui.git/HEAD/Gruntfile.js> – we'd definitely welcome suggestions and patches. :-) J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Flow scrum notes, Thurs Aug 28
by Danny Horn 28 Aug '14

28 Aug '14

Deployment's going out today. We're going to freeze the Echo deployment to group 2 wikis (en:WP), so we can fix the bugs we found on Mediawiki. Shahyar missed the meeting. *Benny*: Worked on fixing performance issues related to the notifications and emails job queue. We'll have to deploy the fix later this afternoon in the swat deploy. Added email bundling for edit and reply, which will help with the notification email spam that we're generating, and performance issue in the dropdown. (Is there a card for this?) We'll have to work on deleting old notifications -- running a cron job. S asks Benny - write this in the bug, we'll have to review it offline. *Erik*: Started working on G-3a, Preview for no-JS. Worked on S' comments on G-3. Worked on 69987 -- board is not being invalidated, anon users are seeing a 2-week old board. It looks like we won't be able to do G-10 -- Special page for Enable/Disable, which is blocked by ongoing database changes for probably a month. *Matthias*: Today - patch for Paging limit doesn't account for moderated topic Code review Blocked on search questions -- Danny sent an email that will hopefully explain. Danny will follow up more. *Jon*: G-4 -- Don't collapse closed topics -- and updated tests Today, focused on getting G-3 through code review. S needs to look at QA-Echo -- he tried yesterday, but ran into a blocker. S and Jon will follow up on that today. *S*: There was a conflict yesterday between Jon's i18n work and a change Shahyar made to the topic header yesterday. Sorry about that. Andrew wants to know what he can work on -- S will talk to him about the LQT conversion.

1 0

Re: [EE] [Design] Standardising icons across projects
by James Forrester 28 Aug '14

28 Aug '14

On 27 August 2014 12:14, Max <max(a)koehler-kn.de> wrote: > There's a grunt task called grunticon that does #2. > https://github.com/filamentgroup/grunticon Max, That's a pretty awesome find; thank you! J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Re: [EE] [Design] [WikimediaMobile] Standardising icons across projects
by May Tee-Galloway 28 Aug '14

28 Aug '14

I'm going to add that besides color, which seems to be the main focus here, that there are several other design issues I hope the solution we choose can offer us. That includes (mentioned <http://etherpad.wikimedia.org/p/Icon_standardisation> at bottom of etherpad <http://etherpad.wikimedia.org/p/Icon_standardisation>): Looking great visually - Icons align with text (on the baseline, or below, or above. It differs from icon to icons) - Icons align vertically and horizontally with other icons - Icon sizes are proportionate to each other Easy to manipulate and push icon changes - No extra workflows apart from changing SVG files - No need to export different color files after making a slight improvement to icon Easy to ship and communicate changes to other teams - No need to dig emails - Easy to track latest versions. No confusion - No extra work for other teams to change icons in their own team applications when we make icon improvements Consistency in application - Easy for everyone to know which icon to use without duplicating different icons for same usage Monte has shown me the script that he's created and I've got to say they are pretty impressive and it ticks off alot of these issues. I'll continue to work with him and the rest towards a solution that better streamline engineering and design workflows while giving us consistently great results. mm On Wed, Aug 27, 2014 at 12:17 PM, Yuvi Panda <yuvipanda(a)gmail.com> wrote: > 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 > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design >

1 0

2014-08-27 Flow design meeting recap
by S Page 28 Aug '14

28 Aug '14

*TOC* May presented design for a TOC bar from which you can bring up the T. As you scroll down it remains at the top,now showing the title of the current topic. You can still bring up the TOC to jump to other topics. See at http://invis.io/PA1A9UCRT , press right arrow to step through. This would replace the collapsed/small/expanded switcher. People liked it! Concerns: quiddity: Discoverability of the click to see TOC, could we have a preference to always show it at first? (Weird, it's a floating thing) Does the fixed header stay visible, or does it vanish when scroll down and slide back in when you scroll up like sites like Medium, etc. Shahyar thought the fixed header could shrink as you scroll. Conclusion: TOC bar remain visible to begin with. If from TOC you jump down to topic 55 while showing the first 10 topics, what do you see when you scroll up? * May prototype has [Load previous 44 topics ] bar. * Alternative is just show the 44 collapsed, and you click any one to expand it. Discussed animation of the scroll down when you click on the TOC. Next step: some more refinement. *Notification "toaster" reminder* https://trello.com/c/VIqXwy4W/618-notification-reminder Discussion on Trello card. Danny knows this works. Roll it out as a notification Beta Feature. *Don't disable reply on closed topic* https://trello.com/c/oSuO1E3T/692-don-t-disable-reply-on-closed-topic If a Closed topic doesn't collapse and remains active, then all that's left is it shows a white titlebar with a (◼) icon. That will stimulate feedback as to what users really want (Lock? Hide-with-summary? Collapse? etc.) *Topic title bar - remove middle line* https://trello.com/c/C2y2NWCE/691-topic-title-bar-remove-clutter We guessed that the most useful topic metadata in order is: 1. Number of comments 2. Last activity date 3. Number of participants 4. "Username started this topic", which is redundant if you can see the first post. So dropping 3 and 4 gets rid of the middle line in the title bar. A more compact title bar is a win! Shahyar already has a patch for this, https://gerrit.wikimedia.org/r/#/c/156728/ Danny's original proposal dropped "Reply" from titlebar as well. There are other ways to quickly get to the end of a topic to reply to it, but without UX research we don't know effect of removing Reply button... so decided to leave the button in. The two cards for Email notifications weren't controversial. -- =S Page Features engineer

1 0

Flow: Feedback on board subscriptions and email notifications
by Danny Horn 28 Aug '14

28 Aug '14

The new version of subscriptions and notifications has been out on Mediawiki.org for almost a week, and we're learning some interesting stuff so far. Some of it is working as intended (and therefore awesome), some of it is buggy and needs fixing, and we're getting some feedback on what's not quite working right. I've seen some grumbles -- some on WP:Talk:Flow [1], some on MW:Talk:Flow [2], and some from people in the office -- that are basically about two things: Email notifications, and Subscribing to a board. *Subscribing to a board* We had a lot of discussion about what subscribing to a Flow board would mean. Basically, we had two options: A) You get an Echo notification that a new topic has been created B) You get automatically subscribed to every new topic created on the board We hypothesized that A would work better for people who look at Echo more than their watchlist, and B would work better for people who look at their watchlist more than Echo. We needed to pick one to try out and see how it feels, so we chose B, which was closer to the way that watching a page works right now. What we're hearing from the feedback this week is that people are feeling spammed -- subscribed to too many topics that they're not interested in. I think it would be reasonable to switch it to A -- that would also solve the "two notifications for the same action" problem that we're currently having with one notification for "created a topic" and another for "posted the first message," which is the same thing. So I'll talk to Erik and Benny, and anybody else who cares, and we'll figure that out. Does anyone have thoughts about it? *Email notifications* Oh, and then we also didn't pay attention to email notifications, and therefore we ruined the world and I feel moderately bad about it. We're sending one email per post on a thread, which is obviously too much. I think the right answer there is to follow the example of watchlist emails -- send the first one, and then don't send any more until the user visits the Topic page. That's how watchlist works, and I think it's fine. I'll make a card and we should probably jump on that as soon as we can, so we stop ruining email. I'm also interested in thoughts on that, if anyone has some. And then we keep on Flowing. Peace out. Danny [1]: WP:Talk:Flow feedback -- https://en.wikipedia.org/wiki/Wikipedia_talk:Flow#Problems_accessing_mediaw… [2]: MW:Talk:Flow feedback -- https://www.mediawiki.org/wiki/Topic:S17tpg980s0mjuvi

3 3

Echo bug
by Benny Situ 28 Aug '14

28 Aug '14

We have introduced an Echo bug during Spring F. The 'More' link at the bottom of all notification page only shows during initial page load, that means users couldn't view older notifications. I have submitted a patch to fix this: https://gerrit.wikimedia.org/r/#/c/156445/. If possible, we should deploy this fix during swat window before it hits enwiki and all other wikis

2 4

Flow scrum notes, Wed Aug 27
by Danny Horn 27 Aug '14

27 Aug '14

Last week, we released new Echo code on Mediawiki.org. It's generally performing well, but we're finding some bugs (mostly intermittent ones) that would be good to fix before we deploy this to En.WP. Benny and S will talk today about holding the Echo code back from the usual WP deployment, so we have another week to fix the bugs. *Erik*: Finished G-3 (no-JS reply and edit), in code review. One problem -- preview doesn't work in no-JS. We'll have to refactor that -- should he do that work? S asks: can we remove the button and pretend it doesn't exist? For G-10 -- only 1 and a half tables have been migrated so far. so that's going to require a lot of other people's work, might be a month. Danny says don't oppose the extra G-3 work -- S will create a card. *Jon*: Yesterday -- a meeting about Wikifont. He'll send an email about it soon. Started working on bug for flash of content for mobile, but putting it off for now to work on G-4 - Dont' collapse closed topics. Wants to work with Shahyar on handlebars stuff -- what should he do about the code freeze? S says we can not +2 them *Matthias*: G-7 & G-8: Revived old WIP search patch, rebased for current. Has some questions about what we're doing with search that Danny needs to answer. *Shahyar*: Today - working on G-11 modal dialog box prototype for Hide, Delete, Suppress. He'll send an email explaining his approach. *Benny*: Looking at bug for Thanks showing UUID. Will sync up with Matthias about Found another bug in Echo -- on the All Notifications page, you don't see Load more button. Also a bug -- visiting a Topic page sometimes doesn't mark as read -- a replication problem. Submitted a patch, hopefully those two can be merged today. Also, Danny found a weird bug yesterday -- "No formatting defined for notification" error messages that aren't being recorded as exceptions. This is a mystery; he and Erik are working on it.

1 0

Flow scrum notes, Tues Aug 26
by Danny Horn 26 Aug '14

26 Aug '14

*Benny*: Mostly code review Worked on redlink problem for older Flow topics -- makes it direct back to the view action. Flow topics shouldn't link to action=edit. Need to run a maintenance script to fix this for all topics created before the Topic namespace was created. (69879) Bug for notifications for "created new topic" doesn't mark as read -- can't reproduce it. (69913) Bug for email notifications for Thanks -- probably already done with Matthias' fix for Thanks notifications *Jon*: G-2 in code review G-12 should be ready to merge We have browser tests for Echo QA: Echo is in code review -- S, please review Working today w Erik on G-3 *Erik*: Working on G-3 (no-JS reply and edit) After that, he'll work on G-10 - Spike for Special page to enable/disable Flow. This should only be a day or two write the whole thing. *Matthias*: Worked on G-2 - i18n for handlebars -- he'll talk to Jon Tomorrow - work on search-related spikes (G-7 and G-8) *Shahyar*: Yesterday -- worked on figuring out ToC UI Wants to change file structure -- will pair up with Jon to figure this out. E-1 bug - Subscribe tooltip in wrong location -- it's done, not breaking tests.

2 1

← Newer
1
...
21
22
23
24
25
26
27
...
51
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE