make datepicker popup optional

[ansemjo]

First I'd like to congratulate you on this piece of software! It looks really refreshingly simple yet powerful. I've been searching for a simple document management system for home use for a long time.

Anyway. I have a few smaller nitpicks that could be converted into seperate issues at your discretion:

• The "Notes" editor is a little weird. It's nice that it supports Markdown but once created, the note doesn't feel well-integrated yet. Why is it highlighted with a greenish colour? And why isn't it used -- at least in an abbreviated form -- for the item card in the "gallery view" when searching for documents?

• In the main view I would like to be able to browse by category or tag. I don't want a full "folder"-like implementation. Actually this is probably one of the reasons why it feels so nice and simple, because it doesn't attempt to mimick a file explorer window .. but sometimes I would like to be able to browse by category without a specific search term in mind. (I am aware I can search for a tag without any other search terms and that works but its not quite the same thing.)

---

Now what this issue is actually about ... the datepicker in the metadata editor is really going on my nerves. 😬

• I would really prefer if it were optional and hidden behind a button in the input field or at least would not pop up immediately when there is a manually entered date in the field already.

• Or at least don't cover the input field when it does pop up. 😋

• I am used to enter dates in ISO format like 2020-07-21. The parser for this field apparently understands this, so that's nice. That would have been more obvious though if I could enter dates manually more comfortably. 😃
  (I haven't seen any suggestions yet, possibly because the dates in my documents are formatted in German like 21.07.2020?)

[eikek]

Hi @ansemjo , thank you very much for your feedback!! (and the kind
words, of course :)).

I agree with all your points. The ui part is really the hardest one
for me, as I've never been a frontend dev and I know that there are
many things to improve. And my patience is very limited when it comes
to fiddle with css … (unfortunately).

Here are some thoughts I had, just for a little background.

Note Editor: It never was really clear to me where it belongs. At the
very beginning it was just a text area in the menu. Then I felt it
deserved more importance and made this editor. Then I wanted to make a
retrospection on those post-its that often were on my papers before;
which is the greenish color (it should be kind of yellow, actually…).
Other thoughts were, that these notes may be a lot of text, which
might be distracting from the document. So I made it "hide-able". But
then those notes are often of some importance (in my workflow
anyways). So I put it before the documents…. But tbh, I just don't
know how to add them properly to the ui. Do you have any idea on how
to better integrate it? It would be possible to have some settings in
the ui-settings for this, but which….

The notes are currently not returned with the list views, that's why
they are not visible in the search view (unless on hits via fulltext
search). But this could be changed, of course. It would be necessary
to abbreviate them, I think. The cards get quite large otherwise and I
think one would loose the "overview" idea then. Tbh, it never occurred
to me that it makes sense to return them in the search view. But this
is just me, of course. I can see that it might be useful, of course.

Main View "folder" Browsing: I'm not sure if I understand. You can
select a tag and then only items with this tag are shown. Isn't it
what you mean? Or do you mean this with a different ui? Maybe a list,
where you just klick the tag without the annoyance of the
dropdown-search field? (that's what is on my list; I want to create a
list of tags, maybe 7 (still be searchable for narrowing) and one
could klick to select the tag, click again to exclude the tag).

Datepicker: Yes, I can feel your pain :) I probably got a bit used to
this by now, but this is no excuse :) It really is not very friendly.
I often find it too small, so I thought to search for a better
(bigger) picker component. That it is placed above the input field is
really …, well, funny. Interestingly it is placed below the field in
the search menu…. So this shouldn't be hard to fix (I hope, it's css
after all). I think I will try to do this: 1) move it below the input
field 2) make it open via a button next to the input field 3) evaluate
other date pickers eventually.

Date Suggestions: The suggestions should show up. There are several
patterns tried to recognize and the German date pattern is included
(because that's what I need, too). It should also find "written"
dates, like 11. November 2019 and suggest it as an item date or a
due date if it is in the future. This works for me, you can get back
to me if this evolves into a problem.

Thank you again for your feedback! It is very much appreciated. I will
create separate issues from this to hunt them one by one.

[ansemjo]

..., as I've never been a frontend dev and I know that there are
many things to improve.

Well, you've done a beautiful job so far. :)

[...]. So I put it before the documents…. But tbh, I just don't
know how to add them properly to the ui. Do you have any idea on how
to better integrate it? It would be possible to have some settings in
the ui-settings for this, but which….

I think I would handle notes similarly to README.mds on GitHub: just show them in full and let the user decide how "full" to make them. Maybe if you find a nice module to abbreviate text at sensible places add a "Read More" link after a few paragraphs, which then expands the note area to its full length?

Other than that, I think I would always show an area suggesting to add a short description when there is none yet and an edit button within the area itself. When trying docspell out earlier it took me a while to remember I need to click the speech bubble in the bar above it to edit the note.

[...] The cards get quite large otherwise and I
think one would loose the "overview" idea then. Tbh, it never occurred
to me that it makes sense to return them in the search view. But this
is just me, of course. I can see that it might be useful, of course.

For lack of document thumbnails in the overview I think it would be useful to have (part of) the note on the card, yes.
The more I think about it however .. the text in the note might even be too long already. It probably needs to be a few words or about two sentences at most to be useful.

---

Main View "folder" Browsing: I'm not sure if I understand. You can
select a tag and then only items with this tag are shown. Isn't it
what you mean? Or do you mean this with a different ui? Maybe a list,
where you just klick the tag without the annoyance of the
dropdown-search field? (that's what is on my list; I want to create a
list of tags, maybe 7 (still be searchable for narrowing) and one
could klick to select the tag, click again to exclude the tag).

What you describe sound like what I mean, yes. I was thinking of something like the clickable "collections" in Outline, I think. This one is low priority for me though because as you rightly say, there is a way to achieve this effect already.

---

Datepicker: Yes, I can feel your pain :) I probably got a bit used to
this by now, but this is no excuse :) It really is not very friendly. [...]

