search

eikek / docspell

Assist in organizing your piles of documents, resulting from scanners, e-mails and other sources with miminal effort.
https://docspell.org
GNU Affero General Public License v3.0
1.66k stars 128 forks source link

FR: UI issues (size of preview and process log) #363

Closed totti4ever closed 3 years ago

totti4ever commented 4 years ago

  1. Size of document preview I'm wondering how that is derived. What I would understand is having the preview window as big as the screen or as big as a typical document. But right now it is bigger (higher) than the screen, which means that scrolling feels somehow unfamiliar: first I scroll down in the main page until the preview windows starts at the top of the screen. And then I switch over to the preview pane itself for further scrolling in the document. Another problem with the preview being bigger than the screen: The tools for setting the size of the preview are at the bottom of that pane, so I have to scroll to the bottom of the preview to make the document smaller/bigger. Suggestion: Make preview pane slighty smaller (to be able to still scroll on touch interfaces, plus to make it visible that we are not fullscreen) than the screen and set the preview size to fit window (is that possible?). Btw I am only using the native preview as the other is not really sharp.

  2. The process log looks like it is a modal window as it fills the screen when scrolled to the top - which is good from my point of view. Also that one can still scroll down to have a look at the queue while it shows the currently processed item is good (have not tried the UI with several JOEX workers though). Just, oneI want to check why one of the failed documents on the righthand side failed, it gets weird: I click on the log icon and nothing happens...because I have to scroll all the way up to the top to see the log. Suggestion: When clicking on a log icon actually provide a modal window, which pops up right where I am - and after closing that I am back whereI was before.

eikek commented 4 years ago
  1. It is as wide as the screen and the height adjusts accordingly. So if you have a screen width>height you need usually to scroll for typical paper formats in portrait mode. If you file is in landscape it would then look better usually or if you rotate your screen. The view-tools are at the bottom for the viewer-js enabled preview (which is only there as a fallback on mobile browsers). It looks way better (on firefox and chromium) when using the "native" view mode. I think that especially firefox has a very good preview. Another improvement to this is imho to move the notes window at the bottom. Scrolling is indeed a problem here, and I don't know how to solve it; I think it's good to use available screen for the document. So you mean to reduce the width of the preview a bit? I'm going to play with that, thanks!
  2. Yeah, I'm thinking to completely redesign that page. It is also quite inefficient, because it periodically polls the server for the complete data - when many items are processed a lot of data is transefered again and again. If there are several joex nodes it even more difficult to use … :-) But when using docspell for a while I don't go to that page very often, so it faded a bit in importance to me:)
totti4ever commented 4 years ago
  1. It is as wide as the screen and the height adjusts accordingly. So if you have a screen width>height you need usually to scroll for typical paper formats in portrait mode.

Scrolling is fine. Just that right now, you first have to scroll in the outer container until the preview pane is level with the browsers top bar. after that you can either scroll in the preview itself OR also in the main page - and I think that is really confusing.

I like the width being slightly less than the full widht. I would just put the height to slightly less.

What you could even think of is to let the header with document's title and so on float on top, so stays visible.

If you file is in landscape it would then look better usually or if you rotate your screen. The view-tools are at the bottom for the viewer-js enabled preview (which is only there as a fallback on mobile browsers). It looks way better (on firefox and chromium) when using the "native" view mode.

I am on native per default. If you did it like suggested, you would still have the benefit with landscape documents or a rotated monitor. Just that you don't have the double scroll areas and you always see the tools as you always see the whole preview pane.

Another improvement to this is imho to move the notes window at the bottom.

I did this also as default right at the beginning, totally worth it! :-D

Scrolling is indeed a problem here, and I don't know how to solve it; I think it's good to use available screen for the document. So you mean to reduce the width of the preview a bit?

No, reduce height, not width! :-)

I'm going to play with that, thanks!

would be great, looking forward to it

eikek commented 4 years ago

But do you mean to reduce the height to the visible area? But this would mean you can never use the whole screen to see the document even if you would be wanting to scroll, right – so this would disable scrolling alltogether (the outer one)?

totti4ever commented 4 years ago

What I mean is the following (blue: whole content, green: preview pane, orange canvas: screen), left today, right future: