Coding suggestions for easy maintenance by non-coders

I'm displaying product thumbnails with brief descriptions on web pages. Clicking
on the product does a javascript popup with larger image and detailed
description info passed to the javascript functions from the table data.

Products can change frequently, and I want to make the maintenance of this
info easier by non-techies (each product has an image name, image width
(currently not using getimagesize), a short description, and a long
description). Can't devote major time to this; using a MySQL database to store
the data is currently not feasible because of the time to create the
administrative interface.

There are two methods that I have been playing with, neither of which I'm crazy
about from the maintenance aspect.

===============================================
Method 1 to display image - hard coded info in table, no php:

<td width="25%" align="center">
<a href="javascript:popUp('prod1/12345.jpg','long product description
text','300');">
<img src="prod1/12345_t.jpg" width="75" border=0></a>
<br>
<div id="productdescription">
prodcode<br>product text
</div>
</td>

Problem is that it's too hard to find the pieces to modify and to easy to screw
up by Joe Noncoder.

===============================================
Method 2 to display image using php:

<?php
// section preceding each TD element has unique product info
$filename="12345";
$thumbline_1="prodcode";
$thumbline_2="product text";
$longdesc="long product description text";
$imgsize=300;
?>

<?php
// functions not shown for brevity
$popinfo = buildpopup($filename, $longdesc, $imgsize);
$thumbnail = buildthumbnail($filename);
?>

<td width="25%" align="center" valign="top">
<a href="javascript:popUp(<?php echo $popinfo; ?>);">
<img src=<?php echo $thumbnail; ?> width="75" border=0></a>
<br>
<div id="productdescription">
<?php echo $thumbline_1 . "<br>" . $thumbline_2; ?>
</div>
</td>

The second method is a bit easier to maintain for an end user, only because the
data to modify is clearly delineated.

===============================================

Another possibility is to have separate include files for each product, but it
could be more unwieldy to deal with 300 or so separate product files.

I'm probably overlooking something more obvious. Other suggestions appreciated!

jw
--
jdub@nospamforme.com

JW wrote:[color=blue]
>
> I'm probably overlooking something more obvious.
> Other suggestions appreciated![/color]

Use a database for the image metadata, with a simple, idiot-proof admin
page. It's a simple table, it should be a quick task and it'll save you
headaches later.

bblackmoor
2004-10-30

JW wrote:[color=blue]
>
> I'm displaying product thumbnails with brief descriptions on web pages. Clicking
> on the product does a javascript popup with larger image and detailed
> description info passed to the javascript functions from the table data.
>
> Products can change frequently, and I want to make the maintenance of this
> info easier by non-techies (each product has an image name, image width
> (currently not using getimagesize), a short description, and a long
> description). Can't devote major time to this; using a MySQL database to store
> the data is currently not feasible because of the time to create the
> administrative interface.
>
> There are two methods that I have been playing with, neither of which I'm crazy
> about from the maintenance aspect.
>
> ===============================================
> Method 1 to display image - hard coded info in table, no php:
> Problem is that it's too hard to find the pieces to modify and to easy to screw
> up by Joe Noncoder.[/color]

I agree 100%. It's also too easy to screw up for a seasoned programmer,
especially for the 300+ pages you mention below. And changing the format is a
real bitch. You always end up with missed files and broken links. A major pet
peeve of mine is working on other people's HTML mixed with my PHP, especially
when they use FrontPage or other WYSIWYG editor.
[color=blue]
> ===============================================
> Method 2 to display image using php:
>
> <?php
> // section preceding each TD element has unique product info
> $filename="12345";
> $thumbline_1="prodcode";
> $thumbline_2="product text";
> $longdesc="long product description text";
> $imgsize=300;
> ?>
>
> <?php
> // functions not shown for brevity
> $popinfo = buildpopup($filename, $longdesc, $imgsize);
> $thumbnail = buildthumbnail($filename);
> ?>
>
> <td width="25%" align="center" valign="top">
> <a href="javascript:popUp(<?php echo $popinfo; ?>);">
> <img src=<?php echo $thumbnail; ?> width="75" border=0></a>
> <br>
> <div id="productdescription">
> <?php echo $thumbline_1 . "<br>" . $thumbline_2; ?>
> </div>
> </td>
>
> The second method is a bit easier to maintain for an end user, only because the
> data to modify is clearly delineated.[/color]

