Re: gnome app pages (was confusingly Gnome Software Map)

[Jeff Waugh <jdub perkypants org>]

<quote who="Gergely Nagy">

> Jeff: I'm obsessed with URLs because it reflects the organization of
> content, which is what we are discussing here.

Talking about URLs just distracts from your focus on the design. You're
putting the horse before the cart. All this talk about projects.go and
/apps/ and so on - these *are* implementation details because you've not
described what you're trying to achieve with either.

> I suggested the wgo/apps/appname URL instead of wgo/projects/appname
> because i feel appname represents applications, and not projects.

And yet, time and time again in this thread I've pointed out that we're
*not* just talking about apps. Use /embedded/ and /platform/ as immediate
examples for your thought experiments. They are products that we need to
demonstrate and canonicalise, but don't fit into /apps/ at all.

> Another thing: thinking about URLs early can avoid confusion later. E.g.
> the URL www.gnome.org/evoltuion came up in some emails. Can you guess
> what it means? It shows it is probably not a good idea to put arbitrary
> app or project names in /, so we *have* to find some organizational
> principle for them. And as it seems, such organization is not trivial :)

The top level URLs were suggested specifically as a navigational aid. Where
does www.apple.com/safari go? Where should www.gnome.org/nautilus go? These
are much easier to answer when you realise that we have products to talk
about, not just apps. Our machinery-exposing /start/ can go away, and we can
focus on user-centric product pages.

> Gezim and Jeff: controlled duplication of information is not a bad thing.
> One reason is aggregation, for example the blog planets. There is added
> value in pulling info together from a number of places. Another is
> repetition while drilling down into a complex topic. Yet another is
> different views on a complex topic.

Totally agree, but if there's going to be value in doing this (and value for
maintainers to use it), then there should be a single tie-it-all-together
location instead of wgo/app, projects.wgo/app, app.com, etc. This is why the
URLs are implementation details - *first* you need to define what is on one
of these pages so it is of value to our target users. Defining URLs and ways
to place this data in the structure without doing that is just spreading
crap around. :-) DOAP is going to be extraordinarily useful here, because it
can be useful beyond wgo itself (we have a lot of associated projects with
their own sites).

> Jeff: projects.gnome.org is not just an implementation detail

As above.

> Currently I see no way to keep content in the wgo/* namespace without
> putting it into the new CMS.

That's a very simple Apache configuration change. We need not be concerned
about this (or breaking the existing wgo/projects URLs) at all.

> Joachim's ASCII diagram about the split hits the nail on the head.

It didn't, for the reasons I described. It makes no sense to 'split' things
like this.

> In this respect I see projects a bit orthogonal, since projects include
> applications (one or more), or perhaps none at all. That's why I'm a bit
> confused why Jeff is merging the two. We need more discussion here.

Consider /safari/ vs. /macosx/features/safari/ and our Nautilus vs. Desktop
Suite.

> Claus' and MurrayC's comment about the purpose of the software list:

Let's leave the list question unanswered for now, and focus on getting good
product pages going for the obvious things. When we've delivered something
that maintainers want to piggy-back on, then we can worry about this. Let's
work with the obvious stuff - the GNOME release suites and technologies, and
documenting them for our target users.

> - they are good entry points for a lot of users
> - and good link targets for other pages!
> (the last two implies it's a good "cyberhub" :)
> - they do smart duplication by aggregating and distilling

(Which, to my mind, implies not splitting things badly.)

> Jeff: about apps vs projects
> I don't know why I keep subconsciously rejecting presenting apps as
> projects, maybe I feel they are not the same. While it's true that apps
> are produced by teams as a project, it is not necessarily the best way
> to present this to our visitors.

Describe how we present the GNOME Desktop solution to our users as an app,
then describe how we present the GNOME Developer Platform technology to our
users as an app, and finally, describe how we present GNOME Embedded
technologies to our users as an app.

Clear? ;-)

> I would also like to mention, that Jeff's project pages are (most
> probably) different from the project management pages that we are
> outlining for projects.gnome.org. Makes me wonder even more :)

I've yet to see a description of projects.gnome.org that wasn't "let's move
wgo/projects there". If someone's thinking about this being like a GForge
for GNOME, then it is a TOTALLY different thing and FUNDAMENTALLY out of
scope for this project.

- Jeff

-- 
linux.conf.au 2007: Sydney, Australia           http://lca2007.linux.org.au/
 
  "A problem worthy of attack, proves its worth by fighting back." - Paul
                                   Erdos