Template talk:VersionCompatibilityVersion/sandbox

From Dolphin Emulator Wiki
Jump to navigation Jump to search

Details of Purpose?

Can you provide more specific details of what you wanted to accomplish here? Kolano (talk) 11:14, 30 December 2015 (CET)

Trying to create something like this: http://i.imgur.com/pzrJ6n9.png
I can't seem to display the text outside the box. By the way, the stacking bars aren't intended. It isn't paint job but rather a piece of screenshot of something I made in CSS test area. Lucario (talk) 06:11, 31 December 2015 (CET)
div class="versioncompatibilityversion"

Seems to combine the multiple color bars into a single bar but hides the revision texts when it's going outside the box. Lucario (talk) 12:23, 31 December 2015 (CET)

(not quite) Finished!

It could be better but due to my limited coding abilities, it's good as it is now! How is the new version compatibility bar? Maybe try to accustom to it first in several game page previews to find out? (just add "/sandbox" in each template then preview) Lucario (talk) 21:18, 2 January 2016 (CET)

I'm not counter to revising this, but there are still some minor issues with the current revision:

  • Longer revisions, almost anything with 4char revision indicators, are being cut off (i.e. 4.0-2800).
  • Close revisions overlap problematically. With the older style, overlapping revisions would overlap but the newer revision would still be legible. Here overlaps make both revisions illegible. Might be addressable in a few ways:
    • Adding background color to the revision label, perhaps with transparent gradient borders to help things not look odd against non-white backrounds.
      • Handled it this way for now. Such obscures the earlier revision, but at least one is legible this way.Kolano (talk) 19:49, 3 January 2016 (CET)
    • Revising things to handle odd/even revisions slightly differently (up/down, or top of the bar/bottom of the bar).
    • Going with fully vertical text

Beyond those, I'd like to take some time to try to work in some other revised functionality before we'd deploy updates:

  • Add indicators of major revisions in addition to the end points beneath the bar (i.e. 3.0, 3.5, 4.0, 5.0)
  • Revise the default covered range to exclude 2.0 revisions (i.e. cover from v3.0-v5.0)
  • Working out a concept of hard vs soft stops. So we could more accurately indicate where a known compatibility change occurs vs compatibility happens to be such at some revision (but the change may have occurred in an earlier one). Basically I'd like to allow replacing the solid 1px right border with a transparent gradient, so the one compatibility would fade into it's prior one.
  • Allow the covered range to be revised, so it would be possible to display 5.0-1.0 or other range of revisions.

Kolano (talk) 22:48, 2 January 2016 (CET)

I'm against text going vertical. It doesn't free up the space between revisions very much compared to diagonal texts. It will in turn harder to read and require more space above to avoid text cut-off. Besides, it's extraordinary to see the revision getting nearly complete overlapped anyway. Well, my original intention was to resolve the overlap problem between two revisions closing each others, but not for those that's nearly complete overlapped. But I'm in for the white/transparent background just in case. I was thinking this illegible text is better than the older revision getting its revision number cut-off or impossible to click.
Maybe we can create mouse over popup so that the revision link will appear when the mouse is hovering the bar or the black arrow. Or mouse over to make the white background so the overlapped text will appear legible? The rotated texts will be no longer needed for this.
Your new ideas sound good too. You can edit this template and see how it goes. I'm satisfied with this new template though more features are welcomed. Lucario (talk) 16:45, 3 January 2016 (CET)
kolano, after seeing the semi-transparent white background in effect I'd actually prefer the illegible text again. Maybe you could revise it to make the white background thinner, blurrier, and don't extend behind the black arrow? Lucario (talk) 18:53, 4 January 2016 (CET)
The semi-transparent background being too thick and extending behind black arrow is now fixed. I still prefer the illegible texts though. Lucario (talk) 21:00, 4 January 2016 (CET)
There's now no more 2.0 starting point. The first revision tested will be starting point of game's compatibility chart. If I'm not mistaken, that fulfills one of your wishlist: "possible to display 5.0-1.0 or other range of revisions"? I'm not sure if we need to implement such way to revise the default covered range above 2.0. Simply removing the old revision lines from game pages may be what you're looking for. Lucario (talk) 09:04, 13 May 2016 (CEST)
Indicators of major revisions made the new bar layout look cluttered and I don't even want to think what would happen if we include indicator for 5.0, so slashed that out. Lucario (talk) 10:18, 14 May 2016 (CEST)

