JamieJamison: Is Bill French the myst technology guy?

Can't find the link to Bill's slides. Anyone?

TrevorFSmith: "a newsreader is a device"?

bfrench: Absolutely ... it is a "device" acting on behalf of the content consumer. Saying that it's not is like saying televisions, radios, cell phones, or GPS systems are not devices. The only difference between these "consumer" products and a comupter with an installed RSS reader is the devices include the mechanisms that support the publish/subscribe process.

TrevorFSmith: Security creates a more agile framework?

bfrench: It most certainly does - imagine a single feed that needs to present items that are different depending on the security context. In a system where a permissions model is non-existent, there is no agility in terms deciding who sees what.

RolandTanglao: i like bill and all but i find his talk too general and apple pie about XML and RSS, how about making $s, concrete examples.

bfrench: Good point Roland. We were advised (as speakers) to keep the presentation on the educational side instead of rambling on about any specific commercial uses. Also, as I mentioned in the session we don't disclose our customer names in public forums unless they've specifically asked us to.

bfrench: I mentioned the Addison-Wesley project in the presentation. We anticipate a significant deployment for their book publishing divisions, but again, these are applications that will never be seen on the Internet. Furthermore, our interest in these enterprise or corporate-class application is not to become a that publishes these as deployments. MyST's business model is focused on OEM licenses for companies that want to use our platform for building things like this. As such, we are reluctant to advertise or promote any single application that we've built to make a point.

alevin: the Smart Tags+Weblogs sounds pretty cool - automatically link a word in your word doc to other weblogs.

bfrench: And not only Weblogs, but to any XML content space or application items. Imagine a Smart Tag subscription for part numbers - each part number typed in an Office document is automatically linked to a master-list of the parts.

bfrench: MyST is not about Weblogs and it's not about RSS. However it is about information agility and that includes many systems and many workflows that business want to develop.

rasterboy: except for all those meta tags people use to prevent smart tag parsing ;)

bfrench: I'm sorry, but you are misinformed. Blocking Smart Tags on public Web pages is not related to the use of our technology. You need to drill a bit deeper and understand the benefits of Smart Tags to businesses, workflow processes, and km solutions.

RolandTanglao: myst is cool ; i just wish they had some other name; the pronounciation is similar to a 'bad' word in German :-)

bfrench: We agree - MyST was never intended to be a widely visible name, but it sort of just happened.

MarkFletcher: So is the Aggregation Portal an example of Myst?

bfrench: Yes - it's an example of using our aggregation engine along with our presentation layer to create what appears to be a unified information space.

MarkFletcher: Is Myst basically an enterprise Google?

bfrench: No, but MyST can be used with Google Appliance and other enterprise search tools to build dynamically changing information channels that may also be subscribed to through RSS, OPML, Smart Tags, etc. Most enterprises don't have the machinery to integrate search engines with Microsoft Office Research Tasks, but by allowing our platform to integrate with their search systems, we can provide Office integrations seamlessly and without any significant coding.

alevin: portal and search of microcontent

bfrench: That is certainly one use case, but there are hundreds of others.

JamieJamison: I think it is more of an enterprise web services application that can serve a number of purposes.

bfrench: Exactly. Think of it as a big bag of Legos(tm) that can be assembled to provide spoecific applications and solutions. And we're looking for developers that have technical requirements that they cannot possibly develop quick enough to meet constantly shifting enterprise requirements.

RolandTanglao: myst is a web services, XML and RSS platform; aggregation portal is a Myst app; it's confusing I agree.

bfrench: Yes - it is confusing. When we created the MyST platform, we did so to meet technical requirements that had not fully matured or had not been encountered. To build a platform that must integrate with applications and standards that have not yet been invented is very confusing to grasp.

JamieJamison: I think that is true for any technology, though.

bfrench: We agree. ;-) Imagine trying to describe a telephone to someone that had never seen or used one before.

JamieJamison: That sort of issue is one of the arguments for some sort of authenticated subscription-based RSS.

bfrench: Authenticated RSS is one of the many things that we didn't anticipate when we designed MyST two years ago. However, it supports this concept and we did no further programming to achieve that.

MarkFletcher: I think it's a case of 'technology platforms' in general being difficult to explain, whereas an application is something that you can show people. It's 'definite'.

