KnowledgeTree Office Add-in Dogfood Goodness

Daniel Chalef's picture

For the last few weeks we've been dogfooding the first product built using KnowledgeTree's next generation of client technology, the KnowledgeTree Add-in for Microsoft Office. Tohir and Donald have already written about some of the building blocks behind the new technology and so I thought I'd put together a quick video tour of the KnowledgeTree Office Add-in from a user perspective.

We already have great extensions for Microsoft Office, but this new version is by far the cleanest integration we have yet built. As Tohir mentioned, we'll be leveraging this new user interface technology (codenamed "Smurf") throughout our product line, including on the server's web user interface and in a cross-platform (Windows, Mac, Linux) Adobe AIR "Explorer" client application.

The Office Add-in as demonstrated currently does a great job of the basics of accessing KnowledgeTree from within Microsoft Office applications: retrieve and store versions of documents from the KnowledgeTree document management repository while not having to change how you work when using Microsoft Office. Our aim is however to provide significantly more richness than just this:

  • We'll be providing access to the KnowledgeTree server's collaboration features (email, discussions etc) from within the Office Add-in.
  • Leveraging KnowledgeTree's new "Document Processing Engine" the KnowledgeTree Office Add-in will know the context of a document you've opened from your local file system: is it the latest version? what folder does it belong in? etc

Our goal is to provide richer document management capabilities than the native Microsoft SharePoint interfaces built into Microsoft Office applications, all sitting in front of a light-weight, open source, cross-platform server.

Of particular interest to our open source community is the new set of SOAP and REST APIs that make this all possible, and the maturing of the existing KTAPI layer to version 1.0. More on this from the engineering team once we near release.

Expect a beta of this new product over the next few weeks.

Office tools suggestion

You should make a configuration option so that when you search using the sidebar office integration that it brings back all results, not just MS Word docs when using the search from MS Word, etc. That way users can just use the office tools without needing the KT Explorer. Also, is it recommended or not recommended to install just KT Explorer from the KT Tools 3.5.4a (not the Office plugins) and then install the KT Office Tools Beta? I definitely like the newer Office tools' sidebar better than the older interface.

Best,
Dave

Re: Office tools suggestion

Dave,

Yes, I agree regarding returning other document types via the search. This feature was disabled in the first edition because we experienced a number of issues trying to launch other applications from within Office. We are trying to work around these issues and will likely re-enable the feature in a future version.

Yes, you may install both KnowledgeTree Explorer (without the Office Addin) and the new Office Add-in. BTW, the new Add-in is now out of BETA and you may download version 1.0 from our web site.

Glad to hear you like the new interface. Please keep the feedback coming!

Philip

What about OpenOffice?

I am currently looking at a document management solution but am wanting to standardize on Open Office and NOT Microsoft Office. There are many reasons for this, but primarily we do have a number of Linux desktop users and Open Office works on Windows, Linux, and Mac. I don't want to be "locked" into Microsoft's bloated applications.

Do you have such integration with OpenOffice? If not then is this planned? When?

Custom properties in MS Word updated by KT

I was happy too see that the KT panel works much like the KT web interface when checking in documents. I.e. it should be possible to enforce "Required" fields (unlike the KT Explorer, which allows checkin with empty fields).

Also important is the use of Apache POI. It should make it easy to implement support in KT for an important use case: showing the Document ID and Document Version in the header of an MS Word document. Then printed versions of the document can be traced to the source. KT should of course update the information automatically at checkin. It could be done by KT setting "custom properties" in the MS Word file. The headers, footers, title page, etc. could contain "fields" (placed there by the author) that are expanded by MS Word when viewing the document, e.g. " { DOCPROPERTY KT-document-id \* MERGEFORMAT }" would be expanded by MS Word to "1234". (See KTS-2276 in the issue navigator).

I'm looking forward to trying the new functionality!

Custom properties in MS Word updated by KT

Andreas, KnowledgeTree Explorer should enforce required fields - is this not the case?

Yes, we may well use POI to write KnowledgeTree metadata to Office documents. Although, our priority at the moment is to write a GUID to documents, which we can use to regain context at any time.

Philip

Required fields

> ...KnowledgeTree Explorer should enforce required fields - is this not the case?

Nope. I tried this on KTools 3.4.2 (old, latest is 3.5.4). Drag-and-drop a file into a Knowledgetree Explorer folder. It opens a dialogue for metadata, but unlike the web interface, I can leave everything blank.

The important point for me is that the Office add-in interface in your video displays a field for document title. It is important that user's don't just leave the file name as a title, because file names are often cryptic, and meaningless titles will decrease the value of the document management system. I hope that required fields are enforced here as well...

