-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All in all, I'd have to agree with the sentiments of this. I don't think anything should be taken personally although I know some personalities might be inclined to react emotionally at the words used, but if you look at the sentiment I believe it's right on. Your users may be developers, but not necessarily for your project. Treat them to a 'user' site.
Brian Tim O'Brien wrote: > On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote: >> <snip> > > > >> Something to think about is maybe not having the initial Maven page be a >>> Maven site. ASF sites in general seems to be more Developer focused >> than >>> user focused. What if the initial Maven site were more like the front >> pages >>> of Mozilla or Rails. An attractive logo, links to resources and >> materials, >>> an introduction. The home page should be user focused, Maven developers >> are >>> a minority of the audience here. >> Are you saying that the developer-centric tendency is appropriate for >> ASF project web sites, then? I'd tend to say that for a product like >> Maven (not an API, like commons-cli, for instance) it's worth striving >> to help the user. Since Maven is an Apache product/project, I'd say that >> having a developer site on a different physical location would be >> bad...they're different aspects of the same product/project. That said, >> I think we need to section the developer docs off and put them a click >> or so in from the main landing page...probably with their own landing >> page. > > > I think I agree with you. > > When I said "developer-centric" I meant > "apache-developer-centric". IMO, more projects need to think about the user > who has "30 seconds to figure out the best way to download/use Derby". The > current Maven site has too many links, too much distracting people from what > should be a simple message - "Download Maven, you won't believe how you > developed without it. We promise.". I'm not saying that we should all > become marketing people, but it's something to consider. > > >> It's not a simple hierarchy, but then, we have a great deal of variation >> among our audience members. As these audience members [possibly] >> transition from users to contributors and so on, we don't want a >> separation like this to get in their way...there should be *some* >> cohesiveness, I would think... > > > I'm not saying this to be contrary, bear with me: most people that use > Maven don't care to know much about the internals or how it is being > developed. They simply want to download a product that works, is > well documented, and use it. A small minority of those users will get an > itch that needs to be scratched or decide that the gift of free software > should be repaid by involvement in a community. So, if you wrote up a > survey, and quizzed people who use Maven every day, I think you'd probably > find that most of them think Jason van Zyl is a famous magician and the > Meritocracy is a spell in Dungeons and Dragons. I'm not saying this as a > cynical jibe, but to make the point that regardless of the Maven website, we > will always about an equal mix - out of 100 - 95 people download Maven, 5 > subscribe to the users list for a week, maybe 4 ask questions on the user > list, and, if you are lucky, 1 submits a patch. And even that's > overestimating, apply that forumla to the httpd project and it would have > 10^5 patches submitted per year. > > Turn your statement around. "....audience members [possibly] transition > form users to contributors". Assume that a simpler user focused launch > page made it easier for people to adopt Maven. If this "separation" of > user-focused and developer-focused documentation increases the population of > users, we've increase the pool of potential contributors. I'm betting on > the fact that as users "root around" the documentation, they'll catch on to > the fact that this is the ASF they will pick up the community. > > I think a good strategy is to make the landing page for Maven as simple as > possible, with a good short sell, as little text as possible, link to > download, and some news and announcements. The Maven launch page should be > very similar to the Mozilla launch page - there are still links to the > developer pages. > > Instead we've got a link named "Netbeans Module", a link on the top of the > page to "Maven" followed by a link to "Maven 2.x" and "Maven 1.x". All the > links have a 20% change of having a completely different skin. There are > links to a Wiki and external sites that are not labeled as such. There is a > "Project Team" report (http://maven.apache.org/team-list.html) that doesn't > list have of the people involved in Maven. Did you know there are no > contributors to the Maven project and that there are only 8 people working > on Maven"? For some reason, I know what the "Actual Time" is for all the > people on the project team down to the second (I've never figured the need > for that field out), but good luck customizing the team-list support. :-) > Here's another good one, click on a Guide, then click on the banner logo. > That links back to /guide, click on the same banner logo, that links back to > the home page. The Maven site is full of these inconsistencies, and it's > not something that people can just fix with patches. IMO, the site plugin > needs serious rework. It doesn't create good web sites, especially > for multi-projects. > > I guess I've just pissed off the Maven development team by telling all of > you that Maven doesn't do a good job of creating web sites for > users. There, I said it. Maven creates so-so web sites for developers, but > doesn't do a good job creating web sites for end-users. Maybe that was > never the goal. Maybe I should just shut up and write the > maven-end-user-site plugin? But, it's one reason why I didn't get too > exctied about contributing to the site last year. I don't think another 100 > APT documents are the right direction, I think you need to think long and > hard about the audience, and I think someone other than Hani Sulemani needs > to say "Maven sites suck" :-) The fact that one of the core committers > for Maven, had to send out an email entitled "Making the current web site > suck less", is not a good sell for generating sites with Maven. > > >>> >>> On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote: >>>> +1 >>>> >>>> Maybe we can put a banner at the top of each page that marks the >> version >>>> it refers to or something. If we styled the reference doco as a manual, >>>> it could be part of the page layout that ties it together. I'd be >>>> willing to trade a bit of the look&feel for that sort of information, >> as >>>> it seems to me that it would reduce confusion. >>>> >>>> -john >>>> >>>> Tim O'Brien wrote: >>>>> Having to choose between publishing the latest and greatest docs and >>>> only >>>>> the released version is a problem that Maven seems to have created for >>>>> itself. Same issue comes up in other projects frequently - Commons >> has >>>> a >>>>> problem because some of the sites only publish on a release. Latest >> and >>>>> greatest are almost never there. >>>>> >>>>> What about publishing the latest and greatest docs to another >> directory? >>>>> The Maven site gets pushed to a directory that has a version of a >>>>> label. http://maven.apache.org/version/1.0 >>>>> , http://maven.apache.org/version/2.0.2, and >>>>> http://maven.apache.org/version/trunk. This way the Maven site can >> have >>>> a >>>>> nightly publish of the most current Maven site to Trunk every single >>>> day, >>>>> but still keep legacy docs around intact for people using older >> versions >>>> of >>>>> the product. The "consumer" site can point to the latest release, and >>>> the >>>>> "developer" site can point to "trunk". The Maven site plugin would >> need >>>>> some mechanism for adding a skin to a site to clearly identify it as >>>>> "Development". >>>>> >>>>> >>>>> >>>>> On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: >>>>>> On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> * I'm still a little torn on where plugin docs go. No hurry on this, >>>> but >>>>>>> something to ponder. We definitely need to make the references for >>>> those >>>>>>> integrate better. Site/skin inheritance will help >>>>>> No matter where they go, I think they need to be updated more often. >>>>>> Random example... the assembly plugin docs are wrong, and have been >>>>>> that way for months. (it's descriptorId, not >>>>>> maven.assembly.descriptorId.) >>>>>> * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html >>>>>> >>>>>> I would like to see the "latest and greatest" docs on the main site. >>>>>> Yes, they'll be ahead of the released version, but not by much, and >>>>>> (hopefully) not for long.When the answer to a lot of "X doesn't work" >>>>>> questions is "It's fixed in the trunk, use a snapshot," it would be >>>>>> nice to have the snapshot docs available in a centralized place. >>>>>> >>>>>> This also makes it more fun to contribute to the documentation, >>>>>> because you get to see your work "in print" right away. >>>>>> >>>>>> Thanks for updating the main site. :) >>>>>> >>>>>> -- >>>>>> Wendy >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFED8RGaCoPKRow/gARAtP4AKCJQwdMKZ9zLx3TtznXjNspY4L2PQCfSqDt nRLUZCjKfHinJS/Tog+xJec= =xRRx -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
