Three improvements suggested:

1- Preferably search be given an extra parameter (or someway) indicating 'direction' - search 'forward' (below current cursor position) or 'backward' (above current cursor).

2- A search should be possible on any attribute/value of P/Sect etc and/or any of its children.

3- A search can also indicate if user wants to get only the first Range (ie 1st search result only) or all ranges (ie all search results). Word doesn't need to scan whole document if all user is looking for is next/previous one result only, which will result in faster turn-around.

All these are specially needed when the document is big like 30-50 or more pages.

According to the documentation ...
"Dialog boxes - Display custom UI in a dialog box that overlays the Office document. Use a dialog box for interactions that require focus and more real estate, and do not require a side-by-side interaction with the document." (Emphasis added)

There is some emphasis in the Office Add-in documentation regarding consistency of the add-in UI with the Word/Office experience, which i whole-heartedly agree with, but this dialog requirement is actually not consistent with the existing Word/Office user experience. Users regularly interact with dialog boxes.

It's probably a small point, but I want to write and extended Find-and-Replace-like extension for authors, that interacts with the document similar to that of the Find and Replace dialog in Word, but if if non-interacting dialog boxes is a requirement for any new add-ins (which seems odd to me), then my project is a non-starter.

As a potential small developer, it's discouraging, since writing the add-in as strictly a task-pane interface is actually contrary to the existing user experience and will be more jarring for the user not less.

In short, please remove such a restriction.

Peter

I'm currently developing a Word add-in and would like to be able to access commentsExtended.xml from the API so that I can gather when a comment is a reply or has been resolved.

As of now, I have to use a 3rd party library to read the docx file to get to the XML. When the document is encrypted, this is not an option and must inform users that replies and resolutions are not available if the document is encrypted (password protected).

If this XML (and perhaps all XML content under /word) could be exposed via getooxml(), this would be great.

Thanks,
Kelvin

Currently we can use Office.getFileAsync api to get the file in slices using getSliceAsync. Then we can construct it into a file, or a blob.

This API seems to very slow when it comes to performance.
In the Desktop app, it is fast, takes less than a second mostly.

But in Word online, it takes easily 4-5 seconds even for an empty document. And in our testing for files with more content it took 10-20 seconds.
So to improve performance, i was trying to request all slices at once, instead of waiting for first one to be returned and then requesting next and soo on. But turns out, only the first slice will be returned, if we request multiple slices at once.
Again this works fine in desktop, where the performance is already good enough.

Can the performance of this API be improved?
If anyone was able to find a way to improve the performance of this API in word online, please let me know!

Just read "Build your first Word task pane add-in". I'd like to suggest that before you start giving developers examples of what one can do with Yeoman and Javascript, that you actually analyze what people use Word for right now.

For the desktop version of Word, where most power users live, applying a style then changing the font is a ludicrous example of automating Word. This is also true of any advanced automation in Excel, too. That you think javascript as it is now being promoted can compete with the power of .net, or better still, vba, is cute. But it's also dangerous for those of us trying to make Word or Excel more powerful rather than just different. A task pane is a great UI element, but not if it does something stupid like applying a style or changing a font.

And if you're thinking you'll just move everyone onto an on-line version of Office 365, you'll be shooting yourselves in the corporate foot.