Talk:Humanizing features

Feedback

Thanks for documenting this.

Having seen some of the mobile experiments around humanizing and these ideas, it seems to me that a few facts are plain: Most of the humanizing work has been done for mobile to date The humanizing work doesn't really have anything in particular to do with mobile The humanizing work will mostly be seen by readers. Mobile readers are minority of our readership. The subtext for those facts is that supposedly it's "too hard to change things on desktop" and "mobile is experimental ground", or similar. Frankly I think that's a cop-out. Early in my team's history, we ran a desktop experiment that nearly doubled (+96%) the amount of readers and editors clicking through to a page's history.[1] We did that in a few weeks, with one completely green developer, no designer, and three (!) inexperienced product managers. Granted, we took down the site once doing it, but my point here is that if that ragtag team can do that on desktop, any one of our teams now can.

Even if mobile should be the only team working on these areas (and I don't think anyone really thinks that, it's just defaulted to that), we have another problem. Building features like a productized version of Jeph's history dataviz directly competes for developer resources with our already completely full to the brim roadmaps. In order to build that, we'd have to form a new team, or hire contractors, or redirect someone's energy.

So here's my request: instead of thinking of a request list of new features or major redesigns of existing features, look at the roadmaps for every team and make a list of how every one of those areas can help make Wikipedia feel more human. Work humanizing in as a design goal across projects,[2] rather than a list of feature requests. This will stop competing for time with other work on our roadmaps, and will get you more traction with these design ideas.

I'm cross-posting this to the Talk page, for posterity. ;-)

1. https://blog.wikimedia.org/2012/07/06/wikipedia-revision-history-experiment/ 2. As an aside... we have a yearly roadmap of features. This year as the UX team has grown, I've heard a little bit of groaning from designers that areas they think are important aren't being addressed. They're probably right, and we just have to live with it because that's how prioritization works. I would like to see the UX team have more say in shaping our yearly roadmaps though. I think something that could be done to complement, rather than compete with, our feature roadmaps is to create a set of clear, simple design goals for the year's work. Things like making Wikipedia more human, fixing typography, introducing sane and consistent controls and use of color. All of these things are design goals that can and are being accomplished across many projects. All you need is a manifesto to tie it all together. ;) This kind of design leadership from the team would be greatly appreciated internally and externally. The product managers and dev leads can't do this, only y'all can

Steven Walling (WMF) • talk 01:19, 31 December 2013 (UTC)

Last edit notifications and "view history" tab

Once there is a "last updated 3 days ago" link, the "view history" tab becomes redundant and less informative. Is there any plan to remove the history tab ? Pginer (talk) 09:44, 2 January 2014 (UTC)