Archive for the ‘Web 2.0’ Category

About Ajax toolkits…

December 13, 2006

lots of toolkits are available today. They are cool but what we need is not necessarly cool effects (although some could help) but a framework that allows us to create our own widgets. So the question is not which toolkit to use but more which kind of design patterns or standard in writing a widget.¬† There are a few basic issues that are solved in these toolkits (like how to load libraries, how to link a html element and a JS class, what format to use for a class etc.) and the community should focus first on these points instead of trying to offer toolkits thaht have been writing for a specific context (i can’t see any that I can apply in my applications). We need design patterns and widget coding guidelines, not toolkits.. In the meantime, the only library I find useful – as a standard – is prototype.js … ūüôā

Advertisements

CSS design patterns for web 2.0

November 26, 2006

 

Summary: web 2.0 has seen dramatic changes in the way pages are developed. CSS standards are evolving to cope with the demand but in todays browsers web 2.0 requirements have outgrown CSS features and very few strategies are either defined or applied by CSS developers in the web industry. This makes web page creation a kind of black magic that is both expensive and risky as magic tricks might not work in next versions of browsers. This article describes the situation and provides 2 design patterns that make a significant change in developing web pages with direct returns on

  • css code reuse
  • quality,
  • safety of investments
  • ease of development and support of browsers.

 

Article:

As the web technology progresses on the client side with Web 2.0 being spread in the industry, we rely more often on both javascript and CSS for building websites and web applications. Whilst the javascript side is fairly well covered on the design side, with the knowledge derived from JS libraries (prototype.js, dojo, Y! UI, G! UI, etc.), we still don’t see enough efforts to rationalise CSS development (yes I know it’s a bold statement, but well just a view from my little corner, and anyway, I like bold statements :-).

We know that browsers are getting closer to each others in terms of CSS support. Thanks to Mozilla, we now have a decent cross platform browser that we can spot on our traffic analysis graphs without a magnifier. That means we now need to support more than one browser and it is a lot easier than it was with the evil Netscape 4 or Mac IE. But there are still some issues CSS developers (yet another title to put on already heavy CV in the industry) have to face nowadays…

First issue: font sizes and accessibility

By law, respect or any other reason, fonts in web pages that are written these days should scale well so that everybody can read them. To have fonts that scale well in all browsers, we should use units such as “em”, “%”, or “small/medium/large”, instead of “px” (pixels). However it is very difficult to use these units because:

  • “em” or “%” units are dependent on their context (what is the current font size), so any change in html or css can (and does) have side effects on other parts of the page. I know  it is possible to write pages like that but it is not easy and it is risky.
  • “small/medium/large” are the easiest and natural way of writing fonts that will scale well in any browser/device. However Mozilla, for probably a very good reason (what is it ?), displays fonts that are smaller than on any other browser. This breaks the design..

Conclusion: we can’t write accessible web pages with only a clean cross-browser CSS sheet.

Second issue: managing z-index

A lot of web applications now use drop-down menus or other widgets that display on top of others. In CSS, z-index property defines which layer should go on top of the other. Well, not always as IE has a bug for elements that are relatively positioned. It then breaks the rules and we have to apply special tricks well described in http://www.aplus.co.yu/lab/z-pos/ .

“height” matter

Not all browser support height properties the same way. IE6 allows to use the CSS “height” property for most html tags, whist in Firefox, the “height” is only supported (as defined in CSS standard) for block elements, and in any case, most of the time it is “min-height” that is equivalent to IE’s height .

Conclusion : getting the right height in CSS involves some kind of trickery to make every browser happy, and to play with “height”, “min-height”, line-height”, “padding” etc. until we get the right result in all browsers (whatever “all” means for you :-).

Lack of CSS reusability

HTML and CSS is often used beyond their limits and new de facto standards are created in this outland area. Examples are:

  • transforming ul/li lists into menus
  • creating side areas with floating divs (replacing tables).

Achieving these effects is not very easy because they use html/css features that were not designed for these purpose. The “float” property was mainly used to have floating text around images, not for replacing tables or create css menus. Although this works fine, CSS development is then quite difficult to write and then is more expensive. Also, because design pattern for reusability are not well known for CSS (apart from reading tutorials and rewriting things from scratch), we haven’t much CSS libraries on the market. Web development tools can help in some cases but not enough for making things any better.

Conclusion: CSS development is tedious and expensive because of lack of reusability and skill levels required.

