Hi,
http://zoyd.tomk32.de/gnu/index.html http://zoyd.tomk32.de/gnu/boilerplate.html
Two things would help to make a website to look and feel Indian. a) text b) images The GNU project's philosophy has been content instead of looks. To achieve this, both text and images should functionally or non-functionally be a part of the content. Text could be made Indian by greeting a visitor with a 'Namaskaar' followed by a standard 'Welcome to the Free ....', projects could have Indian names, like Naba Kumar's Anjuta and Raju Mathur's VishwaKarma. Images should be used as sparingly as possible. I don't think we want to make another one of those Indian portals having images all over for no reason. Some pages could contain random images of places/festivals around the country with a small description of the image. These images would be contributed by hackers from their own city/state. Thereby encouraging involvement. Such images would be put only in pages that are the most viewed instead of all the pages.
It would be boring to have (fsf|gnu).org.in to be running phpnuke/slash/squish/zope and the likes. I volunteer to built the (fsf|gnu).org.in website, both backend and frontend. Could someone in the Board or close to it please maintain a offsite list of the tasks at hand and the volunteers working at it.
My views on the FSF-I logo and logos in general. Logos are for easy identification of an entity. A Logo is similar to a brand. It needs time for people to associate a logo with an entity. The artwork of a logo must be such that it can be presented in all kinds of media. The most tricky and expensive is the print media. There are very different rules for offset multicolor, digital, screen, block printing, etc. The logo should not loose it's correctness and preferrably also it's effectiveness. There should not be a dependency on color. The GNU head as it is works well for most cases. The GNU head will almost never be used alone. It will be accompanied with the name 'Free Software Foundation of India', on letter heads, visiting cards, brochures, flyers, etc. The Linux penguin doesn't have 'Linux' and 'http://www.linux.org' as a part of it's logo, nor do most logos. It was just a matter of time that people associated the penguin with 'Linux'. Making the name of the organisation a part of the logo artwork is not necessary. The name in a small font size serves no purpose when the name will appear again somewhere around it. We have a handsome and well known logo. The more we use it as it is the better it's for us. Clarity, correctness and simplicity should be the mantra. Think about it.
Thanks, Vinay Pawar, Pune.
On Wed, Mar 27, 2002 at 02:01:14PM +0530, Vinay Pawar wrote:
It would be boring to have (fsf|gnu).org.in to be running phpnuke/slash/squish/zope and the likes. I volunteer to built the (fsf|gnu).org.in website, both backend and frontend. Could someone in the Board or close to it please maintain a offsite list of the tasks at hand and the volunteers working at it.
It is so nice to find a volunteer like you. We do need your services.
Regarding webapplications listed above and your comment, I must say that I disagree. Reason: It is important to have a collaborative site which is maintainable by a group of people, instead of one web master. Suppose if the webmaster leaves, we will be in no position to maintain the site, because the backend is not known. When we use applications we follow a standard, and the content can be syndicated. The reason why we want to use a product like squishdot is for this purpose. Content grows by collaboration, classified, searcheable, catalogued, syndicatable, automatic linking, not from one single page, but from all over the site etc. In what sense it is boring is not clear to me.
I am also not in favour of toomany custom applications for FSF-Site. Using a general application is beeter. An example comes to my mind. the web site www.freeos.com was done in php, and most stuff was customized by one php guru. After he left the site was down for months. That should not happen to us.
My views on the FSF-I logo and logos in general. Logos are for easy identification of an entity. A Logo is similar to a brand. It needs time for people to associate a logo with an entity. The artwork of a logo must be such that it can be presented in all kinds of media. The most tricky and expensive is the print media. There are very different rules for offset multicolor, digital, screen, block printing, etc. The logo should not loose it's correctness and preferrably also it's effectiveness. There should not be a dependency on color. The GNU head as it is works well for most cases. The GNU head will almost never be used alone. It will be accompanied with the name 'Free Software Foundation of India', on letter heads, visiting cards, brochures, flyers, etc. The Linux penguin doesn't have 'Linux' and 'http://www.linux.org' as a part of it's logo, nor do most logos. It was just a matter of time that people associated the penguin with 'Linux'. Making the name of the organisation a part of the logo artwork is not necessary. The name in a small font size serves no purpose when the name will appear again somewhere around it. We have a handsome and well known logo. The more we use it as it is the better it's for us. Clarity, correctness and simplicity should be the mantra. Think about it.
You are quite right, I agree that the logo need not have any text. But for that we really need a symbolic figure. Some thoughts about taking peecock/elephant are good, but they dont go so easily with GNU. Let us see, I am also searching for ideas.
Nagarjuna
There seems to be a tiny bit of confusion. I didn't say I would webmaster the website. I'll built it such that others(including myself) can maintain/webmaster it, much like the squishdot kinds allows us to. And by maintainence I mean articles, news and other content can be posted/edited/deleted with a web interface. I haven't used phpnuke, squishdot, etc. But I guess it would be tricky to have it generate HTML like the gnu.org website. Those applications tend to have the same 3 column look which I find very boring. All the dynamic magic they do is great but they're used too much and often when a custom backend is not feasible and there's no idea for a particular look'n'feel for the website. If we can build a backend that is simple and does exactly what we want it to do, why use squishdot's backend which might be complex to customise. I don't understand what kind of 'php guru' would make something that others can't maintain. Is there a plan about what the fsf.org.in website is going to contain. I hope I'm more clear. Thank You, Vinay Pawar, Pune.
On Wed, 27 Mar 2002 17:11:41 +0530 "Nagarjuna G." nagarjun@hbcse.tifr.res.in wrote:
...................
Regarding webapplications listed above and your comment, I must say that I disagree. Reason: It is important to have a collaborative site which is maintainable by a group of people, instead of one web master. Suppose if the webmaster leaves, we will be in no position to maintain the site, because the backend is not known. When we use applications we follow a standard, and the content can be syndicated. The reason why we want to use a product like squishdot is for this purpose. Content grows by collaboration, classified, searcheable, catalogued, syndicatable, automatic linking, not from one single page, but from all over the site etc. In what sense it is boring is not clear to me.
I am also not in favour of toomany custom applications for FSF-Site. Using a general application is beeter. An example comes to my mind. the web site www.freeos.com was done in php, and most stuff was customized by one php guru. After he left the site was down for months. That should not happen to us.
................. Nagarjuna
If memory serves me right, Vinay Pawar wrote:
I'll built it such that others(including myself) can maintain/webmaster it, much like the squishdot kinds allows us to.
Yes, that's a good idea. I can help with some stuff. I'm sort of good with <?php?>.
I haven't used phpnuke, squishdot, etc. But I guess it would be tricky to have it generate HTML like the gnu.org website.
Are we talking about gnu.org.in or forum.gnu.org.in ?. The forum uses the defautl squishdot template.
Those applications tend to have the same 3 column look which I find very boring.
.......
backend is not feasible and there's no idea for a particular look'n'feel for the website.
That's where I come in, suggest a good style and I can try implementing that style.
we want it to do, why use squishdot's backend which might be complex to customise.
The cross browser HTML generation is a black art of CGI programming . Things like CMS (content management systems) simplify such things.
I don't understand what kind of 'php guru' would make something that others can't maintain.
I would have understood if you had said "perl guru" (LAMO !) Php is a pretty decent language if you use the OO features well.
Is there a plan about what the fsf.org.in website is going to contain.
Again more doubts. About forum or fsf site ?
Gopal.V
If memory serves me right, Vinay Pawar wrote:
HTML like the gnu.org website. Those applications tend to have the same 3 column look which I find very boring. All the dynamic magic they do is great
I've got a fresh CVS of Zope & Squishdot and will try some DTML for the forum. Will report results .
Gopz
On Wed, Mar 27, 2002 at 06:17:19PM +0530, Vinay Pawar wrote:
There seems to be a tiny bit of confusion. I didn't say I would webmaster the website. I'll built it such that others(including myself) can maintain/webmaster it, much like the squishdot kinds allows us to. And by maintainence I mean articles, news and other content can be posted/edited/deleted with a web interface. I haven't used phpnuke, squishdot, etc. But I guess it would be tricky to have it generate HTML like the gnu.org website. Those applications tend to have the same 3 column look which I find very boring. All the dynamic magic they do is great but they're used too much and often when a custom backend is not feasible and there's no idea for a particular look'n'feel for the website. If we can build a backend that is simple and does exactly what we want it to do, why use squishdot's backend which might be complex to customise.
It is clear now that what you mean by boring. True, the three colum format is boring. But we can change that, without changing the squishdot application. As I said earlier, in Zope as in any OO application the design of the views is independent of the logic. Then let us discuss what changes we should make to the design.
Nagarjuna
On Wed, 27 Mar 2002 14:01:14 +0530, Vinay Pawar zoyd@gmx.net wrote:
It would be boring to have (fsf|gnu).org.in to be running phpnuke/slash/squish/zope and the likes.
The present consensus is to use plain html for static content and zope for dynamic content (such as free software directory, news, events, ongoing projects etc). The choice of zope for the latter is actually very appropriate because it enables collaborative development; groups of authenticated volunteers can contribute entries to the zope web-applications in an organised manner. (Nagarjuna or Arun will please correct me if I am wrong here)
As for the choice of squishdot for the forum, is there a need for an argument? Of course, there may be alternatives, but since it is already in place, let us accept in and carry on with the real work of providing content as you have rightly stressed. But I don't understand what you mean by describing these solutions as "boring."
I volunteer to built the (fsf|gnu).org.in website, both backend and frontend. Could someone in the Board or close to it please maintain a offsite list of the tasks at hand and the volunteers working at it.
Vinay, there is no need to involve high level entities :) like the Board here. We will try and do everything by consensus right here on this list. I hope you have seen the first post in the archive of this list for some background.
My views on the FSF-I logo and logos in general. Logos are for easy identification of an entity. A Logo is similar to a brand. It needs time for people to associate a logo with an entity. The artwork of a logo must be such that it can be presented in all kinds of media. The most tricky and expensive is the print media. There are very different rules for offset multicolor, digital, screen, block printing, etc. The logo should not loose it's correctness and preferrably also it's effectiveness. There should not be a dependency on color.
Sure. This point has already been made before.
The GNU head as it is works well for most cases. The GNU head will almost never be used alone. It will be accompanied with the name 'Free Software Foundation of India', on letter heads, visiting cards, brochures, flyers, etc.
We should have the organisation's name as part of the logo precisely to make the addition of the organisation's name in text unnecessary! With the incorporation of the organisation's name and URL the logo becomes independent and self-contained. We can then, for example, place just the logo on other websites (of individuals, like minded organisations etc.) without any need for an accompanying caption. We can also, for example, make stickers of just the logo. Flyers, brochures etc then need to have just the logo at the top and it will serve the purpose of a title and url-referrer without any addition of text. The advantages are innumerable.
The Linux penguin doesn't have 'Linux' and 'http://www.linux.org' as a part of it's logo, nor do most logos. It was just a matter of time that people associated the penguin with 'Linux'.
We are mixing up brands and organisations here. Most organisations' logos *do* have their names in them. (And a large number of organisations' logos are actually nothing but a distinct rendering of their name and nothing else!) Besides, we can't wait for the Indian public to recognise the Gnu head and automatically associate it with FSF-I. That would take a really long time indeed. Even when we do reach that utopian period when people recognise the Gnu head as they now recognise the Mercedes emblem for example, they wouldn't know whether to associate it with the GNU project, FSF-America or FSF-India.
We cannot have a logo which is so completely dependent on accompanying text to qualify its association. That defeats the purpose of a logo.
If memory serves me right, Khuzaima A. Lakdawala wrote:
of authenticated volunteers can contribute entries to the zope web-applications in an organised manner. (Nagarjuna or Arun will please correct me if I am wrong here)
Oops, Authenticated volunteers ?. I think it needs an army of volunteers to moderate a site it if it gets popular. (which it should).
As for the choice of squishdot for the forum, is there a need for an
First make it popular, then build the kernel. (oops !).
We will try and do everything by consensus right here on this list.
As democratic as possible please.
With the incorporation of the organisation's name and URL the logo becomes independent and self-contained. We can then, for example,
"The logo says it all".
We are mixing up brands and organisations here. Most organisations' logos *do* have their names in them. (And a large number of
one point from me -- GNU is not the logo of FSF .. But we would like it to be associated to FSF in some way -- so we put it on our logo !.
Gopal.V
On Wed, Mar 27, 2002 at 06:18:59PM +0530, Khuzaima A. Lakdawala wrote:
On Wed, 27 Mar 2002 14:01:14 +0530, Vinay Pawar zoyd@gmx.net wrote:
It would be boring to have (fsf|gnu).org.in to be running phpnuke/slash/squish/zope and the likes.
The present consensus is to use plain html for static content and zope for dynamic content (such as free software directory, news, events, ongoing projects etc). The choice of zope for the latter is actually very appropriate because it enables collaborative development; groups of authenticated volunteers can contribute entries to the zope web-applications in an organised manner. (Nagarjuna or Arun will please correct me if I am wrong here)
Correct! It is possible for me to give permission to maintain a directory or even a file to somebody, without giving him/her total control of the site.
As for the choice of squishdot for the forum, is there a need for an argument? Of course, there may be alternatives, but since it is already in place, let us accept in and carry on with the real work of providing content as you have rightly stressed. But I don't understand what you mean by describing these solutions as "boring."
If we have time, we should spend it for applications that need to be developed. A web magazine problem is solved, let us not reinvent it unless something is seriously wrong with the available applications.
Nagarjuna