Paperwork 0.2 UX issues

[mjourdan]

Hi,

While I had to scan about a dozen of documents, I gave a try to Paperwork and would like to share some thoughts on it's user experience. You'll find in a separate post some ideas to fix the issues listed below.

Ux review

First things first, everytime I launch Paperwork, I'm delighted by it's logo and think "straight and fast, this will light me of a burden". However, Paperwork is not as close to the "scan and forget" philosophy as I hoped, because reaching the scan step requires too much effort and time (see how lazy I am).

In my opinion, controls make user think too much :

1. huge number of buttons make feel every actions are equally important. This should be "scan and forget", but it more looks like "scan or modify or print or move or zoom or open a dir and forget"
2. document controls (new, edit, delete) are separated from the document list (by a too wide searchbar)
3. useless quit button
4. the app menu contains actions specific to the current window
5. Settings icon and Preferences in the app menu do exactly the same thing but appear twice and under different names

I also think the actual content is drawn in a far too complex layout:

1. tabs to switch between labels and pages make think labels are as important as pages
2. at a time, the document list shows no more than 2 documents (on a 15" screen)
3. 3 columns layout for two kinds of items (documents and pages), so a single page may appear three times at a time (two times as thumbnails in document list and pages list, plus the page itself)
4. some empty space at the bottom of the screen look very weird
5. huge amount of vertical space lost (up to 7 lines of controls + windows decoration on the labels tabs)

Once she have figured out how the ui works, user will need to find out how to get this stupid scanner working:

1. scanner detection requires an extra step on every launch (Hint: open preferences, wait a couple of seconds until a scanner is found, then close the preferences)

Finally, it's pretty easy to get rid of a maximum of paper in a minimum of time. Being able to move pages across documents and marking documents with labels are great features, for example to avoid bothering with scaning the right pages in the right order. Nonetheless, there is plenty of room for improvement.

Regards

[mjourdan]

Proposal

Objectives

Goals:

• focus on content
• ease of use

Non-goals:

• add new features
• remove existing feature

Use cases:

• scan documents long of several pages
• scan a bunch of pages, sort pages later
• retrieve and read a previously scanned document

Tentative design

Scanning is not an end, it's a mean to retrieve and read our documents. Simplify layout so the user spends less time reading and actionning controls. Free up some space to give focus to the content.

List documents on the left, view pages on the right.

Documents:

• show several items at a time, to allow quicker switch between documents
• display multiple labels on a single line, to reduce space consumption
• move less meaningful actions to the bottom (editing document properties or labels would not even exist if OCR was perfect)

Pages:

• highlight the key features, which are view and scan
• group the less useful actions in a single menu

Mockups

Document view, thumbnails

Document view, adjusted

Labels selection

App and list menu

Comments

Thanks for reading, and thanks for that cool piece of software!
What do you think, Jérôme?

[jflesch]

I haven't had time to read everything yet (probably next week). However the mock-ups show some interesting ideas.
Just out of curiosity : what software did you use to make the mock-ups ?

[mjourdan]

I use Inkscape.

You'll find the mockups sources on my repo.

[jflesch]

Let's make a list of the suggested changes:

• Toolbar: Make it more Gnome 3-like + remove all the useless crap. OK
• Toolbar: Add a button to display a popup allowing to change the view settings (page list / pages + zoom level + words highlighting). OK
• Document list: Reduce the thumbnails. OK (but need testing, I'm not sure if the thumbnails are really helpful anymore if they are too small)
• Document list: display the labels beside the thumnails instead of below. OK (if thumbnails reduction is OK too)
• Label list: Drop it. Replace it by a button+popup below the document list: OK.
• Page list: Drop it. Instead, when opening a document, if there is only one page, display it directly, otherwise, display the page list as a grid. OK
• Application menu: move some item to the window menu. OK
• Application menu: scan source selection. KO: This is not how I see things. By default, Paperwork use the input source selected in the settings dialog for scanning, unless the dialog for multiple scans is used, in which case it will automatically use the feeder. In other words, I'm fine with the way things are currently.
• Window menu: Import option. KO: Import option should be beside the scan button (as of now). I see no reason for changing that

Missing:

• Scan button: Missing: Option for multiple scans from feeder (as of now)
• Window menu: Missing: Export function

Change I would like to see too:

• Remove the progress bar at the bottom left. Instead, display on-demand progress bar below the document list or below the page area.

Yep, I think it could work :)

[mjourdan]

Hey! I'm glad you're ok with most ofthe points! There is one I didn't emphasize on, though, which is giving a name to a document. I know you don't like the idea, still I would like to make a mockup for that. I'll also update the current mockups with your comments, and intend to publish all that in a week or two. I think the view popover will be the trickiest part to implement, because as far as I know, gtk+ doesn't provide yet an easy way to embed widgets inside them.

Let me know if I canbe of any help regarding this thread.

[mjourdan]

Comments

Application menu: scan source selection. KO: This is not how I see things. By default, Paperwork use the input source selected in the settings dialog for scanning, unless the dialog for multiple scans is used, in which case it will automatically use the feeder. In other words, I'm fine with the way things are currently.

The point was to avoid offering the user to choose between the same action shown twice. For example, the scan button and "scan one page" menu entry are redundant when the user has configured the flatbed as the default input. To fix this detail, my idea was to allow to quickly change the input which would be used by the scan button. We could as well make it the way it is now, by displaying only the non-default input in the menu.

Window menu: Import option. KO: Import option should be beside the scan button (as of now). I see no reason for changing that

As far as I know, there is no widget combining an action button and a menu. Actually, Paperwork uses currently 2 separate buttons. The mockups do exactly the same. Import deserves indeed a more prominent place, though.

Window menu: Missing: Export function

I thought of using "print to file", hence the disparition of export.

Remove the progress bar at the bottom left. Instead, display on-demand progress bar below the document list or below the page area.

Mockups 2

During scan, we keep the progress bar close to the scan button. You'll notice biggest thumbnails on the left pane, (64px wide, the same size is used by evince, for example) :

Giving documents a name or an object may be helpful. Here are two proposals. On the left, we add a new field. On the right, we automatically use the first line of the extra words. Take a look:

App menu + window menu, updated according to your comments:

[jflesch]

I have a problem: In your mockups, you use 2 header bars, and it doesn't work.

.

As you can see, there are visual issues (I can take care of the height of the header bars, but not their corners). Also, because we want two of them, I cannot use GtkWindow->set_titlebar(), which means I have to disable decorations to make the usual title bar disappear ... which means the window cannot be resized anymore.

I will try and see if I can pack GtkLabels in the header bar. In which case, it could help solve most of this problem. However, I will have to find a way to make a clean separation between the 2 "fake" header bars ... maybe a custom Gtk widget.

[jflesch]

Note to myself:

The XML for the header bar (Glade doesn't support header bars yet, so I will have to make it by hand):

<object class="GtkHeaderBar" id="headerbar">
  <property name="visible">True</property>
  <property name="title">Paperwork</property>
  <property name="subtitle">Grep for dead trees</property>
  <property name="show_close_button">False</property>
</object>   

[mjourdan]

Some other pieces of software already use left pane since gtk 3.10. You may take a look at gnome-contacts, gedit or polari.

You may want to refer to the latest mockups on my repo, in particular one to browse papers by label.

[jflesch]

You're right.
From what I can see in Polari, the trick I missed is that the 2 GtkHeaderBar must be in the same parent GtkBox. I'm still a little bit fuzzy regarding how they keep the lengths of the GtkHeaderBar consistent with the rest of the window, but that's easy to manage anyway.

[jflesch]

Funny thing, Polari uses GtkWindow->set_titlebar() but not Gnome-contacts. Meh, whatever works.

[jflesch]

Note to myself:
For the document list : https://developer.gnome.org/gtk3/stable/GtkListBox.html
(to check: if the performances are ok ... otherwise, a custom widget may be required :/)

[mjourdan]

To keep width consistent, Gedit seems to put its side_panel and side_headerbar in a GtkSizeGroup in its ui file and bind them together in its window.c. Contacts seems to do pretty much the same thing.

[jflesch]

Nice, I didn't know about GtkSizeGroups.

[jflesch]

Ok, got it : 09bd226 + adc9238 (branch: wip-ui-redesign)

[jflesch]

Header bar content: 00aa327 (needs some minor style improvement + there is a workaround I should remove)

[mjourdan]

Nice to see things going on!

[jflesch]

Scraping off the status bar, the page list and the label list: ad3df2d

[jflesch]

ca71a83 : Fix the style of the page numbers

[jflesch]

Current state :

[mjourdan]

Some Feedback here, while it is still wip.

New document button: icon looks perfectly relevant but I worry it may confuse users. The page symbolic should be used either to represent documents, either to represent pages. If we chose to keep the image_button_new_doc, then we should find something else to switch between "single page" and "grid" in the content view.

App menu: having Edit/Export/Print/Delete entries duplicated under two top-level menu feels weird. The vast majority of software first offers to select Export/Print, and then offers to either proceed with the whole document or to pick up some pages. Also, if editing a page is rotating it or croppring it, I can't figure out what editing a document could be. Probably we should be more specific here, e.g. use "document properties" instead of "edit".

Content view: scrollbars should be hidden when there is nothing to scroll.

[jflesch]

1. New document button + icon : Fair enough. I can change it back to a simple '+'. IMHO, it doesn't matter that much anyway.

a) Hm, 'print' shouldn't actually be duplicated. My bad. Update: actually, if I duplicate the others, 'print' should be too, or it will be weird .... I don't know ... :/
b) No problem with renaming 'Edit' into 'Properties' for the documents
c) I think 'delete' can safely be duplicated as of now. IMHO, it's easy to understand.
d) Regarding the export options and dialog, if you have any ideas / mockups, please feel free to share them. But right now, I think the way it's done currently is probably the simpler.