bfrench: Absolutely. This is a huge challenge for us because most people expect to see a product. What we have is a federation of Web services components that can quite literally be anything and participate in helping developers of content-related applications, solve anything.

alevin: are these real applications? have they been deployed?

bfrench: Yes - but they are applications that you would probably not recognize. For Ipswitch we manage a wealth of channel data and provide a collection of integrated processes that help their marketing staff deal with problems in the reseller channel. The business intelligence gathering process is done with Channel Gears; the same technology that drives the RSS Radar channels on the RSS WinterFest site. The 'application' was designed specifically to inform the marketing group how well the reseller channel was representating the Ipswitch brand, their products, and availability on each of their web sites. This is a very difficult task without workflow and process automation.

JamieJamison: I think klog news is publicly accessible at myst's site.

bfrench: Yes - you'll find it at klognews.com.

RolandTanglao: klogsnews is defintely public; and it has an RSS feed which i've subscribed to for months.

bfrench: And the nice thing about it - it's all automated. We write very little on that site - the rest is automated.

JamieJamison: Adina, can you ask him if the integration connector is custom coded, or part of their platform?

bfrench: Most integration connectors are custom because almost every integration requirement is unique in some way. However, we have defined declarative scripts that ease the pain of connector development. For example we have a 'gear' scripting language with just a few commends, but it allows you to create integrations with the Google API and the MyST API without actually understanding either of these technologies.

alevin: interesting as a comment aggregation mechanism

bfrench: Yes, and the idea that comments are first-class objects is important too. It means that they are suitable as commonly subscribeable items like any other items.

alevin: seems like a complicated and special-purpose way of doing something that everyone needs

bfrench: Complicated until you realize how it's done and what the benefits are. ;-)

RolandTanglao: ross: i agree about wiki being better for book review but the RSS feed for chapters and being able to comment on paragraphs and have RSS feeds for comments sounds cool, don't think wikis do this?

bfrench: Wiki's are very good at a number of things. In the case of book authoring - there is one, maybe two authors. The Manuscript Review system engages at a point where the manuscript already exists and needs to be reviewed for technical and perhaps legal purposes. The MyST application satisfies the need to create an operationally efficient process. There are many processes like this through businesses.

JamieJamison: I agree. This might be something that could be done in a wiki, but the process-oriented nature addresses the overwrite and certain other problems.

bfrench: Indeed, but it all depends on the requirements. There are certain situations where not all reviewers should see all paragraphs or chapters. For that to be possible the application must present content (regardless of type - RSS or comments, or paragraphs) in a security context. Wiki's are not well suited for meeting rigid permissions or security contexts.

wkearney99: there's also annotea

bfrench: Yes - another good spin on a similar objective.

JamieJamison: I think wiki might be better for more collaborative writing than review and comment with the author maintaining some control over the text, no?

alevin: you can use wiki with various social conventions.

bfrench: Absolutely - very possible in many cases, but social conventions don't always meet the requirements set forth by IT. ;-)

MichaelP: wikis are user-hostile to most people.

bfrench: Today perhaps. But that will change as they mature.

bfrench: MySmartChannels (a simple demo application on the MyST platform) is also user-hostile IMHO. This is why we call MyST a Weblog Application Server - applications must be built for these new loosely-coupled technologies to find traction (no punn intended) in enterprises.

wkearney99: the good point here is using tech to aid flow in a programmatic way. that there's more than one way to do it.

bfrench: Agree - find the business requirements, then select the implementation approach.

stevenzenith: I think the speaker is overstating the immediacy of rss - the immediacy depends on the publisher and subscriber independent of rss.

bfrench: Perhaps I wasn't as clear as I could have been. Indeed there are dependencies. However the MyST platform serves up RSS dynamically making it possible for immediate awareness if clients so choose to accelerate the polling processes. Since we typically sell servers for specific purposes and business processes, bandwidth requirements have already been factored in.

JamieJamison: His ability to post from word, adina.
alevin: I think he just said standard but costs extra

bfrench: Sorry for the confusion. The process uses open standards (XML and SOAP), but we normally provide specific Word template integrations under consulting services. In the future this may not be an issue (advent of InfoPath).

MichaelP: weblogs are a form of content managment, but they are not workflow engines

bfrench: Absolutely true, and workflow states are critical ingredients in enterprise applications. Thi is why the MyST platform includes association objects. MyST is actually a state-machine that provides elemental objects that can move content resources from state to state.

bobwyman: Isn't he basically saying that since Office has COM and VBA, and the office applications expose their object models for automation, you can write whatever you want...

bfrench: In terms of integration with MyST or any Web services platform, yes.

MarkFletcher: Does Myst have any actual deployments of their tech that they can point to to illustrate how it's being used in companies today?

bfrench: Yes - please contact us at your convenience and we'll set up some demos of real deployments. The difficulty in doing so is related to the confidential nature of the content that our clients have in thier MyST servers. But we have some that are willing to let us take people on tours.

JamieJamison: But is Office Research Services an RSS-based technology?

bfrench: No - Office Research Services is a specific Microsoft Web Services API that supports XSLT for presentation panes and SOAP for communication. It does require a fair bit of knowledge about the integration API and how the Office platform works.

bfrench: What we've done is eliminate the need for developers to learn all of that - instead focusing on the content integration. If you have RSS or other XML-based content sources, we have the tools to integrate the content to the MyST platform and almost instantly make that content available in Microsoft Office through Office Research Tasks and Smart Tags.

bobwyman: So, since we've already got the object models for word, excel, email, etc. The really interesting question would be: What interfaces should we be exposing for the RSS stuff and services that office things might want to be integrated with?

bfrench: TrevorFSmith: Does Myst believe that google intranet boxes will soon ship with Blogger? If so, how do they plan to differentiate their product from that offering?

JamieJamison: So myst can make the ability to search RSS syndicated information from within office using hooks into the Research side. I think I have it now.

bfrench: Yes - you get it - but again; that's one of many things we do well. ;-)

MichaelP: you need authentication & authorization, status, unified nomenclature, etc...

bfrench: Yep.

RolandTanglao: Jamie: I think it's two ways, search RSS and search office docs without having to modify RSS feeds or office docs.

bfrench: Indeed, and not having to modify anything is a big requirement. It must seamlessly work without user intervention.

bfrench: Thanks everyone for taking the time to listen. Feel free to ping me anytime.

Although not scientific, here's a simple return on investment [ROI] analysis for one use case of RSS.

Imagine you're a marketing director for a large firm. Each morning you must log into the corporate portal and review information concerning your job. By virtue of very specific processes developed by your manager and the IT administrator of the portal, there are seven pages that will contain the information that you should be focusing on at least once a day - preferably three times a day.

Assume this task takes approximately 7 minutes total (or about 1 minute per page). Also assume the navigation steps require about 1.5 minutes of the total time spent; 1125 minutes per year. Assume also that it takes about 12 seconds to determine if a given page has changed. 7 pages, three times a day is another 4.2 minutes a day or 1050 minutes a year. Combined this represents about 2175 minutes per year spent navigating between pages wondering which are new – all necessary to get the information to do a job.

This fictional director of marketing spends a little over 36 hours a year navigating to these seven pages just to SEE if anything has changed. If we assume that [on average] three of the seven pages change only a few times a week, we can see a pattern of time usage in the following chart for User A whom endures a fixed cost of visiting all seven pages three times a day. Imagine an RSS-based solution where the newsreader is receiving only a list of the changes on certain pages and does so every hour. Not only have you eliminated the time you spend looking at a page to see if it has changed, you eliminate the navigation time and the need to navigate to the pages when they haven’t changed. This causes rapid acceleration of awareness of the subject matter for User B (an RSS adopter) while also eliminating more than 90% of time spent navigating and pondering.

For a single employee this seems insignificant. Furthermore, there are costs associated with acquiring the reader technology, engineering the feeds, and perhaps providing RSS training. However, in a 10,000 person company, it starts to add up (10,000 x 36 hours = 360,000 person hours of savings per year). At a very modest $20/hour office worker salary, you can buy a lot of technology for $7.2 million dollars. And this example includes one very small slice of the typical office worker's information diet. Factor in the portal visits to HR and the many other information sources that employees are expected to stay abreast of, and you have a recipe for widespread productivity enhancement.