I'm not entirely sure how much of a good idea this is... we get a lot of "I tried it and it was good!" things which did not change the rating or have anything notable in them, which do not belong on the version compatibility graph. By the definition of "where compatibility change occured", if we strictly followed our own rules this is almost never an issue. The only times I can think of where it would genuinely be useful is cases like, a bug occurs and it is fixed rapidly. But the wiki often misses those anyway. :P But anyway, we shouldn't change anything until clear improvements are established, and I'm not really seeing them right now. - MaJoR (talk) 16:14, 4 January 2016 (CET)

As of right now the styling of this new bar isn't really good, such as a wasted space above and few other ugly styling layouts. They will be ironed out eventually. By the way, there is overlap problem like this Star Wars Rogue Squadron II: Rogue Leader that this new bar may be better for that. Let's also take narrowed browsers into consideration, where the revision labels will be overlapped even more in there. I'm hoping to implement this hover popup (like http://www.wickham43.net/hoverpopups.php) which works for Safari on iOS. Currently I and other iOS users cannot view notes or revision number of the overlapped revision. Lucario (talk) 18:53, 4 January 2016 (CET)
Major, there are a bunch of Compatibility Graph updates to work through. We'll work on a few things here before releasing it. I'd guess your concern were partially raised by the "unsure of revision" change. Addressing such rather than ignoring it allows for a few things:
  • Specifically shows unclear changes. Given there are over 700 in the [:Category:VersionCompatibilityVersion Template missing notes] list there are likely many of these.
  • Lets us label titles /w unclear revs for investigation. The category above addresses many of them, but there are unclear entries with notes.
  • Generally allow us to more clearly address cleaning up things like [Ben 10 Alien Force: The Rise of Hex]. We know the rating was updated to 4 back in 2012, but don't know what revision from that timeframe corrected the crashing formerly seen.
Cleaning up compatibility graphs will generally be a longer term project. Tasks like reviewing the Issues lists will help with such.

Overlapping Text Correction

Overlapping versions had initially been accounted for by adding a background color to make the topmost version legible. This was recently revised to use the presence of a 4th parameter to shift a later revision sideways. The new correction makes up to 2 overlapping revisions visible. But I don't think works out for more than 2. The restoring the background color would help a bit with that (i.e. so at least 2 of three overlapping results would be legible). Use of the additional variable also complicates things, so I'd like to find an alternate solution.

I think we also generally dislike consuming the additional space above the graph just for labels. One way I'm thinking a bit about to address both would be creating a hovering window over the graph acting like a magnifying glass. Allowing the graph to be drawn wider than the page, and increasing gaps between revisions (perhaps to the a 1 rev per px resolution. Alternate revision labeling would also be feasible. Not clear that works out smoothly, as there would still be limited resolution to the mouse coordinates. It might also alleviate the need to allow revising the revisions to cover. Kolano (talk) 07:39, 5 January 2016 (CET)

I think games with three version compatibility revisions overlapping together even with this new bar layout is just extremely rare. I don't think we'd have to worry about that. Let the extreme cases have illegible text. Lucario (talk) 12:04, 12 May 2016 (CEST)

Default Revision Range

As discussed elsewhere, we may need to reduce the number of revisions covered to keep it's output reasonable. I'm not clear on a good range to trim it too. There have been so many 4.0 revs I think limiting it to just those may be appropriate, but I'd like to hear from others before moving forward with related changes. Kolano (talk) 07:39, 5 January 2016 (CET)

Any flaws? Dislikes?

Ok, so I haven't found a (an obvious) flaw as of late besides the flaws inherited from the current bar layout (tooltips unavailable to iOS). Is it good enough to replace the current bar layout? Like I said you could try get accustomed to it after previewing sandbox templates in the game pages so you can judge better.

