August 26th, 2002

  • brad

We need web designers!

Mart's update stole most my thunder, but I don't care... I didn't want to type that all. Anyway, the compiler really kicks ass now, and the core layer is coming along nicely.

Some demos....

Apache-style indexing: (it's not Apache!)

Paging in galleries:

Paging between pictures:

Bottom scrolling frame:

Color on mouseover:

But, like Mart said: we need designers now! (Maybe all the designers stopped reading this community?)

We still have a lot to do, but nothing that should block progress on making layouts.
  • mart

Status Update

Brad's out, so I'll do a status update before I go to bed. Does anyone even read these anymore? ;)

  • The S2 data structures are essentially completely populated now. Some of the builtin functions may still be missing (I'm not sure how far Brad got with that) but we can make layouts now and have them run. The stuff that's still missing is stuff that there's no way to define yet, such as image titles.
  • Paging works for both galleries and pictures within galleries, and the core layer provides a default implementation of the paging links which is simple and will probably be overriden in most layouts.
  • Some compiler stuff was fixed, and Brad's working on array and hash literals, which will work like this:
    var string[] blah = ["element", "element", "element", "element"];
    var string{} bloo = { "key1" => "value1",  "key2" => "value2" };
    The similarity to perl syntax is intentional. Unlike perl, though, all values in these literals must be of the same type, and that type is what decides what the return type of the literal is. In my examples, the return type is a string array because all of the members are strings. Also, unlike perl, the hash syntax does make a distinction between => and a comma, but for people who write sane code that shouldn't matter! ;)
  • The type coersion stuff is being added in other places. One example is that it should soon be possible to assign an object to a string variable and have it coerced into a string using the toString method if it supplies one.
  • Both Brad and I have been working on layouts. Brad's been improving his Apache indexing layout, and it now has a working indexpage aside from a few minor flaws such as the date format being wrong, because the code to handle that will use hash literals!
  • I'm going to be writing default implementations for everything in core.s2 soon, so layout authors won't necessarily need to write everything anymore. (Although in most cases they should, because the output from the core layer is not guaranteed to remain the same forever.)

We need people to make pretty layouts, though. Where did all those designer-types go? ;) I've been working on some, but I'm a programmer rather than a web designer, so my ideas are pretty simplistic and don't really go beyond the “bunch of thumbnails in a grid” idea. If anyone wants to submit some HTML templates showing a layout's overall page style, what the galleries should look like and so on, either Brad or I will make S2 code out of them.

Collapse )

back from vacation

ok, so i'm back from a very fun two weeks away from the computer and in the sun. i'm headed back to school in the next few days, but i was wondering if there are any nagging things that need to get done on fotobilder. if i had any real design ability, i'd try my hand at that. i tend to be able to help people design things well, but it takes me WAY too long to do anything myself. anyways, i'll just read back through all the S2 posts and see if anything pops out.
amused, happy
  • mart

Requirements for Design Submissions

In order to make a FotoBilder layout from submitted template HTML, we'll need the following:

  • A design for the overall page layout, if applicable. This is the 'template' into which the different views content gets placed. Even if you aren't going to have common template stuff between different views, we'll need this to implement the "Misc" view which will be used to generate things which don't have real S2 views yet.
  • A HTML template for an index page, a gallery page and a picture page, as well as information about what should happen when there are too many pictures to display on a single page (usually some kind of navigation links) and when viewing a single picture out of a gallery and there are several pictures in that gallery (again, probably the same kind of navigation links in most cases)</p>
  • Information on how many pictures should be the default maximum number shown on a single gallery page, what other options you would like to include (and obviously details about their implementation) and details of how you'd like the colours to be customisable.
  • Some kind of design and/or description of how you'd like gallery and picture management links included in the page if the viewer is the owner of the gallery. When a user is viewing their own gallery or picture, there should be a link somewhere to edit that gallery or picture, but that link does not show up if another person is viewing the gallery or picture, so we need to know what needs to be left out in the case where this link is not displayed.
  • In similar vein to the management links, there should also be a 'log in' link somewhere which is displayed when users are not logged in. This link can be turned off on a site, user and gallery-specific basis and doesn't show up when the user has already logged in, so we need to know what to leave out in the case that the link is not displayed.

If you don't include all of this stuff, either Brad or I will have to put it in ourselves, and the result will probably interfere with your design sensibilities. I also reserve the right to clean up people's yucky HTML, so feel free to submit nested table monstrosities but be prepared for me to make your HTML code clean and tidy! ;)

With all that said, have fun!