If you choose this route, you may want to consider arrays in an include file.
Code (HTML or PHP) is confusing enough for non-coders. I wouldn't make them
sift through all of it if they only need to deal with a small part. Give them
written instructions on how to deal with ' or ", whichever quote you use. And
I'd put 2 copies of the file - a live one and a dev one. Give them instructions
on how to update and FTP the dev file. Write a very quick script that includes
the dev file, and, if there are no errors, replace the live file. This could be
written very quickly. And you may also want to make an auto-archive feature
(copy old file to archive directory as "name-".time().".txt"), assuming there
won't be daily/hourly/ changes and you have room for dozens/hundreds of copies
of the "database".


[color=blue]
> Another possibility is to have separate include files for each product, but it
> could be more unwieldy to deal with 300 or so separate product files.[/color]

Of course, if you wanted a product list, you'd have to open all 300 files, read
the product name, and close them (unless you used the filename to store product
name). But this does have the advantage that, if they screw something up, they
will only screw up one product.


[color=blue]
> I'm probably overlooking something more obvious. Other suggestions appreciated![/color]

One thing I did years ago was let a client maintain an Excel (which they already
knew how to use) spreadsheet of their products. They exported as a delimited
file (tab or comma), uploaded to server and my Perl script took it from there.
If you choose to do this, you might want to make a quick script that does some
low-level checking (make sure images named in file actually exist on server,
make sure all required fields are filled out, etc.) and just print the errors to
an admin page -- nothing fancy, but would save client trouble of clicking
through 300 pages.

But basically, I think you'll find that there's no magic solution to avoiding
making an admin interface. Though I would love to be proved wrong on this
point...

There will always be concessions when allowing the client to edit their site
with no interface. The biggest one is the inevitable errors and the
corresponding panicked phone calls. But you also have to train them,
troubleshoot their mistakes and train them again, accept that they're not going
to be as happy with it as they would be with an interface (and your
word-of-mouth suffers).

Whatever system you go with, make sure the server has a very good backup
system. All the methods above enable the client to seriously mess things up.

Regards,
Shawn

--
Shawn Wilson
shawn@glassgiant.com
http://www.glassgiant.com

JW <jdub@nospamforme.com> wrote in message
news:<s5c3o0lauto060e9opk7roto85k0snr04p@4ax.com>. ..[color=blue]
>
> I'm displaying product thumbnails with brief descriptions on web pages.
> Clicking on the product does a javascript popup with larger image and
> detailed description info passed to the javascript functions from the
> table data.
>
> Products can change frequently, and I want to make the maintenance of
> this info easier by non-techies[/color]

Then treat the maintainers accordingly. Wirte an administrative
interface and make sure every maintenance task can be done via
that interface and no manual fiddling with server-side files is
required.

Cheers,
NC

Shawn Wilson <shawn@glassgiant.com> wrote:
[color=blue]
>JW wrote:[color=green]
>>[/color][/color]
(snip)
[color=blue][color=green]
>> Products can change frequently, and I want to make the maintenance of this
>> info easier by non-techies (each product has an image name, image width
>> (currently not using getimagesize), a short description, and a long
>> description). Can't devote major time to this; using a MySQL database to store
>> the data is currently not feasible because of the time to create the
>> administrative interface.
>>
>> ===============================================
>> Method 1 to display image - hard coded info in table, no php:
>> Problem is that it's too hard to find the pieces to modify and to easy to screw
>> up by Joe Noncoder.[/color]
>
>I agree 100%. It's also too easy to screw up for a seasoned programmer,
>especially for the 300+ pages you mention below. And changing the format is a
>real bitch. You always end up with missed files and broken links. A major pet
>peeve of mine is working on other people's HTML mixed with my PHP, especially
>when they use FrontPage or other WYSIWYG editor.
>[color=green]
>> ===============================================
>> Method 2 to display image using php:
>>[/color][/color]
(snip)[color=blue][color=green]
>>
>> The second method is a bit easier to maintain for an end user, only because the
>> data to modify is clearly delineated.[/color]
>
>If you choose this route, you may want to consider arrays in an include file.
>Code (HTML or PHP) is confusing enough for non-coders. I wouldn't make them
>sift through all of it if they only need to deal with a small part. Give them
>written instructions on how to deal with ' or ", whichever quote you use. And
>I'd put 2 copies of the file - a live one and a dev one. Give them instructions
>on how to update and FTP the dev file. Write a very quick script that includes
>the dev file, and, if there are no errors, replace the live file. This could be
>written very quickly. And you may also want to make an auto-archive feature
>(copy old file to archive directory as "name-".time().".txt"), assuming there
>won't be daily/hourly/ changes and you have room for dozens/hundreds of copies
>of the "database".
>[color=green]
>> Another possibility is to have separate include files for each product, but it
>> could be more unwieldy to deal with 300 or so separate product files.[/color]
>
>Of course, if you wanted a product list, you'd have to open all 300 files, read
>the product name, and close them (unless you used the filename to store product
>name). But this does have the advantage that, if they screw something up, they
>will only screw up one product.
>[color=green]
>> I'm probably overlooking something more obvious. Other suggestions appreciated![/color]
>
>One thing I did years ago was let a client maintain an Excel (which they already
>knew how to use) spreadsheet of their products. They exported as a delimited
>file (tab or comma), uploaded to server and my Perl script took it from there.
>If you choose to do this, you might want to make a quick script that does some
>low-level checking (make sure images named in file actually exist on server,
>make sure all required fields are filled out, etc.) and just print the errors to
>an admin page -- nothing fancy, but would save client trouble of clicking
>through 300 pages.
>
>But basically, I think you'll find that there's no magic solution to avoiding
>making an admin interface. Though I would love to be proved wrong on this
>point...
>
> There will always be concessions when allowing the client to edit their site
>with no interface. The biggest one is the inevitable errors and the
>corresponding panicked phone calls. But you also have to train them,
>troubleshoot their mistakes and train them again, accept that they're not going
>to be as happy with it as they would be with an interface (and your
>word-of-mouth suffers).
>
>Whatever system you go with, make sure the server has a very good backup
>system. All the methods above enable the client to seriously mess things up.
>[/color]

Thanks for your comments. As mentioned in another reply, I'll focus on
separating data from code even though I can't spend time an admin interface.

Perhaps I wasn't explicit. There aren't 300 pages, but 300 products. These are
grouped into a dozen or so categories, with all products in a category displayed
on a page. Currently each category has its own separate subdirectory that
contains its images.

I'd like to strike a balance between performance and maintainability. Let's say
there are 20 products in a category. Would it be excessive overhead to read in
20 include files each the page loaded? Would be better to have a single include
file per category?

jw
--
jdub@nospamforme.com

nc@iname.com (Nikolai Chuvakhin) wrote:
[color=blue]
>JW <jdub@nospamforme.com> wrote in message
> news:<s5c3o0lauto060e9opk7roto85k0snr04p@4ax.com>. ..[color=green]
>>
>> I'm displaying product thumbnails with brief descriptions on web pages.
>> Clicking on the product does a javascript popup with larger image and
>> detailed description info passed to the javascript functions from the
>> table data.
>>
>> Products can change frequently, and I want to make the maintenance of
>> this info easier by non-techies[/color]
>
>Then treat the maintainers accordingly. Wirte an administrative
>interface and make sure every maintenance task can be done via
>that interface and no manual fiddling with server-side files is
>required.
>[/color]

I'm afraid that with this project I won't be able to devote time on creating an
admin interface. Unfortunately, it isn't always easy to convince folks that the
time spent in preventing problems saves time and money in the long run. Will
therefore focus on separating data from code.

jw
--
jdub@nospamforme.com