(Note: as you pointed out yourself in your initial UX review, it's not the application menu. I guess the correct name should be 'window menu' :)

3. Regarding scroll bars, I will see what I can do.

[mjourdan]

Regarding the second point:

a. I think we shoud avoid duplication here, we can make simpler things
b. Do you think the "properties" and "label" buttons (bottom-left toolbar on the mockup) are an unappropriate way to go? Would you be interested with mockups of a popover on the document title in the headerbar?
c. What about making the bin a larger area (let say a third of the left pane width), so that both documents and pages could be dragged and dropped to?
d. I'll see what I can do, the export is not that usable for now

[jflesch]

b. No, I actually forgot about these buttons in the bottom-left when I made the menus .... I'll remove 'properties' from the menu ... :)

c. The bin ? For deletion you mean ? No, deletion is not an operation that much common. I don't think a larger area makes sense.

Hm, here are some random ideas:

1. For pages, the buttons 'delete' and 'edit' can be put on the grid view (a pencil at the bottom left of each thumbnail, and a 'X' at the bottom right of each)
2. In the window, only keep rarely used options like : 'open directory', 'redo ocr', 'print', and 'export'. 'export' would then be a submenu to specify 'document' or 'page'
   I think with that, we would have all the options placed in a smart way. What do you think ?

[jflesch]

Actually, I think we can apply the same logic everywhere : there is no need for a toolbar at the bottom.
For each document, I can add buttons "properties", "labels", and "delete".

As for the page grid, the button will only be display when the mouse goes over the document (or the page)

By the way, I also think it would make sense to merge the label and properties dialogs (--> one single button).

[mjourdan]

Actually, I think we can apply the same logic everywhere : there is no need for a toolbar at the bottom.
For each document, I can add buttons "properties", "labels", and "delete".

I thought of the toolbar to avoid cluttering the document pane, but I agree that wouldn't work as well as I hoped.

As for the page grid, the button will only be display when the mouse goes over the document (or the page)

How would it work with touch screens ? Maybe a "delete document" in the window menu would fit better?

By the way, I also think it would make sense to merge the label and properties dialogs (--> one single button).

It makes perfect sense; please find a mockup below.

1. Left pane:
   1. stuff is called "papers" instead of "documents", to reflect Paperwork's scope (documents like slideshows and spreadsheets are somewhat out of scope)
   2. papers can be sorted either by date or by title (should probably be hidden and auto-reveal when reaching the top of the list)
   3. papers can be deleted using a specific icon (doesn't look nice, I think)
2. Document properties:
   1. the first text field is expandable, the first line will be used as a title for the paper, others are extra words.
   2. the second field allows to change the date
   3. the third field offers self-completion to easily pick up labels

[tiramiseb]

Hello,

I'm currently trying this new UI. Some comments:

• multiple pages preview is a great idea but not very effective as-is: pages previews are generated given a size (and I can change this size, great), but I would prefer setting a "number of pages on a single row", pages size would change when resizing the window
• margin between pages is way too large
• I would prefer having three buttons instead of a dropdown menu on the "scan" button. maybe a dropdown on the side as in Simple Scan...
• the documents list is too large, the only important information is the page thumbnail itself. the document's date takes 4x more width than the thumbnail...

[jflesch]

multiple pages preview is a great idea but not very effective as-is: pages previews are generated given a size (and I can change this size, great), but I would prefer setting a "number of pages on a single row", pages size would change when resizing the window

I understand your idea, but I'm not sure how it can be presented without making the GUI complex to use. This isn't a common approach (see for instance Evince, when it's freshly started and display the last documents used ; or any file browser)

margin between pages is way too large

In which view ? Grid, list, or both ?

I would prefer having three buttons instead of a dropdown menu on the "scan" button. maybe a dropdown on the side as in Simple Scan...

Hm, good point

[tiramiseb]

I'm not sure how it can be presented without making the GUI complex to use

By default, multi-page documents would display 3 pages per row, no matter the size of the page. The same slider than now would be used to set the number of documents per row. But instead of setting the size of a single document, it would set the number of documents per row (with gaps between two steps on the slider ; eg. settings for number of cpus or number of screens in virtualbox).

Problem with fixed thumbnails sizes is that if the window is 1 pixel narrower than a number of thumbnails, the last thumbnail goes on the next line and there is a wide empty space.

see for instance Evince, when it's freshly started and display the last documents used ; or any file browser

Displaying pages in a document and files in a directory is not the same thing. content vs icons.

In which view ? Grid, list, or both ?

grid. the space between thumbs in the grid (which can be pretty small) is the same as the space between pages in the list (which is usually large, 100% width zoom by default ?).

BTW, in all situations Ctrl + mouse wheel should changes pages size, on-the-fly (Ctrl + "+" and Ctrl + "-" too).

[jflesch]

By default, multi-page documents would display 3 pages per row, no matter the size of the page.

Why 3 ? :)
Also, a problem with that is that pages can have various width. You can have portrait pages on the first line, and only landscape pages on the second line. The zoom level couldn't be the same for both lines.

So I just implemented something a little bit different :
Paperwork checks if it can fits all the pages in one line without making the previews too small. If it can, it does, if not, it fall back to the previous grid layout. It doesn't really solve the problem for big documents, but it does for small ones.

Please tell me what you think of it ?

grid. the space between thumbs in the grid

I reduced the margin. Again, please tell me if it is ok for you.

in all situations Ctrl + mouse wheel should changes pages size, on-the-fly (Ctrl + "+" and Ctrl + "-" too).

Good point. I'll see what I can do

[jflesch]

Hm actually, maybe you're right.
In grid mode, the slider could be the number of pages par line
In page mode, the slider could be the level of zoom (as of now)

I can give it a try this evening

[tiramiseb]

Paperwork checks if it can fits all the pages in one line without making the previews too small. If it can, it does, if not, it fall back to the previous grid layout

I really didn't notice that at first. It's not clear, but it is a pretty great idea.

I reduced the margin

It's better

Hm actually, maybe you're right.

Yes I am ! I am always right !!! 😃

However, when there are less pages than the number of pages configures, they could be larger than the selected value...

---

After playing more with that, I realized something : the current slider is in a drop-down menu, displaying with an annoying animation. It makes me feel like it is a long-term setting which should not be used ofter.
But in fact it is only a zoom level slider. A zoom level slider should either be always or never visible.
Example for "always" : LibreOffice, low-right corner
Example for "never": Evince, textual percent drop-down / edit box

The same applies to switching between "page" and "grid" views. Buttons on a popup doesn't feel right. 2 buttons on the bar would be better.

Moreover, the "highlight words" is more like a long-term setting and should not be placed with zoom parameters.

[jflesch]

While I agree that the slider could control the number of pages per line, I disagree with moving the settings.

The current logic is the same for the zoom level, the grid/list layout buttons and the "highlight words" switch :

• They all control the way pages are displayed, and so, IMHO should remain together
• In a perfect world, those are things you should never have to use

The zoom level is always annoying to set correctly (LibreOffice and Evince actually give good examples: if often end up being trial-and-errors)
The layout : If there is only one page, the layout 'grid' is useless anyway. If there are more, you start with the grid, and then look at one or two pages specifically. I'm not sure there are so many cases where you have to switch back to the grid layout (I'm not saying it doesn't happen, I'm saying it happens rarely).
"Highlight words" : That's more a debug feature than a really useful one. I guess it helps people relax by making sure the OCR worked (I know it does for me ;) ).

So in the end, if the UI is done right, you shouldn't have to use them really often.

Also, I think moving them out of this dialog would clutter the main window.

[tiramiseb]

Understood.
In this case, I think this behaviour is a step towards a UI done right / a perfect world.
It should be used by as many people as possible to check which improvements could be done.
I will use it and see if it fits my usage of Paperwork.

[jflesch]

Note to myself: I must also re-add support for drag'n'drop also (the API tends to be really painful to use ; I did some crappy work in the previous UI :/)

[tiramiseb]

I don't know if I should open a new issue for the following thought...

Clicking on "New document" on the documents list displays an empty document (zero page)
Clicking on "+" makes the documents list jump to "New document", displaying zero page
Clicking on "Scan" gives a list of options for importing documents (scan or pdf import). Even if a document is displayed, the scan (or import) is done in a new document.

My idea:

• "New document" and "+" are useless
• "Scan" can be split in 3 buttons (or a button for "default action" + a dropdown), placed on the left panel in place of the "+" button

I think "Scan" has nothing to do with the current document, nothing to do on the right panel.

[jflesch]

"New document" and "+" are useless

How would you start making a new document then ? oO

I think "Scan" has nothing to do with the current document, nothing to do on the right panel.

"Scan" add a scanned page to the current document. Always. ("scan single page" anyway)

[tYYGH]

Maybe scan and import just shouldn't stay together: import would go to the left, and scan would remain to the right.

[tYYGH]

Unless of course you intend to allow importing additional PDF content to an existing document…

[jflesch]

I don't.

But as of now, "import" can import PDF as a document, or images as extra pages to the current document :/

[tiramiseb]

Wrong memory on my side, sorry, you are of course right. Recently I have only imported PDF documents :)

