PF site update

[Tapewolf]

It may not look like much, but a lot has changed under the hood.  It should be far more manageable next time I need to update the top and bottom menu bars.  In terms of actual content, there is a 'Forum' button and the 'About' button now actually works.  Oh, and Niall's cast page is up too.

If people could kick the tires a bit, and/or rewrite suggest improvements for the 'about' page, that would be really handy.

http://www.project-future.org

**EDIT**
There is a known layout difference between the PHP pages and the regular HTML which causes the buttons to move around slightly.  I'll chase that tomorrow.

[RobbieThe1st]

Well, I messed around with your archive page, and it seems sound - I couldn't make it error out with various invalid strip numbers. Everything not a valid number defaults to the latest page, which I personally like.

Question - How are you handling the archive? Are you using some sort of database(text perhaps?) with a list of the valid strips, and any additional info, or simply doing a file_exists('./strips/comic/strip'.str_pad($cleanedGETstripval,3,STR_PAD_LEFT).'.png') to check that the input is valid? Or, something else completely?

A suggestion - It would take a bit of work, but might be nice to have, especially as your comic archive grows: A search method. I figure probably a text-database with all the text in each of the comics, and strstr/stristr for searching. I am thinking something like http://www.schlockmercenary.com strip search here.


For the about page(and heck, it would work for the cast page also), how about this: You have two content columns, a narrow left one with images/text links to each section of the page, and content on the right in a DIV frame. You have nice, shiny mouseovers for each of the images/links(link mouseovers can be simply a brighter color or something), and when you click on each one it pulls that section into the DIV via Javascript(Probably a set of Javascript strings in the HTML, for instant loading). If Javascript isn't enabled, when you click on the link it loads the page again, but with that section selected - doing the same thing via php.

Those are just my crazy crack-pot ideas.


-RobbieThe1st

[Tapewolf]

Well, I messed around with your archive page, and it seems sound - I couldn't make it error out with various invalid strip numbers. Everything not a valid number defaults to the latest page, which I personally like.

Yeah.  The engine, IBAE, was written by llearch, so technical questions about its implementation are for him to answer.  Rumour has it that DMFA will switch to a version of it when the site is updated.

The strip database is a flat text file of the form:

1|filename1.png|
2|filename2.png|

...The second pipe denotes a third parameter, which seems to be a subtitle thing like on DMFA, but I haven't looked into using it yet. 

A suggestion - It would take a bit of work, but might be nice to have, especially as your comic archive grows: A search method. I figure probably a text-database with all the text in each of the comics, and strstr/stristr for searching. I am thinking something like http://www.schlockmercenary.com strip search here.

I don't know enough about PHP to do that, but it would be cool if I can figure it out, or if someone can contribute such an engine.  (Hint hint)

For the about page(and heck, it would work for the cast page also), how about this: You have two content columns, a narrow left one with images/text links to each section of the page, and content on the right in a DIV frame. You have nice, shiny mouseovers for each of the images/links(link mouseovers can be simply a brighter color or something), and when you click on each one it pulls that section into the DIV via Javascript(Probably a set of Javascript strings in the HTML, for instant loading). If Javascript isn't enabled, when you click on the link it loads the page again, but with that section selected - doing the same thing via php.

I've no idea how that would be done.  My knowledge of HTML is basically 1995-1998 era, but it's a nice idea.  Except it would probably break on some browsers.  Ideally I'd prefer it if the thing still works on Lynx, at least to some degree.

[llearch n'n'daCorna]

A suggestion - It would take a bit of work, but might be nice to have, especially as your comic archive grows: A search method. I figure probably a text-database with all the text in each of the comics, and strstr/stristr for searching. I am thinking something like http://www.schlockmercenary.com strip search here.

I don't know enough about PHP to do that, but it would be cool if I can figure it out, or if someone can contribute such an engine.  (Hint hint)

Such a thing is doable. Eminently so.

Time taken to implement it would vary. You might be able to get away with ohnorobot, although my experience of them is that they tend to provide some... interesting code, and aren't all that stable...

[RobbieThe1st]

Well, I can work on(and probably build) such an engine for you. The hard part(in my opinion) would be getting the scripts & text indexed.

I looked at feasibility right now, and threw together a simple script that searches case-insensitively in PHP4 both single words in any order, or specific strings(so searching for 'test "and something else,"' would only return the record if it contained both 'test' and 'and something else,'). I could probably add NOT support also fairly easily.

