PDA

View Full Version : Photopost template gripes


Alex Taylor
May 21st, 2004, 04:56 PM
I had to skin a Photopost installation for a client and was assuming it would be relatively straightforward, like most template systems. Being used to vB, I suppose I've been spoiled by their fantastic template system, but I've worked with others before and after a slight learning curve I'm on my way.

However, such was not the case with Photopost. While the program itself is great, especially for forum integration, it's major pitfall is the template system. Frankly, it could do with an overhaul. Instead of just complaining pointlessly I've compiled a short list of specific things that need to be addressed.

Poor documentation: There needs to be more documentation, at the very least comments in the code, specifying the location and filename of each template, and how to call it. A quick example: the variable $comq does not immediately suggest the quickcom.tmpl template. Why can't it be called $quickcomment? Small change, but it would make a world of difference.

Also, that brings me to a quick note about consistency: the quick comment element is called with a variable, i.e $comq. However, the rest of the templates, like cathead and albums, are called via a PHP include. There's no reason $comq (and probably others that I haven't found) should be called in this fashion, and not like the rest of them. Usually when a variable is called I expect it will be found in the PHP file for the page, like most of your other variables (all the {$xxx[x]} variables, for example).


There is far too much markup "hard-coded" into the PHP files. Image display, phrases etc come to mind. The user SHOULD NOT have to hunt for this through thousands of lines of code. A template system is supposed to be versatile. Having small bits here and there hidden in PHP code severely limits your purposes. For instance, there should be an easy way to edit the language phrases to your liking. There have been times when I've wanted to change words or remove a question mark in a phrase (eg. 'Recent Posts', 'User:,' etc) and I have to dive into the PHP files. Not fun, especially when I have to look through two or three files before finding what I want.


And the reverse of the previous one.. Too much code in the markup. Templates should contain as little code as possible, and as much markup as possible. For example, vB's templates have simple variables ($threadlist, $postbit, etc) to specify elements. It's unexcusable to have so much code in the template files so that the user must wade through it. I'm lucky I have a basic knowledge of PHP, otherwise I wouldn't have been able to figure out what all the code was for.

I realize that there are certain elements of code that must be present in the templates, such as elements that can be turned on and off in the control panel. But these could be either simplified, like vB does with their <!if> tags, or cleaned up considerably.
_____________________________

Making those changes would, in my opinion, drastically improve the usability of the template system. There has to be more versatility within the templates in order to allow full customization, and prevent the homogenization of all Photopost sites.

Thanks for reading this, and I hope some of these issues may be addressed for future users.

Zed
July 9th, 2004, 07:32 AM
I dispise the PhotoPost templates... They are the bain of my very existence... They are without a doubt the most fiddly and awkward excuse for templates I have ever witnessed.

Just thought I'd point that out as I search through file after file after file after damn file for the most simple of elements that I need to change... before realiseing that the element in question is located in multiple files and will need to be changed in all of them...

*Sigh*

Michael P
July 9th, 2004, 09:56 AM
Since you area familiar with vB templates, then you should know that the template system itself is made up primarily of PHP-like syntax structure. An if in <> is still an if.

Forcing our users to learn a new language syntax would itself involve more documentation and a learning curve than most of our users would appreicate.

Our template system is quite user friendly, doesn't require a preprocessor and doesn't involve new syntax. We keep the logic to a minimium and, for the most part, templates are easy to find as they match their script filename.

No system is ideal and we'd take slack from our users even if we wrote a vB-compatible template system.

berlin
February 20th, 2005, 12:41 AM
It's a mess.

Chuck S
February 20th, 2005, 11:19 AM
Actually here's my 2 cents. I think VB's template system is quite terrible and the worst I have seen so its all a user's preference. I would never put templates in a database. I can say this because I own a VB license.

I think our template system which is straight HTML surrounded by PHP conditionals is the easiest I have ever seen.

VB's conditionals I think on there template system are a little bit harder to follow than ours so as Michael stated we would receive flack whatever way you did it.

The hardest thing to do is to please all your customers. You never will thats just a fact. You will get criticism anyway you do things. Especially when the majority of your customers use frontpage to design a site and upload it so when they switch to a php program to generate dynamic content there is a learning curve that goes with it.

I think after you investigate and get comfortable with our css edit window and template window and how php conditionals work you will be amazed at how simple it is to change things.

