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