Below is a link to a presentation called "WikiProject Medicine for Medical Education". Two of the people mentioned in this presentation are Ocaasi (Jake Orlowitz) and Jmh649 (Dr. James Heilman, MD, CCFP-EM). Quote from http://outreach.wikimedia.org/wiki/Education_Portal/Newsletter/Newsroom: "Big news, UCSF has proposed a 4th-year medical elective, for
credit, in which students would choose and improve a medical topic on
Wikipedia. This is the first medical school education project we have
heard of, ever!" Although this was first annou
Here's a link to a presentation which was just noted on the Outreach wiki: https://www.dropbox.com/l/IlZ2gDoenHOttj9QJkBG19
This looks awesome.
Pine
I put together a proof of concept showing how to use the UserMetrics API to generate project-level engagement metrics dashboards. Think of it as the equivalent of the TAE dashboard from the WMF reportcard, but:
(1) obtained in (virtual) real time via the UserMetrics API
(2) using an arbitrary metric among those available in the API.
http://toolserver.org/~dartar/dashboards/metrics/threshold/
(Note: the toolserver has the hiccups again, I attach below a screenshot if you can't load this URL)
How do I read these graphs?
The first graph represents a project's overall new user activation rate, or more precisely the proportion of daily registered users completing at least 1 article-namespace edit within 24 hours of registration. The second graph represents the absolute number of new users hitting the 1st edit in 24h threshold each day.
We extensively use the 1-edit/ns0/24 threshold metric in E3 as an indicator of new editor engagement at experiment-level (typically for cohorts of a few thousands users), but the same metric can also be calculated for the whole population of new users registered in a Wikimedia project in a given timespan.
What story do these graphs tell?
New users on the German or Dutch Wikipedia have a much higher activation rate (28.7 -28.9%) compared to the English Wikipedia (27.2%, i.e. a pretty large 6% average difference) in this 8 day period. Conversely, other projects (like zhwiki) have a much lower new user activation rate (11.4%).
In absolute terms (second graph), the Spanish Wikipedia outperforms the German Wikipedia, adding every day twice as many 1-edit threshold hitters than the Germans, despite having only half its new user activation rate.
How were these graphs generated?
You heard that UserMetrics can compute cohort metrics. In fact, there's a magic cohort named "all" which computes a metric for all new registered users in a specific period.
The data for these dashboards was generated for each of the top Wikipedias using requests like the following:
https://metrics.wikimedia.org/cohorts/all/threshold?time_series&aggregator=…
The query took less than a minute to compute the threshold metric for about 31,500 users registered on enwiki in 8 days.
Are these dashboards refreshed daily?
No, this is a static proof-of-concept, but it's trivial to set up scripts to refresh this data.
What other project-level dashboards can I generate?
Try new metrics:
instead of the activation rate you can visualize the 24-hour revert rate for all new registered users, day by day
Change time slices:
maybe you want to extract activation rates by hour, or by week or by month. You can do this by manipulating the time slice size
Change metric-specific parameters:
instead of the 1-edit threshold, you can visualize the proportion of 24-hour 5+ threshold hitters
you can limit the metric to the Article and User namespaces, or any arbitrary namespace
you can measure threshold hitters in 48 hours or 7 days since registration
Change aggregator
we build daily aggregates by measuring a method that returns the proportion of threshold hitters, but you can use any of the available aggregator functions, for example visualize the mean or the median 24-hour revert rate
Change the group-by method
this example groups users by registration date and calculates the proportion of 24-hours hitters for these daily groups. You can also group by activity and look at how many users, regardless of when they registered, reach the threshold (or any other metric) within each 24-hour slice
Are you suggesting we should replace TAE as a key metric?
No, I am suggesting that we can now easily complement that single, monolithic metric with more granular metrics that can help us gauge how different projects perform at engaging and retaining new users.
Known issues
Computing project-level metrics consumes a lot of resources, the usage of the "all" magic keyword will need to be restricted (so that regular API users cannot trigger it). Stability issues for these computationally intensive requests also need to be addressed.
Hope this gives you a sense of the data that can be generated by the API, let me know if you have any questions.
Dario
Hi everyone,
For those of you using or planning to use guided tours, I just wanted to
let you know about a small but key change to the user experience.
Currently, you can close a tooltip via a variety of methods (ESC, click
outside, etc.) but to end the tour, we made you explicitly check a box that
said "end tour". This is the version deployed currently, if you want to try
it via the test tour etc.
As part of our usability testing for the next version of Getting Started +
a guided tour, we found that method to be too heavy-handed, and that we
were essentially doing it to make it harder to end a tour. Part of this was
out of a fear that users would accidentally end a tour too quickly, when
all they wanted to do was close a single guider.
Going forward, we removed the "end tour" checkbox in favor of simply having
the [X] button end the tour. You can see what this looks like and get more
info at: mediawiki.org/wiki/Guided_tours#Description_of_guider_elements
Many thanks for feedback from Pau, Vibha, and Matt on this change.
Hopefully this will be simpler and cleaner for everyone who might use
guiders.
--
Steven Walling
https://wikimediafoundation.org/
Hey great work!
Two constructive visual comments.
I think the 'see more' bar with the jagged edges looks a bit tattered. I
would prefer something round or square or a triangle edge.
My big issue with the liquid threads model and through to this prototype is
how vertically inefficient they look compared to standard existing talk
pages. I'd like to see if we could tighten up the spacing, move buttons,
etc. to make each comment more vertically compact. I think this is really
important. Every line that's not fully utilized means more scrolling.
Every bit of spacing that's not really needed means more scrolling.
Looking forward to seeing the rest of the demo evolve!
Jake (Ocaasi)
On Thu, May 9, 2013 at 1:54 PM, <ee-request(a)lists.wikimedia.org> wrote:
> Send EE mailing list submissions to
> ee(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/ee
> or, via email, send a message with subject or body 'help' to
> ee-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> ee-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of EE digest..."
>
>
> Today's Topics:
>
> 1. Re: [Product] [Design] Flow Prototype (Fabrice Florin)
> 2. Re: [Product] [Design] Flow Prototype (Brandon Harris)
> 3. Re: [Design] Flow Prototype (Brandon Harris)
> 4. Re: [Design] Flow Prototype (Luke Welling WMF)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 9 May 2013 09:34:54 -0700
> From: Fabrice Florin <fflorin(a)wikimedia.org>
> To: WMF Product Team <wmfproduct(a)lists.wikimedia.org>
> Cc: "A list for the design team." <design(a)lists.wikimedia.org>, WMF
> Editor Engagement Team <ee(a)lists.wikimedia.org>, Philippe
> Beaudette
> <pbeaudette(a)wikimedia.org>
> Subject: Re: [EE] [Product] [Design] Flow Prototype
> Message-ID: <756B3D12-5322-4427-B4F8-86D2F4C30F0F(a)wikimedia.org>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Brandon,
>
> I just want to say this prototype is **awesome!**.
>
> I have been so busy on Echo that I haven't been able to pay as much
> attention to this prototype as I'd like, but I am really, really impressed
> with all the great progress you've made in recent weeks. It seems
> herculean, both in scope and quality.
>
> Kudos, man!
>
> I hope the community likes it as much as I do.
>
> Look forward to attending the chat today at 11am PT -- and debriefing with
> you on Friday …
>
> BTW, I found it hilarious that you put words in my mouth to show my
> fictional comments history for this prototype -- you were actually really
> close to my character, expressing gratitude profusely, as I'm prone to do.
> So this is as much a work of art as a technical prowess.
>
> Godspeed!
>
>
>
> Fabrice
>
>
>
> On May 8, 2013, at 10:36 PM, Brandon Harris wrote:
>
> >
> >
> > Hello!
> >
> > I have released a new version of the Flow prototype into the wild.
> This will be the version that is discussed during office hours tomorrow.
> >
> > The URL for the prototype has moved. It is now located at:
> >
> > http://unicorn.wmflabs.org/flow/
> >
> > I have also created a page that explains what the prototype is and
> how to use it. I will be updating the release notes there from now on and
> not posting to this list, so you should watch this page for changes:
> >
> >
> http://www.mediawiki.org/wiki/Flow_Portal/lnteractive_Prototype
> >
> > I'll include the latest release notes, though (mirrored on the
> mw.org page):
> >
> >
> > === May 9, 2013 ===
> > * Read posts are now only collapsed in the Feed views
> > * The "+Topic" button now reads "+New Message"
> > * Hide the "New message" button when in feed view
> > * Tag actions no longer work on unsubscribed topics
> > * Author metadata (edit count, etc.) can now be hidden from a tool in
> the sidebar
> > * Posts by yourself now have a blue border instead of grey (h/t to TheDJ)
> > * Added in a "mention" example to the Echo flyout.
> > * Cleaned up the json file for Jimmy Wales' board with regard to post
> depths.
> > * "Reply" buttons changed to mw-ui-constructive (green)
> > * Changed the green color of unread posts to match the reply button
> color (avoid clashing)
> > * Going to a "Feed" view now removes any tabs. Returning to a board
> shows the tabs again.
> > * Taglist section no longer displays if there are no tags
> > * In Feed view, topics on own board no longer include your username
> > * In Feed view, the sort of topics is NOT based on "last update time".
> Instead:
> > ** Topics that you are ''subscribed'' to are sorted by last update time;
> > ** Topics that you are ''not'' subscribed to are sorted by create time.
> > *** This more accurately reflects the behavior when you are subscribed
> to a user but not every topic on their board
> > * Added a new sidebar section, "Back and Forths"
> > ** This gives you a "masquerade" view, so that you can see what the same
> topic will look like from the viewpoints of different users.
> > *** The first is ''your'' view.
> > *** The second and third are the views of two other participants.
> > * In Board view, all topics are expanded by default (for easier
> fast-scanning)
> > * Individual posts can be flagged as "abusive". This is the beginnings
> of a workflow; actual anti-vandalism functionality will require more work.
> > * Removed the "Jorm Board" - it was a redundant view
> >
> > === May 4, 2013 ===
> > * Read posts in any thread are collapsed by default, with an indicator
> to open all of them up.
> > ** Posts are not collapsed if the thread is collapsed
> > ** Collapse sections is an all-or-nothing deal
> > ** You cannot "re-collapse" read posts. Adding a control to every post
> is too heavy
> > ** Collapsing a thread will uncollapse all posts inside of it and remove
> the indicator
> > *** Reopening the thread will expand all posts
> > * On start up, a modal appears asking you for your user name.
> > ** The form saves it and operates as "that person" from then on.
> > ** This is saved to a cookie, which prevents the modal from opening in
> the future
> > **There is a "clear saved username" link on the side.
> > * The feed link now treats itself as if it were the "logged in" user and
> does some replacing on text to imply that the conversations are happening
> with them (and not the original owner of the posts)
> >
> >
> >
> >
> > ---
> > Brandon Harris, Senior Designer, Wikimedia Foundation
> >
> > Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
> >
> >
> > _______________________________________________
> > Wmfproduct mailing list
> > Wmfproduct(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wmfproduct
>
> _______________________________
>
> Fabrice Florin
> Product Manager, Editor Engagement
> Wikimedia Foundation
>
> http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
>
> Donate to keep Wikipedia free:
> https://donate.wikimedia.org/
>
>
>
>
>
>
>
On May 1, 2013, at 3:25 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
>
> * Rudimentary search functionality
> - Loading throbber
> - case insensitive
> - DOES NOT tokenize
> - searches titles, authornames, tags, postcontent
>
> In Firefox and Chromium this is giving me an error: Cannot call method 'match' of null
Should be fixed (s/taglist/\.taglist/);
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On May 9, 2013, at 9:51 AM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> My main complaint is that I'm not sure if indented threading is the way to go; we know we end up with reallly deep conversation threads on these things, and it gets hard to read a few levels in. Pre-collapsing already-read parts of the thread should help a lot in common circumstances, but if you expand it you don't want it esploding.
I've been thinking a lot about this and wrote up several ideas here, including my corollary to Godwin's Law:
http://www.mediawiki.org/wiki/Flow_Portal/User_to_User_Discussions#Thread_D…
Currently, I'm not restricting depth but I think we should after 4 levels.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Honestly, I just want people to leave their feedback as raw and simple as they can on the wiki page that is linked from the sidebar.
Adding overhead process to giving feedback about design results in less feedback. I don't want people to have to read an instruction booklet before they feel like they can tell me if they like or hate something.
On May 5, 2013, at 10:32 AM, Sumana Harihareswara <sumanah(a)wikimedia.org> wrote:
> On 04/30/2013 05:16 PM, Brandon Harris wrote:
>>
>> I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
>>
>> You can play with it here: http://elohim.gaijin.com/flow/
>
> Thanks for doing this - and thanks to everyone for thoughtful praise,
> criticism, and questions. Honestly it might be worth choosing a few
> posts from this thread to link to as examples from
> https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/How_to_give_desi…
> and to use for the feedback template.
>
> --
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On May 1, 2013, at 3:25 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
>
> I think Gmail is a very good model to follow -- they've put a lot of effort into making a good system that handles long discussions, with collapsing of already-read items but it's easy to click through to open them and see more context.
Yeah, I'm trying to get there but the way the HTML is generated makes something like this a SERIOUS pain in the ass.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
I'm responding to everybody in this single mail, but first:
There is a new version at http://elohim.gaijin.com/flow/
This is what's changed:
* Posts are automatically marked read as you scroll through them.
* Unread posts are significantly called out (green headers, experimental - this is fairly obnoxious but you are warned)
* Topic titles are now hot
* Rudimentary search functionality
- Loading throbber
- case insensitive
- DOES NOT tokenize
- searches titles, authornames, tags, postcontent
* Clicking the gear icon now brings up a menu
* Clicking the subscribe/unsubscribe stars now do things
* Clicking the tag icon now opens a small dialog (that doesn't work yet);
* Reply form auto-focuses to the textarea now.
On Apr 30, 2013, at 4:05 PM, Trevor Parscal <tparscal(a)wikimedia.org> wrote:
> First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
>
> A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback.
> • The affordance for expand and collapse (a chevron symbol pointing right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.
I agree; I went with chevrons because they are used in mobile for section expansion and I thought that having a similar theme would be useful.
The first ones I used were . . . "fatter". . . but they felt clunky and blocky so we've got this.
Right now, I've made the entire title "hot" as well so as to increase the affordance size. They should also probably have a hover state to indicate that something is going to happen.
I'm absolutely open for better ideas.
> • I think it's a good idea to be conservative about how many buttons to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).
The "Collapse all" button is actually there for ease-of-use in the prototype. I'm not really thinking it should make it into the final product because, as you said, the concept of "all" doesn't make a lot of sense in the context of a lazy-loaded, infinitely scrolling discussion system.
On Apr 30, 2013, at 4:56 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> A few more notes:
> * the collapse/expand is only available at the top level, which can make it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content
So, this is what LiquidThreads does, and maybe we should revisit it. I worry, though, that having *too* many controls will be difficult to handle.
One possible solution to this (which I will prototype up) is to:
a) Automatically collapse read "branches"
b) Only provide a control to *expand* those posts (and it would expand all posts in the branch (so you don't have to do the horrible Quora style "click to open each comment)
> * the appears-on-hover "(board * contributions)" links are hard to discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)
Jah. Erik asked that I provide minimal information and only do selective reveal, which isn't mobile-first but we're trying to illustrate concepts here rather than final functionality.
> * I really want the entire thread title to be clickable as expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :)
Done.
> * The input box should probably expand to fit longer input paragraphs, if possible (at least up to some reasonable size). Right now it's hard to edit a long response.
I'm doing some experiments with auto-sizing textareas but I'm not happy with anything I've gotten so far.
> * Paging or infinite scroll need to be planned for for really long talk pages.
Infinite scroll is the Plan™.
> I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.
See above comment about collapsing.
Right now, I'm using a very obnoxious green header for each unread post. I do not expect this to last, but you DEFINITELY know if it's read or not.
On Apr 30, 2013, at 5:06 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> My understanding from talking to Brandon earlier is that unread parts
> of the thread have a green vertical border right now, like the
> comments in the first example thread in
> http://elohim.gaijin.com/flow/ , and the idea is to make that fade out
> as you scroll over them (not yet implemented).
This is now implemented, but I'm not sure of the "action" yet. I'm using a library called "waypoints" and it works but there are lots of variables we can tweak.
On Apr 30, 2013, at 10:02 PM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote:
> On a more general note, I'm still not sure I grok the board/feed distinction – I was thinking that new stuff would appear in your feed, and all stuff you follow would appear in your board, but that doesn't look to be the case.
More like the opposite:
Feed: Stuff you follow
Board: Stuff about you and your activity
> This is also a big problem I have with the concept behind LiquidThreads – if I'm already following pages on my watchlist, which is kind of my de facto feed, I really don't want to visit a separate "new messages" page unless it actually shows me a roll-up of all new messages related to those pages (as opposed to basically the full threads of three-year-old discussions, with one or two new messages buried somewhere in the middle). I'm also not sure how the watchlist is going to interact with Flow, given that, in essence, it's serving many of the user needs that Flow is trying to solve for (albeit in a weird, suboptimal way) at the moment. Have you done any thinking about how to delineate these features more clearly?
>
> Lastly, the feed/board distinction (if I'm understanding it correctly) seems much more useful for when all discussions (village pumps, articles, the glorious future when messaging goes cross-project...) are Flow-enabled, not just user talk. Then there's an obvious need for seeing the stuff I may be semi-passively following from various scattered discussions on one view, and having a separate view for really important stuff directed specifically at me. Having two different views for just user-to-user messaging, though, feels too heavy to me. Why not just one for now?
Actually, the feed solves for two very distinct use cases that are not addressed by the board:
1) Conversations occurring across multiple talk pages
2) Tracking conversations that you are involved in on other people's talk pages
While I had originally spent a lot of thought on the "single board, two viewpoints" solution, in the end having a board/feed model made more sense to me because:
1) User talk pages already *kind of* match the "board" model (and mapping contributions into it isn't that much of a leap)
2) Most people are used to the concept of "my stuff" versus "the stuff I'm following", even if there are many ways this is done:
Facebook has a "Profile" and a "Feed"
Twitter has a "Profile" and a "Stream"
LiveJournal has a "Journal" and a "Friends Page"
etc.
3) We can probably roll out easier. We give *all* users a Feed, but then users can selectively "upgrade" their talk pages to "Boards". This gives users flexibility as to when they move into the Bright Future.
On May 1, 2013, at 12:53 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> When clicking save the text under is very wordy. I wonder if this could be collapsed somehow
This is a requirement from legal. There's no real way around it.
> pps. the be nice placeholder is a lovely touch. A subtle reminder of the community we want/ need to foster.
Kind-of-not-quite "accidental". :)
On May 1, 2013, at 4:01 AM, Mathieu Stumpf <psychoslave(a)culture-libre.org> wrote:
> When you click reply, you should directly have the textfield focused.
> Also within the textfield pressing tab should let you switch to the save
> button, then the cancel button, with a highlight which let user know
> which element is focused.
I've got the textarea focusing but there's some goofiness I ran into with handling tabindex on the other elements. I'll see what I can do about it but at the end of the day this is only about half as powerful as it will be when it is truly backed by a server-side system.
> Always reducing the box with a bigger left margin is not great for very
> deap threads. I have no perfect solution to give instead those said.
> Maybe having a "box-min-size" test that will change the comportement
> when reached, for example you may go back to a bigger box but with a
> right margin and using right box borders to let users follow the flow.
Right now, I'm not applying any logic to how deep the branches can go. I've got an exhaustive analysis of branch depths located at mw:Flow Portal someplace; I think the final layout is going to be "branch in for 4 levels, and then go 'flat'" but I wanted to get it out in an easy state first.
Applying this kind of functionality WILL have an effect on the conversation style and norms but I don't think that's a bad thing.
> I think tags/subscribe/other icons should be more spaced.
This should be easy to do.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate