Your email client seems to have mangled the indenting for some reason,
so I tried to repair it. Apologies if I've messed anything up in the
process.
On 15/11/15 09:47, Jon Robson wrote:
On 15 Nov 2015 2:31 p.m., "Isarra Yos" <zhoris...@gmail.com> wrote:
I agree that it's important to move away from desktop-first, but switching to
mobile-first isn't the answer either.
Why not? Whats wrong with a fixed width centered site? Old phones do not
have media query support nor do they have ability to support conditional
statements.
It doesn't work for MediaWiki. As a product, it is too complicated, has
too many modes and tools, to effectively communicate to the user what
they can and cannot do using only simple styles. (I assume you mean
max-width, since just fixed width doesn't work on mobile anyway.)
When you have more space, you can tell them more. When you have less
space, you need to use other affordances to tell them things, and hide
links and tools behind menus, but this adds to the steps required for
both discovery and use, and should only be done when you have no other
options. For desktop users who actually do have the space to lay the
important things out, having everything hidden behind buttons and menus
is simply not fair - or useful.
For complex products (discussion boards, skins, anything that could benefit
from a lot of space), there are going mobile-specific styles same as any
other resolution - do ANY as the 'main', and you're having to undo and
override those styles on every other one, which results in unnecessarily
complicated and large code, which just makes it all that much harder to
maintain and work with.
As an example, this is an important part of why it's been so hard to make
Vector properly responsive - so many of the desktop styles needed to be
overridden in order for any mobile design
to be applied. (This would have applied in either direction because its
desktop and mobile layouts are so completely different.) But suppose that
same step had been replaced with instead separating out the desktop styles
into a separate stylesheet for a similar amount of effort, and with each as
separate, independent stylesheets - code for both desktop and mobile would
be made cleaner, and far easier to iterate upon.
This will never happen. True mobile development is a lot more than moving
around styles.
True mobile development is nothing more than developing for mobile. You
lay things out and use the tools mobile affords - same as any other
platform. You just need to actually do this for ALL your platforms.
Including mobile. Including desktop. Including screen readers.
For example the current responsive vector skin that exists
in an experimental state sits at the bottom of the page which is a dead
zone. I'm yet to see any good examples of this done well.
What exactly do you mean? Is this a bug in the implementation in which
the entire skin shows up off the page on mobile or something?
Or are you referring to the navigation? Because yes, that definitely
needs work. I was under the impression nobody had actually gotten to
that part yet; my point was more that the skin now renders on mobile in
a legible fashion at all, which was previously not the case with the
sidebars and tabs and whatnot.
You want a responsive skin though. What you are describing is not one. A
responsive site uses the same stylesheet for both desktop and mobile.
'Responsive', in reference to websites, means that the site layout
responds to and renders well regardless of the size of or device type on
which it is displayed.
A single set of styles for everything can be made to work (or even no
styles, technically speaking - just look at motherfuckingwebsite.com),
but also introduces serious limitations in terms of what can be done for
each, which in particular poses problems for MediaWiki for the reasons I
explained above (yes, you can still do it; it's just not exactly
optimal). But the fact of the matter is that the entire reason @media
size queries were introduced in the first place was mitigate this sort
of thing by allowing for more specific styles to be employed, optimised
for the different displays and taking full advantage of their different
features. This is exactly what it is for, and we should be using it for
this.
(People wanted me to iterate on what's there now and I couldn't even figure
out where to begin. Not that I'm that good at CSS in the first place, but
that code is scary.)
What we need to do is get better at distinguishing and leveraging the
common styles, and using common variables and mixins, because this is how
you make consistent overall styles and also simplify the overall thing.
Then build these into something that works for each platform.
And if we're going to support stupid broken things, we need to explicitly
support them with some sort of fallback that doesn't require a lot of
manual rejigging. I'm not sure IE8, as an ancient desktop browser, getting
mobile styles is really any better than an ancient mobile browser getting
desktop styles.
Why not?
Effective mobile navigation on a platform of this complexity almost
exclusively requires javascript to function due to the extremely limited
space it must be optimised for. This includes popups, accordion menus,
expanding sections, anything where the content is initially hidden and
only made visible upon user action.
IE8 will soon not be served javascript.
Other experts in the field far more qualified than myself think so.
For example
https://stuffandnonsense.co.uk/blog/about/the-guardians-take-on-mobile-first-responsive-web-design-and-ie8
There are countless more if you Google.
Does the Guardian use the same interface for authoring, editing and
publishing as it does for reading? Does the Guardian only serve js to IE9+?
Those experts are discussing what applies to them, but we have our own
use cases, our own problems. What works for others will not necessarily
work for us because we are doing different things. But we can still look
at and learn from these other things; we just also need to consider why
they did what they did and whether those reasons apply to us. We can't
blindly follow others, in other fields, when we are the pathfinders in
our own field.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
