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

[Gergely Nagy <greg gnome hu>]

On Tue, 2006-08-08 at 02:36 +1000, Jeff Waugh wrote:
> <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 use URLs as a thinking aid. We apparently just think differently :)


> 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.

The original subject of this thread was Software Map, and /embedded/
and /platform/ are _not_ software. They are something more top-level,
and I agree, they deserve their own place. They must be discussed, I
just didn't get how it involved this thread.

Currently /projects/* _is_ just a list of applications, and I had the
impression the new software map was supposed to be the new, standardized
list of those apps. Perhaps my mistake.

> > 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.

Let's start a new thread on products, I think it deserves it.

> > 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).

I think you got it backwards. I did not first think let's have wgo/apps,
what shall we put there? I considered the task "Sofware Map", looked at
the current /wgo/projects/* pages, realized they were all about
applications, and suggested to place them under /apps/. I also said I'm
ok with doing a /projects or something instead, but that is a different
thing then!

> > 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.

It's not just about that. It will look and feel different, just not
integrated.

> > 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.

safari == safari. nautilus "part of" 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.

This thread is about a list of software.


> > - 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.)

A hub does not split, it connects :)

> > 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? ;-)

We present those things elsewhere. On the desktop solutions page you
don't want "Nautilus is what makes your desktop tick" (what about
beagle,dbus,etc,etc,etc). On the nautilus page you do. Similarly we
don't say on the developer platform page "You can comfortably develop
your gnome software with Anjuta", on the Anjuta page you do. You don't
say "The Gnome Desktop allows you to manage your data with ease" on the
beagle,nautilus,evolution,etc,etc,etc page. You say that on the desktop
solutions page.

For what you are suggesting we need new pages, definitely. But that's
not IMHO for this thread, really.

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.

I suggested to make them trac-like. I disagree with cp -r wgo/projects
prgo. I suggest to redo wgo/projects/ as wgo/apps/ AND create XYZ
projects pages that can reference those where appropriate.

Greg