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

[Gergely Nagy <greg gnome hu>]

Hi,

mega answering roll follows


First of all, Quim, thanks for coming up with such a great diagram! I
think it illustrates well what we are aiming to do, and it can help the
discussion a lot.

Jeff: I'm obsessed with URLs because it reflects the organization of
content, which is what we are discussing here. I don't think coming up
with the URLs should be an afterthought, it should be developed in
parallel with the content. I also think it helps distilling what we are
trying to put on-line, since good URLs are brief and descriptive.

I suggested the wgo/apps/appname URL instead of wgo/projects/appname
because i feel appname represents applications, and not projects. I hope
to spark a higher-level discussion by this, because I feel we (as in the
whole team) are not on a common denominator about this. More on that
later.

So I'm not saying we should carve in stone our URLs from day 1. But if
we cannot agree on the URL, it indicates we probably don't agree on what
they represent. I'm ok with having /projects/projectname instead
of /apps/appname, but then it's _not_ a software map anymore!

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

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.

We just have to make sure we can control the duplication. We can use
feeds, CMS features etc. For example, if we could use application
introductions in both the app pages, manuals, (which are translated
anyway btw), about boxes, etc, we could save some effort and come a long
way.

Also, I don't see us competing with gnomefiles.org, exactly because it
has different goals than wgo.


Jeff: projects.gnome.org is not just an implementation detail, it
implies we are offloading all that content to another site, that is
currently out-of scope. Also, when we are discussing things that are
out-of-scope, it is to determine what is in-scope. If things we push off
the table now fall into nice boxes, we can pick them up later and
continue there.

Currently I see no way to keep content in the wgo/* namespace without
putting it into the new CMS. So when we discuss wgo/projects/ we have to
know what belongs there, and what belongs to a projects.gnome.org. Also,
if we decide to just stick with a simple list of apps for now, we have
to decide what happens to the current wgo/projects/* pages. We'd be
crucified it those just disappeared until the next web release :)

Joachim's ASCII diagram about the split hits the nail on the head.
Quim's just looks prettier :)

As I mentioned in a previous email, I see wgo/apps as a middle ground
between a full-blown software map (gnomefiles) and the full-blown
homepages and project pages. Maybe I should have drawn something too :)

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.

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

If the list's sole purpose is to display what app is "officially"
considered part of gnome, it's like saying here is my nipple use it for
target practice. IMHO there is no single official list of apps, at least
not for Average Joe. What the foundation or the release team nods on is
irrelevant for him. What his distro supports, or better yet, what his
admins support (large deployments are after all our largest user group)
is his official list of software. So putting up a list like this has
IMHO little value for a large number of users, and will just get some
people offended (like Claus said)...

On the other hand, if the purpose of the list is to give some basic info
and links to further info, it has added value as a good aggregation. If
we say "this is the software we consider useful for our users, and it is
here to provide good starting points to discover them, and we maintain
this info in several languages so a lot of people can access them" is
way better than "This is our official list of software, click on the
names to go to their homepages. If you are not on the list, piss off"

Quim, and Gazim was it? "Not scrolling" is soo overrated. Screen sizes
(and windows sizes!) are not uniform, so there is no way of avoiding
scrolling. (To rant a bit, I hate designs which impose too much
structure on a web page. It might look cool on the designer's mac, but
as soon as you change font size, or resize the window so you don't have
to strain your eyes on miles long lines the whole layout blows up in
your face. I hope the new wgo will not do this...)

OTOH if you meant a screenfull of info, i.e. not too detailed, I agree.


Quim's notes on "featured projects". That's a great way of putting the
purpose of our own project (or app or product...) pages: "A product
featured page won't aim to substitute or shadow the product website: it
will introduce the product in a brief and tasty way like the trailer of
a film or the review of a book."

To recap my view about the app pages' added values:
- they are authoritative, which I'm rephrasing to mean "we guarantee the
information is useful, uniform, up to date, and available"
- they are translated
- 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

Joachim: your kitchen metaphor is great :))


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. It is somehow alien to me to send
Average Josephine to a "project page" when she wants to find out more
about her email app... I think for some visitors the project is not
interesting, only the app. For some it's both. Perhaps for some it's
just the project. I don't see how they are the same, and would recommend
keeping them separate and use extensive cross-linking and some
controlled info duplication, if necessary.

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

Greg