Visualize Document Details in Document Folder Navigator

Hello Mathias,

I selected to Imbed the Details page.  I’m guessing somewhat as to what imbedding the Details page would look like.  Ideally, I think I’d like to be able to select a document and then have its details available on a page (a new tab?).  I’m interested in speed and the first option appears that it will be a little slower and present some unusual functionality.  The 3rd option would end up being another screen to deal with, another thing to train on, and another thing to explain not to mention the extra work in maintaining and programming it.  Without examples, that’s what I decided.

Can I change my vote to option 1?

Any chance of seeing a mock-up of what you’re describing?

Open the Document Folder Navigator, then open the Document Revision page in a new web browser window. Then imagine the latter totally replacing the right hand side of the former 🙃 That's how it should look. Really.

The cold start problem consists of two sides: one is that it's a big page, and like other big pages it takes a few seconds for the client framework/runtime to render it, based on the metadata it reads from the server. But then there's another problem related to being able to connect a document to a large number of objects. For each object type, the client loads some metadata, at runtime. It's primarily a problem on the server as I understand it, and not easily solved. I think it needs to be solved though. But, it's also not as big of a problem as we think internally. It's enough that one user loads the page after the server has started, then it will be relatively quick for the rest…

A document revision page is a valuable tool in many contexts, such as project management, content creation, collaborative writing, and quality control. Here are some reasons why a document revision page can be considered the best:

• A revision page provides a chronological record of changes made to a document over time. This makes it easy to track who made what changes and when, which is crucial for accountability and transparency.
• By maintaining a revision history, you can identify and rectify errors, inconsistencies, or inaccuracies that may have been introduced during the editing process. This contributes to the overall quality of the final document.
• A revision page serves as a historical reference point, allowing you to revert to earlier versions of a document if needed. This can be particularly important if you need to recover lost information or revert to a previous state.
• When multiple people are collaborating on a document, a revision page reduces confusion and the potential for conflicts by providing a clear overview of changes. This can streamline communication and decision-making processes.
• A revision page serves as an official record of changes made to a document, which can be important for auditing purposes, reporting, and archiving.

Not sure if that was arguments for option 1, but no doubt a Document Revision page (at least a good one, and I think the one in IFS is such) has all of those characteristics/feature/possibilities.
But, in the context of the Document Folder navigator I think we also have to put usability in as a parameter (nudge Mathias response :D).

And as long as we can navigate to the Document Revision page we get the best of both worlds, so I think I stick to option 3 :).

/Erik

I like the idea of embedding one of the existing pages rather than creating a 3rd version.

Since putting documents into different folders is an administrator activity (?) make it the admin version of the page i.e. Document Revision

right… so i was wondering do we need 2 doc folder navigators, an admin one and a browser one?

Can you please clarify this a bit more?

• Visualize documents within the folders directly within a document folder node.
• Visualize the document details in the Document Folder Navigator page.
• Drag and drop documents between document folder nodes in a structure.

Ad 1

Will you show a list of all documents inside the folder tree in new node? Will it be possible to collapse this node or have an option not to show this document node in the navigator?

Ad 2

Will you create a new tab to show document metadata for the selected document in the Document tab?

Ad 3

Will you make it possible to move the documents from one folder node to another folder node with drag and drop?

What we really need is a possibility to collapse the Document/All Documents block to easily use the Attachment panel.

Example:

If you have few documents, it is not a big problem, but when you have over 100 documents connected, it makes it less viewable and can be confusing.

Thanks for your answer.

So if a folder has both child folders and documents connected you cannot only see the folders?

We really don’t want to see the documents in the folder tree.

We have big folder structures and it can be over 100 documents connected to a folder in the structure.

We don’t want to see documents in the Folder tree.

We have large folder structures and some nodes kan have over 100 documents connected.

We want the folder tree structure to be clean and clear and not disturbed by documents that make it unclear.

Ok, thanks for the examples.

It looks good that you can avoid seeing the documents in the folder tree structure. Your first answer when I asked if we could collapse - I misunderstood.

So ok 😊