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 : 09bd22672896caba9f390485380db32a90d43bf0 + adc9238880323a5d26c32f3ed9cbbe41188e2e1b (branch: wip-ui-redesign)

[jflesch]

Header bar content: 00aa327850740c1afd369a304400805c68809536 (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: ad3df2d1391b11a23de49bcbff53eab717c0056a

[jflesch]

ca71a83d387d8a6db55f881ffb70560088d37e1c : 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.

2) 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

[jflesch]

Hm, for me, the window menu should contains options rarely used. From my experience, those options are used quite often:

• doc properties : because label guessing doesn't always work as well as I would like it to :/, and because I'm often late with my scans
• page edit : because page orientation detection screw up sometimes
• page delete / doc delete : because sometimes you're tired, you put the sheet of paper with a 20 degrees angle, and the orientation detection is not (yet) smart enough to fix that, and it's just simpler to rescan the page.

Here is how I see things and why:

I think there should be a "properties" button and a button "delete" beside every document in the document list (like you did in your mockup). Now, having all these buttons would be ugly and kind of flood the user eyes in a bunch of useless visual elements. So these buttons should only be displayed when the mouse goes over the document, or when the document is selected (--> works with touchscreens).

Same goes for the page grid: "edit" and "delete" should be on every pages. However to not flood the user and hides page details, they should only be displayed when the mouse goes over.

Problem is, when we select a page in the grid, it will switch to page list mode. So as-is, it doesn't work with touchscreens. I guess it can be solved by adding these two buttons also in the list mode. We can put them beside each page to not hide details of the page.

