Return-Path: Mailing-List: contact community-help@apache.org; run by ezmlm Delivered-To: mailing list community@apache.org Received: (qmail 60068 invoked from network); 5 Nov 2002 15:44:07 -0000 Received: from unknown (HELO set.superlinksoftware.com) (66.35.175.110) by daedalus.apache.org with SMTP; 5 Nov 2002 15:44:07 -0000 Received: from dhcp-64-102-71-144.cisco.com ([64.102.71.144]) by set.superlinksoftware.com (JAMES SMTP Server 2.1a1-cvs) with SMTP ID 785 for ; Tue, 5 Nov 2002 10:27:47 -0500 Message-ID: <3DC7E6CB.4090400@apache.org> Date: Tue, 05 Nov 2002 10:42:03 -0500 From: "Andrew C. Oliver" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: community@apache.org Subject: [offline] Re: Subtle barriers to entry References: <3B622F05-F030-11D6-9F7D-003065F93D3A@topsail.org> <3DC6D3DD.DE632DAA@Golux.Com> <3DC6F160.808@apache.org> <3DC7B04F.5010604@apache.org> In-Reply-To: <3B622F05-F030-11D6-9F7D-003065F93D3A@topsail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: > Andrew C. Oliver wrote: > >> > >> > >> > since i answer the asf email, this is something that has bugged >> > the crap out of me, and about which i have complained several >> > times to no avail. >> > >> > there is no canonical /mailing-lists.html location to which >> > i can point people for j random project, so i have to tell them >> > to search the project site for the info. that sucks. >> > >> > >> >> so fix it. > > > Uh, Andy, that helped a lot. Thanks. :) No problem ;-) > > Can you estimate the emount of energy it takes to go into every > project and tell them to update their site? or, if you want to do it, > why do you think they would agree with you? maybe they don't like the > URI name, maye they have a community.html page that already lists > those things. or maybe, for whatever reason, they don't want > development mail lists to be easy to find (I did needed that once in > order to slow down community building!) That is another issue entirely. Whether consistancy and usability has a cost-benefit ratio that makes it worth your while. Or whether consistancy can be a goal in a diverse group of people whom are not beholden to your goal. > In fact, Forrest is just *one* possible use of Cocoon. Forrest is a > Cocoon spin-off, but the great value is its focus: come up with a way > to generate a *nice* web site, nice navigation, nice look&feel, easy > content administration. In the future, we might also include a > web-driven content management system on top of Forrest (running Cocoon > underneath). Although I use Cocoon for this task, to be honest its not very well suited for this in my opinion (and I'm sorry to say this). Its much slower and sucks down way more memory than anakia/etc does to generate static documentation. Now for dynamic stuff, Cocoon is defintely the cats meow but if it weren't for the fact that Nicola Ken has made documentation with XML brainless for me, I'd probably use something else. I'd like to see either Cocoon increase performance by about a factor of 3 and decrease memory consumption by at least a factor of 3 for static documentation generation or see Forrest support other suck transform engines in a pluggable manner so that those can be fast. > > I spent several months with my former girlfriend (who is a usability > engineer) to design the Forrest layouts and the usability of the > navigation. A lot of work has ben put into that, while other efforts > (maven, stylebook) simply didn't care about navigation and usability, > but just about look and ease of regeneration. And it looks really nice. I can't wait to use it. It has made it on my palm pilot based task list (along with voting to put a burr in Bush's boot which I did today ;-) ). Ease of regeneration is usability for developers. > > Of course, I'm way biased here, so don't start a maven vs. forrest > pissing contest, please. > > I just want to point out that the only way I see to fix our web > interface problems is to create better tools and hardcode a number of > usability guidelines into them. I disagree. The tools do not make the man, nor do they make decisions. I'm actually rather suprised to hear this from you. One of the reasons I prefer Centipede (for instance) over Maven is that it enables me to do things my way where maven tends to tell me how I must do them. There is an inherent disabillity towards consistancy in this type of development and I think the best way to afford it is through personal leadership. (Look at the architecture of Cocoon, the only thing consistant about it is Avalon and XML technologies....the rest is often more different than night and day). Another approach to this (rather than try and create tools for folks to do things your way) is to simply pick up the hatchet and create a site for all of the projects that is consistant and etc. One way to do this is to get like minded people like yourself start it and see if others come and fall in line... Perhaps forrest is exactly that.... However its success depends on a number of folks saying "gee thats a good idea" and "gee thats easy to use" (from a developer standpoint) and "that sure is pretty"... And in the end since this is apache we'll have at least two competing versions ;-)...Perhaps as our community becomes less western centered we'll become less concentrated on dualism and more concentrated on diverse cooperation. So I think I agree with your methods and, etc, but not your perspective on the matter ;-) > > Starting with a project.xml info file is a great thing and we can keep > going from that point on. > I agree. -Andy