Re: [Gimp-developer] New GIMP Webpage the 2nd
On Thu, May 24, 2001 at 04:46:21PM +0800, Malcolm Tredinnick wrote:
> On Thu, May 24, 2001 at 11:28:57AM +0300, Ville Pätsi wrote:
> > Uhm. Funny enough, right now there is a big discussion in
> > gnome-webmaster list about wml.
>
> It's not just on gnome-webmaster -- it's raging across a number of
> Gnome lists. In amongst some of the crazed hand waving and finger
> pointing one of the good points raised that hasn't been mentioned
> here (at least, not clearly) is standards compliance.
>
> Some of the complaints about the current Gnome site and it's
> potential replacement is how to ensure that it is possible for
> people to validate that what they are about to commit will generate
> valid HTML. Here "valid" means conforming to the W3C standard for
> whichever version of HTML is chosen and also passing through
> something like htmltidy without complaint. The former is obvious,
> the latter maybe not so common (try running the current
> www.gimp.org/index.html through tidy -- lots of warnings).
>
> That greatly increases the chances that whatever you have will
> degrade nicely to different browsers.
I am unfortunately _very_ out of touch with web standards - I
preferred HTML in about 1995. I think it's safe to say that however
this gets done, the HTML in the "content" should be limited to ,
, , , , and everything else should come from a template,
one way or another.
On Fri, May 25, 2001 at 02:20:24PM +0300, Tuomas Kuosmanen wrote:
> But the first thing to think about is NOT how it looks. It is what
> we want to put there, what the users need, and how to organize it
> nicely so it will serve the needs of the users and the Gimp project.
I've tried to build things so that these decisions can be made in
parallel - that is, if we decide to stick with the simple left-side
tree-style navigation, what actually appears in the tree can be
changed without much worry.
> Once we have some serious stuff done on that area, I can even see if
> could put some "free time" aside for doing the look, if you want.
Cool, I was hoping you would say that.
> > 1. dynamic - php/*sql - easy to code, offers many possibilities, we use
> > it at the GUG and it's excellent for those purposes IMHO
> Beware that PHP can get slow under heavy load if you dont do it right.
> It is very easy to have all kinds of stupid spaghetti tricks there, as
> well as get lost in the table labyrinth when you include stuff a lot.
Yes. That's why my Perl stuff has a _very_ short path to decide
whether there is a cached copy of the page -- then the spaghetti can
commence for the unlucky soul who is the first to visit a page that
has just been edited. :)
> It is easy to generate static pages via Cron if it becomes a problem
> though. ("snarf http://www.gimp.org/dynamic.html static.html")
Indeed - when global changes are made to the site, I nuke all the
cached files and use a recursive wget to force a regeneration.
Cheers,
Tom
--
Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/ |
I know I've made some very poor decisions recently, but I can give you my | H
complete assurance that my work will be back to normal. I've still got the | A
greatest enthusiasm and confidence in the mission, and I want to help you. | L
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
On Thu, May 24, 2001 at 11:28:57AM +0300, Ville Pätsi wrote: > > Uhm. Funny enough, right now there is a big discussion in > gnome-webmaster list about wml. It's not just on gnome-webmaster -- it's raging across a number of Gnome lists. In amongst some of the crazed hand waving and finger pointing one of the good points raised that hasn't been mentioned here (at least, not clearly) is standards compliance. Some of the complaints about the current Gnome site and it's potential replacement is how to ensure that it is possible for people to validate that what they are about to commit will generate valid HTML. Here "valid" means conforming to the W3C standard for whichever version of HTML is chosen and also passing through something like htmltidy without complaint. The former is obvious, the latter maybe not so common (try running the current www.gimp.org/index.html through tidy -- lots of warnings). That greatly increases the chances that whatever you have will degrade nicely to different browsers. Cheers, Malcolm -- Never make any misteaks. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
On 23 May 2001 18:43:52 -0400, Michael Spunt wrote:
> Hi!
>
> On Wed, 23 May 2001 17:13:54 +0200 Christoph Rauch
> <[EMAIL PROTECTED]> wrote:
>
> > I have updated my lists at http://home.bn-paf.de/smokey/gimp_org/
> > It would be great if we could get all that uncertainty out of them.
> > :-))
> > We must know what we want to have as the result and how to get there.
>
> One point I have to criticise:
> "...* No so important ones: 1. Netscape 2. IE..."
>
> The web-site should look perfect in every browser, also there are many
> Windows users and people who use Windows at the office / internet café
> :-) etc. Any discussions about which browsers must be supported more /
> less are no good IMHO.
>
I agree. And sometimes it is useful to use Lynx (slow link, or to fit
the window next to the Gimp stuff) Even rather complex table hack can
be made nice in a text browser (go see www.ximian.com with Lynx to see
what I mean)
CSS works okay if done right. www.linux.com is a pretty good example of
this - Garrett knows his stuff really well.
> Anyway, here are my votes on different topics (see also my mockup):
>
> layout:
> 1. layout - appearance - clean and cool, the current color map is not
> that bad, consequent "theme"
> 2. in-detail design - a set of icons is required to mark special news,
> sections... see above
> 3. a logo is nice, should contain Wilber
> 4. navigation structure should be changed (see my mockup)
There should be one designer (or a few working closely together) that
does the look I think, design by committee has never worked well. But
there is a lot of work needed in other areas as well, like the content
structure, how to do the navigation etc.
But the first thing to think about is NOT how it looks. It is what we
want to put there, what the users need, and how to organize it nicely so
it will serve the needs of the users and the Gimp project.
Once we have some serious stuff done on that area, I can even see if
could put some "free time" aside for doing the look, if you want.
> 1. dynamic - php/*sql - easy to code, offers many possibilities, we use
> it at the GUG and it's excellent for those purposes IMHO
Beware that PHP can get slow under heavy load if you dont do it right.
It is very easy to have all kinds of stupid spaghetti tricks there, as
well as get lost in the table labyrinth when you include stuff a lot.
It is easy to generate static pages via Cron if it becomes a problem
though. ("snarf http://www.gimp.org/dynamic.html static.html")
Tuomas
--
..
| Tuomas Kuosmanen | Ximian | Art Director |
| [EMAIL PROTECTED] | www.ximian.com |
`'
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
> Really? Do YOU have experiences with it? I use it for my pages (not big > piece of art, but anyway: http://www.pvtnet.cz/www/pvt.benkovsk/gimp/ ) > and it works. There are certainly some problems when using perl in > divertions etc, but it easily allows you to use content-describing > tagging (as SGML/XML) in addition to appearance-describing one (HTML). Uhm. Funny enough, right now there is a big discussion in gnome-webmaster list about wml. The decision not to use wml has been made, but the current site thats on uses wml. A Japaniese person requested that a link to his site would be added to the link page in the GNOME website. He had mail four (4) times before anyone was bothered to mess with the crap known as wml. A new website is in the works that doesn't have these problems. The biggest problem with wml(and others) is that the original creator of a page knows it inside out, and knows wml quite well, since he had to learn it to create the page. But when new information needs to be added by an another person, problems arise. The problem is, that most content providers shouldn't need to be wml experts, and most aren't, so content is not being added. I am not saying I know a perfect way to make a big website. I personally would probably go with css, http://www.linux.com/ is a good example of a site that uses css nicely, and it even works with Netscape 4. > That said, I think it's not so important what to use, provided that it > will be free and easily accessible, makes webmaster's routine work easy > and will keep the site clean as discussed recently. Exactly. Thus no wml, since it shouldn't be the webmasters work to provide content. The webmasters job would be to maintain the service and the style- sheets. He's job should not be to morph someone elses content to the whatever-codebase. -- Ville Pätsi -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
Ville Pätsi wrote: > > These 1.4K bytes were from Christoph Rauch, > > Agreed. Then... why not use WML. It's easy to learn and flexible enough > > No! The current GNOME-website is made with wml. And the problem is that wml is > a horrible piece of crap. The next generation GNOME-website will not use wml > because its a nightmare to maintain, not to mention incredibly difficult or > perhaps impossible to compile without some serious black magic. If we used wml > we would be where we are right now. Really? Do YOU have experiences with it? I use it for my pages (not big piece of art, but anyway: http://www.pvtnet.cz/www/pvt.benkovsk/gimp/ ) and it works. There are certainly some problems when using perl in divertions etc, but it easily allows you to use content-describing tagging (as SGML/XML) in addition to appearance-describing one (HTML). Fr example, you could create download box with something like this: ftp://ftp.gimp.org/";> http://www.warez.org/.";> And it could make a nice coloured box with title and links with filesizes displayed. That said, I think it's not so important what to use, provided that it will be free and easily accessible, makes webmaster's routine work easy and will keep the site clean as discussed recently. Regards, Jarda Benkovsky ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
These 1.4K bytes were from Christoph Rauch, > Agreed. Then... why not use WML. It's easy to learn and flexible enough > for almost everything. Uses a makefile system and various includeable > languages (you need not use them if you dont want to). But then... it may > be overkill. ;-)) No! The current GNOME-website is made with wml. And the problem is that wml is a horrible piece of crap. The next generation GNOME-website will not use wml because its a nightmare to maintain, not to mention incredibly difficult or perhaps impossible to compile without some serious black magic. If we used wml we would be where we are right now. -- Ville Pätsi -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
On Wed, 23 May 2001, Simon Budig <[EMAIL PROTECTED]> wrote: > Christoph Rauch ([EMAIL PROTECTED]) wrote: > > The current page displayed in lynx is "suboptimal". Well, at least it is not too bad. It is still looking better in lynx than http://gug.sunsite.dk/ and some other gimp-related pages. ;-) [...skipped nice HTML trick...] > > PHP has a advantage over passive html-pages. You can react on the user > > immediately. Think of: You go to gimp.org in germany and see german > > content. Same thing in GB or the US and you see it in english. PHP can be > > made to react on the browsers language preferences. > > > > But perhaps we could configure Apache to do it too? > > Yes, this is possible with content negotiation. And it is better, IMHO. Apache allows you to store several versions of the page in different languages, and it will serve the most appropriate one according to the user's language preferences. This approach also has the advantage that if you want to get one page in a different language than the one specified in your preferences, you simply have to modify the URL (e.g. "index.fr.html" instead of "index.html") without having to reconfigure your browser for a single page. As I mentioned in a previous message, static pages (generated once, not at every request) can be cached, which is not always possible for dynamic pages and definitely not possible if cookies are used. Static pages are good for the user's browser as well as for large caching proxies that speed up the downloads for many users. I am behind a proxy that is used by several thousand users, so I can see the difference... -Raphael P.S.: This has been surprisingly active discussion... Unfortunately, I will probably be away from the 'net in the next 4 days, so do not be surprised if you do not see more replies from me. I hope that the other topics that were discussed before this web site thread started will not be lost in the noise... Bye! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
Christoph Rauch ([EMAIL PROTECTED]) wrote: > The current page displayed in lynx is "suboptimal". For a neat trick have a look at http://www.home.unix-ag.org/simon/ . The layout is similiar to the Gimp homepage but the menu is at the *end* of the page. This is done with a small table trick: +---+ ++--+ ++ | | M |Content | | e | | | n | | | u | | ++--+ With this layout the "Menu"-Html-code is *after* the "Content"-HTML Code and lynx renders it at the end of the page. You don't have to skip lots of links at the beginning. [...] > PHP has a advantage over passive html-pages. You can react on the user > immediately. Think of: You go to gimp.org in germany and see german > content. Same thing in GB or the US and you see it in english. PHP can be > made to react on the browsers language preferences. > > But perhaps we could configure Apache to do it too? Yes, this is possible with content negotiation. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
Michael Spunt schrieb: > > I have updated my lists at http://home.bn-paf.de/smokey/gimp_org/ > > It would be great if we could get all that uncertainty out of them. > > We must know what we want to have as the result and how to get there. > One point I have to criticise: > "...* No so important ones: 1. Netscape 2. IE..." That was more meant as a ... joke? ;-)) Of course the page should display nice on every target. Ranging from lynx over netscape and ie to mozilla. The current page displayed in lynx is "suboptimal". > 4. navigation structure should be changed (see my mockup) This needs to be discussed further... > content: > 1. all news in the Gimp / general image processing world (new > algorithms, contests...) At least, anything which has a direct link to the gimp itself. All that relates to it would be a bit much I think. Think of "stuffed wilber - buy now" :-/ > cms: > 1. dynamic - php/*sql - easy to code, offers many possibilities, we use > it at the GUG and it's excellent for those purposes IMHO > editing: > 1. people should get an editor's account to add news, articles etc. via > web-interface (perhaps slashdot-like commenting, get ready for "AC", > "fp" and "ge.cx" ;-)) oh my! :-) I see a flameware rising. "Active vs. Passive" PHP has a advantage over passive html-pages. You can react on the user immediately. Think of: You go to gimp.org in germany and see german content. Same thing in GB or the US and you see it in english. PHP can be made to react on the browsers language preferences. But perhaps we could configure Apache to do it too? Christoph -- http://home.bn-paf.de/smokey/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
Andreas Jaekel schrieb: > Concerning the "Content Engine": > We use CVS and a simple perl script for recursive dirctory walks > to compile the pages from templates. We have design and content > templates, but that's only the way we do it. I had something like this in mind too. > The advantages are: > o [...deleted...] Plausible. > Now, I'm not saying this is the tool to use. Rather, I'm suggesting > to use something like it. I'd gladly provide it as a starting point, > but a few small tune-ups are in order. I'd volunteer to write these. Where can we find it? Is there a public CVS server to get it? I would like to document the current system to ease transition to a new or only improved one. > I think using nothing but html pages will simply not work and using > a complicated content management will be too hard to learn. A newby > joining in later will have a high learning curve ahead of him/her > before (s)he can contribute. Agreed. Then... why not use WML. It's easy to learn and flexible enough for almost everything. Uses a makefile system and various includeable languages (you need not use them if you dont want to). But then... it may be overkill. ;-)) Christoph -- http://home.bn-paf.de/smokey/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
Hi! On Wed, 23 May 2001 17:13:54 +0200 Christoph Rauch <[EMAIL PROTECTED]> wrote: > I have updated my lists at http://home.bn-paf.de/smokey/gimp_org/ > It would be great if we could get all that uncertainty out of them. > :-)) > We must know what we want to have as the result and how to get there. One point I have to criticise: "...* No so important ones: 1. Netscape 2. IE..." The web-site should look perfect in every browser, also there are many Windows users and people who use Windows at the office / internet café :-) etc. Any discussions about which browsers must be supported more / less are no good IMHO. Anyway, here are my votes on different topics (see also my mockup): layout: 1. layout - appearance - clean and cool, the current color map is not that bad, consequent "theme" 2. in-detail design - a set of icons is required to mark special news, sections... see above 3. a logo is nice, should contain Wilber 4. navigation structure should be changed (see my mockup) content: 1. all news in the Gimp / general image processing world (new algorithms, contests...) 2. tutorials, articles, interviews (ok, this is a little portal-style but why searching the net for hours to find stuff you need!?) 3. (maybe) integrate registry.gimp.org and add screenshots / examples as far as posible 4. dynamic list of mirrors, RPM / DEB locations 5. links to external resources (e.g. linuxgraphic.org, gtk.org, linuxartist.org <- is it alive, btw?) 6. mailinglist archives 7. cvs usage / getting involved / compilation / requirements / Windows LZW quirks cms: 1. dynamic - php/*sql - easy to code, offers many possibilities, we use it at the GUG and it's excellent for those purposes IMHO editing: 1. people should get an editor's account to add news, articles etc. via web-interface (perhaps slashdot-like commenting, get ready for "AC", "fp" and "ge.cx" ;-)) Just my 0.02 Euro. -- --=[[EMAIL PROTECTED]]=-- --=[ http://www.technoid.f2s.com ]=-- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New GIMP Webpage the 2nd
Hi. > It would be great if we could get all that uncertainty out of them. :-)) > We must know what we want to have as the result and how to get there. Concerning the "Content Engine": We use CVS and a simple perl script for recursive dirctory walks to compile the pages from templates. We have design and content templates, but that's only the way we do it. The advantages are: o design and content are seperated o the templates are very simple, especially the content ones o the template directory structure mirrors the final web site structure o the whole script is ~370 lines (easily understood) o you can define site wide macros o you can define macros to be replaced with script output (e.g. $CURRENT_WEATHER:Berlin or $DATE, ...) o it's easy to use, even as a CVS notify trigger Now, I'm not saying this is the tool to use. Rather, I'm suggesting to use something like it. I'd gladly provide it as a starting point, but a few small tune-ups are in order. I'd volunteer to write these. I think using nothing but html pages will simply not work and using a complicated content management will be too hard to learn. A newby joining in later will have a high learning curve ahead of him/her before (s)he can contribute. Greetings, Andreas -- Andreas Jaekel, CableCats GmbH, Flottenstr. 28-42, 13407 Berlin http://www.cablecats.de/ Tel.: 030 - 916 11 77 3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