Also, I would like to point out that you focus too much on document titles IMHO. I'm not even sure I want to implement them. Here is why: Paperwork goal is "scan & forget". In other words: Put all your documents in a big virtual stack, and let the computer do the job. If we make it possible to change document titles and sort documents by titles, people will feel that, if they want to use Paperwork efficiently, they have to put a title on every documents. That's simply not true (or I did my job really poorly ...), and that would actually be using Paperwork less efficiently. Based on my experience, thumbnails are much better than titles for identifying them (except you can't sort them, but it hasn't been a problem yet ; hmmm... random idea: allow sorting thumbnails by image similarities ... ?) Also, my main reason : it's one of those features that I won't use (and so won't test it much, and it will be buggy).

[mjourdan]

Ok, thanks for explaining.

I think there should be a "properties" button and a button "delete" beside every document in the document list (like you did in your mockup).

What about using the date (forget about the title for now) in the headerbar to edit properties, as shown in the mockup above ?

So these buttons should only be displayed when the mouse goes over the document, or when the document is selected (--> works with touchscreens).

Seems good to me.

Problem is, when we select a page in the grid, it will switch to page list mode. So as-is, it doesn't work with touchscreens. I guess it can be solved by adding these two buttons also in the list mode. We can put them beside each page to not hide details of the page.

Maybe we can use some sort of selection mode in grid view to allow dragging multiple pages to an other document or deleting them. "edit" would only be available in page list.

Also, I would like to point out that you focus too much on document titles IMHO. I'm not even sure I want to implement them.

Yeah, that's a controversial point I wanted to introduce.

people will feel that, if they want to use Paperwork efficiently, they have to put a title on every documents

Hum. Didn't think of that. This is absolutely true on the mockups.

Based on my experience, thumbnails are much better than titles for identifying them

Actually I see this more as a "subject" than a title, when thumbnails fail to give a clue.

Also, my main reason : it's one of those features that I won't use (and so won't test it much, and it will be buggy).

Really, that's probably nothing more than showing the 20 first caracters of the extra words in the papers list and the headerbar.

I'll iterate some more.

[jflesch]

What about using the date (forget about the title for now) in the headerbar to edit properties, as shown in the mockup above ?

Possible. But there are 2 things that disturb me with this approach:

• there are no visual clue that the labels can be changed by clicking on the title/date
• shouldn't the option to set labels and change doc properties be closer to the doc and its labels ?

Maybe we can use some sort of selection mode in grid view to allow dragging multiple pages to an other document or deleting them. "edit" would only be available in page list.

Hm, do you often need to handle multiples pages at once in Paperwork ?

Actually I see this more as a "subject" than a title, when thumbnails fail to give a clue.

Yeah, that's one of the reasons I made the thumbnails so big. But still, I think we can reduce them and keep most documents recognizables (labels actually help in that matter).

Really, that's probably nothing more than showing the 20 first caracters of the extra words in the papers list and the headerbar.

Extra words are only here to palliate cases where the OCR doesn't work. For instance, I have some invoices with a crappy yellow background on which Tesseract didn't work. But even then, it's only useful for about 2 documents out of 989.

[mjourdan]

Possible. But there are 2 things that disturb me with this approach:

• there are no visual clue that the labels can be changed by clicking on the title/date
• shouldn't the option to set labels and change doc properties be closer to the doc and its labels ?

I agree it is not obvious that the document date will allow the user to add labels, but I would argue that the dropdown icon make it discoverable enough.

If we place the edit button in the papers list, I'm afraid it turns one of the following:

• we have edit and delete icons horizontaly aligned, which results in very short width for thumbnails, text and labels
• we have edit and delete icons verticaly aligned, which would make popovers a bit obtrusive I think, but why not?
• we have a dummy icon to open a popover to chose between edit and delete, which would lead to a very disruptive dialog

Perhaps we could imagine something sliding out under the item directly in the papers list, but that would require to code specific widget, wouldn't it? The bright side is it would allow to open a calendar as a popover to chose the date, which would be nice stuff I think.

Hm, do you often need to handle multiples pages at once in Paperwork ?

Perhaps as much often as I open Paperwork for importing files. Use case: user has a lot of papers to scan. She brings a dead tree or two at work, and she scans from feeder to her email, as a single batch. At home, she imports that in Paperwork then uses split the file into several documents. This would be used from time to time, but could save a lot of time. That's the kind of feature wich allows to spend less time both with paper and with software.

Yeah, that's one of the reasons I made the thumbnails so big. But still, I think we can reduce them and keep most documents recognizables (labels actually help in that matter).

Sure.

Extra words are only here to palliate cases where the OCR doesn't work. For instance, I have some invoices with a crappy yellow background on which Tesseract didn't work. But even then, it's only useful for about 2 documents out of 989.

Sure, again. Displaying a few words when available seemed to me a nice answer to make the extra text visible, completing thumbnails without adding one-shot labels. But eh, if you're convinced that's a bad idea, I won't insist more and will make it disappear for the next mockups.

To do next:

• a screen for empty papers
• a simple label editor
• wires to attach labels to a paper

[jflesch]

I would argue that the dropdown icon make it discoverable enough.

I think it's quite small for something used that often.

we have edit and delete icons horizontaly aligned, which results in very short width for thumbnails, text and labels we have edit and delete icons verticaly aligned, which would make popovers a bit obtrusive I think, but why not?

I was thinking about putting them vertically. I don't know if the popover would be obtrusive, but I must admit it feels weird to have it pop at variable locations.

we have a dummy icon to open a popover to chose between edit and delete, which would lead to a very disruptive dialog

Ney.

Perhaps we could imagine something sliding out under the item directly in the papers list, but that would require to code specific widget, wouldn't it? The bright side is it would allow to open a calendar as a popover to chose the date, which would be nice stuff I think.

This might work (and don't worry about the custom widgets).

Another possibility : Like for the export, we can use an info bar at the top of the page/grid view. (I'm really tired right now, so I'm not sure it makes sense)

she scans from feeder to her email, as a single batch. At home, she imports that in Paperwork then uses split the file into several documents. This would be used from time to time, but could save a lot of time. That's the kind of feature wich allows to spend less time both with paper and with software.

Hm, it makes sense. It can be useful. However, I think we should keep in mind this is a rare use case, so I think this selection mode should be discreet.

But eh, if you're convinced that's a bad idea, I won't insist more

:) Just so you know, this ticket has officially become my main example for a good feature request / change request. (and yes, right now, I'm convinced)

[jflesch]

9a7d13cf9f775260061b98babb01b7747fa92512 : Display doc list + labels (still missing: thumbnails + buttons)

[jflesch]

a2fcc462672f052eee8c4c549bf674fee2c786a0 : Thumbnails in doc list

[jflesch]

7587645c002f476c7f234e4eabbe8c71b2261a19 : Implement custom progress bar (so it may disappear when unused)

[jflesch]

1a541aa1dbd0df4013b27597ca36d4d0a96d63ce : Doclist: add edit and delete buttons

[mjourdan]

I think it's quite small for something used that often.

Actually dropdown icon is a very common trick, used by thousands of well-known websites and applications, including gmail, github, pocket, owncloud, and so on.

I made some more experiments:

• compact properties popover
• empty headerbar popover
• selection widgets to edit directly from list

You'll notice I removed the additional keywords from the papers list, so editing them together with date is a bit surprising. I don't know what is the way to go.

[jflesch]

Actually dropdown icon is a very common trick, used by thousands of well-known websites and applications, including gmail, github, pocket, owncloud, and so on.

Yes, but from an ergonomic standpoint, there are quite small targets to click on with a mouse. Which means they should be used only for operations that are not done often. But changing the labels is actually quite common in Paperwork.

selection widgets to edit directly from list

I think this idea is interesting. It avoids pop-over, which, IMHO, is nice.

I think that when the user clicks on "edit", we can extend the space allocated to the document in the list. This way, we can make label selection faster (maybe like the label list existing currently in Paperwork 0.2 ?).

We can also add an a button below the labels that would open a dialog to type in the additional keywords (again, extra keywords are and should rarely be used, so it's not a big deal if it's hard to reach). What do you think ?

[jflesch]

6ab296400f43f084856a22762977b67a9894b241 : Popover dialog for view settings (not connected yet)

[mjourdan]

Yes, but from an ergonomic standpoint, there are quite small targets to click on with a mouse.

Nah, the icon is only here to advertise there is something to activate, the actual target is the icon + the item besides it. In our case, that would be the whole headerbar title.

I think this idea is interesting. It avoids pop-over, which, IMHO, is nice.

I think that when the user clicks on "edit", we can extend the space allocated to the document in the list. This way, we can make label selection faster (maybe like the label list existing currently in Paperwork 0.2 ?). We can also add an a button below the labels that would open a dialog to type in the additional keywords (again, extra keywords are and should rarely be used, so it's not a big deal if it's hard to reach). What do you think ?

Both points seem right. We even could use a simple ">" as the only button for each item. Activating it would slide the whole left pane, with the following (sorry, can't do mockups for now):

• "<" in the headerbar to return to the papers list
• a bin icon in the headerbar (in place of the "+") to delete the files
• in the properties pane, a calendar widget (eventually in a popover) + text field to change the date
• the list of labels (scrollable if too long) + text field
• at the bottom, the additional keywords text area (eventually expandable)

[mjourdan]

Please find some wires which cover paper creation and properties edition.

[jflesch]

1) welcome popup: KO (I hate useless popups) 2) "No paper yet !": OK 3) "Use the + button to add your first paper": OK 4) "New document" that appear only when we click on "+" : OK 5) "Use the scan button (...)": OK 6) Scan button locked: OK ; Maybe we can turn it into "Cancel" to stop the scan ? (may be useful if the paper is not correctly inserted in the scanner) 7) Progress bar on top : Actually, I put it at the bottom for now. At the top, it raises the question : should everything move down, or should the progress bar hides something ? 8) The panel to edit document properties : Looks good. However, if we want it to be clear, I need to be able to animate the switch from the document list to the document properties (without animation, I think the switch may be disturbing for the user). I'm not sure if there is an easy way to do that with Gtk.

