[Nipy-devel] website modifications

[Brian Hawthorne]

2 cents:
not to throw a wrench in the works just as consensus has been reached...
but i think a desirable longer term scenario might be for trac to support
easily
turning off the developer links on some pages and to transparently support
users without svn accounts.  then end-users can get the kind of distinct
wiki experience that we'd like to give them, on the trac site, without being
confused
by a bunch of technical info they don't need.

on the other hand, one of the great things about trac is its simplicity, so
maybe not.

-brian

On 5/14/06, Fernando Perez <fperez.net at gmail.com> wrote:
>
> Hey Jarrod,
>
> On 5/14/06, Jarrod Millman <millman at berkeley.edu> wrote:
> > Sorry for the delayed response, I was busy and wanted to see if anyone
> > else had any comments before I responded.  I don't know how coherent it
> is,
> > but here are my thoughts about the issues raised by Fernando's last
> email.
>
> Thanks a lot for this detailed reply.  I was half-way of either
> opinion for ipython (while strongly convinced it was the right choice
> for more visible projects like scipy), but I think after reading your
> reply, I'm happy going with the Moin setup for ipython as well.
>
> In fact, we already have a Moin up for ipython thanks to R. Kern:
>
> http://ipython.scipy.org/wiki
>
> But right now it's completely empty of either content or style.  But
> the engine is in place.
>
> > I think that we all agree that for any open development project it is
> > important to provide distinct user's and developer's sites.  I also
> think
> > that making the 2 sites obviously and *visually* distinct is important
> in
> > terms of user accessibility.  Having the 2 sites on different wikis is
> > a very easy way to achieve this.
>
> [ snip detalied discussion ]
>
> I actually find these arguments valid and convincing, so I'm going to
> follow suit with moving to Moin on the ipython site as soon as I can.
> I just need to get a bit of info on how to customize it a little, and
> on permissions (to avoid spam), and I'll be good to go.
>
> It's also true that a wiki (with suitable registration controls to
> prevent spam) is really effective at getting real community
> involvement.  The only catch with wikis is to keep an eye on them so
> they don't become too disorganized, but I know that for example you've
> already been doing precisely that with the nipy Trac.  I've also
> tried, on the ipython one, to have some broad categories, summary
> pages with all the relevant links, and to use the navigational aids
> (Trac table of contents plugins) to help.  So I think this is an issue
> that, with a bit of attention, can be managed.
>
> > Currently, both the ipython and nipy projects have a pure html user site
> > and a trac based developer's site.  I think that both sites work will
> > in the sense
> > that a new user coming to either site can quickly find the information
> they need
> > without feeling overwhelmed.  There is a lot of information pointed to
> > by the ipython
> > main site, but it is feels like the site is manageable, because it is
> > so visually obvious
> > that most of the links take you to "other" sites.  I know this may
> > seem like a small
> > point, but I think it has a big impact on the user's perception.
> >
> > A user coming to the ipython site first sees that almost everything
> > about ipython
> > for the user is contained on one page.  You can find out what it is as
> > well as how
> > to download, install, and use it fairly quickly.  You also find a host
> > of links to other
> > sites, which contain more information.  I feel that this gives the
> > user access to the
> > most important things quickly, but also conveys to the user that these
> > other sources
> > of information are not necessary to read in order to get some use from
> the code.
> >
> > I think that ipython and nipy would benefit from making the user sites
> > a little nicer,
> > but I would argue for keeping both sites visually distinct and very
> > minimal compared
> > to the developers sites.  Both ipython and nipy should have more
> > visually appealing
> > front pages, which convey a more professional image to users.  The
> > developer's site,
> > however, should be in a state of greater flux and have less gloss.
>
> The ipython single-page html site is getting /really/ long in the
> tooth, and I had been delaying doing anything about it out of pure
> laziness/business.  When I first put it up, it was OK (if barebones),
> but over time that single page has grown way too long, and I'm too
> lazy to do any decent CSS/navbars to make something nicer.  So I think
> that switching to Moin will allow me to just sidestep the issue
> altogether, and ride on the infrastructure which Moin provides (with a
> suitable theme) to get something a bit nicer.
>
> Thanks again for the feedback, I'm happy with this solution for
> ipython, and hopefully it will also work for nipy (even if, as you
> said, you delay a bit the creation of the Moin site).  I still think
> that eventually you'll want to treat your 'type 1 and type 2' users as
> clients of the Moin site, and leave the Trac one mostly for those
> interested in contributing to the core of nipy.
>
> I hope we're not underestimating the overhead of having information in
> two places, since there is still some danger of not knowing where to
> put certain things which arguably can be of interest to both end-users
> and developers.  But I guess we can try to sort such things out as we
> run into them...
>
> Cheers,
>
> f
> _______________________________________________
> Nipy-devel mailing list
> Nipy-devel at neuroimaging.scipy.org
> http://neuroimaging.scipy.org/mailman/listinfo/nipy-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060514/9a37e2d9/attachment-0002.html