RE: subproject layout conventions
Leo Simons wrote: As long as we agree that nothing should get into the way of site functionality (and we do), why would you oppose a site that also is easy to navigate and looks good? The only thing I oppose is the idea something being set in stone or approved by some mythical designer. http://www.mail-archive.com/general%40jakarta.apache.org/msg04500.html ouch. Bad wording. Not what I ment. I'll -1 myself on that :) We're in agreement (I was sure we were, just didn't get where it went wrong). Sorry to waste your time. regards, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On Thu, 2002-03-28 at 17:12, Pier Fumagalli wrote: Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) +1 Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
-Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 5:12 PM To: Jakarta General List Subject: Re: subproject layout conventions Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Whatever hater ;P It pays the bills, ya know what I mean? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Leo Simons wrote: I very much agree. I was under the impression though that at this point, there are some designers available somewhere. It would be good if they would explain which things would be good to change so we can put that into the system. There is no paid staff, and AFAIK, no designers who are also committers. And even if there was one, we can't depend on something like that. We can depend on there being programmers here, otherwise there would be no living products, and before long, no users or Website to worry about. except that the website is not only for geeks. It's also for people that make decisions and have money. Says who? I'm thinking Jakarta is a developer-to-developer site. If other stop by, they're welcome, but our focus has to be on what we know. Personally, I leave the eye-candy to others, and focus on functionality. Given the products we write here, I think that's going to very common. I'm not saying that I would be particularly interested in any design anyone else came up with. I'm just saying that if I need to change it, I'm going to change it, because there ain't nobody else here to do it. Personally, I'd say it's better that our sites don't look ~too~ good. That way people don't get the wrong impression. There is no commericial support here. Just a bunch of volunteers doing the best they can. Jakarta is an all-you-can-eat buffet, and should probably look like one :o) -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On 3/29/02 8:26 AM, Berin Loritsch [EMAIL PROTECTED] wrote: -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 5:12 PM To: Jakarta General List Subject: Re: subproject layout conventions Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Whatever hater ;P It pays the bills, ya know what I mean? So do my Mac's running OS X. (OS X is another story...) It's java! Come to the light! ;- -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Java : the speed of Smalltalk with the simple elegance of C++... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
There is no paid staff, and AFAIK, no designers who are also committers. The maven layout looks like it has been designed by a designer. except that the website is not only for geeks. It's also for people that make decisions and have money. Says who? Me. I wan't to use jakarta stuff in the 'corporate' world. Parts of the corporate world want a 'sleek' looking site. Where it doesn't hamper anything else, I think there is no problem making the site look 'sleek'. Personally, I leave the eye-candy to others, and focus on functionality. I thin navigation is part of functionality, not eye-candy. Without navigation, you need to know the address of every web page on the site. I'm not saying that I would be particularly interested in any design anyone else came up with. I'm just saying that if I need to change it, I'm going to change it, because there ain't nobody else here to do it. I need to change it, so I want to do so. Since I believe the changes I need to make will benefit all of jakarta, I am trying to make them in a way that all of jakarta can live with. Personally, I'd say it's better that our sites don't look ~too~ good. Don't worry, we're not gonna look too good just yet :D That way people don't get the wrong impression. There is no commericial support here. Just a bunch of volunteers doing the best they can. Jakarta is an all-you-can-eat buffet, and should probably look like one :o) Jakarta is partly funded by commercial companies. I think some of them would rather not be associated with something looking like an all-you-can-eat ;) As long as we agree that nothing should get into the way of site functionality (and we do), why would you oppose a site that also is easy to navigate and looks good? regards, - Leo __ Launch your own web site Today! Create a Web site for your family, friends, photos, or a special event. Visit: http://www.namezero.com/sitebuilder -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
-Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] On 3/29/02 8:26 AM, Berin Loritsch [EMAIL PROTECTED] wrote: -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Whatever hater ;P It pays the bills, ya know what I mean? So do my Mac's running OS X. (OS X is another story...) It's java! Come to the light! ;- I said it pays the bills, I didn't say it was the best... Besides, MS Word is not Java--and it costs too much not to have it bundled with a new machine. (I looked at Mac laptops, really). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Leo Simons wrote: As long as we agree that nothing should get into the way of site functionality (and we do), why would you oppose a site that also is easy to navigate and looks good? The only thing I oppose is the idea something being set in stone or approved by some mythical designer. http://www.mail-archive.com/general%40jakarta.apache.org/msg04500.html I need to change something, then I will change it. Everything is a shared resource here, and every committer is encouraged to take whatever action they feel prudent. I actually support what you are doing, so long as you remember who you are doing it for. The committers are the bosses here. Everything we do has to empower the committers and help them get past the adminutia and on with the development; or else there will be no committers, no products, no users, and no Web site. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On Thu, 2002-03-28 at 01:14, [EMAIL PROTECTED] wrote: Jason van Zyl [EMAIL PROTECTED] wrote on 28/03/2002 08:15:53 AM: On Wed, 2002-03-27 at 17:13, Leo Simons wrote: It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. http://jakarta.apache.org/turbine/maven/ There's a sample structure there, with lots of documentation and the printable pages issue is dealt with. Hey Jason, don't undersell Maven :) It's a godsend for projects. I will undersell it until it is at a point where it not only works (it works fine now) but when it is transparent for clients to absorb changes that are made. If the project descriptor changes, or the way the process works, or stylesheets change, or additional documents are added then I want automatic transformations to upgrade the project descriptor and a mechanism to allow clients to take advantage of the change immediately with no hassle. Right now I know of 33 projects using Maven and it is still a PITA when a change is made and this has to be dealt with before I would push anything. There are tools in Maven that can deal with XML xformation (using dvsl) and non XML xformations (using ORO) but they aren't integrated yet. So I'm still looking for the combination of easy propagation (the InstallAnywhere installers are getting there) with easy forward porting. But we're going to release a beta anyway :-) It works great right now, but the process and mode of communication with clients is just as important IMO, and the source of most problems. Most people here could probably get Maven running pretty quickly but it's the not no experienced developer that I'm targeting. Not only does Maven provide docs, pages but it also helps with jar file downloading, dependencies, mailing lists, build file reuse, metrics, code cross reference and more. Bring it on! We're getting there. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
On Thu, 2002-03-28 at 09:05, Berin Loritsch wrote: -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED]] On Wed, 2002-03-27 at 17:13, Leo Simons wrote: It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. http://jakarta.apache.org/turbine/maven/ There's a sample structure there, with lots of documentation and the printable pages issue is dealt with. I'm aware of that. Not going into the html / css it uses, I think it does not address the issues mentioned in my last post (it addresses some others _really_ well though). I would be happy if we had something like Maven for the general site, or even the Avalon portion. I would want to clean up the colors used, but the general layout is well organized. Thanks! You can thank Pete Kazmier and the Collab CSS Kingpin for that :-) I like the section on project stats and javadocs. Those should be included in every project IMO. They are, all the turbine sites have that little section at the bottom. Maven just deposits all that information there are part of the standard maven:site target. If a decision is made that maven will be the basis for jakarta-site3, I'm more than happy to instead direct this discussion toward maven and focus my 'creative energy' there, ie sending patches to address those issues. I would definitely like to see a Maven like system across the projects in Jakarta--even if the main site is not altered much. It would be good to give the freedom to the sub-projects to refine their color choices, but the general layout and site organization should be the same. We had this discussion the other day and I tend to be somewhat forceful in my idea that the organization and presentation of the information is crucial in helping someone to easily understand a project and that it's important that all projects look identical insofar as the develop documentation is concerned. Colors maybe, but I would like if that once someone had become familiar with the layout of a maven project then learning another project becomes a matter of custom. I'm not trying to stifle anyone's creative urges, I just feel that in the matter of project comprehension that it is pragmatic to have everything look the same. Some don't agree with me but what I'm really trying to avoid is the infinite configuration quagmire where everyone adds things to make things look the way they like and thus you loose all cross project cohesion. I just wish I new about Maven a lot earlier--it delivers on a lot of promises, and in my book that's golden. It's been in the works for a long time but really it's only been in the last 3-4 weeks that others have worked on it and it's taken off primarily because of the interest people have in making their develop lives easier. There is definitely an interest there because people would rather focus on their apps then fart around trying to get a build system to work and have it produce useful information. Since different people will have different things to say about what will be site3 (a discussion which hasn't happened just yet), I was keeping this discussion tool-independent. ie Maven: Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. me: My primary goal atm is to improve the experience of both developers and users that visit the avalon site. As parts of the problem with that site are inherited from problems with the main site, I will try to address those problems first. In practice, Maven's goal and your goal coincide. Yes, they do. By allowing a developer to comprehend the complete state of a development effort in the shortest period of time, you improve the experience of developers and users. Exactly, that's the goal. The question then becomes how do we make Maven's organization expand to Jakarta-site3? One thing that we must understand is that sub-projects can have sub-projects. Jakarta Commons, Jakarta Sandbox, Avalon Excalibur, and Avalon Apps all attest to that. You can look at the Turbine layout sites for an example of what we've done. I enclosed a screenshot so that people can have a quick reference. I see the line with the sub-projects able to be two lines tall. The first line would be the parent level, and the second line would be the current line. That way we can have something like this at the root level: Alexandria Avalon BCEL ... And at the sub-project level, we would be able to have something like this: Jakarta| Theory Framework LogKit *Excalibur* Cornerstone Phoenix Apps CLI Collections Concurrent That way we can easily navigate the site, and drill down quickly to the actual information we need. --
RE: subproject layout conventions
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] On Thu, 2002-03-28 at 09:05, Berin Loritsch wrote: I would definitely like to see a Maven like system across the projects in Jakarta--even if the main site is not altered much. It would be good to give the freedom to the sub-projects to refine their color choices, but the general layout and site organization should be the same. We had this discussion the other day and I tend to be somewhat forceful in my idea that the organization and presentation of the information is crucial in helping someone to easily understand a project and that it's important that all projects look identical insofar as the develop documentation is concerned. Colors maybe, but I would like if that once someone had become familiar with the layout of a maven project then learning another project becomes a matter of custom. The only thing I would want to customize are: 1) Project Logo 2) Project color-scheme That's it. I really don't think that is too much to ask. The layout should remain constant without a doubt. I'm not trying to stifle anyone's creative urges, I just feel that in the matter of project comprehension that it is pragmatic to have everything look the same. Some don't agree with me but what I'm really trying to avoid is the infinite configuration quagmire where everyone adds things to make things look the way they like and thus you loose all cross project cohesion. Everything should definitely feel the same. However, color is a definite clue that you have changed contexts. By drilling down a Project's heirarchy, it helps to have a visual clue that you are not at the same level you used to be. Color customization is not just a cosmetic tool, it does help to understand a project's hierarchy. Logo changes can be missed, but a different background or header color is hard to ignore. As a side note, it would be cool if we could include the Jakarta and project logos as a header in the printed documentation, but that is a stylesheet change. I just wish I new about Maven a lot earlier--it delivers on a lot of promises, and in my book that's golden. It's been in the works for a long time but really it's only been in the last 3-4 weeks that others have worked on it and it's taken off primarily because of the interest people have in making their develop lives easier. There is definitely an interest there because people would rather focus on their apps then fart around trying to get a build system to work and have it produce useful information. Absolutely. So what did you think about the two line navigation approach for Jakarta Site? I see the line with the sub-projects able to be two lines tall. The first line would be the parent level, and the second line would be the current line. That way we can have something like this at the root level: Alexandria Avalon BCEL ... And at the sub-project level, we would be able to have something like this: Jakarta| Theory Framework LogKit *Excalibur* Cornerstone Phoenix Apps CLI Collections Concurrent That way we can easily navigate the site, and drill down quickly to the actual information we need. -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
On Thu, 2002-03-28 at 09:53, Berin Loritsch wrote: The only thing I would want to customize are: 1) Project Logo 2) Project color-scheme No problem :-) That's it. I really don't think that is too much to ask. The layout should remain constant without a doubt. We are in agreement then :-) Wow a new era for Avalon and Turbine developers ;-) We did you avalon in part to produce PDFs :-) I'm not trying to stifle anyone's creative urges, I just feel that in the matter of project comprehension that it is pragmatic to have everything look the same. Some don't agree with me but what I'm really trying to avoid is the infinite configuration quagmire where everyone adds things to make things look the way they like and thus you loose all cross project cohesion. Everything should definitely feel the same. However, color is a definite clue that you have changed contexts. By drilling down a Project's heirarchy, it helps to have a visual clue that you are not at the same level you used to be. Color customization is not just a cosmetic tool, it does help to understand a project's hierarchy. Logo changes can be missed, but a different background or header color is hard to ignore. I'm definitely flexible on the color thing. As a side note, it would be cool if we could include the Jakarta and project logos as a header in the printed documentation, but that is a stylesheet change. I just wish I new about Maven a lot earlier--it delivers on a lot of promises, and in my book that's golden. It's been in the works for a long time but really it's only been in the last 3-4 weeks that others have worked on it and it's taken off primarily because of the interest people have in making their develop lives easier. There is definitely an interest there because people would rather focus on their apps then fart around trying to get a build system to work and have it produce useful information. Absolutely. So what did you think about the two line navigation approach for Jakarta Site? I like the idea and I've thought about how to aggregate the content of many projects into an uber site but I haven't done much work on it as I've focused on the project level. But I'm definitely thinking of the aggregation of projects: for documentation and building. I see the line with the sub-projects able to be two lines tall. The first line would be the parent level, and the second line would be the current line. That way we can have something like this at the root level: Alexandria Avalon BCEL ... And at the sub-project level, we would be able to have something like this: Jakarta| Theory Framework LogKit *Excalibur* Cornerstone Phoenix Apps CLI Collections Concurrent That way we can easily navigate the site, and drill down quickly to the actual information we need. -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
On Thu, 28 Mar 2002, Berin Loritsch wrote: Everything should definitely feel the same. However, color is a definite clue that you have changed contexts. By drilling down a Project's heirarchy, it helps to have a visual clue that you are not at the same level you used to be. Color customization is not just a cosmetic tool, it does help to understand a project's hierarchy. Logo changes can be missed, but a different background or header color is hard to ignore. Unfortunately, you can't depend solely on colour to communicate an important piece of information. If all subprojects have a blue background and all subsubproject have a purple background and thats the only indication of the project level, anyone who is red-green colour blind is hosed. Anyone who is completely colour blind is obviously hosed. I don't disagree that colour is a very useful tool, just don't depend on it. You need an additional way of indicating what the current project depth is. And no, I'm not colour blind. :-) Glenn McAllister SOMA Networks, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
-Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED]] another lenghty post, so I'll start with a summary: - color variations (and all other lf changes) should be part of the original look-and-feel design. Giving programmers free reign to do this spells disaster. It would be best to have the original designer of a look and feel work this out. Very strictly. :( Seriously, I don't dig the big blue background. With projects like Batik, we can generate images that fit with any background color. Let me say this plainly: color should be flexible to a point. The background color for the main text area must be white and the main text color should be black. The color customization whould be in the project header. - the navigation setup we currently have sucks. The one used by turbine right now is slightly better, but only slightly. We need arbitrarily deep levels. The best option is a breadcrumb trail. Yes and no. The Breadcrumb trail + the Maven approach would be ideal. It is easier to get a grip on what is available without having to go back to the parent level each time. You should at least see all peers. here's the elaboration: Look and Feel - (replying to: 2) Project color-scheme No problem :-) ) IMHO, look and feel variations should be designed into the template by the original designer, then set in stone. When you say flexible with color, I find that scary. When its the background color of a locations also containing images, that's a lot of work as well (ie the blue bar on the maven site) as we work with anti-aliased images which you need to duplicate for each color change. I know a bit about this as I was on the team that had to tackle this for www.planet.nl. Rather than having some programmers talk about this, I'd much rather have the original designer propose exactly what parts of the layout can change to what colors. And I have designed several web applications, and also am well versed in site design and color customization. I even created a demo site to generate logos and other images on the fly--even when the background was a different color. Anti-aliased images won't really be a problem. I hope I don't offend anyone too much when I state that, generally speaking, programmers (and other technical people) are really bad at designing intuitive interfaces. Jakarta is no exception. But they like simple color schemes--which is what I would want. Many sites include a customized color depending on what major part of the site you are visiting (my.yahoo.com, mail.yahoo.com, etc.) Navigation structure I proposed a breadcrumb trail in my earlier post. Those work well, but keep in mind that we need to make all peers available as well. Berin: The question then becomes how do we make Maven's organization expand to Jakarta-site3? One thing that we must understand is that sub-projects can have sub-projects. Jakarta Commons, Jakarta Sandbox, Avalon Excalibur, and Avalon Apps all attest to that. Jason: You can look at the Turbine layout sites for an example of what we've done. Berin: I see the line with the sub-projects able to be two lines tall. The first line would be the parent level, and the second line would be the current line. I like a breadcrumb trail better. My last post was a bit abstract in explaining, so I'll try an example now... Imagine you're at http://jakarta.apache.org/avalon/applications/avalon-db/client /gui/userguide /introduction.html (which might very well exist in the near feature) Using a breadcrumb trail, you'd have apache.org jakarta avalon applications avalon-db client gui userguide: -== INTRODUCTION ==- in addition to maybe a menu like this: Avalon Client - overview - getting started - download - install - ... GUI User Guide - introduction - the menubar - the db browser - running queries - ... Commandline User Guide - introduction - getting started - command reference - BeanShell integration - ... ... The setup Maven currently provide would have the Jakarta logo, the avalon logo, followed by a list of avalon-db sub projects in the horizontal bar, and the same menu on the left. Using an extra horizontal bar would add a list of avalon-apps sub projects. You would really need at least _another_ horizontal bar. See the problem? What's wrong with both the breadcrumb trail and the sub-projects bar? I.e. jakarta.apache.org avalon excalibur CLI Collection Command Concurrent And the right hand navigation like on the maven site? Honestly, the breadcrumb alone is not enough, and neather is the strict maven style site. But both together will provide a good balance. Another issue is the ever recurring
RE: subproject layout conventions
- color variations (and all other lf changes) should be part of the original look-and-feel design. Giving programmers free reign to do this spells disaster. It would be best to have the original designer of a look and feel work this out. Very strictly. :( Seriously, I don't dig the big blue background. that is something we agree on =) While we're at it, I think the entire header should be smaller. The jakarta logo is just too big. I'm not volunteering though... I'm no photoshop biggie. With projects like Batik, we can generate images that fit with any background color. really? How well does that work? Does it work on bitmaps? The color customization whould be in the project header. note that all jakarta subproject logos currently are meant to work with a white background. The Avalon logo would probably look terrible against something else (as it has little color). Yet the maven design falls apart if you make the header white (doesn't really fit in). - the navigation setup we currently have sucks. The one used by turbine right now is slightly better, but only slightly. We need arbitrarily deep levels. The best option is a breadcrumb trail. Yes and no. The Breadcrumb trail + the Maven approach would be ideal. It is easier to get a grip on what is available without having to go back to the parent level each time. You should at least see all peers. I agree. In general, I would not recommend it, but most of the peer pages on jakarta have a tight enough relationship that is warranted. Is it true for all pages, though? Maybe a peer list should dissapear at a certain depth. This deserves more thought. (...) And I have designed several web applications, and also am well versed in site design and color customization. Then you will agree that changing of the header color should also mean changing of the color of all the section headers. And that, if you change the header to white (as would be required for some subproject logos), you should change the section headers to a black background. Which is equivalent to shouting. Hence I'm scared of free reign. jakarta.apache.org avalon excalibur CLI Collection Command Concurrent And the right hand navigation like on the maven site? I would probably not have the breadcrumb and peer lists directly below each other in the current maven layout. This deserves more thought. anyone feel like throwing stones at me yet? :) Sure, but let me get my aim just right :P You seen braveheart? :) cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
Jason van Zyl [EMAIL PROTECTED] wrote on 29/03/2002 12:53:36 AM: On Thu, 2002-03-28 at 09:53, Berin Loritsch wrote: The only thing I would want to customize are: 1) Project Logo 2) Project color-scheme No problem :-) The only other thing I've found handy is if there's no project Logo to replace it with the project name in a suitable font. [snip] -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Berin Loritsch [EMAIL PROTECTED] wrote: Attached is a small screenshot of the maven page with a white header. Aaah WINXPCRAP! :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
Hey, I'm a programmer myself ;) as a reassurance: the changes this discussion talks about will happen in jakarta-site2, and will consist of backwards-compatible changes to site.xsl and site.vsl. Projects that depend on jakarta-site2 will change to the new look and feel automatically. For projects that don't, all I ask is that they, after evalutation of the changes, update their local copies of those files. And it really is just a request. So this will _not_ change the way a project website is maintained. Somewhat further down the road is converting your project to use maven. This is apparantly not that difficult. The advantage maven will bring you is that you have to worry _less_ about updating the website, as it does a lot of boring stuff for you. This is of course a project's own decision! as background: Our company is venturing out from its microsoft-only platform and directly into open source, because a big new client requires it. Some of my collegues want to move from ASP to PHP. I wan't to move to all the wonderful stuff at jakarta. Problem is, my boss makes the decision. To convince him, step 1 is a project site which he likes. Danny: I agree with Ted, it'd be nice to have a more polished and brand conscious site, but at then end of the day we're just a bunch of geeks writing stuff for other geeks, and in general I think we each want to concentrate our efforts on the geek stuff. except that the website is not only for geeks. It's also for people that make decisions and have money. Leo Simons wrote: anyone feel like throwing stones at me yet? :) Ted: Only to remind you that the programmers/developers are the decision-makers here. So if you want them to buy into something, you need to coddle them the same way you would your boss or any other suit. And I always thought being reasonable, giving good arguments and doing the job yourself if you want it done was how we work =) The day Jakarta starts to say, it has to be this-way or else, is the day a lot of us would choose or-else. I think many people will agree that how the website looks and works is something where it would be very benificial to all the projects if there was a consensus. So I think Jakarta _should_ say: *here's* why we recommend we all do it *this way*, and *here's* how to do that (ie see: http://jakarta.apache.org/site/jakarta-site2.html) When the original designers are not available, whoever is available needs to do whatever needs to be done. The only ones we are sure are going to be here are the programmers, so the programmers ~have~ to be able to do everything. I very much agree. I was under the impression though that at this point, there are some designers available somewhere. It would be good if they would explain which things would be good to change so we can put that into the system. I'm very much in favor of what you are trying to do, but what we want to hear is that this is something that should just work out of the box for everyone, but can still be easily adjusted if necessary. =) One thing the proposed changes will do is that they will make it easier to adjust the stylesheet. In short, I understand these concerns, they are of course addressed, and we can go a little further than that once maven stabilises and make everything even better (how's that for marketing? :P) cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
subproject layout conventions
It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. Lets start with some discussion :) --- Navigation / Organisation --- The current website is presented as three layers: - Jakarta main - subproject main - subproject menu - subproject submenu so the deepest level you end up in is jakarta subproject section webpage #position-on-webpage The jakarta site has grown a lot bigger than supported in such a hierarchy, hence the problems. Some projects try to adhere closely to unofficial convention by adding a layer: - jakarta main - subproject main - sub-subproject main - sub-subproject submenu jakarta subproject sub-subproject section webpage #position-on-webpage while maintaining the layout. Avalon is an example. Recently, Turbine has chosen a new layout to add this extra level. I don't really like this solution, as it will likely prove to be inadequate in time. Also, subprojects that organise themselves differently according to different criteria might not fit into such a layout IMHO, we should have arbitrarily deep levels, and a navigation structure which reflects this. There are five main approaches in websites tackling this: 1) breadcrumb trail site subsection ... subsection page example: www.dmoz.org 2) GUI-style menubar. Your browser probably has one. Requires DHTML or similar technology, _still_ doesn't seem to work well (ie combined with html forms etc). example: http://www.webreference.com/dhtml/hiermenus/ 3) GUI-directory style tree. Don't know of a file browser that hasn't got one (ok, so you can do something different in MacOS 10, so what?). Also requires DHTML or similar technology to work; scripts available that _do_ work well. example: http://msdn.microsoft.com/library 4) keyword-associated. Kinda difficult to create by hand; WikiWiki's are usually structured into tree-like structures by many people. example: http://c2.com/cgi/wiki 5) criterium-selected. An example is slashdot where the criterium is date of placement. Older items fade into oblivion. Each of these is often accompanied by a keyword-based search facility, and depending on the site can have specific search options as well. They can, of course, be combined. There are, of course, silly sites that have an approach that's different from these. Users get lost on those. So far for stating the obvious. I would like to combine #1 with listing a limited tree containing the current subsection and the parent subsection. Its scalable and simple, and degrades well towards older browsers. Also, it is very commonly used on many websites so users are familiar with it. --- Common Sections --- These can only be commonly defined to a limited extent. However, recognising that we are dealing with open source software projects means the subproject sites (can/probably should) have more than just a navigation structure in common. For each subproject, I propose, based on what the various projects are currently doing, the following sections and subsections: Essentials - Overview - News and Status - Features - Downloads - project specifics Documentation - Installation - Getting Started - Tutorial - User Guide - Developer Guide - Javadocs - project specifics Development - Changes - Todo - Proposals - Resolutions - References - project specifics project specifics for subprojects that do not have further subprojects. For those that do, I propose the following sections and subsections: Essentials - Overview - News and Status - Downloads - project specifics Subprojects - list of subprojects Development - Changes - Todo - Proposals - Resolutions - References - project specifics project specifics regards, - Leo Simons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On Wed, 2002-03-27 at 17:13, Leo Simons wrote: It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. http://jakarta.apache.org/turbine/maven/ There's a sample structure there, with lots of documentation and the printable pages issue is dealt with. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
Leo Simons wrote: It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. Lets start with some discussion :) All this and more is being tackled (slowly but steadily) in Forrest - and having some Jakarta people involved for cross-pollination would be good. There's not much yet except for the foundation and build environment and some static site generation, but you could familiarize yourself using http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and http://cvs.apache.org/viewcvs.cgi/xml-forrest/ Regards, /Steven -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
on 3/27/02 2:26 PM, Steven Noels [EMAIL PROTECTED] wrote: All this and more is being tackled (slowly but steadily) in Forrest - and having some Jakarta people involved for cross-pollination would be good. There's not much yet except for the foundation and build environment and some static site generation, but you could familiarize yourself using http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and http://cvs.apache.org/viewcvs.cgi/xml-forrest/ I think Maven will be the pants off forrest and is already further along. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On Wed, Mar 27, 2002 at 03:23:35PM -0800, Jon Scott Stevens wrote: on 3/27/02 2:26 PM, Steven Noels [EMAIL PROTECTED] wrote: All this and more is being tackled (slowly but steadily) in Forrest - and having some Jakarta people involved for cross-pollination would be good. There's not much yet except for the foundation and build environment and some static site generation, but you could familiarize yourself using http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and http://cvs.apache.org/viewcvs.cgi/xml-forrest/ I think Maven will be the pants off forrest and is already further along. I agree (as much as I like Cocoon and the Centipede build system). Maven could be a revolution on the scale of Gump. --Jeff -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Jason van Zyl [EMAIL PROTECTED] wrote on 28/03/2002 08:15:53 AM: On Wed, 2002-03-27 at 17:13, Leo Simons wrote: It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. http://jakarta.apache.org/turbine/maven/ There's a sample structure there, with lots of documentation and the printable pages issue is dealt with. Hey Jason, don't undersell Maven :) It's a godsend for projects. Not only does Maven provide docs, pages but it also helps with jar file downloading, dependencies, mailing lists, build file reuse, metrics, code cross reference and more. Bring it on! -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
From: Steven Noels [EMAIL PROTECTED] Leo Simons wrote: It has been brought up by many people that there is no common way of organising subproject websites. I propose we draft a set of guidelines (_not_ rules) on a general structure. Lets start with some discussion :) All this and more is being tackled (slowly but steadily) in Forrest - and having some Jakarta people involved for cross-pollination would be good. There's not much yet except for the foundation and build environment and some static site generation, but you could familiarize yourself using http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and http://cvs.apache.org/viewcvs.cgi/xml-forrest/ BTW, there are three available skins there, for Jakarta, xml-apache and scarab-like. If any project doesn't want to mess with site generation, just ask me or even better on the Forrest mailing list ([EMAIL PROTECTED]) and we will set it up for them. Thank you. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
