head err
I usually try not to worry about work stuff at home, but this thing had me thinking for quite some time now. Well, not just me, but two other designers from my team, a developer, and two content team members.
All the fuss is over a header that we need to introduce to intranet pages. 30 px tall, two form elements, four links… if we can put it on every page on the intranet, people would know when they are on an intranet page, and could jump effortlessly to any other page, do a search, fill out their timecard, etc. etc.
Sounds easy.
Now, the intranet consists of a large number of different servers, some UNIX, some Windows. OK… There are a lot of apps, JSP, XSLT, you name it. OK… A CMS system would help things? Sure. There is one. But no one is using it. D’oh.
Soooo… we have the header code, HTML, CSS, with some JavaScript mixed in. We want to keep it in one location, so that we could easily make updates and see them reflected across the intranet. It would be great to just server-side-include it everywhere, but you can’t SSI across servers. Double d’oh.
The developer had a great idea – stick the header inside the iframe. Nobody likes iframes, but here it seems to work (since you don’t need to print/scroll/crawl the header). Tiny wrinkle – when the browser window is resized, the header goes on two lines and grows beyond 30px. The iframe stays at 30px. Not so good.
The developer was not discouraged – he coded up a solution that resized the iframe in the parent window when needed. Brilliant. Only JavaScript doesn’t work across servers.
Since then, we’ve cooked up a dozen schemes of pushing the header code to the other servers automatically – even separating the iframe-related script to wrap it around the normal header. Of course, the network admins would have to configure each server separately.
But, around this time, I’m getting to the point of just saying that we should code the header in a way that would keep it from having to grow on resizing. Stick it in the iframe, and call it a day. The users might not see all the links in all the screen sizes, but you know what, sometimes the result does not justify the means.
All the fuss is over a header that we need to introduce to intranet pages. 30 px tall, two form elements, four links… if we can put it on every page on the intranet, people would know when they are on an intranet page, and could jump effortlessly to any other page, do a search, fill out their timecard, etc. etc.
Sounds easy.
Now, the intranet consists of a large number of different servers, some UNIX, some Windows. OK… There are a lot of apps, JSP, XSLT, you name it. OK… A CMS system would help things? Sure. There is one. But no one is using it. D’oh.
Soooo… we have the header code, HTML, CSS, with some JavaScript mixed in. We want to keep it in one location, so that we could easily make updates and see them reflected across the intranet. It would be great to just server-side-include it everywhere, but you can’t SSI across servers. Double d’oh.
The developer had a great idea – stick the header inside the iframe. Nobody likes iframes, but here it seems to work (since you don’t need to print/scroll/crawl the header). Tiny wrinkle – when the browser window is resized, the header goes on two lines and grows beyond 30px. The iframe stays at 30px. Not so good.
The developer was not discouraged – he coded up a solution that resized the iframe in the parent window when needed. Brilliant. Only JavaScript doesn’t work across servers.
Since then, we’ve cooked up a dozen schemes of pushing the header code to the other servers automatically – even separating the iframe-related script to wrap it around the normal header. Of course, the network admins would have to configure each server separately.
But, around this time, I’m getting to the point of just saying that we should code the header in a way that would keep it from having to grow on resizing. Stick it in the iframe, and call it a day. The users might not see all the links in all the screen sizes, but you know what, sometimes the result does not justify the means.
0 Comments:
Post a Comment
<< Home