0

I developed a prototype of a graphical time scheduler but need to re-code most of it since the JS is a mess at the moment. And I realized this is the best time to make any major changes to my design as well.

It uses an html table and looks like:

schedule app

Currently:

  • starts off empty and grows/shrinks via jquery rewriting it
  • fairly dynamic (time scale, sizes, etc can all be changed at run time)
  • horizontal lines are halfway through cells, they aren't cell borders (like here).
  • red boxes are anchored in a cell and given an offset and size via JS. same with blue box.
  • time tags are divs inside cells and not really fun to work with

I need to add a bunch more functionality:

  • some basic/limited zooming
  • multi-day tags
  • labels on the redboxes
  • hover/click effects
  • possibly some drag effects

I can figure out all of the above but I'm unsure if it's better to go with a table or list (or something else?). Technically, it's a "timetable" but it looks more like a graph. My experience with lists is very limited so I'm looking for someone's advice that's done this kind of thing before before. I don't want to switch to a list and realizing I need to change my base html type partway through.

Also, this is not a "public" app (it's behind a login), if that makes a difference. And my key priorities are smooth development and easy maintenance/customization. Though thoughts about JS performance would be useful too.

EDIT:

Rereading, my question is a bit vague (the 'why' part of it).

What I'm interested in is which html element makes it easier in regards to:

  • positioning, alignment
  • absolute positioned things like red boxes
  • effects and events (of the type previously mentioned)

Or are they fairly similar?

Conclusion Edit:

I eventually changed my design to a grid like div system. Tables worked up until I tried to add Firefox compatibility. Firefox and Chrome handle tables differently when it comes to complicated positioning and trying to get it pixel perfect was a nightmare.

Brian Tompsett - 汤莱恩
  • 5,195
  • 62
  • 50
  • 120
DanielST
  • 12,317
  • 5
  • 39
  • 62
  • 1
    The list would likely be built in a model similar to a table if it is not specifically using a table format (ul as table-row and li as table-cell). If you were going to be implementing all those additional features I'd imagine using a list all though you are placing divs in your cells int exactly valid html. Person preference in this case is go to the list. – TheHamstring Jul 25 '14 at 14:32
  • @TheHamstring if it were you, would you _change_ to a list if you had the table already been built. I'm recoding it, but obviously it's a bit easier to stick with the same design since I don't have to change the css much. – DanielST Jul 25 '14 at 14:51
  • It's definitely easier to keep with the table. I don't know what your future plans are with this structure but if you use a table it is rigid. A list you can turn off its table like grid structure which would give you more play. If you wont be playing with this structure in the future the table grid you have already will be fine. – TheHamstring Jul 25 '14 at 14:57

1 Answers1

1

Why lists? seems like each "box" should be a div. That would give you the most freedom when it comes to positioning and drag and drop functionality.

vectorfrog
  • 1,193
  • 7
  • 10
  • Wouldn't it be better to put the divs into a list? Otherwise I'd be building my own columns and rows out of divs instead of using the appropriate type. – DanielST Jul 25 '14 at 15:35
  • lots of ways to skin the cat, I was thinking using a css grid system to handle the "table like" layout. Just choose your favorite CSS grid system, or roll your own. Or you could use something like gridpak, to quickly build a custom grid layout. – vectorfrog Jul 25 '14 at 15:51