24 January 2005

XML One Step: Doing more … more easily


Creative Commons License

Link to and cite as . This work is licensed under a Creative Commons License.

Summary

Your success in generating advertising revenues and return on stales is more than generating statistics. It’s about getting eyeballs on your content.

Developers and XML CEOs need to focus on how they’re going to convert those who submit their feeds, into users who use the XML tools.

Feed submitters aren’t using your tools because your tools are a hassle. Rather than giving them something that is simpler than HTML, but gives them more than HTML: XML appears to have gotten it backwards: Providing links to complicated platforms, and segregated the various tools.

Users don’t want to focus on the technology. They want access to solutions. That means making sure your XML products are easy to use. Give them something that is easy to access, and with one click, give them something more than they can get with HTML.

Purpose

This note outlines a number of examples of how end-users could get more out of simpler XML tools.

This note spends time exploring some of the potential solutions to this problem: How to give them more than what they can get in HTML, and make it easier than HTML. What’s needed are streamlined tools; and tools that do more than they can get elsewhere.

These examples are merely illustrative. I’m sure you have many other ideas. Indeed, these examples could already be well used.

Keep in mind as you read these examples: How to give your end-user something more than they can get with HTML, and give it to them in a manner that is easier than a link. Combine functions. Give them XML tools that they are already familiar with in HTML-land.

Discussion

XML isn’t catching on because end-users find it to be a hassle. The short answer is: Why all this hassle?

The solution is to give end-users more… with less hassle. Give them more than they can currently get on a website-webpage, and do it more simply than what’s on a webpage.

I noticed that one site had many subscription feeds, but only a fraction of those users were actually using the service. The trick is to convert those feed-submitters into both product-users and satisfied product users with simple links, but springboard into more than what they can get under HTML-websurfing.

Here are some thoughts on how this could be done. Perhaps you’ll find these of use in your areas for brain storming, or getting a sense of how to translate user feedback into something that really addresses what they’re talking about.


Examples

Each of these examples is intended to germinate what is possible. But don’t focus on the solution or approach given. Focus on the idea of: Giving more…more easily.




One link jump


Users don’t like XML because that little button makes them do a lot. Unlike a simple link that takes them somewhere, psychologically, the XML button means “a lot of steps to add something that may not actually work.”

Think like how most of the web surfers are: They see a link, click on it, and there’s more stuff. It’s not work. It’s easy.

Users want, when they hit an XML-type product, is a spring into more stuff than they can get with HTML: A big map of subscriptions like you can get with NetNewsWire – that java news map that shows all the content in a single snapshot. It’s java-based and you don’t need an aggregator to use it.


One Step Link saver


XML-related tools need to be simpler than del.icio.us. Bookmarking is nice. But how about a simple system where you really only have to click once; and you get, right at the link, a java-like window showing you exactly where you can folder that URL-URI. Then a cross-table showing you all the aggregate changes made to your folder.

Think: A simple one step approach to saving URLs and URIs; move away from this silly multi-step process with an aggregator. Have all those preferences already loaded into the tools, for one step addition and incorporation. User’s don’t want to mess with aggregators, they’d rather spend their time looking at new content.

Users want a simple way to save the link to the exact location: Provide in that XML-link recommendations on the target folder; with auto-sing in for seamless flow of data across XML to non-XML platforms and tools.

Also, when have all these new XML-related links and subscriptions, want a visual-clustering tool to visually identify new patterns of what’s saved; and change the cluster.

Focus on how to quicken the time to seamlessly save URLs-URIs; then permit those saved links to have attached to them user-generated options that only have to be entered once; later it is automatic.

The goal on this link-saver is to quickly change the parameters of the search right there.


XML Send

Simple subscription chicklets to send XML feed URIs from non-XML products


Every time I see an XML button I think, that’s not content, that’s just a link. Turn it around. Think: One link, which spring boards me into XML-connected applications.

Here’s an example. I have a link to XML-content-subscription. What Id’ really like is a simple tool to move from that link to an image of where I currently am in my project; then show me content related to the tasks to my goal; and as I provide feedback to that stream, it gives me information to adjust and get back on track. The tool provides an auto-search for similar XML feeds and content that may be more useful as time passes.

Think of a feed subscription chicklet as linking them not to a single feed, but to all the search and subscription results related to that original link. A feed is a single horizontal stream; users want a broad vertical spectrum to choose from. This XML-link needs to be quickly posted to a variety of platforms.

Your current non-XML users want [but don’t realize it], a simple way to get to more good stuff. They want a faster way to post in HTML blogs and templates this XML-link to content streams. Users don’t want links, don’t want codes: They want quick links to content.


Finding Similar Technorati Tags


Google offers similar links. Technorati Tags are very specific; tags can be different simply by using different capital letters.

One-step approach is to allow end-users to use any tag they feel is appropriate [perhaps matching others, if they choose], but then allows others to find similar tags. That way, if someone says SpamSummit….or spamSummit …or BlogCommentPsychoPoster, they’ll all get to the same thing.

We have top-ranked links in Google; could have the same with Technorati tags. Those that most people are using could be put at the head of the queue.

Concept of finding similar links could be also applied to similar subscriptions and feeds. I differentiate between the two. Subscriptions are linked more to search terms; while a specific fee is related to content. Think of feeds as going horizontally; and end-users would benefit if they could go vertically across both the feeds and subscription-searches to find similar searches and similar feeds.

Rankings would be good for similar subscriptions and feeds. We have search-results in both google and delicious by key terms; same approach for tags, subscriptions, and feeds. Allow end-users to access this type of information to improve the quality of their searches.

Users care less about source, content than getting guidance to meet objectives. They want suggestions and other approaches that may not match exactly what they are doing, but apply the analogies to their own situation to meet a goal.


XML URI Nurture
An approach to URI-URL feed link rot


Keep hearing a lot about links rotting. Problem isn’t going away with XML subscription URIs. A solution needs to embed the search-mode into the URI-URL; either have an embedded code within the URL, or a second code-spot-permission in W3 standards permitting end-users to embed in the link information: Alternatives; search routines; browser address of original search; search platform used.

That way, if people want, they can share their browser searches with others. Those who get to the rotten URI, can then have a direct-auto-link to a pop-up box showing: Similar links related to the original intent of the author; similar links searched at the same time as the original author found them and posted them to either their private bookmarks or del.icio.us; and provide a mechanism to move through the rotten link to a suitable alternative.

The results could be shared and tagged back to original rotten link in the code, giving the next-web-surfer additional information of what might be more appropriate. Consolidated information kept and archived.


XML Enabler
Convert any workproduct into XML-content streams


There are tools that convert non-XML to XML. OK.

How about a way to convert any software product output to XML. And one step to an XML feed, and added.

Not talking about a quick way to add feeds. But a one-step process to convert non-XML-content from text, pdf, ACII, and Optical Character Recognition data into an XML feed. Seamlessly.

Think of this as changing from adding an XML feed to sending and XML feed. Users don’t want to have to open another window. They want to stay where they are, working in their non-XML-related product; and send the stuff from their non-XML-product into the feed with one click. Send: It’s there, saved, loaded, and ready as a feed.


XML Consolidator
Moving value, not software


