Archive for May, 2006

Getting it right..

Sunday, May 14th, 2006

Sometimes I get things right even if I have no idea what the right answer to a certain question is. Today the question was which type of company is the most common in Slovenia and by how much. My answer was “d.o.o. by 13 times”. It’s actually by 13,18 times. I hear there’s this certain smile I do when things go right.

Frameworks in the future..

Sunday, May 14th, 2006

We recently had two workshops on AJAX and in the second one my co-host presented some JavaScript frameworks and we got into a discussion about when we’ll start using one of them. It seems that it was not a question of if but of when. I should point out that both of us are proficient in JavaScript and are not the primary targets of frameworks.

A few days later Eric posted Flummoxed by frameworks that started a huge debate about it (he also posted a later explanation). Yesterday I was also listening to Dustin’s episode 12: YUI Library Discussion about the Yahoo! User Interface Library.

What I got from all this was a weird feeling about frameworks. I can’t decide whether I like them or not and why. I don’t especially like any single one of them. Like any other advanced developer I have my own bunch of methods/functions/objects that I regularly use and copy around. This code evolves automatically as I find bugs or need more features. Frameworks on the other hand do this with a plan. Or so it seems. Hopefully the developers behind them are strong enough to fight the feature requests coming from noobs to keep the core frameworks small, simple and above all understandable. Even though some say bandwidth is almost free nowadays.

After a whole day of pondering I think I like the idea but probably not the hype and the implementations that more than anything frustrate me. I’m off to write my own framework.

Writing for web

Wednesday, May 10th, 2006

I need to consider this when writing for my apps. I’ll just do a search and replace…

Webby awards

Wednesday, May 10th, 2006

Webby awards have not been a surprise this year.

Semantic CSS

Monday, May 8th, 2006

Today as I was driving home from work I was thinking about ways to accomplish margins in CSS. This was probably due to a code inspection of a certain CSS file I was doing a few days ago that was ugly as hell. It made me think that maybe the number of WYSIWYG/clickety-click editors of CSS/HTML that produce DIV layouts is reaching the point where this needs discussing.

In my opinion a good HTML developer is one with at least a few years of experience doing various web sites on various platforms. This is due to all the things that can screw up a layout when things go off the chart either via user-generated content or by the constant redevelopment. You just can’t learn all the quirks and good practices through reading.

Up untill now it was really simple to figure out if somebody was proficient in CSS – they were using DIV layouts. Now you just can’t. And there are so many ways to create a layout that are just plain wrong and some people don’t know why. I’m not saying I always do but I think all the years of experience help.

So back to the beginning – let’s take a list item element. There is a bunch of ways you can change it’s margins. Let’s first look at the left margin.

  • text-indent:10px;
  • margin-left:10px;
  • padding-left:10px;
  • position:relative;left:10px;

Now let’s look at the top margin.

  • margin-top:10px;
  • padding-top:10px;
  • position:relative;top:10px;

If you add more elements to the mix you get even more options and usually more confusion.

If you’re proficient in CSS you should be thinking of other ways to do this. If you’re not you should know that ‘margin’ property is the way to go and that ‘padding’ property is the only way to add the padding. It’s really the same discussion as why an unordered list with items should be ul-li and not a p-br. And I hope you do know that one…

Changing the way we change websites…

Friday, May 5th, 2006

A while ago Marko wrote about reusability of css based designs. I didn’t agree with him fully but had no idea how to explain/prove it.

In the times of table layouts the process od redesigning a site was actually (at least) three things. First the content was restructured and some of it written again (the sitemap). Then the layout was changed to reflect the new structure and to better fit the content (the wireframes). At the end a façade was made for reflecting the latest trends in ‘webdesign’ (the design – or is there a better word for it?). Even if it was a three way process it was rarely done by three different people – ‘webdesigners’ did almost everything themselves. Since this was quite a lengthy process it was also expensive and some corporate websites changed once every three (or more) years.

Now it seems things are changing for the better. With a DIV layout, CSS based designs and a strict separation of layout and content we can actually split these three into separate stages. The strict division of these stages gives us the posibility to focus our work on what it really has to achieve. It’s true that you cannot use the whole 100% of the other parts but being able to keep 80% is good enough.

About a week ago I found out about two ‘design’ contents and the one Slashdot is holding was interesting because it was about proving a point – you can change the façade without changing the layout or the content. I did the whole thing without changing a bit of HTML (with a bit ugly CSS, would be nicer if a few lines of the code were changed).

I think this way of thinking will settle in and more and more changes will include only one of the three stages. Hopefully they will be based on user testing and/or usage data…