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

[Jeff Waugh <jdub perkypants org>]

<quote who="Gergely Nagy">

> The original subject of this thread was Software Map

Which is the wrong way to think about the problem, isn't it? That's why I'm
pushing for a different way of thinking about it.

> Currently /projects/* _is_ just a list of applications

It's not really. Have a look. It's a grab-bag of crud. Libraries, websites,
components of the desktop suite, unrelated things, and a few applications
mixed in.

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

Okay, so: The task is not right. Nor is the analysis of /projects/. Let's
think about *user goals*, not mashing the crap we have into the crap we'll
have next. Yes, sorry, I'm being blunt.

I started on this thread by suggesting that we're approaching the problem
the wrong way. I'm still saying it. Does your Mum want a software map? Mine
doesn't. Mine wants to know more about "Tomboy" when her friend tells her
about it, and wants to find out about the cool new things in GNOME, and if
there is another way of doing her email. She wants to know if there is a
project management program for her GNOME laptop. She wants to know how to
add cool new backgrounds and panel applets. She wants to tell the Evolution
developers that they rock, and file bugs on her file manager. She wants to
know where to send my brother when he decides he wants to work on software.

"Software Map" is not the right way to approach these problems, and it's not
the right way to get things our users care about on the page.

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

That's fine. We're running to a highly compressed schedule. We can make the
template look reasonably similar. We Have The Technology.

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

Wrong, or maybe it was a trick question: Safari is part of the Mac OS X user
experience. Nautilus is part of the GNOME Desktop user experience. If you're
keen on thinking in terms of products and projects, then both of these fall
into the category of products inside projects. (Not that I think this debate
is entirely useful, I just wanted you to think more about URLs and what I'm
saying about products vs. apps vs. projects, and why it's not so scary.)

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

Exactly my point. So why split?

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

Nautilus is part of the desktop experience. /desktop/ -> /desktop/files/ if
you want to think in URLs.

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

/platform/ -> /platform/tools/ if you want to think in URLs.

> Clear? ;-)

No, you're not clear on this. You're trying to solve problems that are not
interesting enough to our users to solve. Let's not do that.

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

Right, okay, so this is clear: You *are* suggesting that projects.gnome.org
be like a gforge or trac, in which case this is TOTALLY different and
FUNDAMENTALLY out of scope for this project. Let's not bring up projects.go
again when trying to solve the problem of presenting our products to users
on wgo.

Thanks,

- Jeff

-- 
linux.conf.au 2007: Sydney, Australia           http://lca2007.linux.org.au/
 
      "Life is short. Forgive quickly. Kiss slowly." - Robert Doisneau