JW wrote:[color=blue]
>
> Shawn Wilson <shawn@glassgiant.com> wrote:
>[color=green]
> >JW wrote:[color=darkred]
> >>[/color][/color]
> (snip)
>[color=green][color=darkred]
> >> Products can change frequently, and I want to make the maintenance of this
> >> info easier by non-techies (each product has an image name, image width
> >> (currently not using getimagesize), a short description, and a long
> >> description). Can't devote major time to this; using a MySQL database to store
> >> the data is currently not feasible because of the time to create the
> >> administrative interface.
> >>
> >> ===============================================
> >> Method 1 to display image - hard coded info in table, no php:
> >> Problem is that it's too hard to find the pieces to modify and to easy to screw
> >> up by Joe Noncoder.[/color]
> >
> >I agree 100%. It's also too easy to screw up for a seasoned programmer,
> >especially for the 300+ pages you mention below. And changing the format is a
> >real bitch. You always end up with missed files and broken links. A major pet
> >peeve of mine is working on other people's HTML mixed with my PHP, especially
> >when they use FrontPage or other WYSIWYG editor.
> >[color=darkred]
> >> ===============================================
> >> Method 2 to display image using php:
> >>[/color][/color]
> (snip)[color=green][color=darkred]
> >>
> >> The second method is a bit easier to maintain for an end user, only because the
> >> data to modify is clearly delineated.[/color]
> >
> >If you choose this route, you may want to consider arrays in an include file.
> >Code (HTML or PHP) is confusing enough for non-coders. I wouldn't make them
> >sift through all of it if they only need to deal with a small part. Give them
> >written instructions on how to deal with ' or ", whichever quote you use. And
> >I'd put 2 copies of the file - a live one and a dev one. Give them instructions
> >on how to update and FTP the dev file. Write a very quick script that includes
> >the dev file, and, if there are no errors, replace the live file. This could be
> >written very quickly. And you may also want to make an auto-archive feature
> >(copy old file to archive directory as "name-".time().".txt"), assuming there
> >won't be daily/hourly/ changes and you have room for dozens/hundreds of copies
> >of the "database".
> >[color=darkred]
> >> Another possibility is to have separate include files for each product, but it
> >> could be more unwieldy to deal with 300 or so separate product files.[/color]
> >
> >Of course, if you wanted a product list, you'd have to open all 300 files, read
> >the product name, and close them (unless you used the filename to store product
> >name). But this does have the advantage that, if they screw something up, they
> >will only screw up one product.
> >[color=darkred]
> >> I'm probably overlooking something more obvious. Other suggestions appreciated![/color]
> >
> >One thing I did years ago was let a client maintain an Excel (which they already
> >knew how to use) spreadsheet of their products. They exported as a delimited
> >file (tab or comma), uploaded to server and my Perl script took it from there.
> >If you choose to do this, you might want to make a quick script that does some
> >low-level checking (make sure images named in file actually exist on server,
> >make sure all required fields are filled out, etc.) and just print the errors to
> >an admin page -- nothing fancy, but would save client trouble of clicking
> >through 300 pages.
> >
> >But basically, I think you'll find that there's no magic solution to avoiding
> >making an admin interface. Though I would love to be proved wrong on this
> >point...
> >
> > There will always be concessions when allowing the client to edit their site
> >with no interface. The biggest one is the inevitable errors and the
> >corresponding panicked phone calls. But you also have to train them,
> >troubleshoot their mistakes and train them again, accept that they're not going
> >to be as happy with it as they would be with an interface (and your
> >word-of-mouth suffers).
> >
> >Whatever system you go with, make sure the server has a very good backup
> >system. All the methods above enable the client to seriously mess things up.
> >[/color]
>
> Thanks for your comments. As mentioned in another reply, I'll focus on
> separating data from code even though I can't spend time an admin interface.
>
> Perhaps I wasn't explicit. There aren't 300 pages, but 300 products. These are
> grouped into a dozen or so categories, with all products in a category displayed
> on a page. Currently each category has its own separate subdirectory that
> contains its images.
>
> I'd like to strike a balance between performance and maintainability. Let's say
> there are 20 products in a category. Would it be excessive overhead to read in
> 20 include files each the page loaded? Would be better to have a single include
> file per category?[/color]

I have never tested a situation where I included that many files. I don't
really know. Maybe someone else here has done this and would be kind enough to
share results with you? But I'm guessing it'd be unique to your situation, so
you'd likely have to do it and test it to find out. If this is a small site and
likely to stay that way, I'd guess it'd be okay. If it's bigger, then likely
not. ("small" and "bigger" are purposely vague descriptors). Sorry I couldn't
be of more help.

Shawn

--
Shawn Wilson
shawn@glassgiant.com
http://www.glassgiant.com