Right now, I was figuring on searching every comic's text just as a text string, however it would be reasonably easily possible to have it look at names as a separate thing - It all depends on what you figure is best.


Layout wise, I never considered lynx. I am honestly not sure. When I have a bit of time, I shall download it and take a look, see what I can come up with.


-RobbieThe1st

[Mao]

While Robbie can likely do more than I can, I'm developer as well and don't mind contributing a bit of my free time/code to help out.  My training was in desktop application level development, but I've been in web application development (legacy systems sadly) since I got out of university 3 years+ ago.  I'm not the most skilled programmer but I'm determined and I love my work so hopefully it balances out.

[Tapewolf]

Right now, I was figuring on searching every comic's text just as a text string, however it would be reasonably easily possible to have it look at names as a separate thing - It all depends on what you figure is best.

You mean the character names?  I was thinking of a straight text search of the dialogue - storing who said it as well might confuse things, but then I've only ever seen one comic's text search.

Layout wise, I never considered lynx. I am honestly not sure. When I have a bit of time, I shall download it and take a look, see what I can come up with.

Looking at it, the thing doesn't quite work on Lynx at the moment, since it isn't displaying the image at all. Adding the ALT tag makes it work in Links (i.e. you can download the strip's PNG for later viewing with ZGV etc) though not in Lynx itself.  Links might be a better bet.

Either way, I'd be happiest if the site can be viewed without requiring Javascript.

While Robbie can likely do more than I can, I'm developer as well and don't mind contributing a bit of my free time/code to help out.  My training was in desktop application level development, but I've been in web application development (legacy systems sadly) since I got out of university 3 years+ ago.  I'm not the most skilled programmer but I'm determined and I love my work so hopefully it balances out.

Feel free.  I can't promise I'll use everything I'm given, but if you can come up with something that fits the bill, I'd be more than happy to look at using it.

[RobbieThe1st]

Right now, I was figuring on searching every comic's text just as a text string, however it would be reasonably easily possible to have it look at names as a separate thing - It all depends on what you figure is best.

You mean the character names?  I was thinking of a straight text search of the dialogue - storing who said it as well might confuse things, but then I've only ever seen one comic's text search.

Yea, that's what I meant. And, it could confuse things, but that could probably be sorted out if it is useful.

Layout wise, I never considered lynx. I am honestly not sure. When I have a bit of time, I shall download it and take a look, see what I can come up with.

Looking at it, the thing doesn't quite work on Lynx at the moment, since it isn't displaying the image at all. Adding the ALT tag makes it work in Links (i.e. you can download the strip's PNG for later viewing with ZGV etc) though not in Lynx itself.  Links might be a better bet.

Either way, I'd be happiest if the site can be viewed without requiring Javascript.

What I was thinking of is a design that looks about the same without javascript, and *works* on most browsers, but if you have Javascript, you get extra visual effects, and the various data can be cached for instant viewing.


Mowser, I would be interested to see what you can think of or come up with.


-RobbieThe1st

[Mao]

Well, it will depend on what I have available to me, are we going to use some frameworks (like spring or struts) or server side scripting languages (php (I'm fairly new to that), jsp, asp, rerouting through pl/sql and so on)  Give me some pm's with what we need and what we have available and I'll start looking at possible solutions in my free time.

[Tapewolf]

Well, it will depend on what I have available to me, are we going to use some frameworks (like spring or struts) or server side scripting languages (php (I'm fairly new to that), jsp, asp, rerouting through pl/sql and so on)  Give me some pm's with what we need and what we have available and I'll start looking at possible solutions in my free time.

Prepare to be disappointed.  Firstly, since the site is running off a shared host, I have a rather limited control of what goes on it.  In fact I'm not entirely sure what is available on it myself, so it would probably be best to aim low.  The webserver is probably Apache 2.2.6, though I can't be certain.  PHP is certainly available, because we're using it.  I don't know which version it is, mind.

Postgres and some version of MySQL are available, but I've never had call to use it before.  I think they are massive overkill for this.  Personally I'd prefer something fairly simple to understand and maintain, and portable enough to work on most hosting services should the thing outgrow its current host.  As it is, I'm already paying extra for additional disk space so I'd prefer to keep things lean.

The site as it stands is an unholy mixture of PHP and HTML with SSI.  The front page and archive are PHP-driven, pretty much everything else, e.g. the cast pages is HTML driven.  The site update of which I speak largely consisted of moving the header and footer menus into separate files which are included inline via SSI.
Switching to PHP for the cast pages etc will obviously mean rewriting them which is currently beyond my ability in terms of understanding PHP.

If anyone is curious I can probably take a dump of the site and put it somewhere temporarily.

[llearch n'n'daCorna]

ew. SSI? With PHP available? *wince*

Iffn you want that fixed, pass me a copy of the files (as in, one file, plus all included files) and I'll show you how to include using php.

Which has the added advantage of being slightly more readable....

[Tapewolf]

Iffn you want that fixed, pass me a copy of the files (as in, one file, plus all included files) and I'll show you how to include using php.

I'll try to sort that out tomorrow.  What really, really annoyed me was that I was unable to get PHP to include the HTML fragments, even though your code managed to do it no problem.  For me, it simply wouldn't do it, and this is why the PHP pages have the headers and footers statically included still.

[Mao]

I won't lie.. I shuddered when I read what you wrote.  Either way, a site dump in a compressed folder of some sort would be nice.  I'm not particular as to which.  gzip, tar, zip...whatev.

[RobbieThe1st]

I won't lie.. I shuddered when I read what you wrote.  Either way, a site dump in a compressed folder of some sort would be nice.  I'm not particular as to which.  gzip, tar, zip...whatev.

Yes, that would be very nice. I too have no problems reading any common zipped format.

Also, one thing that would be useful:
Create a blank text file in notepad or w/e, and paste in this line:

Code Select Expand


<?php phpinfo(); ?>

Name it "phpinfo.php" or something like that, upload it to your server, and then paste the link here.
This gives a bunch of information about what your PHP install supports, its version, and more data than a normal person can handle.
Still, this will tell us both what your server can and cannot do. I find this extremely useful.

If you could do that, Tape, it would be extremely helpful.

Edit:
So, I had a bit of time on my hands, and threw together this layout:
http://robbiethe1st.afraid.org/pf/cast.html
This is *basicly* what I was thinking about with the selector, although a proper final version would have some proper colors, perhaps even nice shiny image borders around things.
Go try out the page with JS on and off. It works in FF fine with both(With JS off, it attempts to load 'cast.php?page=*name*' - Later on, that would load up a copy of the same page with the data box having the cast page for *name* pre-loaded).

The actual data can be in a scrolling-"frame"(like this one), or one that stretches as long as it needs to(so you would scroll with the window scroll-bar instead). Note that I am using a DIV for it, so no worry about real frames and incompatibility.

I went with DMFA images and data, why? They were the right size. Don't sue me.

Note that I am using Javascript-controlled CSS for the mouseovers, and each mouseover image is a single image with both the regular and mouseover images in it. As such, there should not be any load time on mousing over, for those of us on slow or laggy connections.
This also means that the mouseover can be whatever combination of effects you want - Just so long as its the same size image(or, with a bit of modification, a different size), it will work.

Also, note that in this proof of concept, I added the data by hand. In a more finished version, that will all be done dynamically via PHP.

What do you think?

Thanks,

-RobbieThe1st

[Tapewolf]

Here's the php info:
http://www.project-future.org/phpinfo.php

Dear gods, it's still on mysql3.  And what's this... sqlite 2.8?  Anyway, PHP itself is version 4, though my understanding is that the site can be moved to a newer server running PHP5 on request.  I guess this is the price of uptime 

As for the experimental cast page, it's definitely pretty.  It's not so pretty under Links, though - the cast names don't have ALT tags and you get a 404 error if you try to click on them.  (/pf/cast.php not found)
The only other thing that I'm not sure about from a spoiler point of view is that it makes it easier to compare cast profiles, though I can probably live with that.  It would definitely rock for the strip archives.

**EDIT**

I've made a few slightly changes to the comiclist file, strip.inc and front.inc.  This should make it work on Links and also adds a comment to the bottom of each strip.

[llearch n'n'daCorna]

Here's the php info:
http://www.project-future.org/phpinfo.php

Dear gods, it's still on mysql3.  And what's this... sqlite 2.8?  Anyway, PHP itself is version 4, though my understanding is that the site can be moved to a newer server running PHP5 on request.  I guess this is the price of uptime 

... I'd be more concerned about the SSL libs, myself. OpenSSL 0.9.7a has known exploits...


Incidentally, Robbie, your server isn't visible from here. :-/

[Tapewolf]

... I'd be more concerned about the SSL libs, myself. OpenSSL 0.9.7a has known exploits...

So does the version of zlib they're running, if I'm not much mistaken.

Anyway, in case you missed it, I have modified the site slightly over the version in the tar file.  You can probably just wget the .inc files...


**EDIT**
You useless lot!  So much for kicking the tyres... the 'First' and 'Last' buttons were knackered on every single page except the front page and the strip archives 

[Darkmoon]

You useless lot!  So much for kicking the tyres... the 'First' and 'Last' buttons were knackered on every single page except the front page and the strip archives 

(points and mocks)

Tape, I'm not a progger, which is why llearch did the backend work on this. But, since you have switched to the IBAE engine, if you have interest in eventually switching the rest of the site over the IBAE/Designs by Firelyte package, I'd be happy to talk to you about a comprehensive site redesign. XHTML 1.0 Strict and CSS2. Be nearly cutting edge (since cutting edge doesn't work in archaic browsers... or Internet Explorer).

[Tapewolf]

Tape, I'm not a progger, which is why llearch did the backend work on this. But, since you have switched to the IBAE engine, if you have interest in eventually switching the rest of the site over the IBAE/Designs by Firelyte package, I'd be happy to talk to you about a comprehensive site redesign. XHTML 1.0 Strict and CSS2. Be nearly cutting edge (since cutting edge doesn't work in archaic browsers... or Internet Explorer).

It's something I might consider for the future.  The big problem is that I don't really know what it should look like.  The current design, with the Impact font was just something I put together quickly, but to be honest it has grown on me.    If I do look at a total redesign, I'll probably want to keep the main logo as black Impact on white.

[Darkmoon]

Well, things can be done with a simple, black and white layout to keep the general feel, and yet add a splash of pop to it, something that makes it look more professional and cool, while not ruingin the clean aesthetic...

If you wanna discuss it at some point, I'd be happy to.

[RobbieThe1st]

I too have problems with the design side of things. I have plenty of ideas, but generally for small things(like the shiny flip-cast page), but no clue what to do around it(which is why if you attempt to find my website, you see lots of half-done stuff). I however like to think myself competent when it comes to taking a layout and producing a backend that works with it; At least in the past I have had no trouble doing such.

In other words, I can build you a search page easily, and make it fast and featureful, but not a GUI frontend for it. I can also make it XHTML compliant - If that is important.

So, that is where I am at, basically.
I have been a little busy as of late, and hesitated on actually building the entire search page, because I am not quite sure what the frontend is going to be, and therefor what options I should add, and quite how I am going to do the frontend-backend connection(hard-coded echos and such, a text file that gets string-replaced, or even an include with HTML and PHP values in it). I should be able to figure out the easiest(and fastest/lightest-weight) solution once I see what I am dealing with, frontend side.


-RobbieThe1st

[Tapewolf]

I too have problems with the design side of things. I have plenty of ideas, but generally for small things(like the shiny flip-cast page), but no clue what to do around it(which is why if you attempt to find my website, you see lots of half-done stuff). I however like to think myself competent when it comes to taking a layout and producing a backend that works with it; At least in the past I have had no trouble doing such.

One of my colleagues was talking about site design yesterday.  I showed him your flip-cast thing and we tried to figure out how it worked.  I must confess we found a few drawbacks in the implementation.
Firstly, it doesn't seem to have a clean fallback if JS is unavailable - the 404 stuff seems to be the product of it assembling a URL from fragments of code that were lying around.
Secondly, each cast page was stuffed into an array which would be hell to maintain.
Unless of course what we're seeing is something cooked by the server and the original source has each page in a .inc file or something?

It's pretty, but kind of rough in its implementation.

In other words, I can build you a search page easily, and make it fast and featureful, but not a GUI frontend for it. I can also make it XHTML compliant - If that is important.

My approach to standards so far has been making the page too simple to go wrong 

I have been a little busy as of late, and hesitated on actually building the entire search page, because I am not quite sure what the frontend is going to be, and therefor what options I should add, and quite how I am going to do the frontend-backend connection(hard-coded echos and such, a text file that gets string-replaced, or even an include with HTML and PHP values in it). I should be able to figure out the easiest(and fastest/lightest-weight) solution once I see what I am dealing with, frontend side.

All that I can really show you is what was in the tar file.  I don't think of the site in terms of frontends and backends - with the exception of IBAE, it is a document rather than a process as far as I'm concerned.  So to be honest, I don't really know how to answer your question.  Are you referring to the layout of the results pages?  I don't see the actual search dialogue as being something that requires a whole heap of design work.

Well, things can be done with a simple, black and white layout to keep the general feel, and yet add a splash of pop to it, something that makes it look more professional and cool, while not ruingin the clean aesthetic...

If you wanna discuss it at some point, I'd be happy to.

I'm just thinking that it might be nice if the site is revamped to coincide with chapter 7, so I probably will take this up with you month or so down the line.

[RobbieThe1st]

One of my colleagues was talking about site design yesterday.  I showed him your flip-cast thing and we tried to figure out how it worked.  I must confess we found a few drawbacks in the implementation.
Firstly, it doesn't seem to have a clean fallback if JS is unavailable - the 404 stuff seems to be the product of it assembling a URL from fragments of code that were lying around.
Secondly, each cast page was stuffed into an array which would be hell to maintain.
Unless of course what we're seeing is something cooked by the server and the original source has each page in a .inc file or something?

It's pretty, but kind of rough in its implementation.

*headbang* Well, first off, the 404 is somewhat intentional. I never made the PHP backend for it(why do that if the design isn't good?)
Rest assured, that in a proper implementation, it would all be done automaticly, and clicking on a link with javascript disabled would *not* 404. Note also that the "cast.php?page=*name*" *name* part is something I just arbitrarily stuck in there so you could see how it would work - In a proper version, it could be something like *cast member's name*, an ID number, or whatever arbitrary string you want.
In the version that is now up, there is *no* dynamic anything set up, so what you see with view-source is what is up on the server, so what you see is what I typed in.

My approach to standards so far has been making the page too simple to go wrong 

Thats what I try to do, although to get nice stuff, its hard. I have been using simple stuff with my Javascript, and the code tends to *work* in IE6, as well as FF3 which I do my developing on. I have had trouble however with "flashing" and or reloading when I use Javascript changing CSS background-positions. I don't quite know what causes it or how to fix it - I am going to have to look that up.

All that I can really show you is what was in the tar file.  I don't think of the site in terms of frontends and backends - with the exception of IBAE, it is a document rather than a process as far as I'm concerned.  So to be honest, I don't really know how to answer your question.  Are you referring to the layout of the results pages?  I don't see the actual search dialogue as being something that requires a whole heap of design work.

Ok. The thing I am mainly concerned with is, are we going to use the current layout and shove some form elements below/above the comic in the archive page(Something like how I implemented it Here), or duplicate the archive page and do the same thing(so one "archive" page with the search-form, one without?), or are you going to be using a new design that I should build it around(Darkmoons perhaps). Do you have any specific plans or ideas as to how a search page should be set up?

Note: Sorry about my last post. I was kind of tired, and didn't make things as clear as I would have liked.

I'm just thinking that it might be nice if the site is revamped to coincide with chapter 7, so I probably will take this up with you month or so down the line.

On my end, I can easily do everything within a month, so no worries there.


-RobbieThe1st

[Tapewolf]

*headbang* Well, first off, the 404 is somewhat intentional. I never made the PHP backend for it(why do that if the design isn't good?)

Ah, so it's just a mockup to demonstrate the look and feel, so to speak?  That's okay.

Ok. The thing I am mainly concerned with is, are we going to use the current layout and shove some form elements below/above the comic in the archive page(Something like how I implemented it Here), or duplicate the archive page and do the same thing(so one "archive" page with the search-form, one without?), or are you going to be using a new design that I should build it around(Darkmoons perhaps). Do you have any specific plans or ideas as to how a search page should be set up?

Barring any mishaps, chapter 7 looks set to kick off around mid-January.  I don't know what Darkmoon's turnaround time is, but the site is liable to remain the same for a few months.
IMHO, the best approach would be to design it to work with the site as it is now, and we'll try to make sure it is taken into account when the site is revamped.