Talk:List of methods

Table Structure

This is potentially a fantastic page but i feel it is organised poorly. I would like to propose a new layout that features the following columns.

Method : Puzzle : Type : Characteristics : (Year) Proposer

So for example the entry for Roux would be ...

Roux : 3x3 cube : Block-building : Speedsolving, fewest moves : (2003) Gilles Roux

What do people think?


I think we need to be careful about making the table unnecessarily wide. Inserting puzzle and purpose in the table will cause a lot of unnecessary repetition, making the table wider, and less likely to be organized well. Headers encourage the information to be placed in blocks of similar methods (eg 3x3 speedsolving). Perhaps adding the year it was invented would be valuable, but it would be better as a separate column rather than inserted as brackets. The proposed 'Characteristics' column is too ambiguous (eg, 'looks cool' might be added here) - I would call it 'Purpose', and leave it in the table sub-headers. Methods generally have a main purpose, since they are often designed with a specific need in-mind. They may also be applied in other domains - almost all methods have lessons that can be used in fewest moves. For example block building in Roux is useful for FM, but doing the whole solve using Roux is not really appropriate. Roux's main purpose is speedsolving, so to avoid confusing beginners it should be called a 'speedsolving' method. Clicking on the method page can provide more information to indicate whether it may be used for other secondary purposes, with a bit more context. For example: "Roux is not an FM method, but familiarity with block-building used at the start may help the user in FM solving."

Cride5 (talk) 03:50, 17 August 2016 (UTC)

Hi there!

I hope I'm responding in the correct way -- I'm just editing my original, or was I meant to create a new section?

Anyway ... you have a lot of good points.

Adding puzzle category WOULD create a lot of repetition, so probably not a good idea. Year as a separate column also a good idea. Also agree characteristics could be a tricky one. What about simply adding algs and av moves? This might be a more objective way to convey the same info -- after all, lower alg/higher moves tends to be for beginners, whereas higher algs/lower moves tends to be for speedsolving. Type column I think could be helpful and can be more objective: LBL, corners first, block building etc although some are hybrids.

Thoughts on that?

Please be careful with your edits - you completely wiped out my last response when you replied.

I created a section, because the discussion page needs to be divided into discussion topics. This discussion is about the table structure.

Methods are pretty complex, and trying to put too much information here will lead to inaccuracy and clutter. Only information which is certain and not open to interpretation should be used in the table.

Things like number of algs is easy to count for beginner methods, but not for more advanced methods. Number of moves, again depends on the solver and style. If you make a guess by doing a few solves yourself and place it in the table then you risk upsetting other solvers who may be more efficient.

These kinds of properties of methods should be discussed within the method page, where they may be given some context. For example, for number of moves it is reasonable to measure the number of moves as the sum of average optimal move counts for each step, but this needs to be stated explicitly. Moreover, what constitutes a 'step' may also be a grey area for some methods. For example in ZZ, some consider a whole 1x2x3 block to be a 'step', while others consider only 1x2 and 2x2 blocks.

Again, for a Type column consider that a single method may use multiple techniques. Roux may partially be considered corners first and blockbuilding. It is certainly closer to the corners-first family than ZZ or CFOP. What type would this method have? I believe that if people are encouraged to place methods into specific type buckets, then there will be interpretation and inaccuracy which might lead readers to the wrong conclusions about a method.

Cride5 (talk) 04:17, 18 August 2016 (UTC)