This bring all non-XML products like e-mail, typing, analysis, CPU, memory, links, blogs, content, documents, bookmarks: Strips them out of their current software packages, and stuffs them into an XML feed. This information is then mixed up, and the end-user relies on tools that will reformat this information into new formats:

  • Stats analysis
  • Quick formatting for export to web, blog, and mail,
  • Transcribe real time text into audio [yes, type: And it’s bundled, saved, and then the computer can send it out to pod-casting.]

    Think of this as creating an XML platform that will take any non-XML text format [.pdf, ascii, docs, scanned OCR-document], pool it into a single XML pool, and then create a platform to organize that data into new patterns, groups. Do more than simply mix links like deli.cio.us; want to identify new patterns; and give end-users the means to quickly consolidate data from many different platforms.


    XML Swipe
    Moving value, not viruses

    There’s a lot of talk about viruses. An alternative to the current system [each computer has data, software that can be infected] is to have a centrally managed software system. The individual computers are only dummy terminals. You extract the needed data from the central software, and work at it at your workstation. This is ancient history.

    What’s new is this: Keep the idea of dummy terminals in mind. But answer this question: What method could we use to ensure all dummy terminals are consistently providing content in similar formats without them talking to each other.

    This process simply strips out the content; keeps the codes in the central location; and then fires back the XML-compatible content back to the central hub.

    Essentially, you have many software products that could otherwise be infected, but all you move is content and value-added output, not the actual software or tools that could carry the virus.

    XML swipe would make sure you don’t have codes that could carry viruses; you simply take the information off the workstation, send it back, and because it’s from XML swipe, it’s already compatible with the other computers, but you don’t have to have the computers talking to each other.

    This replaces the problem with firewalls: Too many walls, high costs, and a lot of work chasing viruses. Create a new information architecture based not on software products, but on sending XML-swiped data, without transmitting function-commands.


    Summary


    No doubt most of the above has already been thought about and is in the labs, if not deployed. The trick is to focus on the users goals, and give them with a single link and spring into more than they can get with HTML.

    The above concepts are just illustrative: What could be done to provide more through XML, but more easily. Users don’t want more hassles. They want an experience that is simpler than HTML, but does more.

    Move away from focusing on promoting XML. Users don’t care about XML, your blogs, or developers. Get over it. They care about their own goals. And achieving them. Without your help, if they can.

    Make XML easier to use, and give them more than they currently get. That way, you can increase the conversion rate. They’ll do more than simply submit their feed. They’ll actually start using your tools: Because they’re easier than HTML, and they do more than they can currently get.

    Think more about creating tools that are easy to get into, and provide a lot of punch at the back end. More easily, providing more.

    Doing more, more easily.



    Creative Commons License

    Link to and cite as . This work is licensed under a Creative Commons License.

    Summary

    Your success in generating advertising revenues and return on stales is more than generating statistics. It’s about getting eyeballs on your content.

    Developers and XML CEOs need to focus on how they’re going to convert those who submit their feeds, into users who use the XML tools.

    Feed submitters aren’t using your tools because your tools are a hassle. Rather than giving them something that is simpler than HTML, but gives them more than HTML: XML appears to have gotten it backwards: Providing links to complicated platforms, and segregated the various tools.

    Users don’t want to focus on the technology. They want access to solutions. That means making sure your XML products are easy to use. Give them something that is easy to access, and with one click, give them something more than they can get with HTML.

    Purpose

    This note outlines a number of examples of how end-users could get more out of simpler XML tools.

    This note spends time exploring some of the potential solutions to this problem: How to give them more than what they can get in HTML, and make it easier than HTML. What’s needed are streamlined tools; and tools that do more than they can get elsewhere.

    These examples are merely illustrative. I’m sure you have many other ideas. Indeed, these examples could already be well used.

    Keep in mind as you read these examples: How to give your end-user something more than they can get with HTML, and give it to them in a manner that is easier than a link. Combine functions. Give them XML tools that they are already familiar with in HTML-land.

    Discussion

    XML isn’t catching on because end-users find it to be a hassle. The short answer is: Why all this hassle?

    The solution is to give end-users more… with less hassle. Give them more than they can currently get on a website-webpage, and do it more simply than what’s on a webpage.

    I noticed that one site had many subscription feeds, but only a fraction of those users were actually using the service. The trick is to convert those feed-submitters into both product-users and satisfied product users with simple links, but springboard into more than what they can get under HTML-websurfing.

    Here are some thoughts on how this could be done. Perhaps you’ll find these of use in your areas for brain storming, or getting a sense of how to translate user feedback into something that really addresses what they’re talking about.


    Examples

    Each of these examples is intended to germinate what is possible. But don’t focus on the solution or approach given. Focus on the idea of: Giving more…more easily.




    One link jump


    Users don’t like XML because that little button makes them do a lot. Unlike a simple link that takes them somewhere, psychologically, the XML button means “a lot of steps to add something that may not actually work.”

    Think like how most of the web surfers are: They see a link, click on it, and there’s more stuff. It’s not work. It’s easy.

    Users want, when they hit an XML-type product, is a spring into more stuff than they can get with HTML: A big map of subscriptions like you can get with NetNewsWire – that java news map that shows all the content in a single snapshot. It’s java-based and you don’t need an aggregator to use it.


    One Step Link saver


    XML-related tools need to be simpler than del.icio.us. Bookmarking is nice. But how about a simple system where you really only have to click once; and you get, right at the link, a java-like window showing you exactly where you can folder that URL-URI. Then a cross-table showing you all the aggregate changes made to your folder.

    Think: A simple one step approach to saving URLs and URIs; move away from this silly multi-step process with an aggregator. Have all those preferences already loaded into the tools, for one step addition and incorporation. User’s don’t want to mess with aggregators, they’d rather spend their time looking at new content.

    Users want a simple way to save the link to the exact location: Provide in that XML-link recommendations on the target folder; with auto-sing in for seamless flow of data across XML to non-XML platforms and tools.

    Also, when have all these new XML-related links and subscriptions, want a visual-clustering tool to visually identify new patterns of what’s saved; and change the cluster.

    Focus on how to quicken the time to seamlessly save URLs-URIs; then permit those saved links to have attached to them user-generated options that only have to be entered once; later it is automatic.

    The goal on this link-saver is to quickly change the parameters of the search right there.


    XML Send

    Simple subscription chicklets to send XML feed URIs from non-XML products


    Every time I see an XML button I think, that’s not content, that’s just a link. Turn it around. Think: One link, which spring boards me into XML-connected applications.

    Here’s an example. I have a link to XML-content-subscription. What Id’ really like is a simple tool to move from that link to an image of where I currently am in my project; then show me content related to the tasks to my goal; and as I provide feedback to that stream, it gives me information to adjust and get back on track. The tool provides an auto-search for similar XML feeds and content that may be more useful as time passes.

    Think of a feed subscription chicklet as linking them not to a single feed, but to all the search and subscription results related to that original link. A feed is a single horizontal stream; users want a broad vertical spectrum to choose from. This XML-link needs to be quickly posted to a variety of platforms.

    Your current non-XML users want [but don’t realize it], a simple way to get to more good stuff. They want a faster way to post in HTML blogs and templates this XML-link to content streams. Users don’t want links, don’t want codes: They want quick links to content.


    Finding Similar Technorati Tags


    Google offers similar links. Technorati Tags are very specific; tags can be different simply by using different capital letters.

    One-step approach is to allow end-users to use any tag they feel is appropriate [perhaps matching others, if they choose], but then allows others to find similar tags. That way, if someone says SpamSummit….or spamSummit …or BlogCommentPsychoPoster, they’ll all get to the same thing.

    We have top-ranked links in Google; could have the same with Technorati tags. Those that most people are using could be put at the head of the queue.

    Concept of finding similar links could be also applied to similar subscriptions and feeds. I differentiate between the two. Subscriptions are linked more to search terms; while a specific fee is related to content. Think of feeds as going horizontally; and end-users would benefit if they could go vertically across both the feeds and subscription-searches to find similar searches and similar feeds.

    Rankings would be good for similar subscriptions and feeds. We have search-results in both google and delicious by key terms; same approach for tags, subscriptions, and feeds. Allow end-users to access this type of information to improve the quality of their searches.

    Users care less about source, content than getting guidance to meet objectives. They want suggestions and other approaches that may not match exactly what they are doing, but apply the analogies to their own situation to meet a goal.


    XML URI Nurture
    An approach to URI-URL feed link rot


    Keep hearing a lot about links rotting. Problem isn’t going away with XML subscription URIs. A solution needs to embed the search-mode into the URI-URL; either have an embedded code within the URL, or a second code-spot-permission in W3 standards permitting end-users to embed in the link information: Alternatives; search routines; browser address of original search; search platform used.

    That way, if people want, they can share their browser searches with others. Those who get to the rotten URI, can then have a direct-auto-link to a pop-up box showing: Similar links related to the original intent of the author; similar links searched at the same time as the original author found them and posted them to either their private bookmarks or del.icio.us; and provide a mechanism to move through the rotten link to a suitable alternative.

    The results could be shared and tagged back to original rotten link in the code, giving the next-web-surfer additional information of what might be more appropriate. Consolidated information kept and archived.


    XML Enabler
    Convert any workproduct into XML-content streams


    There are tools that convert non-XML to XML. OK.

    How about a way to convert any software product output to XML. And one step to an XML feed, and added.

    Not talking about a quick way to add feeds. But a one-step process to convert non-XML-content from text, pdf, ACII, and Optical Character Recognition data into an XML feed. Seamlessly.

    Think of this as changing from adding an XML feed to sending and XML feed. Users don’t want to have to open another window. They want to stay where they are, working in their non-XML-related product; and send the stuff from their non-XML-product into the feed with one click. Send: It’s there, saved, loaded, and ready as a feed.


    XML Consolidator
    Moving value, not software


    This bring all non-XML products like e-mail, typing, analysis, CPU, memory, links, blogs, content, documents, bookmarks: Strips them out of their current software packages, and stuffs them into an XML feed. This information is then mixed up, and the end-user relies on tools that will reformat this information into new formats:

  • Stats analysis
  • Quick formatting for export to web, blog, and mail,
  • Transcribe real time text into audio [yes, type: And it’s bundled, saved, and then the computer can send it out to pod-casting.]

    Think of this as creating an XML platform that will take any non-XML text format [.pdf, ascii, docs, scanned OCR-document], pool it into a single XML pool, and then create a platform to organize that data into new patterns, groups. Do more than simply mix links like deli.cio.us; want to identify new patterns; and give end-users the means to quickly consolidate data from many different platforms.


    XML Swipe
    Moving value, not viruses

    There’s a lot of talk about viruses. An alternative to the current system [each computer has data, software that can be infected] is to have a centrally managed software system. The individual computers are only dummy terminals. You extract the needed data from the central software, and work at it at your workstation. This is ancient history.

    What’s new is this: Keep the idea of dummy terminals in mind. But answer this question: What method could we use to ensure all dummy terminals are consistently providing content in similar formats without them talking to each other.

    This process simply strips out the content; keeps the codes in the central location; and then fires back the XML-compatible content back to the central hub.

    Essentially, you have many software products that could otherwise be infected, but all you move is content and value-added output, not the actual software or tools that could carry the virus.

    XML swipe would make sure you don’t have codes that could carry viruses; you simply take the information off the workstation, send it back, and because it’s from XML swipe, it’s already compatible with the other computers, but you don’t have to have the computers talking to each other.

    This replaces the problem with firewalls: Too many walls, high costs, and a lot of work chasing viruses. Create a new information architecture based not on software products, but on sending XML-swiped data, without transmitting function-commands.


    Summary


    No doubt most of the above has already been thought about and is in the labs, if not deployed. The trick is to focus on the users goals, and give them with a single link and spring into more than they can get with HTML.

    The above concepts are just illustrative: What could be done to provide more through XML, but more easily. Users don’t want more hassles. They want an experience that is simpler than HTML, but does more.

    Move away from focusing on promoting XML. Users don’t care about XML, your blogs, or developers. Get over it. They care about their own goals. And achieving them. Without your help, if they can.

    Make XML easier to use, and give them more than they currently get. That way, you can increase the conversion rate. They’ll do more than simply submit their feed. They’ll actually start using your tools: Because they’re easier than HTML, and they do more than they can currently get.

    Think more about creating tools that are easy to get into, and provide a lot of punch at the back end. More easily, providing more.

    Doing more, more easily.


    -->

    Creative Commons License

    Link to and cite as . This work is licensed under a Creative Commons License.

    Summary

    Your success in generating advertising revenues and return on stales is more than generating statistics. It’s about getting eyeballs on your content.

    Developers and XML CEOs need to focus on how they’re going to convert those who submit their feeds, into users who use the XML tools.

    Feed submitters aren’t using your tools because your tools are a hassle. Rather than giving them something that is simpler than HTML, but gives them more than HTML: XML appears to have gotten it backwards: Providing links to complicated platforms, and segregated the various tools.

    Users don’t want to focus on the technology. They want access to solutions. That means making sure your XML products are easy to use. Give them something that is easy to access, and with one click, give them something more than they can get with HTML.

    Purpose

    This note outlines a number of examples of how end-users could get more out of simpler XML tools.

    This note spends time exploring some of the potential solutions to this problem: How to give them more than what they can get in HTML, and make it easier than HTML. What’s needed are streamlined tools; and tools that do more than they can get elsewhere.

    These examples are merely illustrative. I’m sure you have many other ideas. Indeed, these examples could already be well used.

    Keep in mind as you read these examples: How to give your end-user something more than they can get with HTML, and give it to them in a manner that is easier than a link. Combine functions. Give them XML tools that they are already familiar with in HTML-land.

    Discussion

    XML isn’t catching on because end-users find it to be a hassle. The short answer is: Why all this hassle?

    The solution is to give end-users more… with less hassle. Give them more than they can currently get on a website-webpage, and do it more simply than what’s on a webpage.

    I noticed that one site had many subscription feeds, but only a fraction of those users were actually using the service. The trick is to convert those feed-submitters into both product-users and satisfied product users with simple links, but springboard into more than what they can get under HTML-websurfing.

    Here are some thoughts on how this could be done. Perhaps you’ll find these of use in your areas for brain storming, or getting a sense of how to translate user feedback into something that really addresses what they’re talking about.


    Examples

    Each of these examples is intended to germinate what is possible. But don’t focus on the solution or approach given. Focus on the idea of: Giving more…more easily.




    One link jump


    Users don’t like XML because that little button makes them do a lot. Unlike a simple link that takes them somewhere, psychologically, the XML button means “a lot of steps to add something that may not actually work.”

    Think like how most of the web surfers are: They see a link, click on it, and there’s more stuff. It’s not work. It’s easy.

    Users want, when they hit an XML-type product, is a spring into more stuff than they can get with HTML: A big map of subscriptions like you can get with NetNewsWire – that java news map that shows all the content in a single snapshot. It’s java-based and you don’t need an aggregator to use it.


    One Step Link saver


    XML-related tools need to be simpler than del.icio.us. Bookmarking is nice. But how about a simple system where you really only have to click once; and you get, right at the link, a java-like window showing you exactly where you can folder that URL-URI. Then a cross-table showing you all the aggregate changes made to your folder.

    Think: A simple one step approach to saving URLs and URIs; move away from this silly multi-step process with an aggregator. Have all those preferences already loaded into the tools, for one step addition and incorporation. User’s don’t want to mess with aggregators, they’d rather spend their time looking at new content.

    Users want a simple way to save the link to the exact location: Provide in that XML-link recommendations on the target folder; with auto-sing in for seamless flow of data across XML to non-XML platforms and tools.

    Also, when have all these new XML-related links and subscriptions, want a visual-clustering tool to visually identify new patterns of what’s saved; and change the cluster.

    Focus on how to quicken the time to seamlessly save URLs-URIs; then permit those saved links to have attached to them user-generated options that only have to be entered once; later it is automatic.

    The goal on this link-saver is to quickly change the parameters of the search right there.


    XML Send

    Simple subscription chicklets to send XML feed URIs from non-XML products


    Every time I see an XML button I think, that’s not content, that’s just a link. Turn it around. Think: One link, which spring boards me into XML-connected applications.

    Here’s an example. I have a link to XML-content-subscription. What Id’ really like is a simple tool to move from that link to an image of where I currently am in my project; then show me content related to the tasks to my goal; and as I provide feedback to that stream, it gives me information to adjust and get back on track. The tool provides an auto-search for similar XML feeds and content that may be more useful as time passes.

    Think of a feed subscription chicklet as linking them not to a single feed, but to all the search and subscription results related to that original link. A feed is a single horizontal stream; users want a broad vertical spectrum to choose from. This XML-link needs to be quickly posted to a variety of platforms.

    Your current non-XML users want [but don’t realize it], a simple way to get to more good stuff. They want a faster way to post in HTML blogs and templates this XML-link to content streams. Users don’t want links, don’t want codes: They want quick links to content.


    Finding Similar Technorati Tags


    Google offers similar links. Technorati Tags are very specific; tags can be different simply by using different capital letters.

    One-step approach is to allow end-users to use any tag they feel is appropriate [perhaps matching others, if they choose], but then allows others to find similar tags. That way, if someone says SpamSummit….or spamSummit …or BlogCommentPsychoPoster, they’ll all get to the same thing.

    We have top-ranked links in Google; could have the same with Technorati tags. Those that most people are using could be put at the head of the queue.

    Concept of finding similar links could be also applied to similar subscriptions and feeds. I differentiate between the two. Subscriptions are linked more to search terms; while a specific fee is related to content. Think of feeds as going horizontally; and end-users would benefit if they could go vertically across both the feeds and subscription-searches to find similar searches and similar feeds.

    Rankings would be good for similar subscriptions and feeds. We have search-results in both google and delicious by key terms; same approach for tags, subscriptions, and feeds. Allow end-users to access this type of information to improve the quality of their searches.

    Users care less about source, content than getting guidance to meet objectives. They want suggestions and other approaches that may not match exactly what they are doing, but apply the analogies to their own situation to meet a goal.


    XML URI Nurture
    An approach to URI-URL feed link rot


    Keep hearing a lot about links rotting. Problem isn’t going away with XML subscription URIs. A solution needs to embed the search-mode into the URI-URL; either have an embedded code within the URL, or a second code-spot-permission in W3 standards permitting end-users to embed in the link information: Alternatives; search routines; browser address of original search; search platform used.

    That way, if people want, they can share their browser searches with others. Those who get to the rotten URI, can then have a direct-auto-link to a pop-up box showing: Similar links related to the original intent of the author; similar links searched at the same time as the original author found them and posted them to either their private bookmarks or del.icio.us; and provide a mechanism to move through the rotten link to a suitable alternative.

    The results could be shared and tagged back to original rotten link in the code, giving the next-web-surfer additional information of what might be more appropriate. Consolidated information kept and archived.


    XML Enabler
    Convert any workproduct into XML-content streams


    There are tools that convert non-XML to XML. OK.

    How about a way to convert any software product output to XML. And one step to an XML feed, and added.

    Not talking about a quick way to add feeds. But a one-step process to convert non-XML-content from text, pdf, ACII, and Optical Character Recognition data into an XML feed. Seamlessly.

    Think of this as changing from adding an XML feed to sending and XML feed. Users don’t want to have to open another window. They want to stay where they are, working in their non-XML-related product; and send the stuff from their non-XML-product into the feed with one click. Send: It’s there, saved, loaded, and ready as a feed.


    XML Consolidator
    Moving value, not software


    This bring all non-XML products like e-mail, typing, analysis, CPU, memory, links, blogs, content, documents, bookmarks: Strips them out of their current software packages, and stuffs them into an XML feed. This information is then mixed up, and the end-user relies on tools that will reformat this information into new formats:

  • Stats analysis
  • Quick formatting for export to web, blog, and mail,
  • Transcribe real time text into audio [yes, type: And it’s bundled, saved, and then the computer can send it out to pod-casting.]

    Think of this as creating an XML platform that will take any non-XML text format [.pdf, ascii, docs, scanned OCR-document], pool it into a single XML pool, and then create a platform to organize that data into new patterns, groups. Do more than simply mix links like deli.cio.us; want to identify new patterns; and give end-users the means to quickly consolidate data from many different platforms.


    XML Swipe
    Moving value, not viruses

    There’s a lot of talk about viruses. An alternative to the current system [each computer has data, software that can be infected] is to have a centrally managed software system. The individual computers are only dummy terminals. You extract the needed data from the central software, and work at it at your workstation. This is ancient history.

    What’s new is this: Keep the idea of dummy terminals in mind. But answer this question: What method could we use to ensure all dummy terminals are consistently providing content in similar formats without them talking to each other.

    This process simply strips out the content; keeps the codes in the central location; and then fires back the XML-compatible content back to the central hub.

    Essentially, you have many software products that could otherwise be infected, but all you move is content and value-added output, not the actual software or tools that could carry the virus.

    XML swipe would make sure you don’t have codes that could carry viruses; you simply take the information off the workstation, send it back, and because it’s from XML swipe, it’s already compatible with the other computers, but you don’t have to have the computers talking to each other.

    This replaces the problem with firewalls: Too many walls, high costs, and a lot of work chasing viruses. Create a new information architecture based not on software products, but on sending XML-swiped data, without transmitting function-commands.


    Summary


    No doubt most of the above has already been thought about and is in the labs, if not deployed. The trick is to focus on the users goals, and give them with a single link and spring into more than they can get with HTML.

    The above concepts are just illustrative: What could be done to provide more through XML, but more easily. Users don’t want more hassles. They want an experience that is simpler than HTML, but does more.

    Move away from focusing on promoting XML. Users don’t care about XML, your blogs, or developers. Get over it. They care about their own goals. And achieving them. Without your help, if they can.

    Make XML easier to use, and give them more than they currently get. That way, you can increase the conversion rate. They’ll do more than simply submit their feed. They’ll actually start using your tools: Because they’re easier than HTML, and they do more than they can currently get.

    Think more about creating tools that are easy to get into, and provide a lot of punch at the back end. More easily, providing more.

    Doing more, more easily.



  • Creative Commons License

    Link to and cite as . This work is licensed under a Creative Commons License.

    Summary

    Your success in generating advertising revenues and return on stales is more than generating statistics. It’s about getting eyeballs on your content.

    Developers and XML CEOs need to focus on how they’re going to convert those who submit their feeds, into users who use the XML tools.

    Feed submitters aren’t using your tools because your tools are a hassle. Rather than giving them something that is simpler than HTML, but gives them more than HTML: XML appears to have gotten it backwards: Providing links to complicated platforms, and segregated the various tools.

    Users don’t want to focus on the technology. They want access to solutions. That means making sure your XML products are easy to use. Give them something that is easy to access, and with one click, give them something more than they can get with HTML.

    Purpose

    This note outlines a number of examples of how end-users could get more out of simpler XML tools.

    This note spends time exploring some of the potential solutions to this problem: How to give them more than what they can get in HTML, and make it easier than HTML. What’s needed are streamlined tools; and tools that do more than they can get elsewhere.

    These examples are merely illustrative. I’m sure you have many other ideas. Indeed, these examples could already be well used.

    Keep in mind as you read these examples: How to give your end-user something more than they can get with HTML, and give it to them in a manner that is easier than a link. Combine functions. Give them XML tools that they are already familiar with in HTML-land.

    Discussion

    XML isn’t catching on because end-users find it to be a hassle. The short answer is: Why all this hassle?

    The solution is to give end-users more… with less hassle. Give them more than they can currently get on a website-webpage, and do it more simply than what’s on a webpage.

    I noticed that one site had many subscription feeds, but only a fraction of those users were actually using the service. The trick is to convert those feed-submitters into both product-users and satisfied product users with simple links, but springboard into more than what they can get under HTML-websurfing.

    Here are some thoughts on how this could be done. Perhaps you’ll find these of use in your areas for brain storming, or getting a sense of how to translate user feedback into something that really addresses what they’re talking about.


    Examples

    Each of these examples is intended to germinate what is possible. But don’t focus on the solution or approach given. Focus on the idea of: Giving more…more easily.




    One link jump


    Users don’t like XML because that little button makes them do a lot. Unlike a simple link that takes them somewhere, psychologically, the XML button means “a lot of steps to add something that may not actually work.”

    Think like how most of the web surfers are: They see a link, click on it, and there’s more stuff. It’s not work. It’s easy.

    Users want, when they hit an XML-type product, is a spring into more stuff than they can get with HTML: A big map of subscriptions like you can get with NetNewsWire – that java news map that shows all the content in a single snapshot. It’s java-based and you don’t need an aggregator to use it.


    One Step Link saver


    XML-related tools need to be simpler than del.icio.us. Bookmarking is nice. But how about a simple system where you really only have to click once; and you get, right at the link, a java-like window showing you exactly where you can folder that URL-URI. Then a cross-table showing you all the aggregate changes made to your folder.

    Think: A simple one step approach to saving URLs and URIs; move away from this silly multi-step process with an aggregator. Have all those preferences already loaded into the tools, for one step addition and incorporation. User’s don’t want to mess with aggregators, they’d rather spend their time looking at new content.

    Users want a simple way to save the link to the exact location: Provide in that XML-link recommendations on the target folder; with auto-sing in for seamless flow of data across XML to non-XML platforms and tools.

    Also, when have all these new XML-related links and subscriptions, want a visual-clustering tool to visually identify new patterns of what’s saved; and change the cluster.

    Focus on how to quicken the time to seamlessly save URLs-URIs; then permit those saved links to have attached to them user-generated options that only have to be entered once; later it is automatic.

    The goal on this link-saver is to quickly change the parameters of the search right there.


    XML Send

    Simple subscription chicklets to send XML feed URIs from non-XML products


    Every time I see an XML button I think, that’s not content, that’s just a link. Turn it around. Think: One link, which spring boards me into XML-connected applications.

    Here’s an example. I have a link to XML-content-subscription. What Id’ really like is a simple tool to move from that link to an image of where I currently am in my project; then show me content related to the tasks to my goal; and as I provide feedback to that stream, it gives me information to adjust and get back on track. The tool provides an auto-search for similar XML feeds and content that may be more useful as time passes.

    Think of a feed subscription chicklet as linking them not to a single feed, but to all the search and subscription results related to that original link. A feed is a single horizontal stream; users want a broad vertical spectrum to choose from. This XML-link needs to be quickly posted to a variety of platforms.

    Your current non-XML users want [but don’t realize it], a simple way to get to more good stuff. They want a faster way to post in HTML blogs and templates this XML-link to content streams. Users don’t want links, don’t want codes: They want quick links to content.


    Finding Similar Technorati Tags


    Google offers similar links. Technorati Tags are very specific; tags can be different simply by using different capital letters.

    One-step approach is to allow end-users to use any tag they feel is appropriate [perhaps matching others, if they choose], but then allows others to find similar tags. That way, if someone says SpamSummit….or spamSummit …or BlogCommentPsychoPoster, they’ll all get to the same thing.

    We have top-ranked links in Google; could have the same with Technorati tags. Those that most people are using could be put at the head of the queue.

    Concept of finding similar links could be also applied to similar subscriptions and feeds. I differentiate between the two. Subscriptions are linked more to search terms; while a specific fee is related to content. Think of feeds as going horizontally; and end-users would benefit if they could go vertically across both the feeds and subscription-searches to find similar searches and similar feeds.

    Rankings would be good for similar subscriptions and feeds. We have search-results in both google and delicious by key terms; same approach for tags, subscriptions, and feeds. Allow end-users to access this type of information to improve the quality of their searches.

    Users care less about source, content than getting guidance to meet objectives. They want suggestions and other approaches that may not match exactly what they are doing, but apply the analogies to their own situation to meet a goal.


    XML URI Nurture
    An approach to URI-URL feed link rot


    Keep hearing a lot about links rotting. Problem isn’t going away with XML subscription URIs. A solution needs to embed the search-mode into the URI-URL; either have an embedded code within the URL, or a second code-spot-permission in W3 standards permitting end-users to embed in the link information: Alternatives; search routines; browser address of original search; search platform used.

    That way, if people want, they can share their browser searches with others. Those who get to the rotten URI, can then have a direct-auto-link to a pop-up box showing: Similar links related to the original intent of the author; similar links searched at the same time as the original author found them and posted them to either their private bookmarks or del.icio.us; and provide a mechanism to move through the rotten link to a suitable alternative.

    The results could be shared and tagged back to original rotten link in the code, giving the next-web-surfer additional information of what might be more appropriate. Consolidated information kept and archived.


    XML Enabler
    Convert any workproduct into XML-content streams


    There are tools that convert non-XML to XML. OK.

    How about a way to convert any software product output to XML. And one step to an XML feed, and added.

    Not talking about a quick way to add feeds. But a one-step process to convert non-XML-content from text, pdf, ACII, and Optical Character Recognition data into an XML feed. Seamlessly.

    Think of this as changing from adding an XML feed to sending and XML feed. Users don’t want to have to open another window. They want to stay where they are, working in their non-XML-related product; and send the stuff from their non-XML-product into the feed with one click. Send: It’s there, saved, loaded, and ready as a feed.


    XML Consolidator
    Moving value, not software


    This bring all non-XML products like e-mail, typing, analysis, CPU, memory, links, blogs, content, documents, bookmarks: Strips them out of their current software packages, and stuffs them into an XML feed. This information is then mixed up, and the end-user relies on tools that will reformat this information into new formats:

  • Stats analysis
  • Quick formatting for export to web, blog, and mail,
  • Transcribe real time text into audio [yes, type: And it’s bundled, saved, and then the computer can send it out to pod-casting.]

    Think of this as creating an XML platform that will take any non-XML text format [.pdf, ascii, docs, scanned OCR-document], pool it into a single XML pool, and then create a platform to organize that data into new patterns, groups. Do more than simply mix links like deli.cio.us; want to identify new patterns; and give end-users the means to quickly consolidate data from many different platforms.


    XML Swipe
    Moving value, not viruses

    There’s a lot of talk about viruses. An alternative to the current system [each computer has data, software that can be infected] is to have a centrally managed software system. The individual computers are only dummy terminals. You extract the needed data from the central software, and work at it at your workstation. This is ancient history.

    What’s new is this: Keep the idea of dummy terminals in mind. But answer this question: What method could we use to ensure all dummy terminals are consistently providing content in similar formats without them talking to each other.

    This process simply strips out the content; keeps the codes in the central location; and then fires back the XML-compatible content back to the central hub.

    Essentially, you have many software products that could otherwise be infected, but all you move is content and value-added output, not the actual software or tools that could carry the virus.

    XML swipe would make sure you don’t have codes that could carry viruses; you simply take the information off the workstation, send it back, and because it’s from XML swipe, it’s already compatible with the other computers, but you don’t have to have the computers talking to each other.

    This replaces the problem with firewalls: Too many walls, high costs, and a lot of work chasing viruses. Create a new information architecture based not on software products, but on sending XML-swiped data, without transmitting function-commands.


    Summary


    No doubt most of the above has already been thought about and is in the labs, if not deployed. The trick is to focus on the users goals, and give them with a single link and spring into more than they can get with HTML.

    The above concepts are just illustrative: What could be done to provide more through XML, but more easily. Users don’t want more hassles. They want an experience that is simpler than HTML, but does more.

    Move away from focusing on promoting XML. Users don’t care about XML, your blogs, or developers. Get over it. They care about their own goals. And achieving them. Without your help, if they can.

    Make XML easier to use, and give them more than they currently get. That way, you can increase the conversion rate. They’ll do more than simply submit their feed. They’ll actually start using your tools: Because they’re easier than HTML, and they do more than they can currently get.

    Think more about creating tools that are easy to get into, and provide a lot of punch at the back end. More easily, providing more.

    Doing more, more easily.


    " />
  • << Home