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 -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list