Lack of common support for javascript behaviors in CSS

One design pattern that provides a direct impact on programming quality, time/money spent on projects of medium size is the “Model-View-Controller” or “MVC”. The basic idea is to separate things so that development can be done in parallel by different people (ex. graphic designer/html developer/javascript specialist/PHP developer/etc.). There are many other quality factors brought by this model (reusability, testing, maintenance, etc.).

In web2.0 applications, we can see components being implemented in web pages (ex. calendars, menus, other widgets, etc.). Modular Javascript libraries are available for helping in the development of such components, however it is still difficult to truly separate html from javascript the way html and css can be separated. The reason for that is we often need to attach a “behaviour” (such as opening a new window, adding a visual effect, etc.) to a piece of html and/or add html fragments in some specific parts of pages. To do so, we need to add <script> tags in the code. This solution is not very effective because html/css developers can’t write the page without either knowing javascript or work with javascript developers. This costs time and money and makes pages difficult to modify.

One excellent way to attach javascript behaviour to html is to put the attachment in a css rule. ex. li.menu { behavior: menu.htc } . This example use IE syntax for attaching a javascript component (HTC) to html. Mozilla has another syntax for behaviours. The main issue is that we can’t use them because they are browser specific (and also some browsers have no support at all for behaviours).

Several workarounds have been added to js libraries but they are cumbersome, fairly slow and/or break the (x)html standard:

  • parsing the DOM and add behaviours to html elements with a specific css selector: cf. “behaviour.js” or “prototype.js javascript libraries.
  • parsing the DOM and add behaviours to html elements with a specific attribute. ex. dojo library with its “dojoType” attribute.
  • add XML tags in the html code and transform by js into components (ex. dojo tags <dojo:widget />)

These solutions are good enough and the best ones we have available but they can make page loading a bit slow. If a standard for web components was defined and supported in browsers, we would probably see a lot more reusable components on the market…

No Support in CSS for selecting rules by user agent