However the behaviour of the "Scan" button is not consistent, as you have said.

Another suggestion:

• the "+" button has the "scan" drop-down menu, to allow directly scanning to a new document or importing a new file
• the "scan" button is only displayed on existing images-based documents which allow new pages to be scanned (hidden or grayed out on PDF documents)
• the "new document" entry doesn't need to exist

[mjourdan]

I don't know if I should open a new issue for the following thought...

Seems to me you're far from being off topic.

Let me rephrase you're idea to get this straight. What you are saying, tiramiseb, is it is nonsense to create document of 0 page, therefore documents should always be created either from file or scanner. Then it is allowed to add pages when a document has been created from scanner, when you imported an image file. However, if you imported a pdf, it is not allowed, because a pdf is considered to be a whole document. Am I right?

Let say a user does create a document using some .jpg file. Would her be able to add pages from her scanning device, and why?

[tiramiseb]

Regarding behaviour when it is a scanned document or a PDF file or an image import, I'm keeping the existing behaviour.

Globally, my idea is to totally remove the "document of 0 page" and to be able to:

• "scan or import a new document" on the left panel
• "scan or import into the current document" on the right panel

However, the current behaviour being "a PDF-based document cannot be modified", the "scan [...]" on the right panel would only be available for scanned docs or images.

