[thelist] Discussing XHTML and ROI with your "boss"

Judah McAuley judah at wiredotter.com
Thu Aug 15 23:27:01 CDT 2002


Tom Dell'Aringa wrote:
> Ok, thats great - I know all that (above). But in today's market, and
> for many businesses - having their web sites or applications
> available on Joe Technoweenies phone/PDA are so FAR down their list
> its near invisible.

I would certainly agree with that.  I've never coded a page to
specifically be looked at by a PDA.  Came close to getting a project
once, but the demand isn't there.  In the US at least.  But what if you
are creating a content base of several hundred pages.  And then your
product/service/whatever is picked up in Europe, which is way ahead of
the US in terms of mobile data services?  Sure, at this moment its not
even that important to probably provide the info to them over a PDA, but
it probably will be in the next year to two.  How much time is going to
be spent rewriting the code so that it can be pushed out correctly?  How
much time does it take to write XHTML compliant code right now so you
don't have to worry about it in the future?

> On the other hand, if you can tell me how I can take that XML and
> perform other business processes on it that will enable my business
> to do things I can't do now -- not THAT is something. Some of those
> things are going to be industry/instance specific, but I bet some
> things aren't..  those are the types of things I was hoping to flush
> out.
>
> For example: Maybe I can take a personnel page on an intranet and
> re-use the content on the public facing site. That might be one
> example.

How about this:  Using CSS to deliver differently formatted pages to IE
6 and NS 7?  Let's say your Intranet is standardized on IE 6 and you
want to do some fancy scroll-bar formatting and other snazzy IE-specific
formating.  But you also want to push out some of the data to an
extranet and not have to make it IE-only.  Now this, admittedly, is not
a feature of XHTML.  It's more of a general argument for the seperation
of content and presentation.  However, XSLT will give you even more
control and presentation options than CSS and XSLT needs more
well-formed data to work on.

>>Furthermore, use of current W3C standards ensures future
>>compatibility.
>
>
> I've read this a million times. Ensures future compatibility WITH
> WHAT?

User agents implementing current W3C specs.  I'm sure that most browsers
will always implement their own proprietary extensions.  The urge for
programmers to show off and put in something they (and their company)
think is "great" is too strong.  But every release of every browser I
can think of has one thing in common: stronger adherence to core W3C
standards than the previous version.  Browser extensions come and go
(think <blink>).  W3C recommendations, while not universal, have a
tendency to have a longer shelf-life across multiple browsers.

>>  Standardization is becoming more and more common amongst browser
>>agents.  The best way to future-proof your applications is to code
>>to
>>established standards.
>
>
> I'd argue the point. IE is still placing their proprietary code in
> thier browser, and they still hold the vast majority of the audience.
> Even their implementations of "standards" differ among the most
> modern browsers.
>
> And what are "established" standards anyway? Which set are you
> referring to? HTML4? XHTML1.0 or 1.1? Which DTD? Using tables or not?
>
> And, its difficult to make the case for "future proofing". Tell me
> how my application is going to break in say, 5 years. I don't think
> you can.

According to the lead headline on w3c.org, XHTML 1.0 Second Edition is
now a W3C recommendation.  Now, am I going to suddenly jump to it and
code everything that way?  No.  Its certainly a case-by-case
determination what to use.  But I think that the argument for using
XHTML is pretty strong and is pretty straight forward.

As to examples of how your app will break, say that you use a fixed
background image to provide an underlayed map using the <body> attribute
BGPROPERTIES=FIXED.  It worked in IE once upon a time.  But when that
map starts tiling its going to wreak havoc for your users.  Or lets say
that you use a <font color="White"> tag for warning text on a black
background and then support for the deprecated <font> tag goes away?

I bet that your app will break in the next few years due to using tables
for layout and font tags for presentation.  Those elements will continue
to change unpredicatbly and may go away entirely.  If you are not using
those elements for layout and presentation then you are close enough to
XHTML for this discussion to be moot.

>>I'd argue that future-proofed applications, platform independence,
>>and
>>the ability to multi-purpose content are all solid business cases.
>>And
>>all of those sort of arguments were included in links sent to you
>>in
>>previous threads.
>
>
> Isn't the WEB itself platform independence? It sure is, thats not an
> issue. Do you mean BROWSER independence? My site already works in
> modern browsers, (all) using HTML only. Why do I need to change?