😬

Sounds like a simple CSS fix then.

Date Suggestions: The suggestions should show up. There are several
patterns tried to recognize and the German date pattern is included
(because that's what I need, too). It should also find "written"
dates, like 11. November 2019 and suggest it as an item date or a
due date if it is in the future. This works for me, you can get back
to me if this evolves into a problem.

I don't think this will be a problem. It just occured to me that the suggestions I saw in the documentation never appeared for me yet.

Thank you again for your feedback! It is very much appreciated. I will
create separate issues from this to hunt them one by one.

You're welcome! What I said above are only suggestions, of course! :)

[eikek]

ansemjo <notifications@github.com> writes:

> ..., as I've never been a frontend dev and I know that there are > many things to improve. Well, you've done a beautiful job so far. :)

Thanks :) All owed to the magic in semantic-ui ;-)

I think I would handle notes similarly to `README.md`s on GitHub: just show them in full and let the user decide how "full" to make them. Maybe if you find a nice module to abbreviate text at sensible places add a "Read More" link after a few paragraphs, which then expands the note area to its full length? Other than that, I think I would always show an area suggesting to add a short description when there is none yet and an edit button within the area itself. When trying docspell out earlier it took me a while to remember I need to click the speech bubble in the bar above it to edit the note.

I like this idea. I can put it then below the document, because I think the files are still the most important content. Maybe this could be configured with a ui-setting. One would need to scroll down then to see the notes.

For lack of document thumbnails in the overview I think it would be useful to have (part of) the note on the card, yes. The more I think about it however .. the text in the note might even be too long already. It probably needs to be a few words or about two sentences at most to be useful.

Do you think document thumbnails are worth it? I tried it very early on and found that most documents just look the same from a distance and the thumbnails didn't really catch my eyes. I always had to look at the meta info, in order to find out useful info. So I decided to not include it in the first place, because it also saves a lot of space (ui and data). I also think that the notes must be shown in abbreviated form in the search view.

--- What you describe sound like what I mean, yes. I was thinking of something like the clickable "collections" in [Outline](https://www.getoutline.com/), I think. This one is low priority for me though because as you rightly say, there is a way to achieve this effect already.

Ah, thanks for the link. Yes this is somewhat what I had in mind.

--- You're welcome! What I said above are only suggestions, of course! :)

Yes and thanks for those :)

[ansemjo]

Do you think document thumbnails are worth it? I tried it very early on and found that most documents just look the same from a distance and the thumbnails didn't really catch my eyes. I always had to look at the meta info, in order to find out useful info. So I decided to not include it in the first place, because it also saves a lot of space (ui and data).

I also think that the notes must be shown in abbreviated form in the search view.

No, you're probably right. It's not worth it to clutter the gallery view with them.
It was just what I came to expect from other document management systems when I saw the gallery "cards". This in itself is not a good reason to copy that feature, though.

What I rather meant was that there is some space left in these cards. If you're not using that space for a thumbnail you could put a short description there, giving additional context to the document title.

[eikek]

So regarding datepicker… it wasn't trivial to make it behind a button or optional. So I just fixed the positioning for 0.9.0. I will look for other date-picker components for some later release. The improvement for the notes is now #192; to add the notes to the list view is #201; the tag view improvement is already on my list. afaics this is all from this issue.

[vanto]

Regarding the date picker: did you consider using the HTML5 date input type? It's supported by all browsers (except IE and the current Safari. The next version will support it and there are poly fills) and provides IMHO the most polished user experience (native look and feel, even on mobile devices, user's localization etc.)

[eikek]

Well, I haven't :/ but only because I only found out about this html5 datepicker some weeks ago… Yes, this is definitely to consider. It would make it much simpler for me (I hope). Thank you for bringing this up. I think I'm fine with not supporting IE, as it will be eol anyways. When safari has support as well as the major browsers, that would be ok to me (I would prefer to not rely on polyfills).