There are two game sandbox pages with this new bar layout that you can check without previewing:

If this new bar layout as whole can't be out of the sandbox, is there something you'd like to add to the current bar layout at least? Lucario (talk) 08:41, 13 May 2016 (CEST)

Thanks for working on this. I like what's been done thus far, particularly removing the static end points. I'd like to see the tooltip text revised though. We should show the rating text for all tooltips, not just when there were changes, and I'd like to get rid of the "Rev"/"Compatibility Updated"/"What's New" labels which just seem like excess text to me. Kolano (talk) 16:45, 14 May 2016 (CEST)

We can get rid of "Unclear entry" and "What's new" however I think "Rev" should stay. The Dolphin revision looks like list number in the tooltip without "Rev", like "r#### – note", "#.0 – note". I like "Compatibiliy update" though as it tells if the bar didn't change the compatibility rating, great for when I've missed that the bar is transparent. Lucario (talk) 05:13, 15 May 2016 (CEST)
We need to find a way to transform that tooltip from div tags into else so that it will work on iOS devices. Mouse over popup will work. We can work on that later... Lucario (talk) 05:24, 15 May 2016 (CEST)
I think the problem with using tooltips was that various browsers truncated longer ones rather than showing multiple lines of output, but it's been a while since I looked at it. Can we be clearer about where the angled text doesn't work out. I'd prefer to preserve it where it looks OK, which may be possible with some fancier CSS rules.
Also I'm unsure that the new overlap handling works very well. If the browser window is small enough all entries overlap, but if it's wider (like on my 4k) we end up with odd entries floating out in space that wouldn't overlap anything. Kolano (talk) 08:02, 16 May 2016 (CEST)
I've used this browser compatibility test and have noticed some browsers couldn't rotate or anti-aliasing the texts so I've removed the rotation codes then implemented more shift to the revision labels. I guess it's a waste of my work because they're for older browsers/computer and I hadn't taken higher res screen into consideration. Lucario (talk) 09:28, 16 May 2016 (CEST)
No harm in trying some things out, outside of some time used. This is a hobby, so that's the point anyway. CanIUse.com seems to indicate support for the rotate transform is fairly good in "current" browsers. If the fallback when the rotation isn't supported is that some of the labels overlap, it's probably not the end of the world. Kolano (talk) 01:51, 17 May 2016 (CEST)
Okay, transform rotate have returned. I realized we probably should only have to worry about how the website looks on the currently supported browsers. I have a question, would it be more performance hit if there's more extension functions behind the template? Lucario (talk) 04:23, 17 May 2016 (CEST)
There are limits, but I'd guess most things likely shouldn't be a problem. What were you thinking of? Also can you add in placemarks for the other major releases (i.e. 3.0, 3.5, 4.0)? Kolano (talk) 04:43, 17 May 2016 (CEST)
This Dolphin wiki seems not to be as fast as Wikipedia when it comes to large pages. Anyway, I have mentioned about indicator points that they made the new bar layout looks cluttered and I don't want to think about what will happen when 5.0 is out. It shouldn't be hard to add them there if you want them. Just have to copy/paste 2.0 indicator point then modify to another version. Lucario (talk) 05:15, 17 May 2016 (CEST)

The graph below charts the compatibility with sandbox, listing revisions only where a compatibility change occurred.

2.0
Δ
5.0-21270 (current)
Δ
Δ
Δ
Δ
Δ
2.0 (r5384)
Compatibility can be assumed to align with the indicated revisions. However, compatibility may extend to prior revisions or compatibility gaps may exist within ranges indicated as compatible due to limited testing. Please update as appropriate.

Just small issue we have right now: The recent dolphin revision's rating text will overflow in the left and then eventually clipped by grand-whatever parent div. I tried fix it with another "overflow: hidden" but wasn't sure where to put it in the template (yet). IDK if that's an issue we should care about, as the dolphin revision increases the revision text will not be overflowing anymore.

Hooray! Lucario (talk) 05:15, 17 May 2016 (CEST)

I haven't talked here because I really only have one thing to say, but, I guess it should be said... I don't like it. :/ The colors, the indicator of our silly in need of reworking definitions for stars, the font choices, the way the revisions are on an angle... all of it really. I honestly think the current system is better. You've put a lot of work into this, and that's not an easy thing to hear, but... those are my thoughts on it. Sorry... I'm bringing it up now since it seems to be nearing completion, and it would not be ok if the changes are just merged without discussion. We'll absolutely need to vote on this before anything is applied. - MaJoR (talk) 21:44, 25 May 2016 (CEST)

I want to contribute Dolphin Emulator in any way I can but this is not what I want to read. Most of your replies sound like prejudice and are killing my motivation to contribute or to love Dolphin Emulator (considering you're higher in position of the Dolphin Emulator community). Prejudice is hurtful. I'm fine with this needing some discussion and voting, but please keep prejudice to themselves. Lucario (talk) 11:42, 26 May 2016 (CEST)
*sigh* That was not prejudice. I made no criticism of you or your capacity to do good work, and I even went out of my way to praise how much work you are putting into this! And you have done a lot of great work here, especially in the guides sections! My criticism was directed at this specific template implementation. Just... I know that stung a lot... I really should have said this waaay before now, before you put a lot of work into this, and um, I'm sorry that I didn't... I was trying to work myself into replying, and then you stopped working on it in January, then I forgot about it, then you picked up on it while I was busy moving... *sigh* I am sorry about that... But I need to give my opinion honestly. If it didn't come up now, it would come up when it came time to vote on this for implementation, and I wanted to say it before that. I know this is discouraging, but, this is kind of how wikis are; lots of my pet projects weren't approved (just look at the many attempts to fix the rating definitions -_-) and that's just a potential you need to be prepared for in this consensus driven environment. Anyway, I'm sorry, and I know its discouraging, but I felt like you should hear this before it is blocked and voted on and all of that.... This was probably nooot the best way to go about it, but, its the best I could see at the time I guess. - MaJoR (talk) 19:19, 26 May 2016 (CEST)
I was under the impression that it is. I just cannot believe that this new bar layout can be stopped by your personal preference. You didn't like this new color, didn't like rotated texts, didn't like thick text, didn't like whatever it's got that the current bar layout doesn't have. You haven't even asked why. There are legit reasons why they're there. You did read this whole discussion, didn't you? Initially this new bar layout was started after you said that the current bar layout couldn't handle clutter (here).
Is there really nothing that can make it out of the sandbox? Lucario (talk) 05:33, 17 June 2016 (CEST)
As any other wiki, the Dolphinwiki works based on consensus. If you, Jhonn, and Kolano all wish to implement it as is, then I'm simply overruled, and have to follow it. I cannot just simply stop it based on my preferences. But the same applies to you - if the majority of us are not in favor of this template, or wish changes to be done first, you'll have to comply with it as well. It doesn't have to be all or nothing, we could find a compromise solution too, based on all of our input. And yes I have read the discussion and have watched this develop, know the reasons behind the changes. I just don't agree. :/ I'll be making sure to go through my position in detail soon, but right now I'm swamped with 5.0 release work! >_< I'll post in detail after 5.0. - MaJoR (talk) 09:31, 17 June 2016 (CEST)
I thought it's almost a given that the bar layout is in need of a revamp. I suppose the new bar layout that I came up with is in need of a consensus since it could be just me who thinks it's a worthy replacement for the current bar layout as it is currently (well, after some cleanup like undoing rating text in the tooltip). What side are you on, User:Jhonn and User:Kolano? We can always work on a better bar layout to replace on top of this new bar layout in the future, like Kolano said something with CSS.
If you'd (MaJoR) like, you can provide a better alternative for something you dislike about this new bar layout meantime. Should it make it in before going out of the sandbox or to save it for the future. I will most likely undo the rating text in the tooltip as you and Kolano seems to oppose it and I don't have strong point with it going out of the sandbox. I didn't returned for a while because I don't like to get involved in discussion like this. I was mad on that time (and still am!).
I hope your progress with releasing Dolphin 5.0 went smooth! Quite excited for it. Lucario (talk) 16:43, 17 June 2016 (CEST)
I share similar thoughts with MaJoR, I would be against implementing this outside of the sandbox in the current state. I can say that the only thing in this sandbox that I personally think it's better than the current template are the new colors, everything else needs adjustments here or there or aren't really necessary (I'll elaborate more after 5.0 release)... - Jhonn (talk) 03:13, 18 June 2016 (CEST)

Let's divide features the new bar layout is made up of, then you and MaJoR can see what you're actually opposing on with MaJoR's unclear response "all of it really".

Feature difference between current and new template Support Presumably support (please decide) Conditional support Neutral Presumably oppose (please decide) Oppose
New color Jhonn, Kolano, Lucario MaJoR
White bar for game with no revision tested Lucario, Jhonn Kolano MaJoR
Rating text on top: white bar to be in its full width ( See #Few questions (opinions usually) ) Lucario Kolano, Jhonn (see notes below)
Rating text (big bold font in bar) Lucario Jhonn, MaJoR
Same rating bar to have white transparent Lucario (if rating text stays) MaJoR Jhonn
Revision text on top Jhonn, Kolano, Lucario MaJoR
Rotated revision text Kolano Lucario (if revision text on top, and no better alternative to overlap problem) Jhonn, MaJoR
Correcting overlapped revision text by shifting later revision to upper-left Jhonn (see notes) Kolano Lucario (if revision text on top, and no better alternative to overlap problem) MaJoR
Major revision points in footer Kolano (Though further revs are needed), Jhonn (see notes) Lucario (if revision text on top) MaJoR
Remove static "2.0" end point Lucario Kolano MaJoR Jhonn (see notes)
Tooltip (before it was reverted) Lucario Kolano Jhonn, MaJoR

I'm in support of big bold rating text as it gives users idea of what color means in the bar. It's got its font style to blend into the background of the bar. This will require the revision text to go outside of the bar. I realized that with revision text on top I can also find version compatibility in wrong order in several game pages (discovered when previewing with sandboxed templates, I can't remember which game I first discovered but Rayman Origins got similar, ordered exactly backward). Lucario (talk) 07:00, 18 June 2016 (CEST)

Okay, got some time to review this, firstly, could you explain better what exactly are you referring to by "Rating text on top: white bar to be in its full width"? I didn't figure out what it might be, so I'm presumably opposing until I understand better. Secondly, about "Correcting overlapped revision text by shifting later revision to upper-left", I'm supportive of having some way to correct overlapped revisions but I think the current design isn't looking good, needs further refinement. Moving on, I'm also supportive of "Major revision points in footer", but in the future, with more releases, it'll get messy. Maybe using some kind of logarithmic instead of linear calculation to the revision position on the bar (so the recent releases get a wider space in the chart compared to old ones, like 2.0). This also relates to "Remove static "2.0" end point": I oppose having anything older than 2.0 being the "earliest", the data available on those revisions are pretty scarce and 2.0 at this point is so old to even bother trying to gather information about it (I mean, the Version Compatibility chart didn't even exist on the wiki around 2.0 release time, AFAIK -- why bother keeping track of revisions before it while we already have trouble documenting revisions released after?). That's all I had to say, for now. If you want to discuss further on some point that I'm officially opposing, let me know. - Jhonn (talk) 04:57, 12 July 2016 (CEST)
Forgot something about the new colors: I don't like the color used for "playable". My suggestion here is using the current "perfect green" as the color for playable and using some kind of blue (somewhat close to the Dolphin logo, for example) as "perfect". - Jhonn (talk) 05:02, 12 July 2016 (CEST)
Will respond in a few bullets bellow... Kolano (talk) 08:54, 12 July 2016 (CEST)
  • I believe the "Rating text on top: white bar to be in its full width" is related to the current revision no longer consuming 100% of the width. Instead there is as odd gap between the last revision shown and the edge of the chart. I remain a bit unclear why that would be necessary, I'd think the header/footer rows would be be styled to allow for overlapping other content avoiding forcing odd offsets, but I haven't had time to look closely at why the gap has been added.
  • Can you or Major be more clear about oppositions to revisions to account for overlapping revision text? The current revision seems to significantly improve on displaying close revisions. Do we not feel there enough CSS3 compliant browsers that support angled text? Neither you or Major have described why you are opposed to the current revisions to account for such? We had considered some additional revisions to offset close revisions further (i.e. allow even closely set diagonal text to not overlap), but wanted to avoid some of the complexities of that for now. In any case I want to have a clearer understanding of the opposition of pulling the change revision indicators into the header, and offsetting them diagonally to allow close set revisions to be legible.
  • I think the eventual goal regarding the baseline revision point will be to make it be set arbitrarily based on whatever revision we have the earliest report on. If we have no reports earlier than 4.0 then there is no reason to clutter the graph with earlier revisions. However, where we have reports from prior to 2.0 I'd like the chart to display them. My vote would be to display all available data and work out some reasonable display when no data is available.
  • I understand there has been some ongoing effort to purge historic data from the wiki, and I understand the lack of desire to maintain such. For instance, I have not opposed the purge of problem data. At the same time there is a historic aspect of things to preserve as well, which I feel the Compatibility graph plays into.

I'm happy to see discussion here, but would like to ensure that we don't deride some of the improvements that have been made due to what are likely more minor design decisions. Kolano (talk) 08:54, 12 July 2016 (CEST)

Few questions (opinions usually)

1. Is the new color scheme good? Particularly that "Playable" bar color. Originally I changed to turquoise because sometime I thought it's "Perfect". But now there is rating text around, I don't mind either. I still like turquoise color though. Lucario (talk) 08:56, 17 May 2016 (CEST)

I'm OK with the new scheme. The non-green is easier to distinguish. Kolano (talk) 07:05, 18 May 2016 (CEST)
Okay, great. Lucario (talk) 08:28, 18 May 2016 (CEST)

2. Does white bar visible in the right bothers you? The games with no revision tested will appreciate this otherwise. They will just have white bar in full width. Lucario (talk) 08:56, 17 May 2016 (CEST)

It does, but I'd guess it shouldn't be too hard to correct for. Can't we just add a margin to push it to the left? If it's finicky we might need a calc CSS rule to handle it. Kolano (talk) 07:05, 18 May 2016 (CEST)
The white bar was originally in the same width as other bars until I've moved it out of div that pushed bars to the left. It's to make the white bar look good on the game pages with no revision tested. I don't know which one is better. In fact, I wasn't bothered by either. So... should the white bar go back to its same width as other bars or leave it as it is? Lucario (talk) 08:28, 18 May 2016 (CEST)

Secondary compatibility bar and the old value

The graph below charts the compatibility with sandbox, listing revisions only where a compatibility change occurred.

Δ
5.0-21270 (current)
Δ
Δ
Δ
Δ
Δ
2.0 (r5384)
Compatibility can be assumed to align with the indicated revisions. However, compatibility may extend to prior revisions or compatibility gaps may exist within ranges indicated as compatible due to limited testing. Please update as appropriate.

The graph below charts the compatibility with sandbox, listing revisions only where a compatibility change occurred.

Δ
5.0-21270 (current)
Δ
Δ
Compatibility can be assumed to align with the indicated revisions. However, compatibility may extend to prior revisions or compatibility gaps may exist within ranges indicated as compatible due to limited testing. Please update as appropriate.

The templates used to display another bar will load the most old values created by the first bar in the current page (this discussion page).

{{#vardefine:rev|}}{{#vardefine:last|}}{{#vardefine:lastrev|}}{{#vardefine:lastrev2|}}

These null vardefines cleared out the old values before loading into the templates of the last bar. For some reason the {{VersionCompatibilityClose/sandbox}} will not reload until I give it as least a pipe character. Lucario (talk) 09:42, 22 May 2016 (CEST)