Where's the money? It's hiding in all the pennies spent finding information instead of information finding you. ;-)

[ While I agree RSS is good, I believe RSS is not good enough to become mainstream. ]

This is like saying XML isn't ready for prime-time - 'prime-time' what? Many RSS opponents and advocates are missing the point of a standard or specification. It's a specification that may or may not be suitable for the implementation of a given objective. RSS is no different than XML (the most abstract XML grammar) except it is less abstract. Most people think of RSS in a very narrow set or use cases, so saying it's not good enough for mainstream adoption is somewhat misdirected.

An important perspective - challenging the effectiveness of a specification is not the same as challenging a technology or a product. If you believe there are problems with the specification, you need to state the issues in that context. I (for one) think there are lots of unresolved issues with news syndication technology, but it's not because of the specification.

[ 1) RSS feeds do not have a history.]

RSS feeds do have a history if the server that hosts them has the notion of history and if the reader that views them understands the same notion. Think outside the 'news reader' box and it's pretty easy to envision lots of models like this.

[ 2) RSS wastes bandwidth.]

It sure does. ;-) But this won't prevent an adoption curve to mainstream. Look at video, audio, and the many other wasteful things we do every day on the Internet. Many of these inefficient technologies are mainstream. Let's examine a team of people that each receive a 1mb Word document via email and then each mark up changes and then email them back to each other - now you have some big bandwidth issues. Imagine an RSS solution that points to one document that's versioned and managed with RSS to keep the group in sync. Imagine how much bandwidth is wasted each day when all the people on the planet read every Intranet and portal and newsletter Web page to glean what they need to know to do their jobs tomorrow. RSS will ultimately put a dent in bandwidth consumption, not increase it.

[ 3) Reading RSS requires too much work.]

It does [today]. In 1999 I did a search for RSS and found a few hundred hits. Today there are 12,000,000. Do you think the usability issues will stop (or slow) this trajectory? Of course not - see RSS: Hiding in Plain Sight

[ 4) An RSS Reader must come with Windows.]

An RSS reader WILL come with Windows [eventually]. Until then it's adoption curve will indeed suffer from a level of immaturity IF (and only if) you assume there is a single use-case for the spec. Why is it that everyone assumes RSS is designed to be consumed by machines that arbitrate directly (and only) with humans? There are hundreds of use-cases for content and knowledge syndication - many of which do not involve end users.

[ 5) RSS content is not User-Friendly.]

No XML content is user friendly. ;-) You have missed one of the most important points of semantic information - it's not supposed to assume a presentation style or use-case. If you want to impose a specific presentation format for a specific business requirement you are free to do so.

[ 6) RSS content is not machine-friendly.]

With the help of a 'machine', Robert Scoble is able to consume 1200+ feeds. Pretty amazing for a human, and certainly not possible without some help from a machine. Machine-friendly is a broad term; RSS happens to be more machine-friendly than many other formats. Search crawlers haven't learned how to deal with RSS [yet], and RSS (the spec) is simple, otherwise it would be called RCS (Really Complex Syndication). ;-)

[ 7) Many RSS Feeds show only an abridged version of the content.]

Indeed they do, and at the publisher's choice. Should anyone be forced to use any XML specification in a certain way? I don't think this is a fair argument against the implementation detail known as RSS. Imagine a use case where an RSS feed must create an awareness of content items that are 1gb each. However, due to bandwidth concerns the content publisher decides it would be best to not overload every desktop with every item's weight. Suggesting that RSS is problematic because publishers don't include all content is simply absurd - consistently applying that argument across ALL use cases doesn't make much sense to me. The MyST platform allows content producers to choose how their content is displayed - full text or headlines only.

[ 8) Comments are not integrated with RSS feeds.]

Many things are not integrated with RSS, but they can be (see name-space extensions). Suggesting that comments should be integrated with RSS is taking the position that every use case for RSS requires commenting - flawed logic and probably not defendable.

[ 9) Multiple Versions of RSS cause more confusion.]

Sure they do, but multiple versions of HTML do the same, and it had no trouble reaching 'mainstream'.

[ 10) RSS is Insecure.]

RSS isn't insecure - the server systems and delivery solutions for RSS are insecure. MyST is evidence this is a flawed argument.