Collection of Bugs

We use dynalist in regular basis, while we encountered some bugs. As I didn’t find any dynalist bug tracking system anywhere, creating separate topics for each bugs would take significant amount of time and bug tracking for developer would be messy so I decided to post collection of bugs in just one topic. Also I have included workaround with issues and as well as suggestion too within the bug.

Bugs

  1. When moving the text insert mark up with arrow keys, starting in the first position in the second line of an item’s note, the first line above jumps over.

  2. The position of the “Undo” icon in the mobile version changes after the first undo to make space for the “Redo” icon that then appears, making it uncomfortable to use “Undo” multiple times in a row.
    The following code fixes this: .MobileHeader-option--undo { right: 175px; }

  3. When using “Ctrl + arrow up” and “Ctrl + arrow down” to move items and the text cursor is located in the note section of an item, then the viewport will jump to the top of the document in addition to moving the item.
    Reproducible in ca. 95% of cases. Observed on: Version 64.0.3282.119 (Official Build) Built on Ubuntu , running on Ubuntu 17.10 (64-bit)

  4. When moving the text insert mark down with arrow keys, starting in the last position in the second to-last line of an item, the last line below jumps over.
    Refers to an item, not to the note of an item. So, we need to create multiple lines in it using “Ctrl + Shift + Enter”.

  5. After cut & paste of a task, its link changes.
    Does not happen after moving it with Ctrl+arrows, or with “context menu → Move to …”.

  6. Scrolling with the mouse wheel or touchpad is only possible at the beginning of a drag&drop operation with an item.
    Means, immediately after the click-and-hold on the item, before moving the mouse pointer for a pixel after that.
    It would be very useful however to be able to scroll during a drag & drop at all times, as two-finger-scrolling is much more comfortable and precise than moving the item to the edge of the viewport and waiting for the document to scroll.
    The breadcrumb items at the top of the main content area should be viable drop targets during drag&drop of list items.
    It should be possible to drag&drop into closed items.
    Namely, by dropping on the item. A gray background behind the item’s text would indicate this case, in contrast to the gray line above or below the item when dropping between two items (like now).

  7. When trying to create a line break at the end of an item by pressing “Ctrl + Shift + Enter”, it will not work the first time.
    It will work the second time and afterwards though. And this is permanent: even after reloading Dynalist, it will work in the items where it has been tried before. So the “fix” is saved to the items.
    When splitting an item into two by pressing “Return” inside it, it should not be split if the only characters following the insert mark are whitespace.
    Instead, a new item should be appended, just as when pressing “Enter” at the end of the item.

  8. Search results do not change to include checked items (that match the search) when switching “Checked Items: Hide” to “Show” in case it was “Hide” while doing the search.
    It works as expected though when searching with “Checked Items: Show” set, and then switching back and forth between “Hide” and “Show”. Since there is this difference, only one of the behaviors can be right. Namely the one when searching with “Checked Items: Show” set.

  9. After deleting ones Dynalist account, a user will still appear in documents shared with that user as “Name (name@example.com+tHy-1vxemnzu)” or similar, and removing that user from the sharing settings of a document fails with “You entered an invalid email.”.
    As a workaround, one can choose “Unshare this document”, then share it again with all pripor collaborators except the bogus e-mail address of the deleted account.

  10. When sharing a document with “too many people”, the buttons at the bottom of the screen will become hidden and unusable as no scrollbar will appear as it should.
    As a workaround, zoom out using the browser functions.

  11. HTML hyperlinks will not be preserved when copy & pasting to a browser.
    The link will be inserted as Markdown source code. Other HTML in the rendered text, such as “** … **” bold formatting, will be inserted correctly (here, as bold text) when copy & pasting. So it’s not a systemic issue. Tested in Google Chrome, with pasting to Google Docs.

  12. The date format “1h”, “24h” etc. works but is not documented.

  13. “created:1d” should search for everything created within the last 24 hours, not within the last 48 hours.
    Currently, “created:0d” can be used to search for everything created within the last 24 hours. But that’s confusing, as “zero” of something is generally understood to be really zero, not “anything less than one”.
    There should be an indication of what nodes are being edited right now, to prevent data losses through concurrent edits.
    By having separate view and edit modes in Dynalist, it is possible to creates these indications in a more precise way as just scrolling in the document in view mode will not change the “what is being edited” indication.

  14. The main content area is always more than 100% wide.
    The fix, as implemented in our Dynalist userstyle: .is-desktop .Document { width: calc(100% - 67px); } instead of originally width: calc(100% - 50px).

