Do programmers ever think of designers? Do programmers ever think of designers?
 

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

Do programmers ever think of designers?

Started by tomas dahlin, July 21, 2004, 11:33:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

tomas dahlin

Hi there everyone!

As this is my first post, let me start by sayng that this image gallery is a kick ass script loaded with first class features. I take my hat off for the programmers who have spent an enormous amount of working hours to produce a top class gallery that is free for all us webmasters out there. It is truly great and all that, but...

How come such a great script i so hard to implement into an existing website??? Please don't come and say that it is easy, because it's not. I've spent my last five years as a professional webdesigner, and I know my way around the block, so please don't brush me off as a newbie not knowing shit about shit. I understand that skins are cool and all that, but if you really want to make this script state of the art, you will have to make it dead easy to implement into an existing website design. And after all the time spent on programming, why not spend just a little more time thinking about the people who are going to implement it into their website?

Thera were a few things that struck me once i got the script installed:

1. Ther was no way to include my own header and footer files. Instead of just adding the url to my header and footer, I had to hard code it into the templatefiles. And even so, the description of how to do this didn't work until I found a post in the forum where the user had removed a piece of the suggested code. So including header and footer files is a bitch, and yet there are so many asking about it in the forums, so there is obviously a need for a simple way to do this. How about two fields in the admin area? And once I got my header and footer to work, I find out that it applys for the admin area as well. Now that area usually requires a little more space (width) than the gallery itself, so a separate header/footer there would be nice. As it is now, it not only looks insane, it is practically impossible to work with.

2. All so called templates are located in one single file. Why? I understand it might be require less programming, but it is a bitch for the designer who has to deal with it. This is the first time I have encountered this, and I still don't get it. The use of separate template files is so much easier for the designer. Just the fact that they can be opened in a HTML-editor is reason enough for me.

I am not here to create a debate wether I am right or wrong in my critisism, and I don't expect replys like "it's free, so shut up". I want a creative open debate wether theese changes could somehow be implemented or not (I´d be more than happy to help in any way I can), and if this would make someone elses live easier than mine? Today, it's a great script for personal homepages, but to reach the professional ones, the gallery must be easier to edit from a graphic point of view.

I guess the bottom line is: Are you interested in making changes or should I take my nagging elsewhere?

If there is is a programmer out there who can actually help me implement theese changes or at least some of them, pleas post a reply. As of today i am forced to look at commercial alternatives, witch is a shame, not because I have to pay for it, but because this script could be just as good, if not better. I am a strong supporter of open source and would love to see this script kick some of the commercial actors off the market.

I'm looking forward to hearing your opinions in this matter.

Sincearly,

Tomas Dahlin
Attack.se

Tarique Sani

We are aware of the short commings of the template design and we will consider changing it when one of us has the time to do it...

If you can do it OR get someone to do it - please do it / get it done and submit the code - How about putting your money where your mouth is? How about hiring a programmer to do the needed changes and submitting the code for everyone to use....

We have had discussions about template design and we do not want it the way you want it split into pieces making it more unmanageable BUT a single file which can be opened in a good WYSIWYG editor and changed as per needs

However if all you can do is rant about it then there is no creative debate which can happen.

So the bottlomline is - It is free and you are free to add to it, please do
SANIsoft PHP applications for E Biz

tomas dahlin

Thanks for your quick answer. I've been trying to get a programmer who can edit the script for me, but as you probably know, not many programmers want to deal with code that they haven't worked with themselves. If I am to pay someone by the hour to do this, it is probably gonna cost me more than to get it written from scratch. Wich by the way is an alternative as soon as I get the money. My stack of money is however not as big as my mouth at the moment. ;)

I know I was a bit aggressive in my first post, but I didn't mean to offend anyone. If I did, i apalogize. If someone is interested to work with me on this one, paid or not, please post a reply. I am a graphic artist myself and do not have the skills to edit the code like I want it. My meaning is not to rant for the sake of ranting, I would really like to see a solution to the things I pointed out. So if you have time and interest, please let me know.

As of the templates residing in one file: I agree with you, it is easier to manage as long as you can edit them through your common HTML-editor. I guess I'm a bit stuck in my own tracks sometimes.

Joachim Müller

There are other projects that use a theming/template engine - some of them tried to break the template into several bits (e.g. phpBB or SMF), but imo they all failed: it requires both porgrammer and artistic skills to come up with a genuine, new theme for the the applications mentioned, that's why most users use pre-defined themes they downloaded from somewhere.
You always have to find a balance between being able to modify the html output completely and yet still have control over the functionality. There have been dozens (if not hundreds) of approaches to create a good template system that can do all that, but in the end nobody was ever able to create one that fitted for all needs.
I agree that the current theming system has some drawbacks and that it should be overhauled, but I'm not sure about the way - that's one of the reasons why we (the coppermine dev team) haven't started yet creating a new theming engine (the other reasons being lack of time and concerns about backward compatibility).

GauGau

tomas dahlin

Thank you for your reply. I understand the difficulties in creating the perfect templatesystem, and especially when being concerned of backword compatibiliy (oh, and time, wich there is never enough of :( ). I'll tune down for now and look for other ways to solve my problems.

jul

hi all,

I was thinking the same than tomas...
I am a beginner, but I tuned my dotclear ( www.dotclear.net , blog application ) and want to do the same thing with coppermine so that they look and feel the same way... I really like the coppermine fonctionalities and so on, but it is not easy to customize!

dotclear is template driven and table less, relying on its css to set all the display. the css classes are quite intuitive and it is easy to customize a theme. when I tried to do the same with cpg, not only the fact that it is full of tables but also the fact that css display info is included in all the files of each theme (html, php and css) makes it really difficult to see what is going on...

I'm not sure that a table less design would be suitable for cpg, as it is more complicated, but if only they could be reduced to the max and carry no display tags but only css classes, it would be a great step forward!

my 2 cents...
Jul

Casper

Have a look at the reynolds or 2bornot2b themes, which are not completely tabless, but based on CSS.
It has been a long time now since I did my little bit here, and have done no coding or any other such stuff since. I'm back to being a noob here

efmoya

By and large I agree with Tomas.

It seems obvious that the design of Coppermine is evolutionary. The html is full of divs, spans and style="" sections which do no more than apply a different css to a particular section of markup. That is just lazy coding.

Some things that I found particularly troubling were:

1) The quality of the html output is atrocious. Its full of strange indentations and funny multiple extra lines. The use of xhtml doesn't seem to provide any advantage. HTML 4.01 markup would be much better. Do a 'view -> source' on my pages to see how I corrected some of this. http://moya.us/MoyaFamily/Albums/

2) The theme.php file doesn't include all the theme related code. For instance, most of the admin pages are generated in 'helper' php files. Searching for which file affects what section of markup is challenging at best. Any re-theming can't be complete unless these files are changed but there's no reference to them in the doc's.

3) There are many instances where the markup results in pages that are not valid xhtml (or html). The worst example of this is the invalid placement of form tags. Its funny that that problem would be there since its so easy to correct.

Ephraim F. Moya
http://moya.us/
Ephraim F. Moya

kegobeer

@efmoya:

Regarding HTML vs XHTML - XHTML is the way of the future.  To keep on the forward end instead of the back end we've decided to make the switch to XHTML.  XHTML offers much more than HTML.  Visit the WC3 for more info.

Regarding themes in general - We know the theme engine isn't perfect.  We are working on a better engine, but it was decided not to introduce anything into the next release, as reworking the theme system is a major milestone in itself.  We appreciate anyone who can help improve the current engine and make helpful suggestions on a better system.

Regarding your views on CSS - I take offence to the idea of using CSS to make theme changes as lazy coding.  If you look around the web (and at other successful forum and image programs) you'll see how much those programs rely on CSS instead of traditional table designs.  CSS makes it very easy to create theme engines, and makes it easy for the end user to make site-wide changes very quickly.  Again, this is the way of the future and we want to stay ahead of the game.
Do not send me a private message unless I ask for one.  Make your post public so everyone can benefit.

There are no stupid questions
But there are a LOT of inquisitive idiots

efmoya

While I think that its arguable that the world is going to xhtml the fact remains that there are NO browsers that can render xhtml. The best one can say is that they TOLERATE xhtml markup. So, IMNSHO, relying on error behavior of browsers is shaky at best.

A construct like:

   <td style="...">content</td>

rather than:

   <td class="...">content</td>
   
with appropriate css is what I mean by 'lazy coding'. In the first case the programmer elected to 'solve' his problem by localizing the style instead of by doing it the more robust way as in the second example. The lazy way results in style that is impossible to change without changing the markup. The 'powered by coppermine' footer line is a perfect example of this.

The first step in fixing problems is knowing what the problems are.
Ephraim F. Moya

kegobeer

I agree that using CLASS is much better than STYLE, as a site-wide change is possible, and it's much better programming.

What browser can't render XHTML?  Firefox, Mozilla, Opera, Safara, and IE all render XHTML documents correctly, as long as the DOCTYPE is set IAW the W3C guidelines.  This forum is XHTML compliant, is it not displaying correctly for you?

XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4.  XHTML requires stricter programming practices (no sloppy HTML coding anymore).  Perhaps you are thinking of XML?
Do not send me a private message unless I ask for one.  Make your post public so everyone can benefit.

There are no stupid questions
But there are a LOT of inquisitive idiots

efmoya

This page:

http://forum.coppermine-gallery.net/

claims to be xhtml in its doctype but this:

Header (Length = 389):
HTTP/1.1·200·OK(CR)
(LF)
Date:·Sun,·03·Oct·2004·21:28:29·GMT(CR)
(LF)
Server:·Apache/1.3.26·(Unix)·PHP/4.1.2(CR)
(LF)
X-Powered-By:·PHP/4.1.2(CR)
(LF)
X-Accelerated-By:·PHPA/1.3.3r2(CR)
(LF)
Set-Cookie:·PHPSESSID=f00a8fb509b9a8fcfbc04d740af23e79;·path=/(CR)
(LF)
Expires:·Mon,·26·Jul·1997·05:00:00·GMT(CR)
(LF)
Cache-Control:·private(CR)
(LF)
Pragma:·no-cache(CR)
(LF)
Last-Modified:·Sun,·03·Oct·2004·21:28:29·GMT(CR)
(LF)
Connection:·close(CR)
(LF)
Content-Type:·text/html(CR)
(LF)
(CR)
(LF)

is the header sent for that page. Note that the Content-Type is 'text/html'. This setting will supercede most browser's doctype detection. This means that the browsers you mentioned are all treating the markup as html and not as xhtml. html marked pages ignore 'errors' even those that are purposely introduced by xhtml markup. I wasn't able to find anything about xhtml mime types but I suspect that browsers will set 'quirks' mode for the xhtml doctype.

So if writing an xhtml doctype makes you feel better, by all means use it. It has no effect on browser's performance, though.
Ephraim F. Moya

kegobeer

Something from the W3C:

QuoteIn summary, 'application/xhtml+xml' SHOULD be used for XHTML Family documents, and the use of 'text/html' SHOULD be limited to HTML-compatible XHTML 1.0 documents. 'application/xml' and 'text/xml' MAY also be used, but whenever appropriate, 'application/xhtml+xml' SHOULD be used rather than those generic XML media types.

Since these documents are HTML-compatible XHTML 1.0, the use of text/html is technically not incorrect.  Since no elements and attributes from foreign namespaces are added (a la XHTML+MathML) there is no violation in the eyes of the W3C (for 1.0.  1.1 is a different story).

I do agree that the document will not be processed as XML and it's not being served properly.  Obviously there's a bit farther to go, but the important thing is to start in the right direction, and that's what we're trying to do.
Do not send me a private message unless I ask for one.  Make your post public so everyone can benefit.

There are no stupid questions
But there are a LOT of inquisitive idiots

gforeman02

Tomas, you just read my mind.  Has anyone ported this app to xml/xsl?  I'm very new to php and would rather just use php like an "app" layer and xml/xsl for the "presentation" layer.  Seems like a fantastic way to workaround the theme issue.  Is this possible?

evolutionweb

#14
Quote from: tomas dahlin on July 21, 2004, 11:33:20 PM
Hi there everyone!

As this is my first post, let me start by sayng that this image gallery is a kick ass script loaded with first class features. I take my hat off for the programmers who have spent an enormous amount of working hours to produce a top class gallery that is free for all us webmasters out there. It is truly great and all that, but...

---- Below added by Paul in response to the above ---

I am not a PHP programmer but a little snooping around can tell even a novice a lot...

One thing I did to incorporate the gallery to fit an existing site is just change the path in the template to the style sheet to use the same sheet used for the main site.  I found that a few font sizes did not work well so made a duplicate of the style sheet with different name and just altered the necessary fonts there...voila!  Except for removing the table in the template to omit the header section image, it matches almost perfectly. Of course I tweaked the template.html a little with respect to table widths to match the site but over all it was pretty simple really.

If you have a footer file called by php you can alter the index.php file " pagefooter(); " to include path to your footer.txt file ( or whatever you use for a footer )

    // original - pagefooter();
pagefooter(readfile("../php/footer.txt","r"));

Obviously the path and file name have to be your own...this is an example unique to this site.

See: http://garfieldautos.com