One more thought about titles: in the Web interface the default title is the filename, minus extension and with "_" replaced with " ". If there is an Office "title" property set, maybe that should be the default? But, then again, we all know that many documents are copied, and the title property has an irrelevant value.

Required fields

Andreas,
Required fields are supported in the 3.5 family of KnowledgeTree Tools and they are enforced in the new Office Add-in as well.

>The important point for me is that the Office add-in interface in your video displays a field for document title. It is important that >user's don't just leave the file name as a title, because file names are often cryptic, and meaningless titles will decrease the value of >the document management system.

Yes, I agree. We pre-populate the field in an effort to make the process of adding new documents more efficient. The final implementation requires that the text be highlighted and in focus, so that as soon as you press any key, the suggested title is overwritten. I felt that this would encourage users to enter a new title, while still suggesting the filename, to save time. Would you rather the field was blank?

>One more thought about titles: in the Web interface the default title is the filename, minus extension and with "_" replaced with " ". >If there is an Office "title" property set, maybe that should be the default? But, then again, we all know that many documents are >copied, and the title property has an irrelevant value.

I suspect that using the Office title might not work too well, as a number of companies do not rely on Office metadata for storing information. As you mentioned, it could contain irrelevant information. This may be something that we could look at making a configurable option for.

Thanks for sharing your ideas with us.

Philip

Required fields

Brilliant! I agree with all you say, including the requirement to highlight the pre-populated title field. It sounds like you gave it a lot of thought already.

Any chance you can leverage

Any chance you can leverage the current webdav interface to do something similar to what Confluence does with being able to edit pages or in ktdms's case documents directly and save them back directly. Combined with drag and drop into the browser or at least a better upload, and the new tools you describe above, it would mean less need for the existing kctool functionality.

Any chance you can leverage

Nicholas, we may well do so in future but for now we're relying on our web services interface and temporarily storing the documents on the local file system. The current version of KnowledgeTree Tools is heavily based on WebDAV and we met with significant challenge trying to extend the protocol, to provide the richness of functionality available in KnowledgeTree.

That said, perhaps a mixed WebDAV/REST-based architecture would be the best solution. We'll definitely put some thought into it.

Philip

2003 Office Tools

Daniel,

With the new version of KT, will the older Office Tools still work if a user wanted to install them considering they may still be using Office 2003? In other words, if they install the latest commercial version of KT, can they use the older Office Tools so they can interface with Word 2003?

Jerry

Office 2003 Tools

Jerry,

If we don't get the new Office Add-in 3 working to our satisfaction in Office 2003 we'll likely continue to maintain current Office Add-in (i.e. releasing bug fixes) for a period of time, most likely not less than a year. We haven't discussed this plan in detail and so I can't yet give a definitive answer.

Daniel

You mention that this UI

You mention that this UI technology will be added to the web interface as well. Is there a certain expected timeframe/estimate for this project?

Timeframe for new UI

Aart-Jan, we're loathe to set GA dates for software that we haven't yet got underway with. Most of the new web app UI will be developed for the client tools first (the Office Add-in, KnowledgeTree Explorer 2 AIR, etc). We're likely to feel more comfortable talking about release dates once we've got the KnowledgeTree Explorer 2 out of the way. I can't imagine us releasing the new web app UI before the end of Q1 2009.

Daniel

but are this kind of office

but are this kind of office interfaces going to be available for the open-source version? when? a very nice feature would be creating a brand new document (with alla metadata) from inside an open word file. This extension looks already great, anyway.

Office Add-in for Community Edition

Vincenzo, it's likely that in the short-term, this functionality will only be available to commercial subscribers. The Office Add-in does allow you to create an entirely new document in the repository from within Word.

Daniel

KnowledgeTree Office Add-in

This certainly looks like a great leap forward. Is it backwards compatible to MS Office 2003?

Office 2003 Support

Colin, we're investigating the feasibility of Office 2003 support. Unfortunately Microsoft changed the architecture of the Office product quite dramatically between Office 2003 and Office 2007 (for the better!) and despite attempting to architect our way around this, we may still have to limit support for Office 2003.

Daniel

Drag and Drop in the Web Interface

Hi Nicholas,

Thanks for the Zimbra heads up. We're considering something similar. Watch this space!

Daniel

New functionality

KT has been falling behind a bit on the client UI side, and this new stuff looks interesting. A better kctool would be good. "Drag and Drop" in the browser would be great - checkout the DnD zimlet for Zimbra.