Porting Modal UI to upstream

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Porting Modal UI to upstream

Dylan Hardison
I think porting the modal UI to upstream is a good thing to do. So I'm
doing that.
it's probably a lot of work. To that end, I've started a branch of the
current trunk to contain and share the effort.

Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins,
and when you force it to (which I have done) it looks bad. So on top
of this work, I've applied Ryan Wilson's Sandstone patch.

Note that I have allowed the upstream port of Bug Modal to allow other
skins to be selected.
Any skins that can't be made to work with it we should probably drop.

Note that with the .psgi support that has landed in trunk, it is
possible to get a local dev environment set up with only perl + cpanm.
I intend to write a blog post about this in short order.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Porting Modal UI to upstream

Dylan Hardison
Woopsy. The said branch is
https://github.com/dylanwh/bugzilla/tree/modal (a branch of a fork, to
avoid cluttering the main repo with what might amount to just be
noise).

On Thu, Dec 24, 2015 at 12:33 PM, Dylan Hardison <[hidden email]> wrote:

> I think porting the modal UI to upstream is a good thing to do. So I'm
> doing that.
> it's probably a lot of work. To that end, I've started a branch of the
> current trunk to contain and share the effort.
>
> Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins,
> and when you force it to (which I have done) it looks bad. So on top
> of this work, I've applied Ryan Wilson's Sandstone patch.
>
> Note that I have allowed the upstream port of Bug Modal to allow other
> skins to be selected.
> Any skins that can't be made to work with it we should probably drop.
>
> Note that with the .psgi support that has landed in trunk, it is
> possible to get a local dev environment set up with only perl + cpanm.
> I intend to write a blog post about this in short order.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Skins (was: Re: Porting Modal UI to upstream)

Gervase Markham
In reply to this post by Dylan Hardison
On 24/12/15 17:33, Dylan Hardison wrote:
> Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins,
> and when you force it to (which I have done) it looks bad. So on top
> of this work, I've applied Ryan Wilson's Sandstone patch.

Before we do a bunch of what may be unnecessary or wrongly-directed work
here, we need to develop a skin strategy. This has come up in a few
meetings.

Currently, Bugzilla ships with two skins - Classic and Dusk.

Users have the ability to choose the skin on a per-user basis. This
means that unless admins have changed Bugzilla to stop users using that
pref, any customizations admins do must be checked with both skins.

Skins, AIUI, do not generally provide additional functionality. They
just look different. I was to suggest that the high cost to us as
Bugzilla developers and to admins of maintaining multiple skins is not
worth it for the user value this generates.

I think we should:

* Keep a skins system
* Ship a single skin
* Remove the user preference for selecting a skin
* Add an admin param to define the skin on a per-installation basis

This preserves UI customizability for admins who want to make Bugzilla
fit in with their environment, but removes the maintenance and
customization burdens for us and for admins who are personally happy
with the default.

So if that logic seems good, which skin should we ship?

1) Dusk. This ships in the contrib directory, and yet became the default
for new installations in bug 259723, nine years ago.

2) Classic. This ships in the "standard" skin location but has not been
the default for a very long time.

3) Sandstone (Mozilla's skin; see
   https://bugzilla.mozilla.org/show_bug.cgi?id=988971 )

Classic seems obviously wrong - we moved to Dusk 9 years ago, why go
backwards?

Remember, we can take a skin and change the colours very easily. We
could ship a Sandstone which looks quite a bit like Dusk; there's no
need to keep the Sandstone colour.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Porting Modal UI to upstream

Gervase Markham
In reply to this post by Dylan Hardison
On 24/12/15 17:33, Dylan Hardison wrote:
> I think porting the modal UI to upstream is a good thing to do. So I'm
> doing that.

Oh and BTW, this is a great thing :-)

> Note that with the .psgi support that has landed in trunk, it is
> possible to get a local dev environment set up with only perl + cpanm.
> I intend to write a blog post about this in short order.

As would that be!

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Frédéric Buclin
In reply to this post by Gervase Markham
Le 29. 12. 15 12:52, Gervase Markham a écrit :
> Skins, AIUI, do not generally provide additional functionality. They
> just look different.

"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. Even Firefox has themes/skins. Even BMO
ships 6 different skins. There must be a reason.


> I was to suggest that the high cost to us as
> Bugzilla developers and to admins of maintaining multiple skins is not
> worth it for the user value this generates.

"High cost" where? How often did you, as a developer, have to deal with
the fact that we ship 2 skins? 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.

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. 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.

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?)


> * Remove the user preference for selecting a skin
> * Add an admin param to define the skin on a per-installation basis

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, or for users with
visual disabilities who require a skin with higher contrast or a
simplified UI or displayed differently to ease readability.


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Frédéric Buclin
Le 29. 12. 15 14:34, Gervase Markham a écrit :
>> "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. :-)

This doesn't mean the cost will be high. ;)


> 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?

Yes, because the custom skin only contains changes made against the
Classic skin. It doesn't need to contain all rules. This is why writing
a new skin is easy: you just edit the few rules you want to change, such
as the background color. For instance, standard/buglist.css is 9.6KB
while contrib/Dusk/buglist.css is only 386 bytes. And
standard/global.css is 19KB while contrib/Dusk/global.css is only 3.7KB.

So even if dylan has to rewrite CSS files heavily in standard/, he only
has to edit a few rules in contrib/ assuming they are still relevant.
This is much less painful than to have to maintain the whole set of
rules again.


> 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?