Because of several cross browser differences, CSS sheets have to be written in browser dependent manner.  How can this be achieved? As nothing in CSS currently helps in writing CSS rules dependent on the browser application (apart from “screen”, “print”, “tv” devices selectors for <link> tag), developers are using black magic based on application bugs or CSS level support:

  • some funny sequences of characters make a rule or part of the rule work in some browsers and not in others (ex. \*//*/ for IE/Mac)
  • conditional compilation in html is supported in IE (in html only)
  • IE6 doesn’t support the “>” parent syntax (as in ul > li), so rules written with this syntax wont be used by IE.

The fact we have to rely on bugs in internet browsers makes the development of pages both difficult and risky. Difficult because these tricks are not easy to achieve and are poorly documented. Risky because bugs could be fixed (we have seen these things happening, even in IE). So in next versions of IE or Firefox we could see a lot broken designs in websites… This could lead to some decent amount of money spent in fixing these websites. It actually reminds me of the huge work involved in fixing applications in year 1999 for supporting Y2K. Or business applications when the euro currency was launched in Europe…

Proposed solutions and design patterns

Solution 1: adapting standards and browsers to the reality of web 2.0 development.

The ideal situation would be to have CSS standard following the development reality by:

  • adding CSS selectors based on the user agent and/or browser application. It could be for example:
    gecko: body {font-size:small;} ie.5+ {font-size:x-small;}
  • or have CSS selectors based on supported features (css2: ul>li {})
  • create standard JS components via css behaviors.

 

Design Pattern 1: add support for browser dependent rules (without relying on browser bugs)

One way to distinguish rules supported by a specific browser is to add a class selector of the form:

body.ie li { position:relative;z-index:100; }, body.ie_mac {position:static }.

Classes derived from the user agent can be added to the body tag at load time.

example (dependent on prototype.js):

// add support for user agent detection in document
Object.extend(document, {
getUserAgentClass:function() {
if (window.opera)
return “opera”

if (/MSIE/.test(navigator.userAgent)) {
if (/Mac/.test(navigator.platform))
return “ie ie_mac mac”
else
return “ie ie_win win”
}
if (/Gecko/.test(navigator.userAgent)) {
return “mozilla”
}
if (/Safari/.test(navigator.userAgent)) {
return “safari mac”
}
return “”
},

setBrowserClasses: function() {
// add user agent to body class
$(document.body).addClassName(this.getUserAgentClass());
}
});

// add UA classes to body
Event.observe(window, ‘load’,document.setBrowserClasses);

NB. by applying this method, we make sure that CSS rules will be safely applied to a specific browsers and that these pages won’t break when browser bugs are fixed or when a new version is launched… This also makes CSS development easier and faster, in the short and long terms…

Design Pattern 2: use an modular/OO approach to CSS

CSS libraries can be implemented by using two interesting features in CSS:

  1. the ability to add several classes to an html tag. ex. <ul class=”horiz_list menu”><li>etc.. </ul>
  2. filtering CSS rules by a selector: ex. .horiz_list ul li {float: left;}. This feature limits the impact of defined rules to only a part of the DOM, thus avoiding side effects to other html parts in the page.

Combining these 2 features allow HTML/CSS developers to create CSS libraries that can be directly reused with less risks of having side effects. In the example above, the horiz_list class is applied to a <ul><li> to make it a flat list. The actual design for the menu (colors, fonts etc.) can then be defined in “menu” class, thus making it very easy to develop horizontal menus…

This example can be applied also to javascript components: separating the design of components (colors etc.) from their function (horizontal menu). We can then share CSS libraries across projects and people and make the creation of web page less tedious and expensive…

Conclusion:

Developing CSS based pages is still difficult, expensive and risky because no actual design patterns or development standards are widely available or used by web developers. This could be easily improved by sharing the knowledge of CSS gurus (such as the guys at Zen garden and many others) into reusable CSS libraries or design patterns. This would help the web industry in getting better development quality at lower costs. The 2 design patterns described above could help achieving this objective and I hope that others will be available and applied in a near future…

Microsoft Gadgets

October 19, 2006

Please ignore the last part of the previous post: Microsoft DOES provide a widget engine and is actually providing the right model for it… Just found their developer blog:

But as many features as we are adding to Live.com, the site is still very much a Gadget platform for you developers out there to build on. We rely on you to build rich and interesting Live Gadgets that we haven’t thought of, and to build a strong ecosystem around this platform. Live.com is still in Beta today, but it promises to be one of the most popular Internet destinations when we launch later this year. You can leverage on the high traffic site to extend services beyond your web site by building Gadgets that live on Live.com.”

and their todo list seems promising:

Some of the things that we know we need to work on are:

  1. Unified Gadget model – we want to enable developers to write a Gadget once and have it run on both Vista Sidebar and on the web, maybe even in other environments.
  2. Allow 3rd party gadgets to change header and footer – today, all 3rd party Gadgets are hosted within and iframe and do not have access to the title, title icon and footer.
  3. Make calling web services easier – this is self-explanatory.
  4. Better Settings model – there is no standard way to do settings today for 3rd party Gadgets. We would like to move to a more declarative model.
  5. Better Localization model – we provide API for you to find out the query the current locale but we don’t provide much other support otherwise. This is not a big problem for most Gadgets, but it would be nice for more advanced Gadgets.

Looks like we’ll see Vista with a widget system intergrated in side bars… Anyone having tested Vista yet?

But will that support other platforms? Y! and G! widget engines work on PC and Macs…

Widget engine: a bridge between web and desktop applications

October 18, 2006

(sometimes I hate WordPress… Second time it loses all the post content and I have to write again… A summary will do I hope…)

Widget engines again… Google, Yahoo and other are creating an interest by adding small applications that link users’ desktops to online applications or websites.

The interest as described in previous post could be very strong once a business application of these system is in place.

If that happens how could other actors react? and who are these potential actors?

Given the fact widgets create a new link from users to (potentially) branded content, it is likely the technology will create an interest from others such as Microsoft…

And M! has already in place most of the required technology within M! Live Messenger: an application which supports authentication, multi channels and a notification engine. And this piece of software already runs on a lot of computers of the planet!!

So the only missing bit is the ability for M! engineers to integrate a widget engine based on html+css+js+ajax and to integrate it in Messenger. Given the development resources they have it doesn’t seem out of reach..

So maybe we could see M! playing as well with this technology in a near future, we never know.. Probably all will depend on the success of G! as M! seems more like a follower on the web these days (personal view:-)…

I’d be interested in your comments on the subject…

Google widgets and Office2.0

October 18, 2006

Google has released a new API for integrating its wdgets in any website. !!!!!!

Which impact can we expect from this news?

On the short term, probably not much except in personal home pages as most of these widgets are “cool” but not very useful, at least for commercial websites. It is unlikely we see these widgets soon on corporate portals, except maybe for some of them like map searches, etc..

However the impact will probably be to awake the web to this type of technology which is:

  • a piece of information displayed in component made of¬†html and javascript (easy to write),
  • this type of component can run on the desktop, in a website or on google portal.

Obviously we don’t really want to include google stuff everywhere, but when product developers realise that they can apply the same type of technology for THEIR own components, then we can expect that the next wave, right after AJAX, will be based on a¬†type of architecture where the content can be freed from website pages. Pieces of content will appear simultaneously:

  • in collaborative websites where users can manage them in a central place,
  • on desktops in widgets frameworks (google/Y! etc.) : so that we can be notified of any new article without opening the website (convenient as side popups can display news without distracting too much user’s attention)
  • in other syndicated websites: similar to RSS feeds which allow content notification to be displayed in RSS readers thus increasing the visibility of¬†the content. We could also with this technology foresee¬†websites exchanging applications modules as a kind of marketing tool. Content syndication will then not only be limited to xml or text forms but will include applications as well (just like Google maps are included in websites).

Is this impact limited to Google only?

probably not. We can expect Yahoo to release a web API and jump onto the mashup train. This new branding channel is too good to be left to a competitor…

This architecture will¬†probably¬†be most useful when provided by other “independent” widget frameworks such as http://www.widgetbox.com/ (mentioned in Reuters news). ¬†although this one does not yet provide a desktop engine for running its widgets and then is limiting their use to online mashup pages only.

Conclusion:

this technology is not yet advanced enough for commercial use but will probably be added to the Ajax-web2.0 pot soon (1-2 years?) so it might be interesting¬†to keep an open eye on its progress…

We can also expect to see other widget engines to come up as well as there might be¬†a dormant commercial market for it and current vendors provide solution targeting more personnal sites than commercial sites. Such a vendor would benefit from the technology awareness provided by Google and heat it up by real applications…

Microsoft Ajax toolkit

September 12, 2006

Just read today an article on CBR news about Atlas, codename project for Microsoft’s Ajax¬†toolkit. I have mixed feelings about it…

Pros:

  • microsoft is ussually good on the client side so we can expect soem nice widgets
  • will support all browsers (!!)
  • architecture distinguishes client and server side. The client side will support any server technology including PHP and CFM!

Cons:

  • it is again Microsoft against everybody else and they are not part of groups trying to create an Ajax standard.

Other:

  • will be integrated server side with their server technology in what they call ASP.NET 2.0 AJAX Extensions.

Conclusion:

Atlase seems like an intersting project to follow. If not tight server side with ASP.NET then it has the potential to be used widely. Not part of any standard though.. We will have to see how this impact the devlopement of conmponents on the server side and teh market for these components. They never really took off with java or ActiveX so it remains to be seen if a standard will be useful here…

Related thoughts…

As for the future of Ajax, I am still wondering how long we will be talking about it before it is integrated as “just another tool” in the development toolkit. But it ssems like it can make a real difference:

  • for enhancing the usability of service based application (the new challenge for Msoft and others),
  • it also has a potential of creating a mashup type of applications where people provide services with a cleint side component (or API). This is where a standard would be useful. The standard should address the various types of request to the server (forms, whole components, etc.). It would probably need to be based on XML for describing resources required by a component. For example: if we load a component, what CSS and JS files do we need to load as well, how do we manage CSS and JS conflicts? By name conventions or by isolating each component in a separate document (iframe)?

New Technology Blog!

May 19, 2006

ok, finally decided to try out this blog platform..

I am involved in web technology, architecture, web products, etc. and will publish stuff related to this type of technologies. There are quite a lot of hot things happening on the web these days (well it has ben like that for a looonnnng time) and there are always new trends and exciting stuff coming out. The thing is everybody gets excited when the "new stuff" arrive and publishes a lot of articles, invest plenty of energy. But it is only when the wave has passed that we can see the actual business and practical benefits for organisations. We have seen thius happening in "recent years" for C++, java, .net, soap/web services, etc. And now we have web 2.0 and it is not difficult to see the same pattern. There is a great value in web 2.0, but we still dont know exactly what will be the final outcome… But hey!, we love our toys and technology would be so boring without them ūüôā

So this blog is about deciphering the new technologies and trying to figure out what it means and where it can be used… Well that's only a try, isn't it?

As it will be a kind of brainstorm, I probably wont filter things too much. Sensitive souls should then wear protective filter glasses where needed.. ūüôā Shoutings and reactions whatever they are are welcome…