berlin
February 20th, 2005, 04:10 PM
my 2 cents. whether the template is in the db or html, it has nothing to do whether the design looks great or not. most programmers lack webdesign skills and that's understandable; they're good in something else. but if you want to charge $129 per license, the design should at least be pleasing enough to look at.

For example: the Recent Photo links which is located underneath the search bar just looks messy. Placing it before the search bar wouldn't require you to have that extra row.

The same goes for the View, Per Page and Sort by menu. The design should be more liquid. When the main table width is set to 80%, the sort menu goes underneath the Per page menu.

"Last comment" becomes

"Last
Comment" making the table fatter and if you have a gradient background from vb, it looks like a mess.

Subcribe to Gallery and email link to a friend also was designed with the main table set at 100% and browser at 100%

If you're an admin, again, with less than 100% table, the following won't fit in showphoto.php page.

"Add to Favorites Post a Comment Report Photo Send as e-Card Receive Email Updates Edit Photo Make Sticky Make Index Thumb..."

Also for some reason the tables in showphoto from the rating to the thumbnails all have different widths.

Also there's a vertical bar that shows up before |poor and after Excellent|

Finally the buttons don't even match. Some are from vb and some are from somewhere else.

All are basic webdesign stuff which can be done by an Elancer from India or eastern europe for a few bucks.

Now If I can only find where to edit these in the template, I'd gladly share my streamlined version here.

Chuck S
February 20th, 2005, 04:28 PM
Well its all a matter of taste as we know. I happen to like the portal look of Photopost.

If you set your screen table width to 80% and expect things to be perfect then thats just plain impossible web design or not. In fact the majority of web sites out there use 95-100% table width. Just a plain fact. I have to absolutely hate 80% width or fixed width sites so its all relative here.

The simple matter is if your going to try running a fixed width or small width site yes you might need to tweak things as displaying the sheer amount of data generated is impossible without tweaking things to your needs.

Example the prev and next thumb box's you would never be able to use on a 80% width site if your using the sidebar on showphoto. Just food for thought. Thats why I personally only use the sidebar on the index because of all the data and admin links etc in showphoto.

We have documentation on what templates are with what scripts in the documentation forum and as for where to edit templates you can do so by hand which is my favorite way or you can use the template editor in the admin section.

http://www.photopost.com/members/forum/showthread.php?t=109478

b6gm6n
February 20th, 2005, 06:33 PM
my 2 pennies : If you have seen any html before or understand a little of the syntax then the PP templates should be a doddle, improvements can always be made of course in the layout of anything. I've customised the look and feel of photopost and made some very nice styles, same with vbulletin, i have the most downloaded style at vbtemplates.com so i know what i'm talking about, the attached is one example of what you can do, looks good IMO (even if i do say so myself) :) - when the final version of PP is out then i can alter the languages, edit the templates and customize away to my hearts content!

-T

somerfeld
February 21st, 2005, 04:54 AM
pulling db calls is faster then include, or least thats what i thought.. pp needs a lot of work but alex,.. if only you where here in the first versions of pp,.. with no templates hahahah

Chuck S
February 21st, 2005, 07:56 AM
Lets not even go there ;)

When all the html was in the php files that was absolutely horrendous. I remember those days

Zed
February 21st, 2005, 08:54 AM
Is it really too much to ask for templates in object orientated css?
;)

Chuck S
February 21st, 2005, 09:04 AM
Object oriented CSS and PHP dont always interact well if you want my opinion.

Besides what your talking about is above the heads of most of our customers. Alot of them have enough of a time figuring out regular html let alone trying to figure out why this thing is displaying over there or why this thing has so much padding around it.

Michael P
February 21st, 2005, 01:08 PM
FYI, on the PP5 update we're moving the menus around to make them easier to use, we've removed some of the graphics and ar using text and we're trying to make the templates more "fixed column friendly".

While our layouts may work for 98% of our users, its maintaining that usability while accomidating the other 2% which makes alot of work.

As for templates, overall our user base is not very technical. Implementing a new template system that uses its own language would in itself be very cumbersome to many of our users. While HTML/PHP may not be the language of choice for some, it is one that is widely used/known and has plenty of reference resources available and doesn't make our users dependent on us to document/teach them. Also, this layout allows for greater flexibility for customization.