Talk:Boundary Snap Guides

*Peter 14Apr13: I note that we need to make clear on this page the distinction between "Snap-to" and these "Snap-to Guides". This is because we have created confusion by giving these, two distinct (albeit mildly related) pieces of functionality, names that are too similar. Is there any chance that we could consider renaming "Snap-to Guides" to something more distinct from "Snap To" or is the nomenclature set in stone.

• Peter 16Apr13: Ok, it's time for some voting on nomenclature, I've combed back through the suggestions of the last couple of days:
  1. Snap-to Guides this is how it started out (on Audacity Selection) - Peter -0.5
  2. Selection Drag Guides - Gale suggested this - but it has the downside of the boundary case of point-snapping - Peter 0
  3. Snap Selection - Steve suggested this - Peter +0.5
  4. Snap Guides - Ed suggested this - Peter +1, Steve +1, Ed +1, Gale -1
  5. Boundary Snap Guides - Gale most recently suggested this variant - Peter 0, Gale +1
  6. Edge-Snap Guides - Gale later suggested this
  • Ed 16Apr13 IMHO - strictly speaking they are not just boundary limited - they work on point labels which don't really signify a boundary.
  • Peter 16Apr13: I strongly agree with Ed here. I *often* use theses guides to snap-to a point label - as a mathematician I am happy to recognize a "point" as a boundary condition of a zero-length region with identical boundaries, but I'm not sure that many of our readers would see it that way. And Gale you seemed to acknowledge the drawbacks of such boundary case in comments you made yesterday.
  • Gale 17Apr13: The distinction between "Snap" and "Snap To" is still not clear enough. Merely making the change encourages a belief that the behaviour has changed and the only thing it could change to is selection format snapping. I notice that even before I tweaked this we were mentioning about "physical boundaries" here (and not denying that a point label was a boundary).
• Ed implemented his Snap Guides on the latest version of this page and now that I see it on the page I *really* like this. It's succinct, it differentiates from "Snap To" while retaining the "snap" terminology - and it deals with both dragging and point selection.
• Gale 17Apr13: How about "Edge-Snap Guides"? Even a point label has an "edge", even if you look at the label representation in the waveform, right?
  • Peter 18Apr13: I have the same misgivings about "Edge" as I do with "Boundary" as far as point labels go - they are pretty synonymous after all. We do mention "boundary" in the intro note (3 times) so I don't think it is necessary to load the nomenclature with either "Boundary" or "Edge" personally. If you, Gale, are dead set on "Boundary Snap Guides" for the nomenclature (and page title) then I can live with that but I would want extra explicit clarification in the intro note that a point label is effectively a boundary itself.
  • Gale 19Apr13: I liked "Snap Guides" as soon as Ed suggested it, and still think it acceptable here. But I have come to think it's a liability on Audacity Selection where we have to discuss Snap To in close proximity. I think that if we change the name "Snap-To Guides" we should change to something completely unambiguous.

    I would strongly support "Time Snap" instead of "Snap To" as I think it would aid understanding. "Edge-Snap Guides" or "Boundary Snap Guides" are what they are - the documentation on this page proves that point. "Location Snap Guides" seems vaguer to me. I've made some clarifications for point labels in intro and "How Snap Guides" work in any case, as I think they are beneficial.

  • Peter 19Apr13:You're confusing me a bit here Gale. Are you saying that you think that it's ok to use "Snap Guides" as the nomenclature here and that we should campaign for the existing "Snap To" in "Selection Toolbar" to be changed to "Time Snap"? If so then I would support that idea, but we should probably not initiate the "Snap To" campaign until after the possibly impending 2.0.4 release, don't you think? If we do settle on "Snap Guides" then in the text on the page we can refer to "boundary Snap Guides", edge Snap Guides" and "point Snap Guides" wherever appropriate defining boundaries/edges or points.
  • Gale 20Apr13: I think "Time Snap" would be a beneficial change irrespective of how to name Snap Guides in the Manual. As you know, some people think Snap To snaps clicks or labels to selections (another reason why I am against "Selection Snap").

    I think it will be better not to talk about "edge Snap Guides", "boundary Snap Guides" or "point Snap Guides" because we then could not say in the intro that guides snap to physical boundaries (which is better than saying "physical locations" IMO). More important, your suggestion would run into "is a line an edge or not"?

    I would accept the following intro, with a page title of "Boundary Snap Guides". We use that term on linking to this page, but use the contracted form "Snap Guides" in the text:

    Boundary Snap Guides (or "Snap Guides" for short) make it easy to draw a selection that starts or ends at a physical boundary like a point or region label or a clip inside the track. Snap Guides also let you exactly place the cursor at such a boundary.

    When the selection or cursor exactly aligns with the boundary, the Snap Guide appears as a yellow vertical line at the point of alignment.

    Even if we rename "Snap To" to "Time Snap", the title "Boundary Snap Guides" makes it much clearer than "Snap Guides" that the guides snap to physical boundaries and not to time formats. Since some boundaries may not always be presented as an "edge", I prefer "Boundary Snap Guides" and in-text "Snap Guides" to "Edge-Snap Guides" everywhere including in text.
• Peter 20Apr13: Fair enough, sounds good to me - I'll work on that. Update: done.