OLL Naming and Reorganization

[Razgorth]

We need a new system for OLL naming and organization. The current number system is unintuitive and poorly structured, not to mention easily forgettable, while the other random names like "Zamboni" and "City" are even more difficult to remember and even potentially offensive ("Nazi"? Really?).

Which OLL number is this? Most people probably have no idea, myself included.
​

So I'm proposing a new OLL organization and naming system, built around the 2-look OLL patterns to smooth the transition between 2-look and 1-look OLL, and using naming structure derived from COLL for general coherency.

This system hinges around the fact that every single OLL is a combination of 2-look OLL's edges and corners. In other words, even if you only know 2-look OLL, you can already recognize every single OLL case. You just haven't been taught how. Therefore, our main orients will be named after the 7 COLL sets.

is the H orient.

is the PI orient.

is the U orient.

is the T orient.

is the L orient.

is the AS orient.

is the S orient.​

Next, edge orientation will be delineated by simply specifying which edges are correctly oriented using the letters B R F L, except in the case of everything already correctly oriented, which will be just the edge orient name, and the dot case, which will be DOT. (EDIT - I think the dot case should be O, just because it's simpler. Also I main a Gans. ) If that didn't make much sense, here are some examples:

is the T-BR orient.

is the PI-RL orient.

is the U-DOT orient.

is the L-BF orient.

is the S-RF orie- wait, what?
​

So yeah, that's a problem we need to solve, one that the current system has not handled very well: namely, that we need a fixed orientation of the 7 OLL edge cases in order for the B R F L system to work properly. The L-BF example actually already shows this problem, but since the L orient is symmetrical, it ends up being the same case, assuming we adopt the current algdb OLL 25 orientation, which I actually do not suggest. I think the transition to COLL could be improved as well if we fix these orients according to the current COLL sets, or change the orientation of the existing COLL images.

In conclusion, I think this system is a more organized, more intuitive, and more streamlined approach to OLL naming convention than currently exists on sites like algdb. The orient names are definitely not fixed, and neither are their current orientations (I'm too lazy to rotate the existing algdb images ). They could even be changed entirely, assuming we make the COLL sets follow suit. The edge B R F L order can be changed: maybe R F L B? F L B R? F R B L? Doesn't really matter to me. EDIT - Actually the edge system is simple enough that you can write whatever order you want. It takes the same minuscule amount of time to process LB and BL.

The most important thing here is the idea, and I really hope that we can end up adopting this system or some derivative of it. It helps with both 2-look -> 1-look OLL and OLL -> COLL transition, adopts a somewhat unified naming scheme for last layer algs, and even helps people with OLL recognition: once you understand that every OLL is just a fusion of OCLL + OELL from 2-look, you realize that you only have to look at the U layer pattern and a maximum of 3 other corner stickers for recognition of any OLL case, and potentially even just one other corner sticker.

tl;dr - The current OLL number system sucks, mine is better so support me.

EDIT - It seems some people are missing critical parts of this post. More highlights have been bolded and some edits have been made.

EDIT 2 - The other ideas in this post are just that: ideas. I am not saying you must use this recognition style. I am not saying you need to throw out the informal lightning bolt shapes, Z shapes, etc. that you are currently using. I am saying that my system is better than the current number system, and so we should replace the current number system. I am saying my system is better for communicating without misinterpretation than the informal shape system. Everything else is secondary.

 

[Razgorth]

Some thoughts on improved names and fixed orientations for the 7 edge cases: we should orient each case according to the popular 2-look OLL orientations to make it easier to learn. Also, naming should resemble PLLs so that we have some sort of continuity.

E orient - Fixed orientation should be with a y rotation so it resembles correct E-perm orientation.

T orient - Looks like a T-perm, keep the orientation.

This is the hardest one to name. Orientation is good for the alg, but it doesn't really look like a U perm at all.
Maybe C orient?

I orient - Keep the orientation.

Y orient - Rotate by y. Resembles a Y-perm in that two corners are wrong.

A orient - Resembles an A perm in that 3 corners need to switch. Also, A for anti-sune.

S orient - Sune is so well-known it makes no sense to change it.​

 

[Daniel Lin]

In conclusion, I think this system is a more organized, more intuitive, and more streamlined approach to OLL naming convention than currently exists on sites like algdb. The orient names are definitely not fixed, and neither are their current orientations (I'm too lazy to rotate the existing algdb images )

I agree with you 100%. I hate how algdb doesn't stick to one orientation
Doubt anything will change though

 

[Razgorth]

I agree with you 100%. I hate how algdb doesn't stick to one orientation
Doubt anything will change though

No harm in trying. I think Stachu is working at the Cubicle, so if everyone who makes an order there puts this in the comments, he might get around to doing it sometime.

 

[sqAree]

Okay, numbers might not be the perfect choice, I agree no one memorizes which case corresponds to which number. However, I dislike your approach as there already exists a popular way of naming OLLs by shapes (small/big lightning bold shapes, letter shapes, etc.) which is just perfect as it directly corresponds to the way we recognize OLLs (I don't think anyone recognizes OLL cases by their OCLL case).

 

[Razgorth]

Okay, numbers might not be the perfect choice, I agree no one memorizes which case corresponds to which number. However, I dislike your approach as there already exists a popular way of naming OLLs by shapes (small/big lightning bold shapes, letter shapes, etc.) which is just perfect as it directly corresponds to the way we recognize OLLs (I don't think anyone recognizes OLL cases by their OCLL case).

I think we should be recognizing OLL by top pattern and OCLL case. All you have to do is recognize the 2-look cases at the same time. There are 4 possible edge orients (line, L, cross, and dot) and 8 possible edge orients (7 OCLLs and solved). Every single case is just a simple OCLL + OELL recognition. The idea is you never have to rotate to recognize the case, even for things like OLL 53-54 (E-FL and E-RF).

Also, please tell me the names of 47-50 and 53-54.

Also I just realized we need an all edges solved case. In that case, just omit the first letter.

is BF orient. Or RL, if you prefer.

is the real DOT orient.
​

EDIT - OLL 18-19 are also problems, 9-10, etc. Even 32 and 44 are problematic.

 

[Dash Lambda]

Some thoughts on improved names and fixed orientations for the 7 corner cases: We should orient each case according to the popular 2-look OLL orientations to make it easier to learn. Also, naming should resemble PLLs so that we have some sort of continuity.

E orient - Fixed orientation should be with a y rotation so it resembles correct E-perm orientation.

T orient - Looks like a T-perm, keep the orientation.

This is the hardest one to name. Orientation is good for the alg, but it doesn't really look like a U perm at all.
Maybe C orient?

I orient - Keep the orientation.

Y orient - Rotate by y. Resembles a Y-perm in that two corners are wrong.

A orient - Resembles an A perm in that 3 corners need to switch. Also, A for anti-sune.

S orient - Sune is so well-known it makes no sense to change it.​

It's kind'a pointless to try to force naming continuity between OLL and PLL. They're just different.
And the names the OP gave for the corner cases are pretty commonly accepted and make sense. H because the corners make two parallel lines, Pi because the corners make two parallel lines with a hat, U because the corners make the two endpoints and it's kind'a easy to visualize the 'U' shape, etc...
So, I respectfully, but entirely, disagree.

I think we should be recognizing OLL by top pattern and OCLL case. All you have to do is recognize the 2-look cases at the same time. There are 4 possible edge orients (line, L, cross, and dot) and 8 possible corner orients (7 OCLLs and solved). Every single case is just a simple OCLL + OELL recognition. The idea is you never have to rotate to recognize the case, even for things like OLL 53-54 (E-FL and E-RF).
EDIT - OLL 18-19 are also problems, 9-10, etc. Even 32 and 44 are problematic.

The problem with that is that it's just not efficient. We recognize cases by shapes and patterns, and the fewer patterns we need to process the faster we are. If we force ourselves to process two separate cases, it'll be slower than just seeing one shape.
That is, unless you're saying we actually should recognize the pattern like normal and use COLL recog if there are hidden corners, which is just something you develop anyway.

While I love systematic naming conventions, I think your framework is a little too rigid to be practical. In the end, a string of letters (especially orientation-dependent) is just as bad as a number. There are a lot of OLL cases, so it's not like we can fit one to a letter like with PLL, so we just have to come up with good names (which we have for many of them, but not all).

-For 9-10: Those are "Kite" cases, and I think that name works great. They're mirrors, so I think it's perfectly reasonable to call them Kite-a and Kite-b.

-For 18-19: The names the wiki gives for those are "Crown" and "Bunny," but I don't really like those. I think they should both be called either "Bunny" or "Mickey" (the mouse, for obvious reasons), either being "Bunny-a" and "Bunny-b" or, since they're not mirrors, "Bunny-dot" and "Bunny-line," characterized by the row opposite the ears.

-For 31, 32, 43, 44: I think those should all be "P" cases, and they should be differentiated by "line" and "dot" as per the previous one and "a" and "b" for mirrors. So we have "P-dot" a and b and "P-line" a and b.

-For 47-50, 53, 54: I think those should all be "Angle," though I don't know how best to differentiate them. You can separate them into three sets of mirrors, and I'd personally call them "Long," "Short," and "L," characterized by the pattern on the sides, but I don't know how intuitive that is or how well it works for other people.

All in all, I do think our current OLL naming conventions are inconsistent and unintuitive to the point of uselessness, and you're definitely onto something, but I think you're trying to apply a little too much structure.

I'll try to compile a complete list of the names I use internally pretty soon to post here, I'm curious to see what everyone else thinks of them.

 

[AlphaSheep]

So that people know how the orientation was chosen for the cases on algdb.net, the images all just use the orientation for the first alg that was loaded for that case.

I think using the corners only as the first categorising feature is a bad idea. The first visible feature is the shape on top, which people have already given names like lightning, L, line, etc. Then you can categorise these by the corner twist as you would look at that second. That's how most people seem to group the cases anyway.

 

[Razgorth]

It's kind'a pointless to try to force naming continuity between OLL and PLL. They're just different.
And the names the OP gave for the corner cases are pretty commonly accepted and make sense. H because the corners make two parallel lines, Pi because the corners make two parallel lines with a hat, U because the corners make the two endpoints and it's kind'a easy to visualize the 'U' shape, etc...
So, I respectfully, but entirely, disagree.

I am the OP. I realize the current system makes sense, and that's why the first post had those naming conventions. I also think, however, that we shouldn't stagnate with what is commonly accepted if there is a potentially better alternative. I think that to an established cuber, suggested changes makes very little sense. To a new cuber, the fact that OLL and PLL have naming continuity is probably helpful.

The problem with that is that it's just not efficient. We recognize cases by shapes and patterns, and the fewer patterns we need to process the faster we are. If we force ourselves to process two separate cases, it'll be slower than just seeing one shape.
That is, unless you're saying we actually should recognize the pattern like normal and use COLL recog if there are hidden corners, which is just something you develop anyway.

I really don't think you've thought about this at all. Please explain to me how to recognize an OLL case with at least 2 unsolved corners by looking only at the top pattern. It's not possible. If you're saying look at top pattern + front face, I'm saying that's inefficient (also you still can't recognize most cases). You don't need to look at any of the edge orientations, because you know edge orientation from just looking at the top pattern. If we count in terms of stickers, all you need to know are the 9 top stickers and one sticker each from 3 corners to recognize OLL. Don't look at the full front block, right block, left block, etc. It's not necessary.

While I love systematic naming conventions, I think your framework is a little too rigid to be practical. In the end, a string of letters (especially orientation-dependent) is just as bad as a number. There are a lot of OLL cases, so it's not like we can fit one to a letter like with PLL, so we just have to come up with good names (which we have for many of them, but not all).

I respectfully disagree. You'll end up with at least 15-20 different names instead of an intuitively understandable 1-3 letter set.

-For 9-10: Those are "Kite" cases, and I think that name works great. They're mirrors, so I think it's perfectly reasonable to call them Kite-a and Kite-b.

Which one is Kite-a, which one is Kite-b? More importantly, how do you enforce the distinction?

-For 18-19: The names the wiki gives for those are "Crown" and "Bunny," but I don't really like those. I think they should both be called either "Bunny" or "Mickey" (the mouse, for obvious reasons), either being "Bunny-a" and "Bunny-b" or, since they're not mirrors, "Bunny-dot" and "Bunny-line," characterized by the row opposite the ears.

Now you've hit the problem on the head: you don't like those. What if people don't like Bunny or Mickey? What if they want to call it V or Peace Sign?

-For 31, 32, 43, 44: I think those should all be "P" cases, and they should be differentiated by "line" and "dot" as per the previous one and "a" and "b" for mirrors. So we have "P-dot" a and b and "P-line" a and b.

Here is another issue: why are you bothering with line and dot? What if you can't see the line or dot? Do you waste time rotating or AUFing, or do you just recognize by OCLL? Assuming you do do OCLL, even subconsciously, why not just do that all the time?

-For 47-50, 53, 54: I think those should all be "Angle," though I don't know how best to differentiate them. You can separate them into three sets of mirrors, and I'd personally call them "Long," "Short," and "L," characterized by the pattern on the sides, but I don't know how intuitive that is or how well it works for other people.

Again, you claim that my system is rigid and impractical, but don't propose a good alternative. Honestly, using my system, I can probably write out all 57 OLL cases in about 5 minutes, without needing to consult a wiki or try to figure out which one I'm missing, and it will be immediately understandable to even a non-cuber so long as I show them the 7 OCLL pictures and the edge orientation idea. I really don't see how you would achieve anything remotely close to that with an arbitrary shape naming system.

I think using the corners only as the first categorising feature is a bad idea. The first visible feature is the shape on top, which people have already given names like lightning, L, line, etc. Then you can categorise these by the corner twist as you would look at that second. That's how most people seem to group the cases anyway.

What I'm suggesting is that cases are grouped by OCLL because you can derive subsets from that. Instead of having OLL as one giant, menacing block of 57 algs, you can have OLL H, OLL Pi, etc. There is very little rhyme or reason as to the current sequence of OLL algs that flows well beyond a group of 2-4 algs.

It also facilitates recognition for people coming from 2-look. If you only know all of the OLL U cases, for example, you can see if it's a U orient: if so, try to remember the alg, if not, just 2-look it.

 

[Razgorth]

As a demonstrative exercise, please name the OLL solved by this alg without consulting any sources (I tried to choose a common one): F (R U R' U') (R U R' U') F'. Don't use algdb, don't use a wiki, don't Google, don't look at notes, don't even tab away from the thread. Just try to think of the OLL number, the wiki name, and then the name under my system (okay fine the system is in the thread, but the idea is that I don't blatantly provide this name and its accompanying picture, so you're still figuring it out yourself). Which one is easiest?

EDIT - I'll even provide the picture.

Now even those of you who use 2-look could probably name this using at least one method hint hint.

 

[sqAree]

Yeah, I agree that with using shapes we still run into the issue of distinguishing between cases when there are many of one shape. I'm personally not too bothered about mirrors and such; after all for PLL we also use Jb and Ja for instance.

I don't know how you think OLL recognition works, but it's more or less one look to recognize the case, when turning slightly slower than usually I think most cubers can predict the OLL case a few turns before reaching it. After knowing the top pattern in most cases there is like one side sticker left to look at to know the case and it's easy to memorize which side sticker to use after knowing the top pattern.

The great advantage of our PLL naming system is its intuitivity and that it works with images. It's easy to assign a letter to a pattern there. Your naming system requires us to count unoriented edges and the OCLL case which might be efficient in terms of stickers (granted) but not intuitive and, contrary to instant shape recognition, requires us to built the picture in our head step by step. I'd say it's easy for everyone to link a shape name with its shape (so the according case).

Furthermore I'd like to point out that I still use 2-look OLL for 2H solving at least so I guess I can speak on behalf of people who want to do the transition between 2L and 1L. Your system is kinda discouraging, and also I think it's inherently not a good idea to use 2L methodology for the transition.

 

[stoic]

This feels like one of those worthy ideas that crop up every now and again but end up going nowhere. (Fingertrick notation, anyone?)

A lot of the OLLs already have names; well, according to the wiki they do, but most of them I never notice anyone using. So is there a need? Anyone learning full OLL is already free to learn the names if they so wish without learning a system to predict them, and that doesn't strike me as too much work.

I respect how much effort you've put in but it seems like you're solving a problem that isn't really there. I'd suggest you don't expend too much more effort at this stage unless the community starts to take this and run with it.

As a demonstrative exercise, please name the OLL solved by this alg without consulting any sources (I tried to choose a common one): F (R U R' U') (R U R' U') F'. Don't use algdb, don't use a wiki, don't Google, don't look at notes, don't even tab away from the thread. Just try to think of the OLL number, the wiki name, and then the name under my system (okay fine the system is in the thread, but the idea is that I don't blatantly provide this name and its accompanying picture, so you're still figuring it out yourself). Which one is easiest?

EDIT - I'll even provide the picture.

Now even those of you who use 2-look could probably name this using at least one method hint hint.

I don't know the name of this case; however I can "see" in my mind what algs I'll use to solve it depending on orientation. I don't know that I'll ever *need* to name it, and therein lies the problem. For me, at least.

 

[Oatch]

I agree that a better naming/categorisation scheme would make the learning and recognition process for OLL simpler. Breaking down larger alg sets into subsets can really help with this - as with COLL, basing them on the OCLL cases. However, I'm not a CFOP solver myself, so I have not really delved into or really attempted at all learning full OLL, so the current system of shape-recognition may already be sufficient - but, with a bit of work, this idea does seem promising.

 

[1973486]

As a demonstrative exercise, please name the OLL solved by this alg without consulting any sources (I tried to choose a common one): F (R U R' U') (R U R' U') F'. Don't use algdb, don't use a wiki, don't Google, don't look at notes, don't even tab away from the thread. Just try to think of the OLL number, the wiki name, and then the name under my system (okay fine the system is in the thread, but the idea is that I don't blatantly provide this name and its accompanying picture, so you're still figuring it out yourself). Which one is easiest?

EDIT - I'll even provide the picture.

Now even those of you who use 2-look could probably name this using at least one method hint hint.

"F double sexy F prime".

 

[Dash Lambda]

I am the OP.

Whoops, didn't read the username XP

To respond to most of what you're saying, a naming convention shouldn't be something you have to think about. You should be able to say the name naturally just by seeing the case, and vice versa. Descriptive names based on shapes and patterns satisfy that, but adding any cognitive steps between an image and a name makes the name less effective. Case recog, of course, is another matter and discussion entirely, and isn't something you can base a universal naming convention off of.

Oh, and for mirrors, it doesn't matter what's a, b, c, d, etc. because they're the same case. We just need to decide which one is which and keep that consistent on paper, in conversation people will normally just leave the letter out.

 

[Razgorth]

I don't know how you think OLL recognition works, but it's more or less one look to recognize the case, when turning slightly slower than usually I think most cubers can predict the OLL case a few turns before reaching it. After knowing the top pattern in most cases there is like one side sticker left to look at to know the case and it's easy to memorize which side sticker to use after knowing the top pattern.

This is true for most cases if you look at one or two specific side stickers. If that sticker is hidden, you need to AUF to find it.

OLL recognition is eventually one-look, yes. Just like how PLL recognition is eventually 2-sided, OLL should be 2-sided as well from every angle. My point is simply that a lot of people incorporate the sides of the edges into that one-look. The sides of the edges are useless. Why? Because by looking at the top pattern, you already know the orientation of all edges.

I am not saying that one-looking OLL is impossible. I am saying that for someone just starting to learn OLL, it is entirely possible that they need to break down the OLL case in their head. How many people developed perfect OLL recognition after a day? Or perfect PLL recognition after a day? I'll bet that even Faz didn't. I am not forcing you to not one-look OLL. I am explaining what you should be looking at to one-look OLL. I've simply divided it into two steps because it's really uninformative to say " its ez just check the top pattern and OCLL simultaneously".

Here's an example.

The tentatively named H-BR orient. OLL 54. According to the wiki, "Anti-Frying Pan". How do you recognize this case, assuming you can only see the top, the front, and the right side? Well the pattern on top tells you it is one of 6 possible OLLs. The left and right front edge stickers are not the top colour, narrowing it down to 2 possible OLLs. You have to look at the back sticker on the right side to determine OLL case. The fact that there is a "dot" edge on the front tells you nothing. Don't look at it then.

The great advantage of our PLL naming system is its intuitivity and that it works with images. It's easy to assign a letter to a pattern there. Your naming system requires us to count unoriented edges and the OCLL case which might be efficient in terms of stickers (granted) but not intuitive and, contrary to instant shape recognition, requires us to built the picture in our head step by step. I'd say it's easy for everyone to link a shape name with its shape (so the according case).

Really? Tell me, which part of the Gabcd classification is intuitive? If I go to a random person on the street and show him 4 G perm images, how do I explain why Ga is Ga and not Gb? Again, to reiterate, shape recognition is fine. However, just knowing the shape does not tell you which OLL case it is most of the time.

Furthermore I'd like to point out that I still use 2-look OLL for 2H solving at least so I guess I can speak on behalf of people who want to do the transition between 2L and 1L. Your system is kinda discouraging, and also I think it's inherently not a good idea to use 2L methodology for the transition.

Please, humor me. Try the system for a week. Then tell me the issues with it.

A lot of the OLLs already have names; well, according to the wiki they do, but most of them I never notice anyone using. So is there a need? Anyone learning full OLL is already free to learn the names if they so wish without learning a system to predict them, and that doesn't strike me as too much work.

There are a few extra benefits to knowing the name. Let's say you're skimming example solves on cubesolv.es, or reading a deconstruction, and someone uses an unfamiliar, or obscure, OLL alg. Which case did they solve? With my system, instead of simply writing OLL next to the OLL step, you can know which case it is immediately, without needing to look up the number or run the alg through Cube Explorer.

There was a video on Youtube of Keaton Ellis and Kim Jokinen (IIRC, it's the Euro 2016 vlog posted by the Cubicle's channel) where, for fun, they were blindfolded and each had one hand on the cube. Jayden McNeill was their "spotter", so to speak, and when they got to OLL he called out, "Stealth Bomber!" Keaton knew which case it was, Kim had no idea wtf Jayden was talking about. (The video's pretty funny by the way, there's more OLL shenanigans in the other blind team solves as well.) I'm not saying that this situation will occur every other day, I'm just saying that having an easy way to talk about individual OLLs is conducive to better communication. People used to think that being colour-neutral was a pointless waste of time as well. This is much easier than switching to colour-neutral.

 

[Razgorth]

To respond to most of what you're saying, a naming convention shouldn't be something you have to think about. You should be able to say the name naturally just by seeing the case, and vice versa. Descriptive names based on shapes and patterns satisfy that, but adding any cognitive steps between an image and a name makes the name less effective. Case recog, of course, is another matter and discussion entirely, and isn't something you can base a universal naming convention off of.

This is why I'm saying that you should try the system out. Go down the list of OLL algs, name each one using the shape system, then name it using my system. I can even name 4x4 OLL parity cases using my system. Intuitively. Within a half second. It's that easy.

Oh, and for mirrors, it doesn't matter what's a, b, c, d, etc. because they're the same case. We just need to decide which one is which and keep that consistent on paper, in conversation people will normally just leave the letter out.

And this is why some people don't know which case is actually Ga, which is Gd, etc. Which case is this?

I know which one it is, but I had to memorize that information. You don't have to memorize any specific cases with my method except for the 7 OCLL orientations.

But specific orientations are too much work, you say. And letters are just arbitrary! None of our other naming systems require specific solving orientation or letter schemes! Oh wait. PLL does. PLL demands you orient the cube in a specific way for each alg that you use and requires you to memorize a total of 13 letters, not including mirrors. My OLL system uses 7 + 4 + 1 dot case = a total of 12 unique letters, for 57 cases, including mirrors.

 

[sqAree]

Here's an example.

The tentatively named H-BR orient. OLL 54. According to the wiki, "Anti-Frying Pan". How do you recognize this case, assuming you can only see the top, the front, and the right side? Well the pattern on top tells you it is one of 6 possible OLLs. The left and right front edge stickers are not the top colour, narrowing it down to 2 possible OLLs. You have to look at the back sticker on the right side to determine OLL case. The fact that there is a "dot" edge on the front tells you nothing. Don't look at it then.

Hm, no matter what recognition method one uses, in the end we still have to look at 3 edges and 3 corners at least? When solving I have full vision on top, front and right anyway, so no AUF needed and I can instantly spot the case.
Sure, I agree looking at UF twice (once for the top pattern, and once when looking at the front) is useless. But the good thing about top pattern recognition is that after it you have to look at 3 more side corners stickers at most, and one less for each oriented corner because we already saw it on the top.

Really? Tell me, which part of the Gabcd classification is intuitive? If I go to a random person on the street and show him 4 G perm images, how do I explain why Ga is Ga and not Gb? Again, to reiterate, shape recognition is fine. However, just knowing the shape does not tell you which OLL case it is most of the time.

Sorry, I confused something and thought you said the PLL naming convention already makes sense. The letters are intuitive, but the mirror classification is not, you're right.

Please, humor me. Try the system for a week. Then tell me the issues with it.

Hm, difficult, as their is no need to name certain OLL cases most of the time. At least for me, very rarely. So the possible issue that might come up is the delay that occurs when trying to encode a case into its name and vice versa. Your system is more accurate than current systems but also requires more time I'd say.

 

[Dash Lambda]

OLL recognition is eventually one-look, yes. Just like how PLL recognition is eventually 2-sided, OLL should be 2-sided as well from every angle. My point is simply that a lot of people incorporate the sides of the edges into that one-look. The sides of the edges are useless. Why? Because by looking at the top pattern, you already know the orientation of all edges.

When I see a 'dot' on the side, it's not the difference between a dot and no dot, it's the difference between a dot and a line. I already know the edge is there, what I'm looking at is the corners, and on a low level it's faster to process the presence of one thing than the absence of two.
Not that that matters for a naming convention, though, because recog is different from communication. It just so happens that it's easy to assign names based on the shapes you recognize in OLL. We don't name PLL cases in terms of headlights, opposites, adjacents, bars, and blocks, we names them by overall shape.

This is why I'm saying that you should try the system out. Go down the list of OLL algs, name each one using the shape system, then name it using my system. I can even name 4x4 OLL parity cases using my system. Intuitively. Within a half second. It's that easy.

I've already tried naming a few, even just in understanding your system you need to construct a few names. I've already explained the thing about intuition and speed.

And this is why some people don't know which case is actually Ga, which is Gd, etc. Which case is this?

I know which one it is, but I had to memorize that information. You don't have to memorize any specific cases with my method except for the 7 OCLL orientations.

But specific orientations are too much work, you say. And letters are just arbitrary! None of our other naming systems require specific solving orientation or letter schemes! Oh wait. PLL does. PLL demands you orient the cube in a specific way for each alg that you use and requires you to memorize a total of 13 letters, not including mirrors. My OLL system uses 7 + 4 + 1 dot case = a total of 12 unique letters, for 57 cases, including mirrors.

I don't know which G case is which, but I can use them just fine. You only need to say "G-perm" in conversation, and when you make a table or something you can just look it up. You don't need to memorize them.
And for orientation, there actually isn't a standard orientation. Depending on the alg you use, you start from different orientations.

 

[Razgorth]

Hm, no matter what recognition method one uses, in the end we still have to look at 3 edges and 3 corners at least? When solving I have full vision on top, front and right anyway, so no AUF needed and I can instantly spot the case.
Sure, I agree looking at UF twice (once for the top pattern, and once when looking at the front) is useless. But the good thing about top pattern recognition is that after it you have to look at 3 more side corners stickers at most, and one less for each oriented corner because we already saw it on the top.

This is what I've been trying to say the whole time, just in a different way. And no, you only have to look at 3 corner stickers for the H and Pi cases. For every other OCLL case, you only need to look at one corner sticker. ONE. TOP PATTERN + ONE STICKER. BOOM. MIND BLOWN.