Suggestions

  1. Listing the document creator as “Owner” in a document is not a helpful concept.
    It confuses people, such as: Will the documents I own be deleted automatically when I delete my account, or will collaborators still be able to access them if I shared them? And: How can I transfer ownership of a document? And: What can an owner do that a manager can not do with a document?

  2. The default key combinations for "Zoom in previous item"and “Zoom in next item” should be changed because they are confusing.
    Square brackets are already associated with zooming in (Ctrl+]) and zooming out (Ctrl+[) respectively. Which makes graphical sense, so it’s logical. But then they should not be associated with zooming in only in this other set of keyboard shortcuts (Ctrl+Shift+[ and Ctrl+Shift+]).
    Proposal: set “Zoom in on previous item” to Ctrl+Shift+↑ and “Zoom in on next item” to Ctrl+Shift+↓. This makes graphically sense, because the previous sibling item to zoom in on is (in a more zoomed-out view) always above the currently zoomed in item, and the next sibling item is below.
    In addition, the wording “zoom in” should be avoided to make the shortcut more intuitively understandable in the help text. Because, zooming in implies focusing on a higher level of detail, while here the focus keeps on the same level of detail but is moved to the previous or next item. So instead, describe this function as “Move zoom to previous item” and “Move zoom to next item”. Or even “Move zoom one item up” and “Move zoom one item down”.

  3. There should be a “view mode” similar to to the default mode in FreeMind, where one has to press a key to enter into edit mode.
    This view mode should either be the default, or could be selected by the user at any time (while being by default in edit mode, such as after opening a document).
    Proposal for keyboard shortcuts: Leaving edit and entering view mode would be done by pressing “Esc”. Leaving view mode and entering edit mode would be done by pressing “Enter”.
    The advantages of a “view mode” include that navigating around with the keyboard is way more comfortable and optically more pleasing. Instead of having to move the cursor by a varying number of lines to move move to the next item in a list, one would only have to press “↓” once. Also, since key presses are not meant to write letters in view mode, more keys are available for shortcuts, such as “Space” (as a large, simple to reach key) for opening and closing a node.

  4. All punctuation should also be considered as ending a tag (@tag or #tag), not just a space character.
    Tags should only be able to contain alphanumeric characters plus “-” and “_”. The first character not of these would mark the end when parsing for tags.
    The current implementation is a bit like this, but inconsequential: “,” will terminate the tag, but not “.” or “)”.
    Without this implementation, it is not properly possible to “use tags like words” in the text, as one can’t use normal punctuation after them, having to insert a space before. This is ugly.
    Seemingly, the only reason for the current implementation is that "#tag " can be used to search for just a tag and not for other tags that start that way, for example “#tagtag”. However, that is a hack. People often accidentally place punctuation after their tags, and in some cases such as for appending “,” the tag-recognizing text backgrond formatting will show this as ok. However when clicking such a tag, it will automatically search for "#tag " and not find that “#tag,” occurrence.
    When clicking on a tag to search for it, the search should result in “tag:#tagname”, not in "#tagname " as currently.
    Because the current search can’t find cases where the tag is followed by a punctuation character, such as “#tagname,”. Just “#tagname” can’t be used either, as it would also find “#tagname-plus-something”. So we need a new search operator.
    To make using the new operator simple: when entering something into the search box that starts with “#” or “@”, proposals should appear according to the currently existing tags, using the new “tag:” search operator.

1 Like

Forum bug: There seems to be no way to include the numbers when quoting or copying from the above post. Also, if I copy some text into Dynalist, I get:

image

This does not seem right to have the extra blank parents. Also, the line break between “in a row.” and “The following” was lost.

To the original author: #2 seems clear but what do you mean by “moving the text insert mark up”?

“Text insert mark” means the little vertical blinking line that marks the position where the next character will appear when typing. Moving it up refers to pressing the “Arrow Up” key to move it to the line above it. (There might be a better term for this thing in English, but I don’t know it …)

1 Like