Skins

[Gervase Markham]

On 29/12/15 12:48, Frédéric Buclin wrote:
> "just look different" is what skins are about, yes. The reason we ship
> two skins is because not everybody like the Classical skin, and not
> everybody like the Dusk skin. 

I am sure people express preferences; we have to balance the engineering
effort and admin effort required to indulge those preferences against
the level of user benefit it brings. I agree the user benefit is
non-zero (although it might be less if we had one skin which we made a
good job of and which could appeal to a wider group, rather than
dividing our efforts).

> Even Firefox has themes/skins. 

Firefox recently deprecated its heavyweight theming system ("complete
themes") precisely because of the maintainability burden. It retains
"themes" (which used to be called "personas"), but these are basically
just a single background image which goes behind the toolbar. That level
of complexity is fairly easy to support.

> Even BMO
> ships 6 different skins.

Actually, AIUI the BMO team only really support Sandstone, and are
thinking of formally dropping support for the other skins. The new modal
UI only works with Sandstone. Perhaps someone from the team reading this
list can comment?

> "High cost" where? How often did you, as a developer, have to deal with
> the fact that we ship 2 skins? 

Well, when Dylan is working on porting the bug modal UI, he's going to
need to deal with it. :-)

> As admin, the cost is zero. If you made
> customizations which do not play well with one of the skins, you just
> have to turn off this user pref and that's it. All users will be forced
> to use the skin selected by the admin.

Except that if the admin doesn't test with the other skin, users who use
it see breakage and they don't know why. They might report it (or they
might not) and after he's debugged it and worked out that it's the skin,
he then has to work out that it's possible to withdraw the skin option
and do it, and _then_ he has to deal with the annoyed users.

> Shipping 2 skins has been a real plus for us. It forces us to think if
> the Classical skin (the one currently in skins/standard/) doesn't
> prevent custom skins from working correctly. For instance, we learned
> that "!important" should be avoided as much as possible, else it would
> take precedence over custom rules. 

Give me a quick refresher: you are saying that if someone invokes a
custom skin, we load _both_ the Classic and the custom skin's CSS?

> Keeping only one skin will inevitably
> trigger such problems in the future. So IMO, a valid reason to keep only
> one skin would be because this skin is great enough that everybody like
> it, not because developers are too lazy to maintain a 2nd skin.

Let's say for a moment that the group concludes you are right. How does
Sandstone fit in? Do we want it, or not? If we do, do we ship 3 skins,
or do we drop one? If we drop one, which?

> Another point: it's currently very easy to write your own skin because
> you can imitate what is in contrib/Dusk/*.css. You can easily clone it
> in e.g. contrib/Foo/ and start playing with CSS files there. If we
> remove the 2nd skin, will the whole skins/contrib/ directory go away? If
> not, how to avoid the confusion between skins/contrib/ and
> skins/custom/? (and do we really still need skins/custom/, to begin with?)

Another good question. "Contrib" in Bugzilla speak is supposed to mean
"OK, we ship this in case it's useful, but we don't support it". That's
clearly not true of Dusk.

> This brings no value, and doesn't make anyone's life easier. If an
> installation has only one working skin, then the admin can already force
> all users to use it. If there are several working skins, I see no reason
> to force everybody to use the same skin. I could even imagine that some
> skins are better suited for smartphones/small screens, 

Our default skin should be suitable for these use cases.

> or for users with
> visual disabilities who require a skin with higher contrast or a
> simplified UI or displayed differently to ease readability.

These things are much better dealt with by using accessible web design
(for everyone) and letting the disabled user's user agent work out how
best to present the information to them. We can't second-guess the
requirements for everyone.

Has anyone ever built a skin for Bugzilla focussed around the needs of
disabled users?

Gerv