10 January 2005

XML Development cycle: What are the prospects for integrated, streamlined user-end tools?

Summary

Single-standalone tools like spell checkers are a nifty concept and can be applied to XML-related products: One stop, integrated, and translate XML-garbage into something that is edible.

Like an auto-correct option the above is integrated, streamlined, one-click, seamless, and transparent to the end-user; and can also be turned off or on depending on end-user requirements.

End users, when given messages, want simple tools to prompt the user:

  • What the situation is
  • Why they are getting the message
  • What is going on
  • Where to go, what to look at
  • What their options are
  • What the result will be if they choose a provided option
  • How to solve the problem
  • What the limitations are with the existing tool or product
  • What other alternatives may provide superior results
  • How to accomplish their desired task-objective
  • Ultimately, what needs to be done to ensure their content arrives at the reader’s eyeballs.

    Word processing tools

    Ever noticed how neat spell check and grammar checkers are? They show you what’s wrong; give you options; highlight the information; direct you to something that is a solution; and the end-user gets to decide what to do.

    Pretty nice how a single tool will solve problems. And it’s all self-contained. The end-user doesn’t have to go read a bunch of specs and documentation on “how to do it.” The instructions are all there.

    If there’s an error or problem, the issue gets highlighted. If there’s something that might not be “what is expected” there’s a flag with options.

    Click on the “highlighted-error”, options show up, and the end-user gets the solution: right information, corrected error, a discussion on the nature of the problem with options, and then the options on the right to ignore, change, or add “how the user did it” to the local-database. Kind of like a local Wiki: Local comments. Tailored to the local-user.

    In the end, the end-user gets to decide “what to do with this feedback.” Pretty nifty.

    Desired Development Standards

    There should be a single-step whereby end-users get the four types of information:

  • Show the error;
  • Refer to the appropriate information to explain the nature of the error;
  • Offer choices
  • Solve the problem

    Spell checkers and grammar checkers offer all four steps in one tool, and it is integrated into the overall software package.

    The features: It is self-contained, all inclusive, and moves the end-user from the state of confusion-problem to a solution. It is streamlined, it works, and it integrated

    Remember, it’s not the job of the end-user to have to put all the pieces together and figure out “what an error message means” or “how to fix the problem.” Rather, options should be presented, and the end-user wants to simply know what needs to be done to fix the problem, then solve the problem, and then move on to the next thing.

    Issue

    The idea of “all in one problem solving” that Microsoft and other companies that develop word processing software seems to be concept that is lost on XML developers.

    What I wanted to talk about were some recurring trends I’ve noticed in the XML development efforts. The above scenario with spell- and grammar-checker should be construed as the model or template for a development effort and error reporting.

    Specifics

    Let’s consider three examples of blog-XML interface issues that show the contrast between what the public is given. Remember, the goal is to illustrate how the desired development standard contrasts with what end-users are getting.

    Validation errors Validators need to show what’s wrong by line; and what the end-user needs to do to fix the problem.

    The good validators are already integrated into the software, whether it be an aggregator [at the tail-end of the XML pipeline] or the blog [the point of origin]. Ideally, the validators will take any XML feed, regardless the “errors,” and work with it. Or provide an explanation of "this will not be a problem with X-burner or Y-aggregator, so don't worry." Even if there is a small percentage of errors, the good validates will strip out the problem, and display “what works.”

    Let’s consider the 2RSS conversion tool. The nice thing about it is that it takes the Atom feed and converts it to something that “those who only choose to work with RSS” can work with.

    Also, some aggregators like RSS Owl will actually take a feed, and let the end-reader look at it.

    The point being is that a good validator is one that will do the same thing as a grammar checker: It takes the information, identifies the problem, offers choices, allows the user to select something, and the end-result is: The end-user can use what they have and be on their way.

    No need for explanations. No need to ask questions. No confusion about which line to go to. No requirement for there to be external support.

    The good validator is integrated. It stands alone. And it takes the garbage or “whatever it gets” and lets the end-user convert it into something that is readable. At best, this is all transparent like Feedburner and MyYahoo which, together, can take an “invalid Atom feed” and still inject it into the aggregator.

    Let’s consider an example where the above standard could make a difference

    Right now, if you’re using some word processors, you’ll notice that there are nifty tools to translate the font into something that is readable. Specifically, if you have Chinese font but your browser is not correctly configured, you’ll get this strange box. You can’t read it, but its still valid information.

    The trick is to ensure there is some auto-mated tool that will translate this “box-information” into something that is “real information” that is useful.

    One problem I’ve see is when copying information from Microsoft Word and posting it into blogger: The quotations end up getting messed up.

    Sure, there’s a solution to this. It’s called “get out the specs” and “find the conversion” and “fix the problem.”

    Hello?!?! Who has time for that? The “nifty solution” [applying the above development standard] is for the system to “automatically detect the box” [because it is not readable, although it is information], and do what happens with a spell checker:

    - Highlight the problem, error
    - Recognize there is a red-highlighted error
    - Discuss in the software package-tool the nature of the error
    - Offer some alternatives
    - Give the end-user the chance to change the box into something that is readable
    - Then resolve the matter so that the quotes are correctly displayed; so the quotes are correctly aligned; and the HTML-link is properly coded so that the end-reader can read the link.

    See how that is? All integrated. Convert the “bad box” into “useful information”. Recognize that there are errors. And give the end-user a clean, quick, and efficient method to highlight and correct the code so that it is useful.

    Not that tough is it? I don’t think so.

    Let’s look at a sample where the above standard doesn’t get applied

    Let’s contrast the above “developer standard” with the lovely error codes that some developers like to leave in their final product.

    At worst the developer will leave an error message, provide no link, and the end-user is forced to dig through specs. On top of that, the end-user gets no specific information or guidance; and the end-user gets inconsistent information on what the nature of the problem is.

    PubSub

    Let’s look at the http-error related codes with PubSub and compare then with the above development standards.

    Again, the goal of the tool is to solve problems. When there is an error message, the good tools will acknowledge the glitch, and offer solutions so the end-user can be “on their way.”

    Not PubSub. Take a look at the rank listings. Go down the list of 100. Notice anything unusual?

    Do you see there are several “http” options? Isn’t that lovely. PubSub is reporting as a “popular link” the code “http”. Keep that in mind.

    Also, when you put in an http-prefix before the code into a PubSub subscription search string, you get an error message.

    Some might suggest “this isn’t a problem” or “there is no bug.” Great. Then why the “red error message”? No answer on that one.

    Also, we get a lovely explanation as to “why this isn’t really a problem”. Oh really? Then why is your PubSub tool issuing a-red-highlighted message saying there is a problem with including the http prefix in the search string? Of course, we get a lovely response later after waiting, but nothing like a spell checker that has a real-time response of the nature of the error; links to the information that might provide assistance; and a method of resolving the issue without outside support or explanation.

    See how easy that is? Not that tough.

    What’s puzzling about this simple “developer standard” is that one would think that a concept like Microsoft’s Grammar- and Spell-checker would be universal standards. One that all developers aspire to.

    Yet, time and time again the end-user is given products that don’t do this. Why is that? We have yet to have a satisfactory answer why developers that used to work at Microsoft and are somewhat familiar with word processing software, somehow think that the XML-related products that they develop are somehow immune to these development standards.

    Surely, there were lessons learned from the focus groups and beta-test feedback at Microsoft that provided direct user-feedback on the benefits of this “all in one tool” for spell/grammar checking.

    One would think that a development effort that had personnel that were once assigned to Microsoft might be able to take the “desirable features” from various non-XML products and incorporate those lessons into the XML-products that they are creating for end-users.

    Not these guys. Somehow the XML-development teams have taken it upon themselves to throw everything out the window. The lessons learned from spell checkers: Ignored. The idea of an integrated product that solves problems: Ignored.

    In fact, if one were to raise the issue, at best the former Microsoft developers are likely to start to scream, rant, and blame those who provided the feedback.

    We often hear things like: ”Hay, I’m doing this for free.” Or “This is my hobby” or “Look at all that I’ve done, how dare you.”

    OK. Maybe we, as end-users, shouldn’t wonder why certain developers that used to work at Microsoft have such a hard time creating products that solve problems in a streamlined and integrated manner.

    The problem isn’t that the end-user has a problem. The problem is: Despite the lessons learned from previous efforts, XML-developers seem to think that everything that might be related to users suddenly doesn’t apply; and the end-user, if they dare comment, are to be treated as if the end-user is a problem.

    Congratulations, developers! All that “corporate knowledge” that you might have taken from Microsoft, you’ve thrown out the window. All that goodwill and experience that you might have gleaned from your technical interchange meetings [TIMs] and discussions with program managers, you want the end-user to believe “isn’t relevant.”

    Actually, the real problem, in my opinion, is that you’re not relevant. You’ve had how many decades of cumulative knowledge and lessons learned from prior developers, but you get new standards like XML and you want to rewrite the rules.

    OK. Great. Rewrite your specs. Make more complaints about “why you do not like XML” or “why you hate Atom.” I really don’t care.

    What I do care about is when you make products that don’t work, are not self-contained, and provide no internal support…and then you as developers go out of your way to throw the problem back on the public/end-user as if “the public isn’t being grateful.”

    WTF?!? All those high cost pre-beta testing that Microsoft did and then incorporated into their end-products – why aren’t these lessons learned being incorporated? Why are you re-inventing the wheel?

    “Oh, XML is easy.” No, it’s really irrelevant to whether it is “easy or not.” The issue is: Can you as a developer take the “body of knowledge” that your prior Computer Science- and Developers- create and build upon, can you use it to create credible tools that solve problems.

    Yet, at this juncture, it seems quite apparent that the developers in re XML have shifted back to the pre-Fortran Days of, “if the customer doesn’t tell us specifically what they want, we’ll give them crap.”

    You know what you can do with your XML-development projects that meet that “non-standard”? You can shove them up your ass.

    It’s absurd for the world in the year 2005 to believe that the cumulative knowledge from IBM in the 1940s and the Dayton Cash register Company like NEC…that all those lessons learned are to be thrown out the window.

    That’s a lot of time and money that you’re ignoring. And the fact that you’re making products that don’t meet those standards doesn’t give you a “lovely green light” or a “lovely sticker” to make the public think that you’re innovative.

    There’s one word for you: Arrogant.

    Take a look at the publicly traded companies on the NASDAQ or NYSE that relate to information technology. Take a look at the number of board of directors. Consider the total number of cumulative man-hours that go into ensuring the audit statements; corporate governance standards; and ISO-XXXX standards are incorporated into your performance plans and product development milestones.

    A lot of people. A lot of time. A lot of manhours. And a lot of Money. It’s called investing today, to reap benefits tomorrow.

    The reason those standards exist is so that a company, like yours, can incorporate lessons learned, and build something that builds off what has worked, and create new things.

    The reason your General Counsels will say, “I’ll get back to you,” is that they’re going to take some time to go look something up. They’re looking at treatises and caselaw. They’re considering the journals.

    This is why attorneys command high fees. They have not only a clearly-connected brain-stem, but they actually use the cumulative lessons learned as promulgated in the statutes, legislative history, and other documents in order to arrive at a reasoned legal opinion.

    For those of you who are lost: The concept is “Take the cumulative lessons learned and apply them to your product, don’t throw them out the window.”

    Got it?

    PubSub>

    Let’s now turn to the, IN MY OPINION, cess pool called PubSub.

    Let’s do a new search. First, go to the search routine and type in your full favorite search string for any website and include the http:// prefix in the code.

    Just do it.

    See the message?

    OK. Now, pretend you are in fourth grade. Pretend your parents are at work. Pretend you have a deadline called, “My homework is due tomorrow and, because I’m in fourth grade I’ve waited until the last day to do this project.”

    What do you do?

    If you live in Bob Wyman’s world, you as a fourth grader are expected to put up with:

  • No explanation of what that red-text means
  • No link to explain what to do
  • No discussion of how to fix the problem or adjust the code

    Rather, the end-user doesn’t get the courtesy of a spell- or grammar-check type function with:

  • A simple explanation of the error
  • A clear link to valid information telling the end-user what to do
  • A simple step of “what to do” to adjust the code or input

    Let’s not even talk about “actually having a search routine that could handle the http:// code at the beginning.”

    No. All we get form Wyman is a non-sense explanation of “I’m surprised….” Huh? I don’t see that in the Microsoft grammar and spell checker functions.

    Got a grammar or spelling error in a word processing, and if Bob Wyman were running things, we could very well have the tool come back with, “I’m surprised….”

    Completely unacceptable Bob. Congratulations! All the cumulative corporate knowledge thrown out the window. Blame the user.

    NOT IMPRSSED.

    Developers like to make tools that the developers like. When the end-user asks a question, the developer gives a nice lecture about “what the end-user is supposed to do.”

    Brilliant. Looks like we have a problem here:

    A. Developer makes a product that is not self-contained
    B. Developer fails to include links to explain what to do when there are errors
    C. The user gets an earful because the developer hasn’t thought through the real goal of the tool: It’s not to showcase the developer’s skills, but to solve a problem.

    Going forward

    Developers that create single-platform tools like world processing with spell and grammar checkers have the concept down. They know that the end-user doesn’t want to walk around with a specs manual on the codes to look things up. Those “developer expectations of end-users” supposedly went out the window when we got into the non-dot-commands and mouse-options with windows.

    So XML developers, here’s the clue. The world hasn’t changed. History is relevant.

    The “uncomfortable environment of Microsoft that some may have had a hard time adjusting too” could very well be the needed discipline to ensure lessons from the past and other software development efforts actually get applied to new efforts with new specifications and standards.

    If you want to give a nice lecture to the end-user about “what they don’t understand,” you’re clearly missing the chance to provide a tool that solves the problem.

    Your job as a developer, to justify continued public confidence in your skill, or justify continued program manager faith in your development skills is for you to apply your lessons-learned from your previous efforts [however much you hated the discipline] and apply those lessons to new products.

    It is not your job to blame or lecture the end-user. It is your job to solve problems, to provide an integrated tool, and to save time.

    Integrated. Streamlined. Simple. Relevant information. And something that actually converts your garbage-errors into something that solves the end-users problem.

    If you’ve got a problem “applying the lessons learned” or “not wanting to create products that are as simple as grammar and spell checkers, fine: Continue to make excuses; continue to ignore the feedback; and please continue the lectures on “why the end-user has a problem.”

    Meanwhile, lonely you, will get passed over by the rest of humanity on this planet. 6.2 Billion people. Every one of them has access to this information. And every one of them has the ability to sit down and read the history of Computer Science; and all of them can easily take the lessons learned from IBM, NEC, and Microsoft and apply those lessons to new products.

    Which is it going to be? Frankly, I really don’t care. Go ahead. Please lecture more. Please, when you get feedback on your error messages, please continue your excuses; please provide no links to the information; and please include your “solution” in obscure blogs that nobody can find.

    I hope you don’t provide the solution in an integrated package. I hope you continue to spend time reading blogs from “stupid end-users” [your attitude] so that you can continue to focus on symptoms, not solutions.

    The problem is your failure to apply the lessons learned and create software and solutions for end-users that build upon reasonable public standards. In your universe, I hope you continue to jump at every opportunity for a new product, all the while passing up the opportunity to simply listen, and apply the cumulative knowledge, and discern the real problem:

  • You are failing to see the real problem
  • You are not taking the time to look at the larger issue
  • You are providing excuses, not solutions
  • You are ignoring the cumulative lessons learned
  • You are telling the people who, ultimately pay the bill, that you expect them to put up with your crap and all the while command higher fees.

    Those days are numbered. Let all the corporate boards know: How developers who are good will solve things: They will do what is in a simple spell- and grammar-checker:

  • One-stop
  • Self-contained
  • Integrated
  • Streamlined
  • Provide options
  • Solve the problem
  • Correct the error
  • User-support
  • Visible
  • Clear
  • Simple
  • Relevant,
  • Useful
  • Timely

    The people that meet this standard work at Microsoft. They make great products. And if you have a problem with that, then you do it better.

    I have seen otherwise in the XML community.

    You can do better.

    Requirements

    For those of you who missed it, this is what I expect:

    Blogger-Microsoft Interface

    A method for end-users to quickly discern “what is the nature of the mysterious box”. End-users need to know in a pop-up box or error-discussion box [like you get with a spell checker]:

  • What is this box
  • What are my options to fix it in blogger
  • What settings can I change in my browser, blogger, word-processing software to make this go away
  • What do I do to convert this box into something that my end-reader can understand

    Validators

  • A remark on the error
  • A by-line highlight of the error
  • What I as an end-user can do to fix it
  • A discussion on whether the “problem” can be corrected by Feedburner
  • A discussion of whether the “invalid feed problem” really matters relative to an aggregator like MyYahoo that can “work with the feed”

    XML Search tools

  • A stand-alone support system
  • No requirement for explanations
  • Discuss the error
  • Point to relevant information that explains the issue
  • Explain why the problem “isn’t a problem”; and at the same time explain why the “non problem” continues to provide search results on the “top list” that include this code
  • Identify in the box the steps the end-user must take to solve the problem
  • Acknowledge the limitations of the tool
  • Discuss “what will not be able to be found or searched for” by making that suggested adjustment
  • Discuss the impact on the number of searches; how the target search will get adjusted, how long the end-user might have to wait; other alternatives the end-user might want to take in the meantime
  • Discuss alternatives to solve the end-users search objectives: Are there other tools; what gaps are there in your system; how might an alternate tool provide the intended search?

    Some might suggest that the above “really doesn’t qualify as a spec” or that it’s “too hard to do that” or that the end user is smart enough to figure it out.

    Well, last time I checked, end-users know that THE is spelled THE not THER … yet, what does a spell check do: It identifies the “obvious” so that the end-user can take a step back, look at the broader issues, and quickly input data, thereby letting the tools and engines do the work.

    It’s called “Saves time.” Uh, remember…”saving time” …that part about “going back over your lessons learned” and applying that lesson to the current effort.

    PubSub

  • Clean story needed within your tool on why including http; in the code is or is not a problem
  • Discuss in your own system where the error occurs what the nature of the problem is; how to fix it; with relevant links to supporting material that is simple, clear, and understandable to someone who is working on a project in 4th grade.

  • If the “red highlighted text” [that appears on your tool] is “not an error”, then why are you highlighting it on your tool in red? [Stay tuned]

  • Include in your coding a link to “solutions information”. If you have an automated code in your software that self-generates a red-colored message [remember, this is your code, you made it], then explain why you are creating a code-message, without supporting links, explanations, options, and solutions?

  • Provide an explanation on your website why “the including the http;// code in the search routine” is a problem; but at the same time your publicity/ranking information then turns around and says, “We are pleased to announce that this http:// code that we can’t handle in our search tool in PubSub…suddenly has a superior rating. In fact, it is such a nifty-high-cool-search term [that we can’t handle in the searches; but provide no error-support for within PubSub]…yet at the same time that “highly rated http:// - codes…..has not just one, but TWO superior “popular rankings” within PubSub.

    Translation:

  • Marriage: Bridge from where you are to where you want to go

    It is absurd to have an “red comment message” about http:// without self-contained documentation adjacent to the message [Salt and Pepper are married; so are messages and solutions];

    It is even more ridiculous for PubSub to issue a red-code-message related to “not being able to handle an http:// code” but not stating “that the problem is because of ____” right there next to the red-message;

    Adjacent frame

    This information and comment should be right there where the red-colored message appears. Look at the clickable plus-buttons that Feedburner has in their stat-discussion. All those bots and RSS readers have detailed information. You could include the same “level of detail” in the pop-up error message; or in a window or side bar as big as your MyStack column that provides relevant information to that particular message.

  • Failure mode discussion

    It is ridiculous to explain away the “inclusion of http;// as a code” as “something that should not be included” without indicating that at the time the error was made [Great, I’ve got a message; what do I do now so I can get the content I want sooner, not later or never?];

  • The nature of the message was not resolved on your website in a self-contained tool, but required multiple explanations that should be visible to all, within your own platform, and presented in a manner that solves the problem: Permits the end-user to continue with their search with useful terms, thereby giving them the chance to then wait for PubSub to return a maximum of 32 responses.

  • Inconsistent explanations for failure mode

    It is absurd to credibly argue “http:// cannot be handled” [in the search], but then on your website show case http:// [without any website information] as a “highly popular website] …yet this is not just once, but TWICE;

  • Self-supporting

    But what is more absurd is despite all the above, the only way to get “an answer” as to “what is going on” is to take your red message, ask a question, and then get a confirming message back, “You are correct, that is a message, but the situation is ____ and this is where to go _____” in a place that few on a planet of 6.2Billion will necessarily see. This information should not be simply provided on your website, but should be incorporated into a single tool so that everyone can solve a similar problem;

  • Developer familiarity with product

    This is your code; and if your code is “generating red-colored messages” that “nobody else has seen,” explain how your developers “knew to include this red-colored message; but at the same time despite including that red-coded message, failed to include self-supporting information within your own platform-tool-product to resolve the issue without explanation from a person, and a simple error-solution format as we see everyday in a spell- and grammar- checker;

  • Demonstration as confidence building in more complicated efforts

    Putting aside the issue of whether this is a subscription; or what may or may not happen in an aggregator; or how FeedMesh may or may not solve this problem—all of this is irrelevant, as we’re looking at PubSub as a single stand-alone entity. If that is not the goal of PubSub, then so state:
    “We are not designed to be a stand-alone search tool; we are designed to be included in an aggregator like MyYahoo; we are not a tool you can rely on for immediate responses or results; we may take a while to get something; if you need something fast, try Technorati or Google.”
    If you want other developers, platforms to buy into FeedMesh, need to demonstrate your relatively simple platforms can work; and that your tools integrate across your single platform. When this is credibly demonstrated, the world might have some confidence that the bigger integration efforts across hundreds of platforms will be timely and feasible.

    Wrap Up

    End users want integrated, simple tools. If there’s an error or failure mode or some “strange situation” that the system cannot handle, the end-user wants something as simple as a grammar or spell-checker to handle the situation. Ideally, self-corrected.
    If the tool cannot handle the input, signal the user “this will not work” and automatically convert the “stuff we can’t handle” into something that can be handled.
    If there’s some code to be copied and corrected, that code should be highlighted so the user knows where to copy and where to highlight and where to place it. Ideally, like a spell checker or grammar checker, the user doesn’t have to copy anything, but simply presses a button that says, “Ignore, change, update, or ignore all”. One click. That simple.

    The user wants to know if there is a real issue. If the “glitch” is something that the Feedburner or MyYahoo or any of the other aggregators can reasonably handle, then the “error” or “problem” should not self-report as an error.

    The end-user wants a simple solution to a glitch. They don’t want lectures. They don’t want font-integration issues; they don’t want to have to get out of a blogging platform, turn to a word processing spec, and then reconfigure things in a third-platform like a browser. This should all be transparent, integrated; at most, one-click-fix.

    When solutions are approved by the end-user, the text and code should auto-adjust. The end-use should not be given a red-message without a “what do we do next” option.

    The end-user should not have to copy codes from one platform, and insert them into another one. This does nothing to assist the mobloggers who do not have the IT infrastructure to do this, are mobile, and away from their “land-based system.” [You can make systems that allow mobloggers in the airport to download from their home cable programs; it’s reasonable to expect a similarly easy-approach to ensuring that all XML feeds will be funneled into one platform-route, and not require multiple codes to be copied in non-moblogging architecture.]

    Error checking should be about fixing errors, not reporting them. If there’s a red-colored message, then there’s a solution. Combined and co-locate the message with the solution. Salt and pepper are married.

    Funky codes and quotation-marks in word processing software should be highlighted and fixed automatically like we see in Spell Checker and Grammar corrector. The goal is to have one-click solutions. End-users want better integration. When the strange box appears, the platforms [in this case three of them: blogging software; word processing software, and browser software] should be integrated, talking to each other and agreeing on how to fix this problem transparently to the end-user.

    FeedMesh

    It is not unreasonable to expect platforms to work together. FeedMesh says that this is possible. Sure, it’s possible. But end-users are also seeing evidence to the contrary: Blogging, word processing, and browsers are not seamlessly integrating on something simple as a quotation mark.

    It’s reasonable to believe that something more complicated like “integrating multiple RSS platforms” is plagued by far larger integration issues.

    Congratulations. This is why they have something called systems engineers, integrators, and technical interchange meetings.

    If we are to believe that this “FeedMesh” solution is going to work, then it would be nice to see the various players and components work together. Meaning: If a validator is going to report an error, then that error better be something that “doesn’t work and is a real problem for Feedburner and the major aggregators like MyYahoo.”

    If the players have so many political-hairs up their rear end, that they cannot make a simple message be something that is supportable; and they report as an error “something that another system can work with,” I have grave doubts about the feasibility of the FeedMesh concept.

    Sure, in all practical terms and technically, the concept “should work.” But if you as developers can’t handle something as simple as simple red-colored error message and are unable to ensure your end-products support one of the most popular blogging-support tools like Feedburner, I really wonder how you are going to do something complicated like:

  • Get the word out about your tool;
  • Ensure that FeedMesh can actually integrate and work with different platforms; and
  • That there is a credible system in place to translate likely error modes into tools and messages that are one-click solutions for both your colleagues on the other platforms and, ultimately, the end-user.

    FeedMesh could very well be a grand idea. But I will only believe it when I see it.You have the burden of proof. MyYahoo, Microsoft, and Feedburner have delivered.

    From others, we hear plenty of excuses about messages. Congratulations. You’re missing the point"
    Single-standalone tools like spell checkers are a nifty concept and can be applied to XML-related products: One stop, integrated, and translate XML-garbage into something that is edible.
    You can do better. You have big shoes to fill.
  • Summary

    Single-standalone tools like spell checkers are a nifty concept and can be applied to XML-related products: One stop, integrated, and translate XML-garbage into something that is edible.

    Like an auto-correct option the above is integrated, streamlined, one-click, seamless, and transparent to the end-user; and can also be turned off or on depending on end-user requirements.

    End users, when given messages, want simple tools to prompt the user:

  • What the situation is
  • Why they are getting the message
  • What is going on
  • Where to go, what to look at
  • What their options are
  • What the result will be if they choose a provided option
  • How to solve the problem
  • What the limitations are with the existing tool or product
  • What other alternatives may provide superior results
  • How to accomplish their desired task-objective
  • Ultimately, what needs to be done to ensure their content arrives at the reader’s eyeballs.

    Word processing tools

    Ever noticed how neat spell check and grammar checkers are? They show you what’s wrong; give you options; highlight the information; direct you to something that is a solution; and the end-user gets to decide what to do.

    Pretty nice how a single tool will solve problems. And it’s all self-contained. The end-user doesn’t have to go read a bunch of specs and documentation on “how to do it.” The instructions are all there.

    If there’s an error or problem, the issue gets highlighted. If there’s something that might not be “what is expected” there’s a flag with options.

    Click on the “highlighted-error”, options show up, and the end-user gets the solution: right information, corrected error, a discussion on the nature of the problem with options, and then the options on the right to ignore, change, or add “how the user did it” to the local-database. Kind of like a local Wiki: Local comments. Tailored to the local-user.

    In the end, the end-user gets to decide “what to do with this feedback.” Pretty nifty.

    Desired Development Standards

    There should be a single-step whereby end-users get the four types of information:

  • Show the error;
  • Refer to the appropriate information to explain the nature of the error;
  • Offer choices
  • Solve the problem

    Spell checkers and grammar checkers offer all four steps in one tool, and it is integrated into the overall software package.

    The features: It is self-contained, all inclusive, and moves the end-user from the state of confusion-problem to a solution. It is streamlined, it works, and it integrated

    Remember, it’s not the job of the end-user to have to put all the pieces together and figure out “what an error message means” or “how to fix the problem.” Rather, options should be presented, and the end-user wants to simply know what needs to be done to fix the problem, then solve the problem, and then move on to the next thing.

    Issue

    The idea of “all in one problem solving” that Microsoft and other companies that develop word processing software seems to be concept that is lost on XML developers.

    What I wanted to talk about were some recurring trends I’ve noticed in the XML development efforts. The above scenario with spell- and grammar-checker should be construed as the model or template for a development effort and error reporting.

    Specifics

    Let’s consider three examples of blog-XML interface issues that show the contrast between what the public is given. Remember, the goal is to illustrate how the desired development standard contrasts with what end-users are getting.

    Validation errors Validators need to show what’s wrong by line; and what the end-user needs to do to fix the problem.

    The good validators are already integrated into the software, whether it be an aggregator [at the tail-end of the XML pipeline] or the blog [the point of origin]. Ideally, the validators will take any XML feed, regardless the “errors,” and work with it. Or provide an explanation of "this will not be a problem with X-burner or Y-aggregator, so don't worry." Even if there is a small percentage of errors, the good validates will strip out the problem, and display “what works.”

    Let’s consider the 2RSS conversion tool. The nice thing about it is that it takes the Atom feed and converts it to something that “those who only choose to work with RSS” can work with.

    Also, some aggregators like RSS Owl will actually take a feed, and let the end-reader look at it.

    The point being is that a good validator is one that will do the same thing as a grammar checker: It takes the information, identifies the problem, offers choices, allows the user to select something, and the end-result is: The end-user can use what they have and be on their way.

    No need for explanations. No need to ask questions. No confusion about which line to go to. No requirement for there to be external support.

    The good validator is integrated. It stands alone. And it takes the garbage or “whatever it gets” and lets the end-user convert it into something that is readable. At best, this is all transparent like Feedburner and MyYahoo which, together, can take an “invalid Atom feed” and still inject it into the aggregator.

    Let’s consider an example where the above standard could make a difference

    Right now, if you’re using some word processors, you’ll notice that there are nifty tools to translate the font into something that is readable. Specifically, if you have Chinese font but your browser is not correctly configured, you’ll get this strange box. You can’t read it, but its still valid information.

    The trick is to ensure there is some auto-mated tool that will translate this “box-information” into something that is “real information” that is useful.

    One problem I’ve see is when copying information from Microsoft Word and posting it into blogger: The quotations end up getting messed up.

    Sure, there’s a solution to this. It’s called “get out the specs” and “find the conversion” and “fix the problem.”

    Hello?!?! Who has time for that? The “nifty solution” [applying the above development standard] is for the system to “automatically detect the box” [because it is not readable, although it is information], and do what happens with a spell checker:

    - Highlight the problem, error
    - Recognize there is a red-highlighted error
    - Discuss in the software package-tool the nature of the error
    - Offer some alternatives
    - Give the end-user the chance to change the box into something that is readable
    - Then resolve the matter so that the quotes are correctly displayed; so the quotes are correctly aligned; and the HTML-link is properly coded so that the end-reader can read the link.

    See how that is? All integrated. Convert the “bad box” into “useful information”. Recognize that there are errors. And give the end-user a clean, quick, and efficient method to highlight and correct the code so that it is useful.

    Not that tough is it? I don’t think so.

    Let’s look at a sample where the above standard doesn’t get applied

    Let’s contrast the above “developer standard” with the lovely error codes that some developers like to leave in their final product.

    At worst the developer will leave an error message, provide no link, and the end-user is forced to dig through specs. On top of that, the end-user gets no specific information or guidance; and the end-user gets inconsistent information on what the nature of the problem is.

    PubSub

    Let’s look at the http-error related codes with PubSub and compare then with the above development standards.

    Again, the goal of the tool is to solve problems. When there is an error message, the good tools will acknowledge the glitch, and offer solutions so the end-user can be “on their way.”

    Not PubSub. Take a look at the rank listings. Go down the list of 100. Notice anything unusual?

    Do you see there are several “http” options? Isn’t that lovely. PubSub is reporting as a “popular link” the code “http”. Keep that in mind.

    Also, when you put in an http-prefix before the code into a PubSub subscription search string, you get an error message.

    Some might suggest “this isn’t a problem” or “there is no bug.” Great. Then why the “red error message”? No answer on that one.

    Also, we get a lovely explanation as to “why this isn’t really a problem”. Oh really? Then why is your PubSub tool issuing a-red-highlighted message saying there is a problem with including the http prefix in the search string? Of course, we get a lovely response later after waiting, but nothing like a spell checker that has a real-time response of the nature of the error; links to the information that might provide assistance; and a method of resolving the issue without outside support or explanation.

    See how easy that is? Not that tough.

    What’s puzzling about this simple “developer standard” is that one would think that a concept like Microsoft’s Grammar- and Spell-checker would be universal standards. One that all developers aspire to.

    Yet, time and time again the end-user is given products that don’t do this. Why is that? We have yet to have a satisfactory answer why developers that used to work at Microsoft and are somewhat familiar with word processing software, somehow think that the XML-related products that they develop are somehow immune to these development standards.

    Surely, there were lessons learned from the focus groups and beta-test feedback at Microsoft that provided direct user-feedback on the benefits of this “all in one tool” for spell/grammar checking.

    One would think that a development effort that had personnel that were once assigned to Microsoft might be able to take the “desirable features” from various non-XML products and incorporate those lessons into the XML-products that they are creating for end-users.

    Not these guys. Somehow the XML-development teams have taken it upon themselves to throw everything out the window. The lessons learned from spell checkers: Ignored. The idea of an integrated product that solves problems: Ignored.

    In fact, if one were to raise the issue, at best the former Microsoft developers are likely to start to scream, rant, and blame those who provided the feedback.

    We often hear things like: ”Hay, I’m doing this for free.” Or “This is my hobby” or “Look at all that I’ve done, how dare you.”

    OK. Maybe we, as end-users, shouldn’t wonder why certain developers that used to work at Microsoft have such a hard time creating products that solve problems in a streamlined and integrated manner.

    The problem isn’t that the end-user has a problem. The problem is: Despite the lessons learned from previous efforts, XML-developers seem to think that everything that might be related to users suddenly doesn’t apply; and the end-user, if they dare comment, are to be treated as if the end-user is a problem.

    Congratulations, developers! All that “corporate knowledge” that you might have taken from Microsoft, you’ve thrown out the window. All that goodwill and experience that you might have gleaned from your technical interchange meetings [TIMs] and discussions with program managers, you want the end-user to believe “isn’t relevant.”

    Actually, the real problem, in my opinion, is that you’re not relevant. You’ve had how many decades of cumulative knowledge and lessons learned from prior developers, but you get new standards like XML and you want to rewrite the rules.

    OK. Great. Rewrite your specs. Make more complaints about “why you do not like XML” or “why you hate Atom.” I really don’t care.

    What I do care about is when you make products that don’t work, are not self-contained, and provide no internal support…and then you as developers go out of your way to throw the problem back on the public/end-user as if “the public isn’t being grateful.”

    WTF?!? All those high cost pre-beta testing that Microsoft did and then incorporated into their end-products – why aren’t these lessons learned being incorporated? Why are you re-inventing the wheel?

    “Oh, XML is easy.” No, it’s really irrelevant to whether it is “easy or not.” The issue is: Can you as a developer take the “body of knowledge” that your prior Computer Science- and Developers- create and build upon, can you use it to create credible tools that solve problems.

    Yet, at this juncture, it seems quite apparent that the developers in re XML have shifted back to the pre-Fortran Days of, “if the customer doesn’t tell us specifically what they want, we’ll give them crap.”

    You know what you can do with your XML-development projects that meet that “non-standard”? You can shove them up your ass.

    It’s absurd for the world in the year 2005 to believe that the cumulative knowledge from IBM in the 1940s and the Dayton Cash register Company like NEC…that all those lessons learned are to be thrown out the window.

    That’s a lot of time and money that you’re ignoring. And the fact that you’re making products that don’t meet those standards doesn’t give you a “lovely green light” or a “lovely sticker” to make the public think that you’re innovative.

    There’s one word for you: Arrogant.

    Take a look at the publicly traded companies on the NASDAQ or NYSE that relate to information technology. Take a look at the number of board of directors. Consider the total number of cumulative man-hours that go into ensuring the audit statements; corporate governance standards; and ISO-XXXX standards are incorporated into your performance plans and product development milestones.

    A lot of people. A lot of time. A lot of manhours. And a lot of Money. It’s called investing today, to reap benefits tomorrow.

    The reason those standards exist is so that a company, like yours, can incorporate lessons learned, and build something that builds off what has worked, and create new things.

    The reason your General Counsels will say, “I’ll get back to you,” is that they’re going to take some time to go look something up. They’re looking at treatises and caselaw. They’re considering the journals.

    This is why attorneys command high fees. They have not only a clearly-connected brain-stem, but they actually use the cumulative lessons learned as promulgated in the statutes, legislative history, and other documents in order to arrive at a reasoned legal opinion.

    For those of you who are lost: The concept is “Take the cumulative lessons learned and apply them to your product, don’t throw them out the window.”

    Got it?

    PubSub>

    Let’s now turn to the, IN MY OPINION, cess pool called PubSub.

    Let’s do a new search. First, go to the search routine and type in your full favorite search string for any website and include the http:// prefix in the code.

    Just do it.

    See the message?

    OK. Now, pretend you are in fourth grade. Pretend your parents are at work. Pretend you have a deadline called, “My homework is due tomorrow and, because I’m in fourth grade I’ve waited until the last day to do this project.”

    What do you do?

    If you live in Bob Wyman’s world, you as a fourth grader are expected to put up with:

  • No explanation of what that red-text means
  • No link to explain what to do
  • No discussion of how to fix the problem or adjust the code

    Rather, the end-user doesn’t get the courtesy of a spell- or grammar-check type function with:

  • A simple explanation of the error
  • A clear link to valid information telling the end-user what to do
  • A simple step of “what to do” to adjust the code or input

    Let’s not even talk about “actually having a search routine that could handle the http:// code at the beginning.”

    No. All we get form Wyman is a non-sense explanation of “I’m surprised….” Huh? I don’t see that in the Microsoft grammar and spell checker functions.

    Got a grammar or spelling error in a word processing, and if Bob Wyman were running things, we could very well have the tool come back with, “I’m surprised….”

    Completely unacceptable Bob. Congratulations! All the cumulative corporate knowledge thrown out the window. Blame the user.

    NOT IMPRSSED.

    Developers like to make tools that the developers like. When the end-user asks a question, the developer gives a nice lecture about “what the end-user is supposed to do.”

    Brilliant. Looks like we have a problem here:

    A. Developer makes a product that is not self-contained
    B. Developer fails to include links to explain what to do when there are errors
    C. The user gets an earful because the developer hasn’t thought through the real goal of the tool: It’s not to showcase the developer’s skills, but to solve a problem.

    Going forward

    Developers that create single-platform tools like world processing with spell and grammar checkers have the concept down. They know that the end-user doesn’t want to walk around with a specs manual on the codes to look things up. Those “developer expectations of end-users” supposedly went out the window when we got into the non-dot-commands and mouse-options with windows.

    So XML developers, here’s the clue. The world hasn’t changed. History is relevant.

    The “uncomfortable environment of Microsoft that some may have had a hard time adjusting too” could very well be the needed discipline to ensure lessons from the past and other software development efforts actually get applied to new efforts with new specifications and standards.

    If you want to give a nice lecture to the end-user about “what they don’t understand,” you’re clearly missing the chance to provide a tool that solves the problem.

    Your job as a developer, to justify continued public confidence in your skill, or justify continued program manager faith in your development skills is for you to apply your lessons-learned from your previous efforts [however much you hated the discipline] and apply those lessons to new products.

    It is not your job to blame or lecture the end-user. It is your job to solve problems, to provide an integrated tool, and to save time.

    Integrated. Streamlined. Simple. Relevant information. And something that actually converts your garbage-errors into something that solves the end-users problem.

    If you’ve got a problem “applying the lessons learned” or “not wanting to create products that are as simple as grammar and spell checkers, fine: Continue to make excuses; continue to ignore the feedback; and please continue the lectures on “why the end-user has a problem.”

    Meanwhile, lonely you, will get passed over by the rest of humanity on this planet. 6.2 Billion people. Every one of them has access to this information. And every one of them has the ability to sit down and read the history of Computer Science; and all of them can easily take the lessons learned from IBM, NEC, and Microsoft and apply those lessons to new products.

    Which is it going to be? Frankly, I really don’t care. Go ahead. Please lecture more. Please, when you get feedback on your error messages, please continue your excuses; please provide no links to the information; and please include your “solution” in obscure blogs that nobody can find.

    I hope you don’t provide the solution in an integrated package. I hope you continue to spend time reading blogs from “stupid end-users” [your attitude] so that you can continue to focus on symptoms, not solutions.

    The problem is your failure to apply the lessons learned and create software and solutions for end-users that build upon reasonable public standards. In your universe, I hope you continue to jump at every opportunity for a new product, all the while passing up the opportunity to simply listen, and apply the cumulative knowledge, and discern the real problem:

  • You are failing to see the real problem
  • You are not taking the time to look at the larger issue
  • You are providing excuses, not solutions
  • You are ignoring the cumulative lessons learned
  • You are telling the people who, ultimately pay the bill, that you expect them to put up with your crap and all the while command higher fees.

    Those days are numbered. Let all the corporate boards know: How developers who are good will solve things: They will do what is in a simple spell- and grammar-checker:

  • One-stop
  • Self-contained
  • Integrated
  • Streamlined
  • Provide options
  • Solve the problem
  • Correct the error
  • User-support
  • Visible
  • Clear
  • Simple
  • Relevant,
  • Useful
  • Timely

    The people that meet this standard work at Microsoft. They make great products. And if you have a problem with that, then you do it better.

    I have seen otherwise in the XML community.

    You can do better.

    Requirements

    For those of you who missed it, this is what I expect:

    Blogger-Microsoft Interface

    A method for end-users to quickly discern “what is the nature of the mysterious box”. End-users need to know in a pop-up box or error-discussion box [like you get with a spell checker]:

  • What is this box
  • What are my options to fix it in blogger
  • What settings can I change in my browser, blogger, word-processing software to make this go away
  • What do I do to convert this box into something that my end-reader can understand

    Validators

  • A remark on the error
  • A by-line highlight of the error
  • What I as an end-user can do to fix it
  • A discussion on whether the “problem” can be corrected by Feedburner
  • A discussion of whether the “invalid feed problem” really matters relative to an aggregator like MyYahoo that can “work with the feed”

    XML Search tools

  • A stand-alone support system
  • No requirement for explanations
  • Discuss the error
  • Point to relevant information that explains the issue
  • Explain why the problem “isn’t a problem”; and at the same time explain why the “non problem” continues to provide search results on the “top list” that include this code
  • Identify in the box the steps the end-user must take to solve the problem
  • Acknowledge the limitations of the tool
  • Discuss “what will not be able to be found or searched for” by making that suggested adjustment
  • Discuss the impact on the number of searches; how the target search will get adjusted, how long the end-user might have to wait; other alternatives the end-user might want to take in the meantime
  • Discuss alternatives to solve the end-users search objectives: Are there other tools; what gaps are there in your system; how might an alternate tool provide the intended search?

    Some might suggest that the above “really doesn’t qualify as a spec” or that it’s “too hard to do that” or that the end user is smart enough to figure it out.

    Well, last time I checked, end-users know that THE is spelled THE not THER … yet, what does a spell check do: It identifies the “obvious” so that the end-user can take a step back, look at the broader issues, and quickly input data, thereby letting the tools and engines do the work.

    It’s called “Saves time.” Uh, remember…”saving time” …that part about “going back over your lessons learned” and applying that lesson to the current effort.

    PubSub

  • Clean story needed within your tool on why including http; in the code is or is not a problem
  • Discuss in your own system where the error occurs what the nature of the problem is; how to fix it; with relevant links to supporting material that is simple, clear, and understandable to someone who is working on a project in 4th grade.

  • If the “red highlighted text” [that appears on your tool] is “not an error”, then why are you highlighting it on your tool in red? [Stay tuned]

  • Include in your coding a link to “solutions information”. If you have an automated code in your software that self-generates a red-colored message [remember, this is your code, you made it], then explain why you are creating a code-message, without supporting links, explanations, options, and solutions?

  • Provide an explanation on your website why “the including the http;// code in the search routine” is a problem; but at the same time your publicity/ranking information then turns around and says, “We are pleased to announce that this http:// code that we can’t handle in our search tool in PubSub…suddenly has a superior rating. In fact, it is such a nifty-high-cool-search term [that we can’t handle in the searches; but provide no error-support for within PubSub]…yet at the same time that “highly rated http:// - codes…..has not just one, but TWO superior “popular rankings” within PubSub.

    Translation:

  • Marriage: Bridge from where you are to where you want to go

    It is absurd to have an “red comment message” about http:// without self-contained documentation adjacent to the message [Salt and Pepper are married; so are messages and solutions];

    It is even more ridiculous for PubSub to issue a red-code-message related to “not being able to handle an http:// code” but not stating “that the problem is because of ____” right there next to the red-message;

    Adjacent frame

    This information and comment should be right there where the red-colored message appears. Look at the clickable plus-buttons that Feedburner has in their stat-discussion. All those bots and RSS readers have detailed information. You could include the same “level of detail” in the pop-up error message; or in a window or side bar as big as your MyStack column that provides relevant information to that particular message.

  • Failure mode discussion

    It is ridiculous to explain away the “inclusion of http;// as a code” as “something that should not be included” without indicating that at the time the error was made [Great, I’ve got a message; what do I do now so I can get the content I want sooner, not later or never?];

  • The nature of the message was not resolved on your website in a self-contained tool, but required multiple explanations that should be visible to all, within your own platform, and presented in a manner that solves the problem: Permits the end-user to continue with their search with useful terms, thereby giving them the chance to then wait for PubSub to return a maximum of 32 responses.

  • Inconsistent explanations for failure mode

    It is absurd to credibly argue “http:// cannot be handled” [in the search], but then on your website show case http:// [without any website information] as a “highly popular website] …yet this is not just once, but TWICE;

  • Self-supporting

    But what is more absurd is despite all the above, the only way to get “an answer” as to “what is going on” is to take your red message, ask a question, and then get a confirming message back, “You are correct, that is a message, but the situation is ____ and this is where to go _____” in a place that few on a planet of 6.2Billion will necessarily see. This information should not be simply provided on your website, but should be incorporated into a single tool so that everyone can solve a similar problem;

  • Developer familiarity with product

    This is your code; and if your code is “generating red-colored messages” that “nobody else has seen,” explain how your developers “knew to include this red-colored message; but at the same time despite including that red-coded message, failed to include self-supporting information within your own platform-tool-product to resolve the issue without explanation from a person, and a simple error-solution format as we see everyday in a spell- and grammar- checker;

  • Demonstration as confidence building in more complicated efforts

    Putting aside the issue of whether this is a subscription; or what may or may not happen in an aggregator; or how FeedMesh may or may not solve this problem—all of this is irrelevant, as we’re looking at PubSub as a single stand-alone entity. If that is not the goal of PubSub, then so state:
    “We are not designed to be a stand-alone search tool; we are designed to be included in an aggregator like MyYahoo; we are not a tool you can rely on for immediate responses or results; we may take a while to get something; if you need something fast, try Technorati or Google.”
    If you want other developers, platforms to buy into FeedMesh, need to demonstrate your relatively simple platforms can work; and that your tools integrate across your single platform. When this is credibly demonstrated, the world might have some confidence that the bigger integration efforts across hundreds of platforms will be timely and feasible.

    Wrap Up

    End users want integrated, simple tools. If there’s an error or failure mode or some “strange situation” that the system cannot handle, the end-user wants something as simple as a grammar or spell-checker to handle the situation. Ideally, self-corrected.
    If the tool cannot handle the input, signal the user “this will not work” and automatically convert the “stuff we can’t handle” into something that can be handled.
    If there’s some code to be copied and corrected, that code should be highlighted so the user knows where to copy and where to highlight and where to place it. Ideally, like a spell checker or grammar checker, the user doesn’t have to copy anything, but simply presses a button that says, “Ignore, change, update, or ignore all”. One click. That simple.

    The user wants to know if there is a real issue. If the “glitch” is something that the Feedburner or MyYahoo or any of the other aggregators can reasonably handle, then the “error” or “problem” should not self-report as an error.

    The end-user wants a simple solution to a glitch. They don’t want lectures. They don’t want font-integration issues; they don’t want to have to get out of a blogging platform, turn to a word processing spec, and then reconfigure things in a third-platform like a browser. This should all be transparent, integrated; at most, one-click-fix.

    When solutions are approved by the end-user, the text and code should auto-adjust. The end-use should not be given a red-message without a “what do we do next” option.

    The end-user should not have to copy codes from one platform, and insert them into another one. This does nothing to assist the mobloggers who do not have the IT infrastructure to do this, are mobile, and away from their “land-based system.” [You can make systems that allow mobloggers in the airport to download from their home cable programs; it’s reasonable to expect a similarly easy-approach to ensuring that all XML feeds will be funneled into one platform-route, and not require multiple codes to be copied in non-moblogging architecture.]

    Error checking should be about fixing errors, not reporting them. If there’s a red-colored message, then there’s a solution. Combined and co-locate the message with the solution. Salt and pepper are married.

    Funky codes and quotation-marks in word processing software should be highlighted and fixed automatically like we see in Spell Checker and Grammar corrector. The goal is to have one-click solutions. End-users want better integration. When the strange box appears, the platforms [in this case three of them: blogging software; word processing software, and browser software] should be integrated, talking to each other and agreeing on how to fix this problem transparently to the end-user.

    FeedMesh

    It is not unreasonable to expect platforms to work together. FeedMesh says that this is possible. Sure, it’s possible. But end-users are also seeing evidence to the contrary: Blogging, word processing, and browsers are not seamlessly integrating on something simple as a quotation mark.

    It’s reasonable to believe that something more complicated like “integrating multiple RSS platforms” is plagued by far larger integration issues.

    Congratulations. This is why they have something called systems engineers, integrators, and technical interchange meetings.

    If we are to believe that this “FeedMesh” solution is going to work, then it would be nice to see the various players and components work together. Meaning: If a validator is going to report an error, then that error better be something that “doesn’t work and is a real problem for Feedburner and the major aggregators like MyYahoo.”

    If the players have so many political-hairs up their rear end, that they cannot make a simple message be something that is supportable; and they report as an error “something that another system can work with,” I have grave doubts about the feasibility of the FeedMesh concept.

    Sure, in all practical terms and technically, the concept “should work.” But if you as developers can’t handle something as simple as simple red-colored error message and are unable to ensure your end-products support one of the most popular blogging-support tools like Feedburner, I really wonder how you are going to do something complicated like:

  • Get the word out about your tool;
  • Ensure that FeedMesh can actually integrate and work with different platforms; and
  • That there is a credible system in place to translate likely error modes into tools and messages that are one-click solutions for both your colleagues on the other platforms and, ultimately, the end-user.

    FeedMesh could very well be a grand idea. But I will only believe it when I see it.You have the burden of proof. MyYahoo, Microsoft, and Feedburner have delivered.

    From others, we hear plenty of excuses about messages. Congratulations. You’re missing the point"
    Single-standalone tools like spell checkers are a nifty concept and can be applied to XML-related products: One stop, integrated, and translate XML-garbage into something that is edible.
    You can do better. You have big shoes to fill.
    " />