On 17 jul. 2012, at 21:23, Jon Robson wrote:
The way we deal with main pages on mobile is a big
mess in my opinion.
It also seems during Wikimania that various people share my view on
this. We should show the same content on mobile as on desktop and stop
special casing it (There's a bug about this -
https://bugzilla.wikimedia.org/show_bug.cgi?id=30405)
Agreed
I think the problem here is we'd need to clean up
every MediaWiki
homepage in existence so that they do not use inline styles and have
mobile specific styles as otherwise if we stop special casing the main
page these pages will appear broken.
Yes this is the problem.
I would suggest we
1) set a deadline for a switch over where we stop the special casing
on the main page - we can work together during that day to ensure
pages are mobile ready 2) we change the code so that a querystring
specialcase=no shows what the main page will look like after the
switchover
3) community works together to move inline styles into a stylesheet
e.g. MediaWiki:Common.css and alter homepages
I don't see this as a requirement. We just need to provide alternate CSS and HTML
layout (without fundamentally breaking IE6) and it needs to be implemented.
4) we turn of the special casing on the deadline date
5) we deal with broken main pages on a case by case basis.
I've added a note saying the above here:
http://www.mediawiki.org/wiki/Deprecating_inline_styles#Deprecating_inline_…
If this seems like a good course of action I'm happy to coordinate.
Please reply suggesting how much of a timeframe for such a switchover
would be necessary and of course speak up if you object strongly.
I still don't agree with your comments on removing inline styling. If we move all
inline styling we have on en.wp, we will have a style file of over 1 MB easily. We need to
be more sensible about it.
Portal styling is arguably one of those things used on only about 15 pages per wiki. There
is no point in having it globally. At most there is a point in having a separate
stylesheet for those 10 pages, though that leads to cache fragmentation and slower loading
times I fear. (I can see a use for cache fragmentation over namespaces, because most
readers never get out of main space, but other than that, you never really want to
fragment the cache of mainspace much I think).
For years the en.wp community has tried to specifically keep certain styles inline if they
are used infrequently (anything under about a 100 transclusions) simply to keep connection
and download size per page per reader somewhat consistent and usable. That styling is
usually captured in templates for easy switching, and everything has id's and
classes.
Yes this system is now also reaching it's limits, but it means we need to be smart and
take into account WHY we use inline styles, and for en.wp it's because bytes do add
up. After weeding down several css filesizes in 2010, the difference was measurable (both
in parsing and visually). Yes connection count was a worse problem, and RL does solve some
of that, but size also does add up. Never forget how extreme the english wikipedia is in
size.
Perhaps we need transcluded internal stylesheets for these kinds of pages, so only pages
that need this css get this css.
DJ
On Mon, Jul 16, 2012 at 7:09 PM, Philip Chang
<pchang(a)wikimedia.org> wrote:
Ok, good feedback. To some degree this is
determined by the admins of each
language, though in English we exercised some discretion.
Copying mobile-l to see if this generates more discussion.
Phil
On Mon, Jul 16, 2012 at 6:51 PM, Imzadi1979 <imzadi1979(a)gmail.com> wrote:
On Jul 16, 2012, at 2:02 PM, Philip Chang wrote:
Thanks for your feedback. It was a conscious choice to include only TFA
and ITN, because of the restrictions of mobile screens.
Do you feel strongly about any of the other content you mentioned?
Phil
On Mon, Jul 16, 2012 at 4:55 AM, Imzadi1979 <imzadi1979(a)gmail.com> wrote:
Just a quick comment, but the display of the Main Page only shows TFA and
ITN. What about DYK, OTD, TFL and TFP?
-Imzadi1979
_______________________________________________
Mobile-feedback-l mailing list
Mobile-feedback-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-feedback-l
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810
Well, that's only 40% of the sections of the real Main Page (33% on
Mondays). I'm sure the people who work hard to get TFP and TFL would be
upset knowing that their hard work is only visible on computers and
third-pary apps, not the one app that carries the WMF "seal of approval".
Sorry, but I don't buy the "restrictions of mobile screens" argument when
Wikipanion or Wikiamo, two apps I downloaded before the "official" app was
available, show the whole Main Page. In short, the Main Page isn't the Main
Page without all of its sections. The other apps don't display it as
gracefully as possible, but they do show all of the sections.
Imzadi1979
imzadi1979(a)gmail.com
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l