Talking to several partners and architects in other companies, there seems to be a general move from page-based sites to frameworks with modules that can either be under your own control, added by users or provided by third party companies. This is an interesting concept for much more personalized web experiences but it also poses quite a technical challenge for web developers.
The job of a web developer (or front end engineer or interaction architect or web designer or [insert your job title of choice here]) is in a constant state of flux. Best practices that were the cats pajamas in the end 90ies are terrible solutions now and solutions that sounded like science fiction then are feasible now.
Browsers are getting better
The environment our code is executed in is still largely unknown but at least the software that renders what we develop becomes more and more sophisticated and reliable. Whilst we can thank the browser vendors to open up more and more to our needs (with IE8 now rendering by default with the new engine as per the latest news cheers!) we have a different challenge ahead of us, which is once again a change in the market and usage needs of web surfers.
Challenges of the past
This is nothing new - after all we faced it before:
- In the beginning browsers and slow connections were our main boundaries. Making sites work and pretty was the main issue in an environment of flaky browsers and low-spec machines.
- In the late 90s and the start of the millennium we needed to explain to clients that WYSIWYG editors are a quick solution but do not result in maintainable and universally working web sites. We did this battling the PR of the companies building software that promised to make our jobs redundant.
- After that it was the CMS vendors satisfying the need of a market to constantly change content without touching the markup. The solution? Just use a (can you guess it?) rich text WYSIWYG editor and templates to build your sites.
None of this was really scary to a clever developer as most likely you already used a sort of templating engine or IDE to create static pages for you. The challenge to move from static pages to writing templates for CMS wasnt that hard then.
A change in perception of web site rendering needs
The main challenge was and is that clients need to grasp that the benefits of templating also come with a few drawbacks. These are first of all that you cant design every page differently and you dont know how much or what text will be used in the final page. If your CMS has hundreds of templates it becomes as hard to maintain as static pages and you wasted a lot of time and money.
To me, acknowledging these drawbacks is great step in becoming more mature developers and content producers: we embrace change as a given rather than just trying to prevent things from breaking. My classic way of doing that was battling the This link is three words, so we dont need more space statement by showing the German or Finnish translation for these three words, subsequently breaking the layout.
There is a new challenge on the horizon that will become more and more important over the next years. Ive talked to several companies and we all seem to go the same way on that. Heres what web developers have to face now:
The web of data and modules is coming be prepared!
All the companies I talked to are moving away from a page-based concept of web publishing to one that is a canvas with independent modules. These modules could be of your own making actually most enterprise level CMS work that way already - but will subsequently also mean third party modules and modules the site user can choose to add, remove and customize.
This is a wonderful concept as it allows us to work a lot faster, more user-focused (by offering content that is related to interests and profile) and allows for parallel development of different modules. The problem however is that the current technologies we render content in browsers with are not catered for that.
The main challenges are the following:
- styling and UI consistency
Styling and UI consistency is a real issue as the technology for styling documents in user agents CSS is by definition not catered for independent modules. The main power of CSS is the cascade you define a setting once and let the browser apply it to every element that matches a selector. This allows you to create wonderfully small CSS files that are easy to maintain as you can change all the look and feel by changing a few selectors. If your CSS solutions have IDs and classes on every HTML element then you havent played the technology to its strengths.
If the modules were talking about are built to blend into a consistent look and feel and just need some colour changes or other minor display changes then this is not really a problem. However, if you are afraid that CSS settings inherited from the page CSS and parent elements will render your module unusable you are in trouble.
The missing HTML element
HTML has no <reset> element that would allow you to override the cascade. For now, the consensus for a lot of companies seems to be to use <iframe> when they need to have a fixed look and feel that is not allowed to inherit from the main document.
This, and other hacks like inline styles or artificially enhanced specificity with several IDs and classes doesnt seem right and results in massive CSS files that slow down the overall page.
The use of iframes hinders the performance of the page as each needs to be loaded separately. In a perfect environment, youd want the document to render in one go with as few HTTP requests as possible.
On the security front, iframes are actually a nice-to-have as theyll sandbox the (possibly third party) scripts in the different modules. From an overall application perspective, this is a hindrance though as youd want to communicate between modules without having to resort to a server-side component.
In any case, there are a lot of new challenges for us to face in the nearer future and I for one think it is a great chance to marry the knowledge of UI-focused web developers with backend engineers to build a new way of defining web applications.
- Event driven application design
- The YUI Module pattern
Were going to watch this challenge closely and are happy to hear your thoughts and solutions.