Skip to main content
Discussion Topic
User avatar

Guidebook data is XML, but can I store and access it locally?

In consideration of Dozuki for a medium sized electronics manufacturer, the major concern of interested parties is the fact that the content - ie the documents - is stored remotely and not necessarily exportable or editable unless via Dozuki. Should Dozuki or any supporting infrastructure suffer a major failure, the system and content is lost to us.

Is my understanding of this correct, or is there a way to store the documents locally and to edit and create final PDF files without the exclusive use of Dozuki's web based system?

To rephrase: How could we carry on maintaining documents if a major natural event wiped out connectivity to Dozuki?

In a similar vein, concern has been expressed over the loss of content if a third party purchased and closed or significantly increase subscription costs.

Hoping these concerns can be allayed?

Edit: So I have now read about oManual and the open XML standard used by Dozuki. My question now then is how exactly open is this - can I download the oManual format for each of my guides and edit and maintain using some system other than Dozuki?

Reply to discussion Subscribe to discussion

Is this a worthwhile discussion?

Score 5
Add a comment

1 Reply

Most Helpful Answer
User avatar

Great questions. I've got a few answers for you.

Is there a way to store the documents locally and to edit and create final PDF files without the exclusive use of Dozuki's web based system?

You can export all of your manuals as PDFs. But PDF is a view only format, and it would be great to be able to edit and author new manuals outside of Dozuki. We developed the oManual file format to solve this problem.

Can I download the oManual format for each of my guides and edit and maintain using some system other than Dozuki?

You can use any XML editing tool out there to edit oManual—there are a good number of options, including XMetaL and Oxygen.

Relative to other XML standards, oManual is new, and there aren't many options for working with it natively yet. We expect that to change as adoption increases. We're working with IEEE to get oManual adopted as an industry wide standard for documentation.

The only apps available for oManual right now are our open source iOS and Android apps, and they're currently consumption-only (using the upcoming JSON version of oManual).

In the meantime, we are testing an XSLT conversion from oManual to DITA (using the Task topic, if you're a DITA geek), which will then allow export to any format DITA provides. (Which is just about everything, because if there's one thing DITA is good at, it's feature creep.)

In summary, here's the workflow:

  • oManual XML -> DITA XML -> PDF / HTML / Anything else your heart desires.

In a similar vein, concern has been expressed over the loss of content if a third party purchased and closed or significantly increase subscription costs.

You're absolutely spot-on to be concerned about that. The industry is full of companies who had a great service, got bought, and screwed their customers. The best assurance I can provide you is this: we've never taken venture capital or outside funding, and we have no intention of doing so.

We're completely self-funded, and we've been profitable for the last nine years. Our goal is to make modern manual publishing tools available to companies of all sizes, and we're going to have to keep our prices as low as they are to make that happen.

I plan to be running iFixit and Dozuki for another couple decades. I'm having too much fun to imagine doing anything else.

Here's another question I can imagine you're thinking:

Given the drawbacks above, why is Dozuki software-as-a-service?

  • Development speed — We deploy bug fixes to all of our customers on a daily basis, and new features almost weekly. We're able to react in real-time to security issues.
  • Economy of scale — The same system administrators that keep the world's largest repair manual fast and responsive are also maintaining your site.
  • Durability — We're able to deploy across many data centers. In fact, we have real time instances of our database in at least two separate data centers at all times. That level of redundancy is rare in most corporate IT environments. If you want more information, we're happy to provide you with our disaster preparedness plan.
  • These advantages and more are the driving factors that have caused many modern services to move to a service-based model. The monthly recurring revenue model also makes it more financially viable for smaller companies like us to cash-flow expensive investments in software development.

Let me also mention our data security and reliability. All of our servers are distributed throughout Amazon Web Service's secure infrastructure. Here's a quote from our security overview:

  • "Physical access to the servers is strictly controlled by a military-grade perimeter, professional security staff, intrusion detection systems, and video surveillance. Staff must pass two-factor authentication no fewer than three times to access the data center floor. All visitors and contractors are required to present identification while signing in, and are continually escorted by authorized staff."
  • "Our data is backed up several times per day, written to more than one server instantly, and stored in multiple locations."

I hope that allays your concerns. I'm happy to answer anything else you can throw at me! Or give us a call at +1-646-397-3624! We'd love to talk to you.

Was this reply helpful?

Score 5
Add a comment

Join the discussion

Author avatar Sam Kivi will be eternally grateful.
TRUSTe