Posted by Barry Bealer on Wed, Feb 22, 2012 @ 07:33 PM
Last week's O'Reilly Tools of Change (TOC) event in New York had a theme of Change/Forward/Fast. Based on the keynote presentations, I think the publishing industry heard loud and clear that they need to change....and now! However, the other underlying theme for the conference was also articulated by the hosts as "we are confused." Needless to say, these two themes are in conflict with one another. How can you change if you are confused? Confusion generally leads to paralysis and that is what I have seen with publishers over the past few years.
While publishers heard success stories about building audiences before publishing a title and on-going interactions with that audience, what was suspiciously absent was how publishers are delivering content to the various devices. Maybe it was the wrong venue, but I suspect many of the success stories started once content was in a sellable format rather than how easily the content was created and published in their content management system.
I also suspect that many in the audience were from the business side of publishing and the TOC event makes them pause and think about their business. TOC did not, for me anyway, tackle the more difficult challanges of multi-channel publishing using home grown or antiquated technology. Sadly, that is what many publishers are wrestling with today. Once they are able to get content in ebook format, they can do really cool stuff with it. Until publishers address the content management side of the equation, I don't see how they will efficiently meet time-to-market demands. The reality is that most ebooks today are created by publishing services vendors because they are converting various flavors of legacy files. Most publishers today are not multi-channel publishing but sticking with the print paradigm and then, through various publishing services vendors, creating ebooks for distribution. Publishers who are stuck with this publishing process need to "change/forward/fast."
I will say that overall the TOC conference appears to be rejuvinated. Two years ago the conference seemed to have run its course, but I believe it is back to being an event that publishers will want to attend to learn how the newbies are doing it without the "burden" of print. Pushing the envelope is what TOC is best at and I hope they continue to push the industry's thinking along the way.
Posted by Marianne Calihanna on Wed, Jun 01, 2011 @ 02:47 PM
<update>June 7, 2011</update>
Since announcing the release of the EPUB 3 specification, the blogosphere and tweet streams have been alive with the sound of music to publishers' ears. No doubt Amazon's news that it will finally accept EPUB also adds to the collective hallelujah chorus.
While there is already an abundance of information, news, and opinions on EPUB 3, this post aims to highlight what features and functionality are most important for publishers to understand:
- Improved accessibility support---It's a big deal that DAISY is converging completely with EPUB 3. This will promote rapid take-up of the standard in education and government segments.
- MathML support---this alone garnered hoots and hollers from RSuite's tech team. No longer must STM publishers sketch out equations as art.
- Embedded fonts---the look and feel of your PDF is maintained because publishers can deliver fonts along with the epub file.
- Improved SVG support---vector graphics mean images scale with your pages and pages are "lighter" thus loading faster.
- New and improved metadata---who doesn't love publication metadata that can include specific handling and distribution instructions!?
- Video and audio support---publishers can synchronize audio with text. This will also raise the bar for all of us, e.g. enabling switching seamlessly between listening in the car and reading at home!
- Javascript---scripting offers chances for interactivity, think forms, etc.
- Layout---multiple columns, hello! Ladders and widows and orphans, goodbye!
We'd love to add your opinions on new functionality to the list. Leave a comment and I'll continue to add on to the bullets.
Posted by Sarah Silveri on Fri, May 20, 2011 @ 08:00 AM
RSuite is exhibiting at booth #34 from June 1st through the 3rd at The Society for Scholarly Publishing (#SSP)!
Schedule your time with us today and see how publishers have done the following things with RSuite:
- reduced book production time-to-market by 8 weeks
- automated aggregation and distribution of journal articles to licensing clients
- Increased website traffic by more than 35%
- and much more
Tweet about us at #SSP using the #RSuite hashtag.
Posted by Sarah Silveri on Mon, May 02, 2011 @ 07:00 AM
Book Expo America is coming up in just a few weeks and we’re so excited to be part of it. RSuite Cloud will be representing Really Strategies, Inc.
At Book Expo America, Book publishers can see RSuite Cloud and understand how it is helping some of the leading publishers:
- Increase revenues with faster time-to-market
- Produce pages in minutes not weeks
- Simultaneously output to print, web, ipad, and more
- Automatically Convert Word files to XML
- Translate and publish to more than 200 languages
People from all around the world within the publishing industry will be there and we want to see you between May 24th and May 26th. We’ll be in the IDPF Digital Zone at Kiosk #2309. Schedule your time with us today!
Tweet about us at #BookExpo using the #RSuiteCloud hashtag.
Posted by Marianne Calihanna on Tue, Apr 26, 2011 @ 09:10 AM
Really Strategies is pleased to add The American Institute of Physics to its growing list of STM and journal publishers who are using RSuite to manage content.
"The American Institute of Physics selected RSuite to manage and store its vast amount of content, including metadata, full-text XML, PDFs, images, and multimedia assets,” stated Evan Owens, AIP’s Chief Information Officer, Publishing. “We see RSuite as a key technology that will allow us to implement industrial strength content management, including version control and automated content distribution, to best support our digital publishing program."
Click here to read the official press release.
Posted by Marianne Calihanna on Wed, Apr 20, 2011 @ 04:10 PM
According to the Association of American Publishers (AAP) ebooks ranked as #1 format among all trade categories for the month of February. The stats track monthly and year-to-date publishers’ net sales revenue in all categories of commercial, education, professional and scholarly books and journals.
A couple potent highlights from the AAP report:
- February 2011, e-Books ranked as the #1 format (Adult Hardcover, Adult Paperback, Adult Mass Market, Children’s/Young Adult Hardcover, Children’s/Young Adult Paperback).
- January/February 2011 compared with January/February 2010---e-Books grew 169.4% to $164.1M
[Read more here]
If you're not generating ebooks, start. If you are generating ebooks, take a look at your back list and bring it forward.
Have any interesting metrics that you can share?
Posted by Marianne Calihanna on Wed, Mar 30, 2011 @ 08:17 AM
Address the top 3 digital publishing challenges with XML. Most content producers no longer rely on a single channel for content distribution. To efficiently and competitively expand digital offerings, publishers are looking to re-use existing content to create new products. Whether creating new content “mash-ups” out of existing content repositories or ensuring consistency between publications that share information, content re-use is a powerful capability allowing content to achieve its maximum value. XML provides an anchor for coping with a diverse and expanding number of channels.
Download our latest white paper, "Make XML a Solution Instead of a Challenge."
Posted by Lisa Bos on Fri, Mar 25, 2011 @ 01:42 PM
The success of a CMS implementation is ultimately determined by thousands of individual choices made every day by team members - developers, PMs, analysts, and so on. Many of these choices are based on design principles with which business managers might strongly disagree but of which they are often unaware. Occasionally one of these decisions has inordinate impact - a complexity of design that results in a complexity of implementation, testing, and maintenance that is radically inappropriate relative to the value of the feature in question.
Managers who aren't deeply engaged with their teams tend to over-simplify such discussions by saying things like, "So-and-so engineer always makes things more complicated than they need to be." It's true some engineers are hard to manage (and that some managers start almost every new project with unrealistic expectations, and that some users won't give up complicated requirements). But I believe this difference in philosophy is also in play, and a PM or other manager would do well to understand and talk about how a team's varying philosophies impact its members' choices, and where change might be in order.
An interesting article on this topic by Eliot Kimber is here.
Such discussions might seem esoteric, but they absolutely are not.
Posted by Christopher Hill on Tue, Mar 22, 2011 @ 11:56 AM
In my
previous blog post I introduced XML in 5 minutes. As a follow up, here's another 5 minute lesson to understand what an XML Schema or DTD is and what it might mean to end users of XML-based systems.
In the previous post we created an XML document to describe a book. Recall that it used tags around the actual content to describe the content.
<book>
<title>Alice's Adventures In Wonderland</title>
<author>Lewis Carroll</author>
<summary>This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.</summary>
</book>
We also learned how representing content in this way allows us to dramatically reduce the effort required to support multichannel publishing. It also helps a great deal with automation and moving content between systems or organizations as it eliminates some of the issues of file formatting.
What would happen to our stylesheet if someone decided to use different tags to label their content?
<book>
<title>Alice's Adventures in Wonderland</title>
<writer>Lewis Carroll</writer>
<summary>This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.</summary>
</book>
What we called author in one document we called writer in another. This inconsistency might be small now, but if we didn't restrict what people named things in our XML we would have to support a potentially endless list of tags. In the
previous article we wrote rules for how to make our books look good on a page. If we can't predict what tags (labels) people are going to use - such as author - then it becomes nearly impossible to reliably write rules.
So even though XML helps us get a consistent base format for content, we need more help to get predictability and consistency.
Enter the concept of a DTD or Schema. DTDs and Schemas are ways that systems can impose rules on the XML itself. You can describe what tags can be used, where they can be used, and put restrictions on the content of those tags. There are two different standards for describing these restrictions: Document Type Definition (DTD) and XML Schemas. We won't get into the syntax or pros and cons of the two approaches. For our 5 minute lesson we can just assume they both are ways to enforce consistent labeling of our tags in our XML documents.
Here in English is how we might communicate the requirements for our flavor of XML:
- Put everything inside a book tag. You can only have one of these.
- The first thing you put in a book is a title tag containing the title text. You cannot leave this out.
- The second thing you put in a book is an author tag containing the author name. You must have at least one author. If there are more, you can repeatedly add more tagged authors.
- After all the tagged authors, you can add a summary tag. This is optional - leave it out if you want. But you can have at most 1 summary.
This is essentially what a DTD or XML Schema does, although they do this in a language friendlier to computers.
You can think of XML Schemas or DTDs as a means to create a template that all valid documents must follow
These rules can now be applied to the two examples above. The first example follows the rules, so we would say that the first XML document is valid. That means it conforms to the rules. The second document, when tested with the above rules, would be invalid. The presence of tagged content labeled "writer" is not allowed by the rules.
In the XML world, XML Schemas or DTDs are used in a lot of scenarios, including:
- XML editors know what is allowed by the rules and prevent writers from making mistakes
- XML programs test incoming content and indicate when the rules are being broken, preventing formatting errors
- XML stylesheets can be much more easily written as they only process valid content and don't have to worry about rulebreakers
- If I want to merge my book content with yours, we can look at the rules and decide what adjustments will need to be made to bring our rules together
- Industries can agree on the rules for types of content. So we might create a set of rules to represent newspaper articles, adopt it as an industry standard, enabling anyone to easily exchange newspaper articles without having to modify the content.
So when you hear someone rambling on about an XML Schema or DTD, they are really just talking about the rules governing how the particular XML document is to be structured.
That's XML Schemas and DTDs in 5 minutes. In the coming weeks watch the blog for more quick lessons on XML-related technologies.
Posted by Christopher Hill on Tue, Mar 15, 2011 @ 07:24 PM
As product manager for an XML-based CMS, often I find myself answering the question "What is XML?" Not necessarily a simple thing to answer in passing - entire books and courses are dedicated to the subject - but in about 5 minutes most content creators can at least understand at a basic level what XML is all about. Here is my 5 minute XML class to give a first pass at answering this question. At the end most people should have a rough idea of what XML is and can start thinking about its potential.
Take a look at the following text:
Alice's Adventures In Wonderland
by Lewis Carroll
This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.
Reading it, you probably can infer that the underlined text is a book title. The italicized text appears to be the author of the book (if you dropped the word "by"). Then there is additional text. If you are familiar with the book, you can tell that the text is not part of the book itself, but appears to be a short summary. We know all of this because of certain conventions we have been taught as well as contextual clues provided by the words themselves.
Let's look at the same text again:
Lewis Carroll
Alice's Adventures In Wonderland
This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.
Even though the text looks quite different, we probably could still successfully interpret the author's intent. Now, imagine you have to train a robot to understand these two cases. What rules might you create to "teach" the robot how to decide how to successfully parse these two text examples and understand what parts of the text are titles, author names, and summaries? Even for these two limited cases, the list of rules is going to be quite involved, and will include rules based on formatting, language, and convention. And a robot will have to know that somewhere in the text are the three pieces of content, otherwise it probably has little chance of determining the nature of what it is looking at (Darwin the Jeopardy-playing supercomputer excluded).
Even if all that was true, errors are likely to creep in. Do your rules allow the robot to understand that "by" is really a formatting cue indicating the following text is an author name? What about the meaning of an underline? Bold? Italics? Each example uses the same formatting cues but in different ways.
When you write a document in a word processor or a desktop publishing program you mostly focus on how that text looks. Imagine after all that careful work making the text look right for your printer, you decide your content should appear on a Web site. Suddenly all that formatting needs to be re-worked to take advantage of the conventions of the Web. Now if you want to deliver to an electronic reader or a mobile phone your formatting may again need to be revisited.
This is an expensive proposition when you start imagining all of the possible delivery channels that may require formatting changes. For many channels, all that formatting work needs to be scrapped and done again.
The answer to this is XML: the extensible markup language. A short way to summarize the promise of XML is that it allows authors to indicate what the content is rather than how the content looks. XML does this using tags, essentially text-based labels that indicate what a particular piece of data might be. Here is the same example as XML. Even though you may not know anything about XML, you can make sense of this content.
<book>
<title>Alice's Adventures In Wonderland</title>
<author>Lewis Carroll</author>
<summary>This book tells the story of an English girl, Alice, who drops down a rabbit hole and meets a colorful cast of characters in a fantastical world called Wonderland.</summary>
</book>
Yes, angle brackets seem a little cold, but notice how they are labels making the meaning of the various pieces of text completely unambiguous. Notice how each tag (i.e. <book>) has a match (i.e. </book>). These pairs create a container. Everything appearing between matching tags is considered contained by them.
Now, imagine you want to deliver the content to a printed page, web site or mobile device. It is much easier now to write a set of rules that indicate how each should be formatted.
Rule for <book>:
start a new page
Rule for <title>:
one the first line, output the text as underlined,16 point Helvetica
Rule for <author>:
start a new line, output the text in italic, 12 point Helvetica
Rule for <summary>:
double-space, start a new line, output the text in 12 point Helvetica
These rules could be called a stylesheet. In reality, stylesheets are written in a more machine-friendly format that are beyond the scope of a 5 minute XML course, but this example should suffice to give you an idea of what a stylesheet's role in creating presentable XML content is.
If I had hundreds, thousands or millions of book content items I could use this single stylesheet to output them all and be guaranteed consistency.
If I decide I want to switch to a new look for my content, maybe using Garamond instead of Helvetica, then I just need to modify the stylesheet. Notice how the original book content exists completely independently of the formatting. And notice that changing the look of something doesn't require any editing of the original content.
Suppose I want to deliver my content to multiple channels. Each channel has its own conventions, limitations, and capabilities. People expect different formatting on a mobile phone than on their desktop computer. A web site typically looks different than the printed page. We used to underline book titles in print - but underline means something else on the web so often a different format is used. Helvetica may not even be an available font for many channels.
Fortunately, XML makes supporting each unique channel straightforward. Instead of endlessly modifying my content, I simply develop new rules (a new stylesheet, or a variation of an existing stylesheet) for a new channel. The authoring process is unaffected. Existing content does not need to be re-edited to support the new channel. Instead, the new rules are applied to the content generating channel-appropriate output. And as the number of channels expand, XML serves as a content anchor point so that you can adapt content rapidly and in an automated way to the unique requirements of each channel.
If all of your content were clearly labeled by what it is, it is not nearly as daunting to support new output formats for new opportunities. Instead to a massive conversion of all your formatted content from one format to another, you just have to develop a new set of rules and you are ready to go.
That's XML in 5 minutes. At least as it impacts content creation and delivery. In the coming weeks I'll be posting additional quick lessons on XML-related technologies.