Unlike W3C, some companies are pretty good at creating bubbles. The art is to draw a lot of attention to something that seems to be new and innovating but really is not! I haven't really figured out how to do this, otherwise I could have been marketing manager. But here are some ingredients: using curiosity of the public, using weblog communities to spread the word and promising lots of new cool features.
Two recent examples: "AJAX" and "RSS functionality in Longhorn".
AJAX technology has been available for years, but only recently got a lot of attention since Google shows off with cool features (auto-completion in web pages). AJAX won't be used much near Rotterdam because it shares its name with an evil soccer club. They would have made a better chance if they found an acronym for Feyenoord.
In the past week Microsoft has created a lot of hype around the new RSS capabilities of Internet Explorer 7. The IE team has renamed itself into the Browsing and RSS-team. Why? You know the little orange button in the right part of the Mozilla Firefox status bar? IE7 will have something similar. Only where Firefox supports more than one RSS feed for one web page, IE7 is limited to the first feed found on the page "because this is easier for users". They're focussing too much on the user not knowing the difference between RSS and Atom and they're forgetting some pages have multiple RSS feeds that differ in content and update frequency.
How do they manage to create hype around such things? They keep secrets, give away a few hints, announcing the date and time of the next announcement with more hints and still not giving away all details. In addition they're mixing up names. They know they shouldn't be too proud of IE7 because IE7 should have shipped at least one year ago. So they are talking about the "RSS capabilities in Longhorn". RSS capabilities in Longhorn?!? Haven't they learnt anything over the past years? For example you shouldn't mix functionality at operating system level too much with functionality at application level? If it's not a technical mistake, it could get them into new lawsuits, I think.
But never mind that, they're doing great creating a hype around RSS. I read somewhere that new versions of Media Player may be supporting podcasts in future. This could be a good thing for the client I'm working for. So let's see what happens.
Tags: Microsoft | AJAX | RSS | IE7 | Hype
Saturday, June 25, 2005
Tuesday, June 21, 2005
The problem with W3C standards
W3C standards suffer from the same problem as the proposal for the European constitution. In earlier posts I pointed out I'm in favor of the constitution, yet the French and the Dutch voted against it and there's little hope the constitution is going to make it. The problem summarizes to "Nobody reads the text".
Can we blame people for not reading the texts?
- Not really.
I can blame W3C for poor dissemination of their results though. W3C produces white papers that seem to be boring at first glance. At second glance, their introduction texts turn out to be interesting texts. But most of the time these white papers don't even get a first glance.
I say the W3C should work on their marketing skills. First of all, they should benefit from the current Weblog hype to spread their message and support the strategy they're setting out for standardizing the web. Secondly, I think many new standards are interesting enough to be reported in major news papers with a little background information and a summary of new developments.
Lacking an audience, let me ask myself a few critical questions:
Where did I get the idea nobody is reading the W3C standards?
Open 5 or 10 websites and view their HTML source. Many of them are full of nested tables, font tags, b- and i-tags. Few of them adhere to standards or even contain remote clues that someone is trying to follow a standard. Ask an average web developer about the difference between XHTML Strict and XHTML Transitional. There's a good chance he'll tell you that XHTML Strict is meant for nerds and it's practically impossible to adhere to this standard. XHTML Transitional is more reasonable and should be used for designing a web page. If you ask him what "transition" the word transitional refers to, you probably won't get an answer.
The answer is really easy though, if you're familiar with the introduction texts of the W3C white papers. The transition is about moving away from mixing document structure and document presentation in (X)HTML. And separating presentation to CSS files. Reading through weblogs I noticed some web designers think that this transition is about "replacing all tables with divs". This is wrong on so may levels I should spend a separate post explaining it.
I work on a content management system with a large number of editors and journalists. Should we require them to read through W3C standards?
The latest developments on (X)HTML are meant to make it easier. The it's-too-hard-assumption is a poor excuse not to adhere to standards. If the basic page setup is right and the tools provided by the CMS make it easy for the content editor to produce valid XHTML Strict without worrying about CSS, there should be no problem. If anyone can point out such tools, please let me know!
Web developers are not the real issue, the problem is with IE forcing web developers not to use standards.
At least Microsoft did read the text and chose not to adhere to the standards. Their excuse is backward compatibility. Microsoft is responding to popular demand. As long as the majority of web developers is not demanding standards compliance, Microsoft is not going to offer any. I'm worried about the implementation of upcoming standards - XHTML 2 and all related modules like XForms and XML Events. But it's too easy to point at Microsoft. Not long ago, in the FireFox community some were arguing against implementation of XForms. Because of the difference in goals and stakeholders, they're working on it now. But the fact that both browser manufacturers are/were reluctant to start with their implementation tells me more about the poor job W3C is doing conveying their ideas than about Microsoft - a company we know for quite a few years now.
Aren't you forgetting to mention something?
Thanks for reminding me! Another thing that isn't helping the adoption of new standards is the lack of cool new features. While I (being a software developer) am convinced of the advantages of an improved XHTML structure, to the large public there's no added value in any of this. They're playing around with the latest hypes like AJAX and new Flash versions. I think both of them are overrated, abused for the wrong purposes and poorly understood by their user community, but that's not going to stop them.
How do you convey to the large public that modularization of XHTML will increase the options for adding in new features in future without needing to replace your complete browser suite?
With a little luck, time will heal the wounds. XHTML standards are meant to last over time and it's likely we're still using them in 10 years. For now I'm a little bit sceptical. We'll find out...
Tags: W3C | standards | XHTML | CSS
Can we blame people for not reading the texts?
- Not really.
I can blame W3C for poor dissemination of their results though. W3C produces white papers that seem to be boring at first glance. At second glance, their introduction texts turn out to be interesting texts. But most of the time these white papers don't even get a first glance.
I say the W3C should work on their marketing skills. First of all, they should benefit from the current Weblog hype to spread their message and support the strategy they're setting out for standardizing the web. Secondly, I think many new standards are interesting enough to be reported in major news papers with a little background information and a summary of new developments.
Lacking an audience, let me ask myself a few critical questions:
Where did I get the idea nobody is reading the W3C standards?
Open 5 or 10 websites and view their HTML source. Many of them are full of nested tables, font tags, b- and i-tags. Few of them adhere to standards or even contain remote clues that someone is trying to follow a standard. Ask an average web developer about the difference between XHTML Strict and XHTML Transitional. There's a good chance he'll tell you that XHTML Strict is meant for nerds and it's practically impossible to adhere to this standard. XHTML Transitional is more reasonable and should be used for designing a web page. If you ask him what "transition" the word transitional refers to, you probably won't get an answer.
The answer is really easy though, if you're familiar with the introduction texts of the W3C white papers. The transition is about moving away from mixing document structure and document presentation in (X)HTML. And separating presentation to CSS files. Reading through weblogs I noticed some web designers think that this transition is about "replacing all tables with divs". This is wrong on so may levels I should spend a separate post explaining it.
I work on a content management system with a large number of editors and journalists. Should we require them to read through W3C standards?
The latest developments on (X)HTML are meant to make it easier. The it's-too-hard-assumption is a poor excuse not to adhere to standards. If the basic page setup is right and the tools provided by the CMS make it easy for the content editor to produce valid XHTML Strict without worrying about CSS, there should be no problem. If anyone can point out such tools, please let me know!
Web developers are not the real issue, the problem is with IE forcing web developers not to use standards.
At least Microsoft did read the text and chose not to adhere to the standards. Their excuse is backward compatibility. Microsoft is responding to popular demand. As long as the majority of web developers is not demanding standards compliance, Microsoft is not going to offer any. I'm worried about the implementation of upcoming standards - XHTML 2 and all related modules like XForms and XML Events. But it's too easy to point at Microsoft. Not long ago, in the FireFox community some were arguing against implementation of XForms. Because of the difference in goals and stakeholders, they're working on it now. But the fact that both browser manufacturers are/were reluctant to start with their implementation tells me more about the poor job W3C is doing conveying their ideas than about Microsoft - a company we know for quite a few years now.
Aren't you forgetting to mention something?
Thanks for reminding me! Another thing that isn't helping the adoption of new standards is the lack of cool new features. While I (being a software developer) am convinced of the advantages of an improved XHTML structure, to the large public there's no added value in any of this. They're playing around with the latest hypes like AJAX and new Flash versions. I think both of them are overrated, abused for the wrong purposes and poorly understood by their user community, but that's not going to stop them.
How do you convey to the large public that modularization of XHTML will increase the options for adding in new features in future without needing to replace your complete browser suite?
With a little luck, time will heal the wounds. XHTML standards are meant to last over time and it's likely we're still using them in 10 years. For now I'm a little bit sceptical. We'll find out...
Tags: W3C | standards | XHTML | CSS
Saturday, June 04, 2005
InfoPath: OPML editor / RSS reader
In addition to my somewhat premature posts about XForms, I think it would be good to discuss a more mature product that has been there for some time now and is related to XForms in many ways but also has fundamental differences. InfoPath is an Office product for editing XML documents using typical Office interface elements. To explore its capabilities, I'm building a form for editing OPML files and viewing the referenced RSS feeds. The end result is alpha quality, not suitable for every day use, but a nice example of the current status of InfoPath.
Introduction
As a software developer, I'm interested in InfoPath as a development tool, helping me create advanced forms interfaces in little time. However, InfoPath is not the latest Visual Studio component. It is part of Microsoft Office, so it should be easy enough for an experienced Office Manager to create fully functional forms using InfoPath.
XML was intended to be easy to read by humans. XSLT was intended to be easy enough to be used by others than software developers. As I see it, XML and XSLT are mainly the territory of software developers and more experienced web designers. Many XML concepts like wellformedness, validity, namespaces and XML schema's are too comprehensive to be grasped without a background and experience in informatics.
InfoPath took the challenge of making XML files accessible to the large public in a user friendly way. In most cases user-friendlyness goes at the cost of developer capabilities. In the rest of this post I'd like to explore both the user-friendlyness and the developer capabilities.
An OPML editor in less than 5 minutes
If you have used InfoPath before, you might be able to do this in 10 seconds I think. This is also the quickest way to convince someone who hasn't seen InfoPath before of its power. Take the following steps (my apologies for bad naming, I use the Dutch version of InfoPath, so I cannot provide the correct steps here):
Finding the limitations
The quickest way to find the limitations of a software product is to use it for something it was not intended for. Without going overboard, I think I'm being reasonable if I want to be able to make a nice looking view for my OPML editor that also dynamically shows the most recent content of the RSS feeds it's refering to. I'm sure someone with inside knowledge of InfoPath could do better than I did. I'm also sure that I could have done better if I took a full week to develop this. But as a lazy person, it's much more interesting what could be done with little effort and in a few hours. Being lazy, I got to a point where I wanted to switch to server side programming to solve issues because this would be easier. This was my clue to stop trying and write this post. This is what I did:
I created a second view for the InfoPath document, so I have one "OPML editing mode" and one "OPML/RSS viewing mode". In the editing mode I tweaked some form options to prevent loads of empty lines appearing when I added new OPML elements. I made some decorative adjustments and a "Switch View" button. I'm quite pleased with this simple and straightforward editing mode. If I ever need an XML editor and I don't have time, this will be my first choice.
RSS viewing is a different story though. Again, I may very well be wrong about this, but this is what I found in a few hours with little effort. In InfoPath I can define secondary data sources. There is a single instance for each data source. The options to load more than one RSS view at the same time are limited. I can attach data elements to a secondary data source. So viewing the RSS feed basically is very easy.
This is where it went wrong: InfoPath expects data sources to follow the same XML schema and producing predictable content structures. XML feeds referenced by OPML files may be very different from each other. Some RSS feeds are simple and straightforward; others are mixed with RDF structures. These cannot be read from one secondary data source. In addition, many XML feeds are not RSS feeds but Atom feeds. Somehow my InfoPath crashed when I tried to load an Atom feed. Also many RSS feeds (those from MSN Spaces for example) contain HTML markup. This messes up the text in InfoPath.
Some preprocessing using XSLT would help a lot here. The secondary data source can only be assigned using a FileURL attribute, not by directly providing a reference to a DOM source which could be the outcome of an XSLT translation. This was the point where I was considering programming server side code. This would work well to get the application up and running, but it would not be an honest review of InfoPath anymore.
Links:
A few more words
In the example above I used JavaScript code to implement actions for the buttons in the form. Microsoft provides an InfoPath SDK for developers. With this SDK you can write action handlers in managed C# code and be able to use the full capabilities of the .Net platform. This increases the capabilities of InfoPath tremendously.
I have played with the SDK and I liked it. But something I was missing - again, this might be my mistake - is the ability to use InfoPath as an embedable component in my .Net applications the same way I can embed Internet Explorer in my own windows. If I were able to do this, I could develop very powerful and good looking business applications. Maybe I should write a letter to Microsoft. The getting-hardcore-Java-developers-to-switch-to-dotNet-team might be interested in my case...
In the developers vs. experienced users and Visual Studio vs. MS Office design choice, I think InfoPath is comparable to MS Access. You require some background knowledge to use it, but with proper training, you don't need to be a computer expert to get results. Access is a nice application to do complicated things very quickly. For professional use, its capabilities are limited. InfoPath fits in the exact same category. In this category, Access only recently got competition by the Open Office product Base. For InfoPath this might take a while. If you're interested, go play with InfoPath.
If you manage to do better than I did - with not too much effort - please let me know!
Introduction
As a software developer, I'm interested in InfoPath as a development tool, helping me create advanced forms interfaces in little time. However, InfoPath is not the latest Visual Studio component. It is part of Microsoft Office, so it should be easy enough for an experienced Office Manager to create fully functional forms using InfoPath.
XML was intended to be easy to read by humans. XSLT was intended to be easy enough to be used by others than software developers. As I see it, XML and XSLT are mainly the territory of software developers and more experienced web designers. Many XML concepts like wellformedness, validity, namespaces and XML schema's are too comprehensive to be grasped without a background and experience in informatics.
InfoPath took the challenge of making XML files accessible to the large public in a user friendly way. In most cases user-friendlyness goes at the cost of developer capabilities. In the rest of this post I'd like to explore both the user-friendlyness and the developer capabilities.
An OPML editor in less than 5 minutes
If you have used InfoPath before, you might be able to do this in 10 seconds I think. This is also the quickest way to convince someone who hasn't seen InfoPath before of its power. Take the following steps (my apologies for bad naming, I use the Dutch version of InfoPath, so I cannot provide the correct steps here):
- Save an OPML document to My Documents - make sure it has nested outline elements, like mine.
- Open InfoPath and create a new document based on an XML file and select the OPML file
- From the Data View, drag an "outline" element to the form.
- Done!
Finding the limitations
The quickest way to find the limitations of a software product is to use it for something it was not intended for. Without going overboard, I think I'm being reasonable if I want to be able to make a nice looking view for my OPML editor that also dynamically shows the most recent content of the RSS feeds it's refering to. I'm sure someone with inside knowledge of InfoPath could do better than I did. I'm also sure that I could have done better if I took a full week to develop this. But as a lazy person, it's much more interesting what could be done with little effort and in a few hours. Being lazy, I got to a point where I wanted to switch to server side programming to solve issues because this would be easier. This was my clue to stop trying and write this post. This is what I did:
I created a second view for the InfoPath document, so I have one "OPML editing mode" and one "OPML/RSS viewing mode". In the editing mode I tweaked some form options to prevent loads of empty lines appearing when I added new OPML elements. I made some decorative adjustments and a "Switch View" button. I'm quite pleased with this simple and straightforward editing mode. If I ever need an XML editor and I don't have time, this will be my first choice.
RSS viewing is a different story though. Again, I may very well be wrong about this, but this is what I found in a few hours with little effort. In InfoPath I can define secondary data sources. There is a single instance for each data source. The options to load more than one RSS view at the same time are limited. I can attach data elements to a secondary data source. So viewing the RSS feed basically is very easy.
This is where it went wrong: InfoPath expects data sources to follow the same XML schema and producing predictable content structures. XML feeds referenced by OPML files may be very different from each other. Some RSS feeds are simple and straightforward; others are mixed with RDF structures. These cannot be read from one secondary data source. In addition, many XML feeds are not RSS feeds but Atom feeds. Somehow my InfoPath crashed when I tried to load an Atom feed. Also many RSS feeds (those from MSN Spaces for example) contain HTML markup. This messes up the text in InfoPath.
Some preprocessing using XSLT would help a lot here. The secondary data source can only be assigned using a FileURL attribute, not by directly providing a reference to a DOM source which could be the outcome of an XSLT translation. This was the point where I was considering programming server side code. This would work well to get the application up and running, but it would not be an honest review of InfoPath anymore.
Links:
- Screen shot 1: view OPML/RSS
- Screen shot 2: edit OPML
- The InfoPath document (use "File->Merge with XML" to load OPML data)
A few more words
In the example above I used JavaScript code to implement actions for the buttons in the form. Microsoft provides an InfoPath SDK for developers. With this SDK you can write action handlers in managed C# code and be able to use the full capabilities of the .Net platform. This increases the capabilities of InfoPath tremendously.
I have played with the SDK and I liked it. But something I was missing - again, this might be my mistake - is the ability to use InfoPath as an embedable component in my .Net applications the same way I can embed Internet Explorer in my own windows. If I were able to do this, I could develop very powerful and good looking business applications. Maybe I should write a letter to Microsoft. The getting-hardcore-Java-developers-to-switch-to-dotNet-team might be interested in my case...
In the developers vs. experienced users and Visual Studio vs. MS Office design choice, I think InfoPath is comparable to MS Access. You require some background knowledge to use it, but with proper training, you don't need to be a computer expert to get results. Access is a nice application to do complicated things very quickly. For professional use, its capabilities are limited. InfoPath fits in the exact same category. In this category, Access only recently got competition by the Open Office product Base. For InfoPath this might take a while. If you're interested, go play with InfoPath.
If you manage to do better than I did - with not too much effort - please let me know!
Subscribe to:
Posts (Atom)