stats.wikimedia.org is visually unattractive (a polite way of saying "ugly"). It doesn't fit in with Monobook or Vector or any of the color schemes used anywhere else on Wikimedia sites. At a minimum, the cream-colored background needs to die.
Version: unspecified
Severity: enhancement
URL: http://stats.wikimedia.org
Assigning to Erik Zatche.
The cream background is a direct reference to our pre-monobook skin <:-)
I don't know how the backend of it currently works (ie. periodically generated static HTML files, or some PHP/Python/whatever backend that pulls data from a database).
If the former I think we should wait untill it's made more dynamic so that styles can be centrally managed. With a more modular approach (eg. an index.php that takes parameter like action, wiki, uselang), and some rewrite rules to make it nice. Which will make creating a design and user interface a lot easier.
eg. something like :
http://stats.wikimedia.org/index.php?wiki=dewiki&uselang=en&view=stats&mode=tables
instead of http://stats.wikimedia.org/EN/TablesWikipediaDE.htm
Could perhaps be rewritten to:
http://stats.wikimedia.org/stats/dewiki/tables/en
(In reply to comment #2)
I don't know how the backend of it currently works (ie. periodically generated
static HTML files, or some PHP/Python/whatever backend that pulls data from a
database).If the former I think we should wait untill it's made more dynamic so that
styles can be centrally managed. With a more modular approach (eg. an index.php
that takes parameter like action, wiki, uselang), and some rewrite rules to
make it nice. Which will make creating a design and user interface a lot
easier.
I think its periodically generated html from a perl script. See http://svn.wikimedia.org/viewvc/mediawiki/trunk/wikistats/ I don't really see how making it dynamic would make changing the output style any easier or harder.
(In reply to comment #3)
(In reply to comment #2)
I don't know how the backend of it currently works (ie. periodically generated
static HTML files, or some PHP/Python/whatever backend that pulls data from a
database).If the former I think we should wait untill it's made more dynamic so that
styles can be centrally managed. With a more modular approach (eg. an index.php
that takes parameter like action, wiki, uselang), and some rewrite rules to
make it nice. Which will make creating a design and user interface a lot
easier.I think its periodically generated html from a perl script. See
http://svn.wikimedia.org/viewvc/mediawiki/trunk/wikistats/ I don't really see
how making it dynamic would make changing the output style any easier or
harder.
Having static files means styling/testing it requires re-running the scripts and see what possible variations there are.
Having it dynamic, object oriented and managed as an output/skin thing makes it a lot easier and the layout will be abstracted seperately from the content.
Right now it would probably mean having to edit bits and pieces of HTML string all over the place.
[mass-moving wikistats reports from Wikimedia→Statistics to Analytics→Wikistats to have stats issues under one Bugzilla product (see bug 42088) - sorry for the bugspam!]
bingle-admin wrote:
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/cards/1389
@ezachte, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?
Not at all! The color was indeed borrowed from other examples. If I remember correctly wikipedia; namespace was colored like this.That's long ago. Right now it serves to identify wikistats pages as such. I have a lot of things on my sizable to-do list (like any of us) that I and others care more about than trivial aesthetics. Of course replacing static html with dynamic content is another matter. But the trigger for this bug was background color. As for dynamic content I expect innovation will happen outside wikistats and its role will diminish.
Can we please fix https://phabricator.wikimedia.org/T93702#1146743 ? If the files were in the repo that would make it possible to also help with this and other open tickets.