We certainly want Sandstone, and it certainly could become the new
default skin. As you said, Dusk replaced Classic as the default skin
since Bugzilla 3.2 and so we don't want Classic back as the default
skin. I gave a quick look at the 40 Bugzilla installations I'm watching,
and many of them use their own skin by default, or Dusk (for those
running 4.4 and newer) or Classic (for those running 4.2 and older, i.e.
"obsolete" installations). So if my understanding is correct, there is a
move towards Dusk. So my proposal would be: replace Classic by
Standstone, and make it the new default skin for Bugzilla 6.0 (if done
on time for 6.0, of course). This way 1) skins/standard/ would really be
the place for the default skin, which makes sense, and 2) we could still
offer an alternative to users, aka Dusk (but we would need to see how
the final Standstone implementation would look like to know what to
change in Dusk), and 3) we don't need to support an extra 3rd skin.

LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Gervase Markham
In reply to this post by Gervase Markham
On 29/12/15 14:20, Frédéric Buclin wrote:
> move towards Dusk. So my proposal would be: replace Classic by
> Standstone, and make it the new default skin for Bugzilla 6.0 (if done
> on time for 6.0, of course). This way 1) skins/standard/ would really be
> the place for the default skin, which makes sense, and 2) we could still
> offer an alternative to users, aka Dusk (but we would need to see how
> the final Standstone implementation would look like to know what to
> change in Dusk), and 3) we don't need to support an extra 3rd skin.

That sounds good... however, all custom skins, which will have been
"based on" Classic, will need to be rewritten to be based on Sandstone.
We'll need to warn people.

Still, I can see the merit of this plan.

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Ryan Wilson-9

Since I've already been through a lot of the work on Sandstone, I'm willing to put in the time for the new standard skins.


On Sat, Jan 2, 2016, 8:25 AM Gervase Markham <[hidden email]> wrote:
On 29/12/15 14:20, Frédéric Buclin wrote:
> move towards Dusk. So my proposal would be: replace Classic by
> Standstone, and make it the new default skin for Bugzilla 6.0 (if done
> on time for 6.0, of course). This way 1) skins/standard/ would really be
> the place for the default skin, which makes sense, and 2) we could still
> offer an alternative to users, aka Dusk (but we would need to see how
> the final Standstone implementation would look like to know what to
> change in Dusk), and 3) we don't need to support an extra 3rd skin.

That sounds good... however, all custom skins, which will have been
"based on" Classic, will need to be rewritten to be based on Sandstone.
We'll need to warn people.

Still, I can see the merit of this plan.

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Ryan Wilson-9
I've started the process of converting Sandstone to replace Classic, but I wanted to pose a question before I got too far into the process:

Since Dusk will remain as a built-in custom option, are we okay if Dusk inherits some of the style design of Sandstone? If not, Dusk will become much larger, as it will need to inherit most of the CSS from Classic.

On Sat, Jan 2, 2016 at 8:41 AM Ryan Wilson <[hidden email]> wrote:

Since I've already been through a lot of the work on Sandstone, I'm willing to put in the time for the new standard skins.


On Sat, Jan 2, 2016, 8:25 AM Gervase Markham <[hidden email]> wrote:
On 29/12/15 14:20, Frédéric Buclin wrote:
> move towards Dusk. So my proposal would be: replace Classic by
> Standstone, and make it the new default skin for Bugzilla 6.0 (if done
> on time for 6.0, of course). This way 1) skins/standard/ would really be
> the place for the default skin, which makes sense, and 2) we could still
> offer an alternative to users, aka Dusk (but we would need to see how
> the final Standstone implementation would look like to know what to
> change in Dusk), and 3) we don't need to support an extra 3rd skin.

That sounds good... however, all custom skins, which will have been
"based on" Classic, will need to be rewritten to be based on Sandstone.
We'll need to warn people.

Still, I can see the merit of this plan.

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Frédéric Buclin
Le 02. 02. 16 21:19, Ryan Wilson a écrit :
> Since Dusk will remain as a built-in custom option, are we okay if Dusk
> inherits some of the style design of Sandstone? If not, Dusk will become
> much larger, as it will need to inherit most of the CSS from Classic.

Which style design do you have in mind?

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Dylan Hardison
In reply to this post by Ryan Wilson-9
On Tue, Feb 2, 2016 at 3:19 PM, Ryan Wilson <[hidden email]> wrote:
> I've started the process of converting Sandstone to replace Classic, but I
> wanted to pose a question before I got too far into the process:
>
> Since Dusk will remain as a built-in custom option, are we okay if Dusk
> inherits some of the style design of Sandstone? If not, Dusk will become
> much larger, as it will need to inherit most of the CSS from Classic.

You can do what you think is best to make Sandstone the default and
base. If Dusk has to change for this, go ahead and do it.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Skins

Ryan Wilson-9
If the changes don't compromise the overall aesthetic of Dusk, I'm thinking about keeping them in. However, if a specific Sandstone pieces make it an eyesore, I'd overwrite on Dusk with Classic styles. Basically, I'm trying to keep size down and the .gitignore file untouched, if possible. 
On Tue, Feb 2, 2016 at 2:38 PM Dylan Hardison <[hidden email]> wrote:
On Tue, Feb 2, 2016 at 3:19 PM, Ryan Wilson <[hidden email]> wrote:
> I've started the process of converting Sandstone to replace Classic, but I
> wanted to pose a question before I got too far into the process:
>
> Since Dusk will remain as a built-in custom option, are we okay if Dusk
> inherits some of the style design of Sandstone? If not, Dusk will become
> much larger, as it will need to inherit most of the CSS from Classic.

You can do what you think is best to make Sandstone the default and
base. If Dusk has to change for this, go ahead and do it.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=theycallmefish@...>