Actually by platform I meant a wider view of user-agent.  IE on Windows
2000, IE on Win CE.  Mozilla on a device running GEOS. A combination of
user agent and computing platform.

And I'm not saying that you do need to change everything you've done.
I'm just saying that moving new development and redevelopment to XHTML
makes sense from a conservative point of view.  Minimal additional work,
maximal flexibility for future utility.

> Multi purposing content is a good idea, but we already do that
> because we pull much of our data from DBs.
>
> The arguments made in those threads are the same general things you
> are saying now, but nothing SPECIFIC. No real case data.

Arguments from logical business standpoints are always the best.  Case
data is specific to the case.  It never directly applies to another
case.  You are always left with extrapolation and induction.  It is best
to start from first principles, see whether the logic is applicable to
your situation, and see whether any outside experiences run counter to
your intuition/deduction.

>
> I'll respectfully disagree. I try to never treat people based on any
> stereotype. I certainly wouldn't want to be treated in such a way. If
> you walk into a situation with a preconceived notion, you've put
> YOURSELF at a disadvantage right away, when the person prooves you
> *wrong.*

I understand this point and it is well taken.  However, I don't believe
that the human mind works that way.  It would take far too long to walk
into every situation without a preconcieved notion and learn everything
you needed to know within the context of that situation.  That is where
past experience comes in.  And then we collectively share past
experience and it gets distilled into stereotypes.  They serve the very
useful purpose of giving us a base understanding to start our
explorations of a situation.  We should not use those stereotypes as an
excuse to not explore a situation, however.  I admit that relying on
stereotypes is a very bad idea, but I do believe that stereotypes are a
collectively distilled set of experiences that form the basis for some
usefull starting points in many situations.

> I've had numerous "bosses" in the same position for many companies,
> and NONE of them were the same.

You've worked for excellent companies then.  Glad to hear it.

> DON'T Mistake my "negativity" for me being against standards or
> XHTML. I am 100% FOR them. That's why I am in the position with
> MACCAWS that I am.

And don't mistake my exhortations in favor of XHTML and standards as an
indictment of those that don't code to standard.  I don't produce valid
XHTML for most of my projects for a variety of reasons.  I work on a
product that has IE-specific features for very good business reasons.  I
don't like it from an intellectual standpoint, but I do what I can to
accomplish a task until I can find a better way to do it.

> But I am challenging folks to come up with good, solid reasons, data,
> cases and paths to ROI on why they should be used. We are researching
> that now at MACCAWS.
>
> I know there are people on this list who have some of this in their
> heads (and some of it has come out). So lets not get all upset
> because somebody challenges you to come up with more detail, or
> challenges you to really explain and quantify something you believe
> in.

I think data is great.  I've got a degree in Math and Quantitative
Ecology.  I love models and statistics and all that.  I really think
that measuring the ROI of standards compliant coding is a great idea
(although a tough experiment to design).  But I don't think that its
necessary in order to say its a good idea.  Business wouldn't get done
if everything required statistically valid ROI models.  Its great when
they do exist but they still are only a guide.  They still won't tell
you if its right for your business.

I think that an explanation for why XHTML was put together in the first
place and why people are moving toward it out to be enough information
to decide if its right for your business.

> I'll give you a real world example: Lycos Europe has taken some of
> their work to XHTML/CSS. It doesn't quite validate all the way, but
> its great code, and the author has shared with us some valuable real
> world data on what it saved them, timewise, what the code did for
> them and so on.
>
> That's what I am looking for, that type of information, whether
> specific or not.

Since I can't give you data from my business (due to the fact we haven't
moved to XHTML yet) I'll pass along interesting results from google
searches:

IT Papers on XML
http://www.itpapers.com/cgi/SubcatIT.pl?scid=201

ROI on Mobile and Wireless Apps (repurposing content for mobile devices)
http://www.networkcomputing.com/1303/1303f13.html

I hope that you can find the ROI analysis that meets your needs.  If you
do, be sure to share it with us as I'm sure it will be appreciated.

Judah





More information about the thelist mailing list