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.
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
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
>
*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
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
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
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.
*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.
*Shahyar*:
working on G-4 - modal dialog
Jon is concerned that a spike turned into an implementation
Shahyar will send an email about it
Shahyar & Jon need to talk about G-5 (spike-ish: mw-ui standardization) to
decide what work needs to be done.
*Jon*:
Friday -- working on i18n patches
Jon and Matthias have overlapped -- Jon did G-2 and G-12, Matthias did i18n
(Infinite scroll defaults language to English. Jon will sort it out -- we
should watch more closely that we're not overlapping sprint work with bugs.
*Erik*:
working on G-3 (reply & edit in no-JS). General concept is done, needs to
touch base with a couple people about it.
*Benny*:
Friday - code review, and worked on patches to fix display of title on post
diff page
Unit tests for timestamp
Confused about bug - Flow is creating notification links that go to
?action=edit