On 20 Jul 2006, at 22:34, John Hwang wrote: > In light of the non-developer end-users, > http://www.gnome.org/project/nautilus seems like too much information. > "Project" has a specific meaning about nautilus and a user doesn't > care that nautilus is a project of Gnome. In my opinion, > http://gnome.org/nautlius or even http://gnome.org/programs/nautilus > makes more sense.
Of course, nautilus is a particularly troublesome case anyway, because many users will potentially never know that their file manager is called 'nautilus' at all. So perhaps we'd need to set up something like gnome.org/filemanager as well... Cheeri, Calum. > > On 7/20/06, Thomas Wood <[EMAIL PROTECTED]> wrote: >> Calum Benson wrote: >> > On 20 Jul 2006, at 07:59, Quim Gil wrote: >> > >> > >> >> Ok, then we would have www.gnome.org/projects/* pages which >> would be >> >> feature pages from projects, probably elaborated by the marketing >> >> team, >> >> while the project pages themselves would fall out of our >> >> responsibility >> >> and would be placed under projects.gnome.org/* >> >> >> >> Since we don't have project feature pages, all the current >> projects >> >> should be under projects.gnome.org/* , we need to decide which >> feature >> >> pages we want to have for the current release under >> >> www.gnome.org/projects/*, and do them. >> >> >> > >> > Is there really any need for the intermediate "projects" level >> in the >> > URL, btw? I always find it unbelievably convenient that the home >> > page for every major Apple application is just http:// >> www.apple.com/ >> > <appname>, for example. >> > >> I would tend to agree here. I think it is important we have a >> number of >> gnome.org branded home pages for the key applications within the >> desktop, like apple.com does. For example, and introductory page for >> nautilus might be at www.gnome.org/nautilus or >> www.gnome.org/projects/nautilus. This would serve as both informative >> and marketing to new users. >> >> Whenever I see projects.gnome.org it makes me think of a sourceforge >> type site the provides hosting and other services. Do we really >> want to >> be a hosting service for some (but not all) gnome related >> projects? Even >> sourceforge does not have directory level urls for each project. >> Instead, each project gets it's own sub-domain. >> >> If we went ahead with just moving gnome.org/projects to >> projects.gnome.org, I don't think we would be solving any >> problems. The >> only problem with /projects at the moment is that it frequently >> causes >> problems with the website build. We could solve this by moving it out >> into separate module(s). The only other problem is that the sites >> don't >> follow the www.gnome.org design, but I think this is outside the >> scope >> of the main www.gnome.org revamp (we need to concentrate on our >> content, >> not other people's). >> >> I hadn't prepared a partitioning draft yet, partly because I >> hadn't been >> aware my name was next to the task, but also because I can not see >> many >> reasons for changing most of the current arrangement. The only >> changes I >> would make would be to either update or remove >> developer.gnome.org, and >> move some of the more anomalous sub-domains to other places (e.g. >> glade.gnome.org moves to www.gnome.org/projects/glade). >> >> So, let's focus on sorting out our own content before we start moving >> other things around. We will have to provide legacy links anyway, so >> there seems little point in moving something unless we are >> absolutely in >> agreement it's what we want to do. >> >> -Thomas >> -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED] Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