[mjourdan]

Le 07/10/2015 11:57, Jerome Flesch a écrit :

It has been a very long time since there was a major Paperwork release, and this GUI is starting to look really great :) --> I would like to ship a 0.3.0 asap. We can still fix minor issues later in the next minors releases (0.3.x).

Anyway, I have a few questions for you:

quick scanner setup for first page scan (needs design)

What do you mean exactly ?

I launch Paperwork, start my scanner, and try to scan a document.
Nothing happens, and I have to open the Preferences so that my device is
detected. This happens every time I launch Paperwork, and is
uncomfortable, as my device is the same for years now. At least, that
was true by the time I wrote this.

sometimes no paper is shown because none is selected in doclist

Well .. it makes sense I guess, no ? :)
I guess we could display the last used documents instead of nothing. But is it blocking for 0.3.0 ?

Yeah, my point was we should always have a document selected, so that we
have something to show, whether it is the last used, or a new empty doc
(in which case we would have a nice message saying "this doc is empty,
you can add pages blah blah"). While it is confusing, I wouldn't say
it's a blocking issue.

the additional keywords text area has no border

I didn't notice it as being a problem.
Maybe it could be a problem based on the Gtk theme used. But then again, is it a Paperwork problem ?

I took a look at a couple of apps (polari, boxes...) and I couldn't
figure out how it happens I can't set a stupid border on this particular
widget. But really it's just about polish.

help is not available without network connection (Jflesch> Won't do for 0.3.x)

This one will require some work, and I'm fairly sure that current users of Paperwork all have an Internet connection :). However, I must admit it's a problem because it makes Paperwork dependent on GitHub, and pages can't be translated. Still, I think it would be best to keep this change for 0.4.0.

Seems wise to me.

in paper list, controls (edit and delete) sometimes disappear

Do you have any reproduction scenario ? I can't find any anymore :(

As far as I remember, I couldn't identify a pattern to reproduce, but
this definetely happened multiple times!

with the first paper opened in grid view, clicking in an empty zone switches the view to a zoom on the second paper

Can't reproduce. However, I did a lot of changes, so I may have fixed it by accident :-). Can you have a look please ?

So, what do you think ?

I'll test a bit and give some feedback soon.

---

Reply to this email directly or view it on GitHub:
#356 (comment)

[mjourdan]

Globally, my idea is to totally remove the "document of 0 page"

This could be a good thing indeed!

• "scan or import a new document" on the left panel
• "scan or import into the current document" on the right panel

I'm not sure about this. This means user would have to chose the source in two different places instead of one, which would result imho in a more complex experience.

[jflesch]

I launch Paperwork, start my scanner, and try to scan a document. Nothing happens, and I have to open the Preferences so that my device is detected. This happens every time I launch Paperwork, and is uncomfortable, as my device is the same for years now. At least, that was true by the time I wrote this.

I think this one is a bug unrelated to the UI changes. The expected behavior, even in stable:

• if Paperwork was never configured, open the configuration dialog
• if it has already been configured (even in a previous session), just do the scan

You can open a ticket if you want. If you do, please have a look in your paperwork.conf after each session / reboot. Maybe your scanner ID changes when you reboot, which could partially explain this bug.

Yeah, my point was we should always have a document selected, so that we have something to show, whether it is the last used, or a new empty doc (in which case we would have a nice message saying "this doc is empty, you can add pages blah blah"). While it is confusing, I wouldn't say it's a blocking issue.

Noted, but for 0.3.x

As far as I remember, I couldn't identify a pattern to reproduce, but this definetely happened multiple times!

Actually, in the meantime, I reproduced it and fixed it :) (please tell me if you see it again)

I'm not sure about this. This means user would have to chose the source in two different places instead of one, which would result imho in a more complex experience.

I agree. The current way is messy and unperfect, but I think most users (if not all) found their way. I doubt we will find a perfect solution anyway. So I think we will just let it as it is for 0.3.0.

I'll just split the "scan" button in two --> "scan" button + a button to have the sub-menu, as done before in 0.2.x

[tYYGH]

About the scanner and the preferences:

I launch Paperwork, start my scanner, and try to scan a document.
Nothing happens, and I have to open the Preferences so that my device is detected.
This happens every time I launch Paperwork, and is uncomfortable, as my device is
the same for years now. At least, that was true by the time I wrote this.

Same for me. Probably because it is an USB scanner, that I plug only when I need it, and it would get a different system ID each time…

[jflesch]

My scanner is also a usb one (HP), but I never unplug it. Anyway, it's still a bug in that case : if the scanner id cannot be found, it should either display a popup saying "scanner not found" or open the settings window.

[tYYGH]

About the “empty document” thing:

Yeah, my point was we should always have a document selected, so that we have
something to show, whether it is the last used, or a new empty doc (in which case
we would have a nice message saying "this doc is empty, you can add pages blah
blah"). While it is confusing, I wouldn't say it's a blocking issue.

I don’t agree. I find nothing either unnatural or confusing about seeing an empty document. In the real world, there are empty folders; there are empty pages; there are empty notebooks… However, it is a really good idea to have a message like “This is a new, empty, document. You can import or scan new pages inside.”

As for always having a document selected, I even more don’t agree. When I start Paperwork, it is:
— either because I will scan/imports new documents, in which case being on a new, empty, document is just perfect;
— or because I have a search to do, and then I don’t care at all what document was selected last time.

Cheers,

[tYYGH]

rel. scanner: I do have a “scanner not found” message. Maybe some heuristics using the scanner name instead of its ID if the ID is not found would solve the issue?

[jflesch]

Hm, I prefer not using heuristics when possible. They tend to be hard to debug (for instance, I'm fairly certain the label guessing has some bugs).

Here, I guess it can be done by simply looking how many scanners are connected. If there is only one ... well it must be this one.
I will just have to ignore camera devices. Since their IDs are prefixed with "v4l:", it should be easy.

Added: #403

[jflesch]

Implemented:

• Drag-n-drop: Page --> another document
• Drag-n-drop: Page --> another position in the same document

5dd34ed
54710c3
1f5012d
7225381

[jflesch]

Most of the GUI changes for 0.3.0 have been implemented (in the branch 'unstable'). I'm going to close this meta ticket.
Please feel free to open a new ticket for each issue you (still) see.