| Raymond | |
| Jan 8 2014, 8:14 AM |
| F12407: VectorBeta-Diff.PNG | |
| Nov 22 2014, 2:29 AM |
| F12408: VectorBeta-MainPage.PNG | |
| Nov 22 2014, 2:29 AM |
Screenshot
On Wikimedia Commons I see a change in the wrong direction today: #bodyContent : max-width: 715px is a waste of space on wider screens
Category pages: Longer subcategory names are hard to read
Version: unspecified
Severity: major
Attached:
This is a high importance bug — the behaviour has been reported multiple times on multiple wikis since yesterday.
Just for the records, quoting https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=589770179#Typography_refresh_beta_feature :
"Placing a maximum width on page contents of 715px. It is widely accepted that text columns with a line length which spans the entire width of a (desktop or laptop) screen are not ideal for reading/scanning. The max width will not apply to Special pages (like Prefences) or to actions on an article, like viewing history."
This may be so but it is not a bug it was intended as you can see on the village pump post above.
I suggest documenting your concerns here where they will get more attention for the next iteration of this experimental Beta Feature:
https://www.mediawiki.org/wiki/Talk:Typography_refresh
A stupid design decision doesn't make for an invalid bug. Bugzilla is where bug reports go. This is an obvious bug, if for no other reason than the "TYPOGRAPHY REFRESH" is affecting layout, as discussed on the design mailing list.
As a side note, I think it's pretty disrespectful to waste volunteer time by forcing users to complain about a change on a MediaWiki.org talk page when you know this will be reverted.
Apologises Raimond if I seemed disrespectful. I do believe there is an issue here, and it is already being discussed on the talk page and I am very grateful that you posted your concerns there so that they get the desired attention. I suspect the change will either be reverted or adapted based on the collective feedback.
MZ. Congratulations. You continue to annoy me by reopening bugs and I am slowly losing my respect for you. Unless you plan to become more involved in developing this BetaFeature and constructively helping with maturing it I kindly ask that you stop reopening bugs.
I reiterate, this is not a bug as it is by design.
On a side note, Andre/James/Steven/Jared is it possible to have me removed from the default cc for the VectorBeta extension and/or remove the VectorBeta extension. It causes nothing but noise to me when all other parties working on this extension are solely looking at the talk page.
When bugs like this are reopened it seriously hampers my productivity and attention. As discussed many a time I would like this BetaFeature to be solely discussed on the talk page and multiple places for discussion does not help this.
cc'ing James, Jared and Steven so you are aware of this source of annoyance to me.
swalling wrote:
(In reply to comment #8)
I reiterate, this is not a bug as it is by design.
To expand on what Jon said...
So in other words, this isn't a bug. Nothing is broken. It's an aesthetic disagreement. Please put feedback about the typography Beta Feature on the Talk page (https://www.mediawiki.org/wiki/Talk:Typography_refresh) where there is already discussion about this and the other recent changes.
(In reply to comment #8)
On a side note, Andre/James/Steven/Jared is it possible to have me
removed from the default cc for the VectorBeta extension and/or
remove the VectorBeta extension. It causes nothing but noise to me
when all other parties working on this extension are solely looking
at the talk page.
(To continue on the offtopic)
This seems a little excessive, no? We can have the component
description updated instead; it will certainly be better than killing
it and leaving people with no instructions as to where to comment on
stuff.
(In reply to comment #8)
Jon: I'm not sure why or how you think it's any more appropriate to waste my time. I've now filed bug 59854. Thanks.
(In reply to comment #10)
(In reply to comment #8)
On a side note, Andre/James/Steven/Jared is it possible to have me
removed from the default cc for the VectorBeta extension and/or
remove the VectorBeta extension. It causes nothing but noise to me
when all other parties working on this extension are solely looking
at the talk page.(To continue on the offtopic)
This seems a little excessive, no? We can have the component
description updated instead; it will certainly be better than killing
it and leaving people with no instructions as to where to comment on
stuff.
{{Done}}
The default CC is now set to me and Jared, and there's a note in the component description asking for concerns to be preferentially raised on the talk page of each feature first.
(In reply to comment #8)
I reiterate, this is not a bug as it is by design.
these two things are not necessarily mutual exclusive: something can be "by design" and a bug at the same time.
personally, i think that such a change should, at the least, be accompanied by user preference to select the width, and i also think that the immediate result of introducing this change at this point in time will result in many people turning off the "beta features", which, ultimately, is counterproductive.
please consider separating the screen-width-limit choice under "beta" to an independent choice, instead of it being part of "Typography refresh", so people who do not wish to use this feature will still be able to test the other parts of "Typography refresh".
peace - ~~~~
swalling wrote:
(In reply to comment #15)
personally, i think that such a change should, at the least, be accompanied
by
user preference to select the width, and i also think that the immediate
result
of introducing this change at this point in time will result in many people
turning off the "beta features", which, ultimately, is counterproductive.
We're probably not going to do this. Adding sub-preferences on top of the preference to opt in to a beta feature is too excessive.
It's actually *okay* if people turn off a beta feature because they don't like it. That's just as helpful in terms of feedback as leaving a comment or filing a bug. If we revert any part of a beta feature and do a new release, we can always notify people and get them to give a try again.
please consider separating the screen-width-limit choice under "beta" to an
independent choice, instead of it being part of "Typography refresh", so
people
who do not wish to use this feature will still be able to test the other
parts
of "Typography refresh".
Potentially doing a separate beta feature for major navigation and layout changes in Vector is not a bad idea. But we probably won't do it just to set or unset the single "max-width: 715px" CSS rule.
web1 wrote:
I'm afraid this is a bug, that is to say, a technical error, not simply an aesthetic disagreement. Independent of the aesthetic (and/or readability) benefits of narrower paragraphs, specifying a max-width of 715px on #bodyContent is a technically incorrect way of producing this effect. First because it narrows too much: it narrows more than just paragraphs of text, for example the two columns in diffs between revisions, and it narrows the whole article width, including the space for floated elements, tables which would benefit from being wider, etc. Second, specifying the width in px is wrong, because we don't know how many pixels relates to a sensible number of characters at the user's chosen font size.
I've explained why pixels, not ems were used here
https://www.mediawiki.org/wiki/Talk:Typography_refresh#What_would_you_change_about_typography_update.3F
If you can suggest a better way to do this than with px that doesn't have the issue i mentioned on the wikipage please suggest it.
bugs are not where stylistic or differences of artistic opinion are best discussed. While we are aware there are pages that this causes issues with, thats fine because it is a Beta Feature, things will break, and thats ok, if it impacts your workflow, leave feedback on the discussion page, and disable the beta feature for yourself.
(In reply to comment #18)
bugs are not where stylistic or differences of artistic opinion are best
discussed. While we are aware there are pages that this causes issues with,
thats fine because it is a Beta Feature, things will break, and thats ok, if
it impacts your workflow, leave feedback on the discussion page, and disable
the beta feature for yourself.
It's difficult to feel sympathy for those who signed up to be guinea pigs, yes.
But there's something to be said for truth in advertising. I don't think the people who signed up for the typography experiment assumed it would include changes of this nature.
And there's something to be said for still treating guinea pigs reasonably. This has every appearance of being a last-minute tack-on to the typography experiment. As _you_ said, doing something like http://simplefocus.com/flowtype/ would be great (http://lists.wikimedia.org/pipermail/design/2014-January/001351.html) and I agree. But that's not what we got....
If you want to test layout changes, make a separate experiment. I've still yet to hear a compelling reason not to do this. Yes, with your approach, you can also gather data about how many people opt out of this experiment, but you're completely needlessly shooting yourself in the foot, in my opinion.
Of course, this has turned into an "us v. them" scenario, yet again, so reason will sit on the sidelines.
(In reply to comment #19)
Yes, with your approach, you can also gather data about how many people opt
out of this experiment, but you're completely needlessly shooting yourself
in the foot, in my opinion.
Let me put it another way: if you treat people like lab mice, I think you'll have a lot of difficulty getting them to trust, appreciate, or respect you when you're not treating them like lab mice. I absolutely think you run the risk of creating a reputation as someone hell-bent on making heavy-handed design decisions and people will have difficulty separating your ideas and actions _as head experimenter on the users_ from your ideas and actions as someone trying to work collaboratively with Wikimedia, the very smart and diverse user community.
Public Service Announcement: Please take personality discussions somewhere else or I'll restrict access. Thanks & cheers everybody.
(In reply to comment #21)
Public Service Announcement: Please take personality discussions somewhere
else or I'll restrict access.
Bugzilla is no place for threats.
(In reply to comment #19)
If you want to test layout changes, make a separate experiment. I've still yet
to hear a compelling reason not to do this. Yes, with your approach, you can
also gather data about how many people opt out of this experiment, but you're
completely needlessly shooting yourself in the foot, in my opinion.
This is actually quite important. Bunching different changes together into the same experiment can easily invalidate the usefulness of the results, and is certainly likely to do so here - because then you have no idea which part was the part that people actually objected to, or which parts were the ones that really made things better. You're left with only speculation and a few isolated specific reports such as this one that are, it seems, easily disregarded.
And to reiterate, just because something was by design does not mean it cannot be a bug. Designs can easily fail in practice despite all good intentions, and often do; it is for this that designers can be afraid to try new things. Is this not exactly what betafeatures was supposed to be for? To serve as a way to safely sort out which things work and which do not...
swalling wrote:
(In reply to comment #24)
This is actually quite important. Bunching different changes together into
the
same experiment can easily invalidate the usefulness of the results, and is
certainly likely to do so here - because then you have no idea which part was
the part that people actually objected to, or which parts were the ones that
really made things better. You're left with only speculation and a few
isolated
specific reports such as this one that are, it seems, easily disregarded.
I think you and MZ are a bit confused about what kind of experiment this is.
This is not an A/B test, and we're not opting anyone in to this by default. We're also not collecting *any* quantitative data beyond how many people have opted in to a particular beta feature.
All of the feedback is qualitative via the Talk page, etc. so it's perfectly fine to bundle many changes together and let people comment about what they like/don't like. That's what's happening, if you look at Talk:Typography refresh on mediawiki.org.
It doesn't really matter how many times you want to reopen this bug. We're not going to roll back a part of the beta that we literally just launched days ago. We're going to collect feedback on it for at least a week or two, then meet again to compile all perspectives on all the latest changes. At that point we'll consider what to retain as beta, what to graduate to stable, and what to throw out. The best thing you can do, if you don't like something about the current release, is to express clearly and calmly why you don't like it on the Talk page. Playing tug of war on Bugzilla is not going to do anything except waste our time.
(In reply to comment #21)
Public Service Announcement: Please take personality discussions somewhere
else or I'll restrict access. Thanks & cheers everybody.
Andre, the attitude that MZMcBride is objecting to here does appear to be quite relevant to the bug, though perhaps there might be better ways to bring it up.
As much as I can appreciate the desire to keep personality issues separate from technical/design issues, the fact of the matter is that these are people making the technical/design decisions and implementations, and people have personalities. Personality issues will at times directly tie into bugs, and trying to deny that won't help resolve the bugs themselves.
(In reply to comment #25)
It doesn't matter what kind of test it is. By lumping things together, you skew results. If part of it annoys people and they opt out because of that, you won't get the same feedback about the rest of it as you would otherwise.
That said, I hope you treat what feedback you do get better than you (collectively speaking) have treated this bug.
(In reply to comment #16)
It's actually *okay* if people turn off a beta feature because they don't
like
it. That's just as helpful in terms of feedback as leaving a comment or
filing
a bug. If we revert any part of a beta feature and do a new release, we can
always notify people and get them to give a try again.
this is a legitimate attitude - it's ok to turn off beta.
however, the whole idea of "beta" is to get feedback, in the form of bug reports from your users.
when viewed in this light, when conducting beta test, it's really the users who get to decide that a certain change (even if it's "by design") should be considered a bug.
if the word "bug" carries with it some emotional load, call it "wrong design decision" or something instead.
Some "Devil's advocating" arguing why this is change is not a good one
the argument that reading very wide columns is not natural and inconvenient is very convincing.
however, the user already has a way to deal with it, without this change: when i read an article on wikipedia (or any other web site, for this matter) on a wide screen, i very naturally change the width of the browser window to the exact width i find most comfortable.
forcing this limit on me feels kind of 90's, where sites would decide for me whether to open a link in the same window (and later, same tab), or open a new one. since all modern browsers support <Ctrl>-click or <Shift>-click which lets the user make this decision herself, it became a faux pas, and sites that still do so are considered to be impolite or downright rude.
this change has the same effect: someone decides for me what's best for me, where i have perfectly useful tools to make this decision myself ("grab the right border of the browser's window, and gently move it leftward until you feel comfortable with the text width").
please consider removing this unnecessary crutch, and let the reader size her content width all by herself.
peace.
About the status of this report, I propose that we keep it open as "Normal - Enhancement", moving the discussion about the topic reported in https://www.mediawiki.org/wiki/Talk:Typography_refresh#max-width:_715px
The maintainers of this beta feature say that the fixed width is part of the experiment and therefore it is not a bug, which is a fair argument. They are also the ones to decide which importance/urgency this report has in the context of their work.
The contributors disliking this feature argue that in any case it is a core issue to be considered in this beta experiment, and therefore this report can't be simply resolved as invalid. This is also a fair argument, considering how things happened. Resolving the bug as invalid can be confused with considering the point reported invalid, bringing unnecessary friction.
The deployment of beta features is new to everybody, and some differences in understanding about how to handle feedback may be expected at the beginning. By design Beta Features encourage users to provide feedback to their related discussion pages. Maybe this needs to be more stressed wherever appropriate. For what is worth https://www.mediawiki.org/wiki/About_Beta_Features says "You can also comment on each feature's discussion page (see links above and on your Beta Features preferences page). If you find any technical bugs, please report them here [in Bugzilla]."
Please, let's stop arguing here about priority status and let's focus the discussion about fixed width at the talk page.
I'm going to try resolving this again as WONTFIX, as that best reflects the position of the team. There's no point in keeping it open, since, as it was repeatedly stated, this is not going to be fixed (in the meaning of "fixed" favored by the commenters here, that is removing the max-width now).
(I'll also state that I too believe this to be a very bad idea and sincerely hope that it will be killed with fire in future iterations, if killing it with fire right now is not an option.)
