Steve Bennett wrote:
- Then we realised that redirects are required to make existing articles
work, not just for searching.
- Having both redirects and another system would be kludgy and complex.
Sorry for this long post, but perhaps part of the difficulty so far is that different concepts, from "different levels of abstraction" makes it difficult to clear things up. Short version: Redirects is primarily a *technical* concept, while you suggested a use case (which may, or may not, cope, or interfere, with the aforementioned technical concept). So to speak.
In other words, don't make, in an early stage, any assumptions at all about Redirects' be or not to be, until the use case (from the users perspective) is very well defined, and optionally, till the Redirect concept is very clearly understood, as a very good and generic abstraction useful as a (technical) design concept (in any complex system really).
Its always good with attempts, and attitudes, which aim to get rid of a problem entirely, preferably before it even rises. But I think that the existing Redirects really serves a purpose, and it is a technical concept rather than a "use case" that should be exposed to the users. This may cause some confusion if not kept apart.
Therefore, don't confuse Redirects per se, with any good ideas about use cases solving real problems for the editors.
In reality Redirects handles, under the hood, real problems, as "freestanding" helpful "guides", which will not go away very easily. This is because some of the problems it solves stems from the way we humans function. Example: People tends to not always find the best title for a topic directly. Then, when a better title is found later, someone may already have linked to the first/old title. Then it is convenient to be able to move a page, and automatically leave a (freestanding) Redirect behind as to not break existing links to the old name/title.
This use of Redirects simply is a good solution. It solves a real practical problem, in real use case(s) (both when moving a page, and in continually catching the now "bad links" in the system). It's just a charmingly good solution.
The Redirect concept actually abstracts a very basic concept in any complex system. The point is that basic concepts implies "useful for many things", which is exactly what *designers* look for when they search for or design their tools for solving things. And in such a complex web of information as WP really is, don't remove redirects, because Redirect is a tool, a technical good "meta solution" to more than one problem. But such (technical) design tools are not necessarily best exposed "naked" to the users (which currently is the case with the present Redirect solution).
So what I am saying is that whether, and how, Redirects are exposed to the users, is quite another matter. You usually do NOT expose abstract "meta solutions" to end users of a system.
I think that this thread is, at least in part, about different use cases useful for editors for this and that. Even if the thread is about a use case, the underlaying technical implementation c-a-n be discussed at the same time. But the technical implementation must not be confused with the essence of the Use Case! Well designed systems often have abstract "meta solutions" which solves, or aids in solving, many *different* problems, meaning that multiple Use Cases may have use for the same meta solutions under the hood. The Redirect concept is such an abstract concept which can serve many purposes and Use Cases.
Therefore: Define the use case(s) (of this thread) 1. very well, 2. unambiguously (... :), 3. with a name/names which catches the core idea v.e.r.y clearly (that's the purpose of a name, really. A bad name/broad meaning = sloppy specification, good name = stringent specification). 4. And, do not bother too much about the redirects early in this process.
The only "problem" with redirects may well turn out to be that they are exposed to the users (!), not that they aren't doing a good job under the hood, even for several different purposes.
After having a concrete (Use Case kind of) specification of the need and functionality of the feature, it will also become easier to pick, or develop, the best technical implementation for just that well defined feature.
Regards,
// Rolf Lampa