[mjourdan]

1) Useless indeed, would fit an app center, though 7) I can't see why the question would not be raised at the bottom 8) Absolutely; I was thinking of slide effect similar to what popovers provide. GtkRevealer, maybe ?

[jflesch]

7) because at the bottom, moving the content up would seem weird --> it can only hide stuff. Also, usually, less important information are at the bottom --> less risk of hiding something important. 8) Ok. I'll have to try it.

[jflesch]

8) Tried and adopted

Just one thing : on your latest mockups, when editing a document, there is no way to cancel the changes. So currently I made things slightly differently : In the panel used for editing, there are at the bottom buttons 'ok' and 'cancel'.

[jflesch]

Hm, screw the cancel button. I'll do it your way

[jflesch]

GtkRevealer : 99adc2a77d1803e658cef52a1ac54ba26814d0e8 b0886a9fc58a117ec8af7b31c160ea8efc3655de ff543206aca56b1ebc1968a75148793fa44cfb41

[tYYGH]

jflesch, mjourdan, I’m impressed with the mockups, the quick adoption, and real improvements this brings!

I post this only to comment about tags. While I agree with most of mjourdan’s improvements, he/she seems to relegate tags to second-class objects in Paperwork, which may explain the focus on titles… Of course, each person may use the software in a slightly different way, but IMHO tags are important, much like they can be on a blog or an email client software. (BTW, +1 for #362!)

I like a lot the idea to start typing a tag and have it auto-completed and changed into an on-screen label with a delete-button. I have a question: what happens when several tags start the same? For instance, since one may not remember the exact spelling of a tag, it would be nice to have a list open just like in the web browser’s search bar, with all tags matching “*typed text*”, case-insensitive and disregarding diacritics.

[jflesch]

Actually, right now, I took an approach similar to before : http://jflesch.kwain.net/~jflesch/paperwork/paperwork_redesign_progress2.png

Why ? Because I'm lazy, and it was the fastest to implement for now :p

Anyway, I think Mjourdan approach is interesting :

• advantage : if there are a lot of labels, the UI is not drowned
• disadvantage : users have to remember which tags exist and which don't

When using Paperwork, the goal is to be lazy. So I'm going to assume that users don't have that many labels, so drowning in the mess shouldn't be an issue. However, having to remember what labels are available is not exactly what I call "the lazy way".

What do you think ?

[tYYGH]

Some context first: I have 697 documents, and I currently use 51 tags, ranging from 5 tags being used only once so far, to 5 tags being used more than 150 times (max 338). On average 3 tags per document, which is consistent with my usage: tags for “who”, “what”, “where”.

In my opinion, remembering the labels is not that much of an issue: I may not remember the casing, or the presence or not of accents, or the presence or not of an article before the noun, or the order of words in multi-word tags… but I doubt the number of tags will become such that remembering the key words will be a problem. My wish to have a suggestion-list along with auto-completion would answer two needs: — the need to remember spelling, eg: I type “kid” and it provides me with “livret €kid”, — the need find out existence, eg: I type “Fnac” and it provides me with nothing, meaning no tag exists with this word. There would need to be some place where all tags can be seen, though, for actions such as deleting obsolete tags, or renaming them.

That being said, the current presentation as a full list is OK as far as I’m concerned, even though my list is longer than the window ;-)

[jflesch]

That being said, the current presentation as a full list is OK as far as I’m concerned, even though my list is longer than the window ;-)

Don't worry. A scrollbar will come to your rescue :)