Link to home
Start Free TrialLog in
Avatar of MPEGyna
MPEGyna

asked on

Web scheduler GUI, JavaSript and CSS resizable solution?

I've managed to create a layout of scheduler with JavaSript and CSS to fit in the given area.
I've tested it in IE6, up to date Firefox and Opera. The resizable property is because of need
of work in major browsers with variable resolution for a web page. I'm not very happy with
my solution of the problem (see http://mpegyna.aleq.cz/hn/plainschema.html). The meetings
are at different positions in different browser, also the computing of positions has some errors
based on the browsers calculating errors and rounding of calculations. I'm asking if there's a
better solution of the problem (different idea of placing the meetings in the calendar or some
CSS or computing improvemets). Or should I use some fixed templates according to the resolution
available? Thank you.

mpegyna
Avatar of COBOLdinosaur
COBOLdinosaur
Flag of Canada image

Oh my; that is seriously defective right from the design concept up.  I hope you are not easily offended, because I don't know anyway to be honest without coming across very negatively.

It is a piece of window glass.  A slight tap breaks it.  You have overflow hidden so with a small screen or a large font part of the display are inaccessible.  You are using pt for font sizes.  points are for printing not display.  The table layout is inconsistent in column widths probably because of the overly complex calculations.  

You are basically trying to draw the page.  That is not layout, that is graphics presentation, so you might as well generate the whole thing as a graphic on the server.  That would not not make it accessible or usable, but would at least deal with the presentation issues.  

It will break in a milion different ways because you have it so overcoded that the browser is not allowed to try an optimize anything.  A simple thing like the user changing font (no you cannot prevent them from doing that) breaks it.  Changing screen size breaks it. Reducing the canvas size by using toolbars breaks it.

It still has zoro funtionality so it is no more than a presentation prototype, and it does not work in even that very passive, static role.  You might be able to convert that to some kind of template but it will have very little ability to absorb anything more than very limited and restricted content.

Sorry I could not be more possitive about it and that I have no real help for you but this is a long way from being usable.  I recommend that you look to much more flexibility, much less dependency on code for layout management, and get familar with web standards and accessibility guidelines.  Then take another shot at it and use EE as a resource to help you through the early parts so you don't end up late in the game with something that is not workable.

Cd&
Avatar of MPEGyna
MPEGyna

ASKER

First, if I can't help me solve my problem, please, don't write here. It's a waste of time.

I forgot to write it's only a layout concept, not functional. Anyway any functionality is added only by inserting right links/clickable areas in the page.

Don't see where is my page messing with web standards and accessibility. It's a chart and therefore it has some specific demands such as the need to see the whole chart instead of text inside the cells (therefore the overflow hidden). Don't know how are you familiar with PC graphics but your argument "points are for printing not display" shows your lack of information in some areas. Also don't see any inconsistence in column widths, because they are calculated to be same, so where's your inconsistence? How is the page broken if screen or page size is changed (maybe you've just found some bugs in browser calculations of the elements, yes, I know about them)? Changing font size to extremes may cause problems, but yes, I can prevent users from doing that.

Evidently you didn't understand my question, because if you do, you wouldn't send your replay.The problem is in right positioning of the meetings. And I ask if there's some solution for it or if it's better to use fixed layout. Think this over and if you're able to anwser me, do so, either don't replay, please.
Enjoy your stay on the site. I hope that someone comes along to help you who does not mind having their time wasted.  If at some later date you decide you would like to learn how to solve your design/development problems feel free to let me know.

Cd&
Okay, I'm going to HOPE that the content is serverside generated. Here's how you can create a useable scheduler if you can pull the content properly from the server with a language like PHP or ASP.

Generate a table with <th> tags for your hours and set a <col> tag for the first column with a class="day" so you can style the days.

When you loop through to create the content <td>s, if one contains a meeting, set it to class="event" and add a colspan with the number of hours (call that X) the meeting will take. Skip the next X-1 <td>s so everything fits nicely.

The end result should look like the code here. I've styled it. Note that this isn't pulled from a database but it easily could have been with the algorithm I mentioned above.
http://intelligentshadeofblue.com/ee/Q_21479618.htm

If you need help with the actual generation of the content, please let me know.

It should be fairly straightforward if you've stored the data, however. If you haven't done that or maybe aren't familiar with serverside languages, you probably need to read up at http://php.net and do some coding yourself before you tackle this project, which isn't exactly beginner (although fairly simple).
As you have your content now, Cd& is extremely and absolutely correct, however. It simply can't be done the way you have attempted to do it and expect good results.

>>points are for print.
Points are also for graphics, true, but they're not for the web in any way, so he's correct there too although his terminology might not be what you're used to. Don't use absolute positioning. It pulls the elements out of the page flow, which is Bad(tm). There are very few exceptions to this, and I can't think how this page has any of them.
(I assume by points you both mean pixels!)
Stormy,

pt == points take a look at the stylesheets.

Because in this forum we have to deal with a lot of designers from print media who think web pages work the same way it is helpful to have some common terminology:  http://www.bbc.co.uk/dna/h2g2/A896231

Make not e of the fact that the size of a point and the size of a pica are not consistent which makes them pretty poor candidates for a unit of measure on a web page.

Cd&
Avatar of MPEGyna

ASKER

StormyWaters: Your simple solution with the colspan will not work with meetings at the same time and day (Wednesday in my scheduler). I thinked about this solution earlier, but there must be also some rowspans and whole together is pretty complicated in functionality than absolute positioning meetings above the table.

But since I'm interested in AJAX, I found this awesome project http://www.monket.net/cal/#top which could solve my problem.

--

>>point are for print
By points I mean font/typographical points (pt not px). Using font size definiton in pixels is not nice, except for small displays (PDA's, cell phones, etc.). It's because the font faces are made in several font sizes and size in pixels require some interpolations and comutations and therefore text isn't nice like if used the defined size in points. Text defined in pixels is wicked.

>>It pulls the elements out of the page flow, which is Bad(tm).
Not in this case. The chart is more likely like embeded object, than a simple table, so no one expects the page view in lynx or at PDA. It's a web applicaton, not the web document. Absolute positioning here is reasonable.

You say Cd& is extremely and absolutely correct. To tell the truth, I don't understand his reply. What do you want to tell me, why should be my page 'wrong'?
Avatar of MPEGyna

ASKER

>> Make not e of the fact that the size of a point and the size of a pica are not consistent which makes them pretty poor candidates for a unit of measure on a web page.

You're absolutely right. But it's essential to use the points as I explained higher.
>>why should be my page 'wrong'?
The original page you linked to is badly designed. It uses too many calculations that the browser should be doing, it's hackish and hard to maintain and has no practical functionality. It's too inflexible to be used.
>>absolute position is reasonable.
Since different browsers render things differently, using absolute positioning can and usually does break a page. It has with yours, the original question.

Anyway, back to the problem. Multiple events.

A bit of a structure change, we'll use <tbody>s rather than <tr>s to control the days.
For every overlapping event (a bit more code) add another row to the relevant <tbody> with that event. For non-overlapping, leave it in the first one. If you want you could rowspan it too with a bit of thought. My page is updated now to include this.
Avatar of MPEGyna

ASKER

Sure I close the question because I found a solution in my post > project Monket calendar http://www.monket.net/cal/
Last comment to Stormy Waters solution. Your table renders events wrongly (or the way I dont like) - the "overlapping events" doesnt have one top border and the "multiple events? fine!" should have height as the sum of the heigts of overlapping events in the same day.
Also using multiple <tbody>s is odd for me.
ASKER CERTIFIED SOLUTION
Avatar of ee_ai_construct
ee_ai_construct
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial