Skip to content
This repository has been archived by the owner. It is now read-only.

Paperwork 0.2 UX issues #356

Closed
mjourdan opened this issue Dec 19, 2014 · 95 comments

Comments

@mjourdan
Copy link
Collaborator

commented Dec 19, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 19, 2014

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

paperwork-thumbnails

Document view, adjusted

paperwork-adjusted

Labels selection

paperwork-tags

App and list menu

paperwork-menus

Comments

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

@jflesch

This comment has been minimized.

Copy link
Member

commented Dec 20, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 21, 2014

I use Inkscape.

You'll find the mockups sources on my repo.

@jflesch

This comment has been minimized.

Copy link
Member

commented Dec 22, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 30, 2014

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) :
paperwork-adjusted-scan-in-progress

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:
document-properties-experiments

App menu + window menu, updated according to your comments:
paperwork-menus

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

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

Image of what happens when we try to have 2 header bars.

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

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 13, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

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

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 13, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

Nice, I didn't know about GtkSizeGroups.

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 13, 2015

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

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 14, 2015

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

@mjourdan

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 14, 2015

Nice to see things going on!

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 14, 2015

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

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 14, 2015

ca71a83 : Fix the style of the page numbers

@jflesch

This comment has been minimized.

Copy link
Member

commented Jan 14, 2015

Current state : img

@mjourdan

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 15, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 15, 2015

  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' :)

  1. Regarding scroll bars, I will see what I can do.
@mjourdan

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 15, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 15, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 15, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 17, 2015

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

paperwork-properties

@tiramiseb

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 8, 2015

"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

This comment has been minimized.

Copy link

commented Oct 8, 2015

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

@tYYGH

This comment has been minimized.

Copy link

commented Oct 8, 2015

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

@jflesch

This comment has been minimized.

Copy link
Member

commented Oct 8, 2015

I don't.

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

@tiramiseb

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 8, 2015

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

This comment has been minimized.

Copy link

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 8, 2015

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

This comment has been minimized.

Copy link

commented Oct 8, 2015

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

This comment has been minimized.

Copy link

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 8, 2015

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

This comment has been minimized.

Copy link
Member

commented Nov 12, 2015

Implemented:

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

5dd34ed
54710c3
1f5012d
7225381

@jflesch

This comment has been minimized.

Copy link
Member

commented Dec 1, 2015

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.