CintaNotes Forum

Oct 22, 2014 - Version 2.8.1 Beta1

In this version:

Enhancements:

• Search history: Current state always displayed in the history menu

Fixes:

• Tag sidebar: wrong tag count display
  
• Notes list: Paragraph formatting not visible in note preview after edit
  
• Search history: Unwanted states got inserted into history (implemented Thomas's suggestions)
  
• Simplenote sync: in some cases tags could get deleted on upload
  
• Notebook title appears in lowercase after closing another notebook
  
• Tag suggestion list is unsorted
  
• Deleting a section doesn't move its notes to the Recycle Bin

Download:
Installable: CintaNotes_2_8_1_Beta1_Setup.exe
Portable: CintaNotes_2_8_1_Beta1.zip

WARNING! BETA SOFTWARE! USE AT YOUR OWN RISK AND ALWAYS BACKUP YOUR DATA!

Did my best to find and fix the issue with disappearing tags, hopefuly it's fixed now, but since the issue was not reproducible there still remains possibility that the problem is still there. With your help in testing this version we'll be able to either reproduce the problem, or gain confidence that it is fixed. Thank you in advance for your invaluable help!

CintaNotes Developer wrote:Did my best to find and fix the issue with disappearing tags, hopefuly it's fixed now, but since the issue was not reproducible there still remains possibility that the problem is still there. With your help in testing this version we'll be able to either reproduce the problem, or gain confidence that it is fixed. Thank you in advance for your invaluable help!

Alex,

can you please tell, what you changed?! It would help on focusing while running tag related tests. Also a re-test with 2.8.0 would be possible to try to make this reproducible. Thanks.

Thomas

Alex,

the changes implemented in regards to the history management are a huge step forward

One or two minor bugs. Other than that it has become predictable and understandable what goes into history!

Issue 1

• search for "javascript ec6"
• change to "javascript harmony"

I had a situation when the search for "javascript ec6" did not make it into history. To reproduce i first reset search using Ctrl+F. Also i cleared the history, then enter "javascript ec6". Check result with Shift+Ctrl+BkSp. Press Esc to close popup. Press Ctrl+BkSp. Enter "harmony". Now, when you look into history the entry "javascript ec6" is gone, whereas "javascript harmony" (current state) is included.


Issue 2

At one point the history got partially deleted. Pretty sure i did not go back to the beginning of the queue, which would clear history. Not sure what i did exactly. I can not tell whether i might have switched to a single section and back to 'all', which can result in misunderstandings. I'll have an eye on it.

Thomas

The reproduction case for the missing tags that I reported in the 2.8 thread does indeed seem to be no longer reproducible with this beta It was 100% reproducible on my system with 2.8 and my notebooks, and I verified as such immediately before updating to this beta. Right after updating, I ran the same steps three separate times, and the tag count remained correct each time.

Chris

Thomas Lohrum wrote:can you please tell, what you changed?! It would help on focusing while running tag related tests. Also a re-test with 2.8.0 would be possible to try to make this reproducible. Thanks

Sure, I refactored tag use count caching and all tag deletion logic, including deleting autodeletable tags.

Thomas Lohrum wrote:the changes implemented in regards to the history management are a huge step forward

Great, was hoping for it!

Thomas Lohrum wrote:Issue 1
search for "javascript ec6"
change to "javascript harmony"

Presently, you need to do something to let CN know that your typing of search query is finished. One of:
1) Move focus away from search box
2) Press X to clear search

When you just change "javascript ec6" to "javascript harmony", CintaNotes has no way of knowing that "javascript ec6" was useful to you, and you didn't intend to write "javascript harmony" from the very start.

I had a situation when the search for "javascript ec6" did not make it into history. To reproduce i first reset search using Ctrl+F. Also i cleared the history, then enter "javascript ec6". Check result with Shift+Ctrl+BkSp. Press Esc to close popup. Press Ctrl+BkSp. Enter "harmony". Now, when you look into history the entry "javascript ec6" is gone, whereas "javascript harmony" (current state) is included.

Yes, Ctrl+BkSp doesn't trigger adding search term into history if you didn't move focus away from the search box. If it would, it would be inconsisent with pressing simple BkSp multiple times.

Issue 2
At one point the history got partially deleted. Pretty sure i did not go back to the beginning of the queue, which would clear history. Not sure what i did exactly. I can not tell whether i might have switched to a single section and back to 'all', which can result in misunderstandings. I'll have an eye on it.

Ok, thanks.

usbpoweredfridge wrote:The reproduction case for the missing tags that I reported in the 2.8 thread does indeed seem to be no longer reproducible with this beta It was 100% reproducible on my system with 2.8 and my notebooks, and I verified as such immediately before updating to this beta. Right after updating, I ran the same steps three separate times, and the tag count remained correct each time.

Chris

Glad to hear that Chris! Thanks!

CintaNotes Developer wrote:

Thomas Lohrum wrote:Issue 1:
search for "javascript ec6"
change to "javascript harmony"

Presently, you need to do something to let CN know that your typing of search query is finished. One of:
1) Move focus away from search box
2) Press X to clear search

When you just change "javascript ec6" to "javascript harmony", CintaNotes has no way of knowing that "javascript ec6" was useful to you, and you didn't intend to write "javascript harmony" from the very start.

I had a situation when the search for "javascript ec6" did not make it into history. To reproduce i first reset search using Ctrl+F. Also i cleared the history, then enter "javascript ec6". Check result with Shift+Ctrl+BkSp. Press Esc to close popup. Press Ctrl+BkSp. Enter "harmony". Now, when you look into history the entry "javascript ec6" is gone, whereas "javascript harmony" (current state) is included.

Yes, Ctrl+BkSp doesn't trigger adding search term into history if you didn't move focus away from the search box. If it would, it would be inconsisent with pressing simple BkSp multiple times.

Alex,

that's a point. Still i think it is a reasonable compromise to distinguish BkSp and Ctrl+BkSp. BkSp only can be considered as correcting a typo, even if pressed multiple times. Ctrl+BkSp however means, i did not find what i was looking for. Next i will try with a similar word. Occasionally i have such cases. When i eventually will find my notes, i use the other terms i used (which should now be in history) to update my notes, so next time i will find notes faster.

Thomas

Thomas Lohrum wrote:that's a point. Still i think it is a reasonable compromise to distinguish BkSp and Ctrl+BkSp. BkSp only can be considered as correcting a typo, even if pressed multiple times. Ctrl+BkSp however means, i did not find what i was looking for. Next i will try with a similar word. Occasionally i have such cases. When i eventually will find my notes, i use the other terms i used (which should now be in history) to update my notes, so next time i will find notes faster.

Let's suppose I write "to be or not to be" in the search box. Then I start deleting it with Ctrl+BkSp. After that the history will contain:
to
to be
to be or
to be or not
to be or not to
to be or not to be

Not quite what I'd want to have..

CintaNotes Developer wrote:

Thomas Lohrum wrote:that's a point. Still i think it is a reasonable compromise to distinguish BkSp and Ctrl+BkSp. BkSp only can be considered as correcting a typo, even if pressed multiple times. Ctrl+BkSp however means, i did not find what i was looking for. Next i will try with a similar word. Occasionally i have such cases. When i eventually will find my notes, i use the other terms i used (which should now be in history) to update my notes, so next time i will find notes faster.

Let's suppose I write "to be or not to be" in the search box. Then I start deleting it with Ctrl+BkSp. After that the history will contain:
to
to be
to be or
to be or not
to be or not to
to be or not to be

Not quite what I'd want to have..

I agree, though besides from being artificial, it does not look like a real usage scenario either. The request to save a history even when the focus did not change can be narrowed down to a change, when a new word gets added. For example:

to be or to be lucky
to be or not to be

The phrase "not to be" can be deleted by any means (BkSp, Ctrl+BkSp or even Del). Since "to be lucky" gets added it signals a change, where i want both items to be stored in history.

CintaNotes Developer wrote:When you just change "javascript ec6" to "javascript harmony", CintaNotes has no way of knowing that "javascript ec6" was useful to you, and you didn't intend to write "javascript harmony" from the very start.

It has a way of knowing that. It is the change in words.

Thomas

CintaNotes Developer wrote:

Thomas Lohrum wrote:Can you please tell, what you changed?! It would help on focusing while running tag related tests. Also a re-test with 2.8.0 would be possible to try to make this reproducible. Thanks

Sure, I refactored tag use count caching and all tag deletion logic, including deleting autodeletable tags.

Lol, good joke. I did some basic testing. Created, modified and deleted notes while adding and removing tags. Also using hierarchical tags. I did not observe any bugs or unexpected issues. I had tag counting activated in the sidebar. Looks good.

Thomas

Thomas Lohrum wrote:Lol, good joke. I did some basic testing. Created, modified and deleted notes while adding and removing tags. Also using hierarchical tags. I did not observe any bugs or unexpected issues. I had tag counting activated in the sidebar. Looks good.

Exactly, Thomas - good joke! I recently thought of creating a set of test suites for CN. The number of test cases I counted was huge!! And still many people regard CN as "simple" - I don't know if its an achievement or the opposite

Anyway, glad to hear that you've found no bugs - gives us hope that they indeed were fixed. Thanks a lot!

Hi Alex,

did you catch my reply here? http://cintanotes.com/forum/viewtopic.php?f=3&t=1922&sid=d0ca4d01de08d66ca083cc4134e56433#p9140

Thomas

Thomas Lohrum wrote:I agree, though besides from being artificial, it does not look like a real usage scenario either. The request to save a history even when the focus did not change can be narrowed down to a change, when a new word gets added. For example:

to be or to be lucky
to be or not to be

The phrase "not to be" can be deleted by any means (BkSp, Ctrl+BkSp or even Del). Since "to be lucky" gets added it signals a change, where i want both items to be stored in history.

It has a way of knowing that. It is the change in words.

Generally I tend to agree, however for me the notion of "change in words" remains somewhat blurry. Let's try to define it a bit more strictly. Please mark which of the following changes should trigger a push to history:
[ ] "blog about java" => "blogs about java"
[ ] "screen" => "screenshot"
[ ] "block" => "blog"
[ ] "java" => "lava"
[ ] "color" => "colour"
[ ] "almost simultaneus" => "almost simultaneous"
[ ] "almost simulation" => "almost simultaneous"

CintaNotes Developer wrote:Generally I tend to agree, however for me the notion of "change in words" remains somewhat blurry. Let's try to define it a bit more strictly. Please mark which of the following changes should trigger a push to history:
[ ] "blog about java" => "blogs about java"
[ ] "screen" => "screenshot"
[ ] "block" => "blog"
[ ] "java" => "lava"
[ ] "color" => "colour"
[ ] "almost simultaneus" => "almost simultaneous"
[ ] "almost simulation" => "almost simultaneous"

None. The latest implementation does a pretty good job, as confirmed before. It remains a difficult task to guess, whether the user did mean some slight modifications or a different search phrase. Resetting the entire search (Ctrl+F) does just trigger a save to history. The best match i can suggest therefore is to also trigger a partial reset (deleting a word via Ctrl+BkSp), even if this does produce your fancy "to be or not be" history

Thomas

Still I'm not convinced, sorry Thomas I can easily imagine some people filing this fancy to-be-or-not-to-be history as a bug. Let's try to find something else - Levestein distance, word count change, I don't know..

It seems to me - and it may just be because I am a little dense - that the history is now being massively over-complicated. Trying to divine a user's intentions as to whether they meant to change a word or not - and thus as to whether to include it in the history or not - is just not going to work, as CN is not a mind-reader.

My advice would be to keep it simple, and accept the fact that some users are going to find search terms in their history that they don't think should be there. Because the history is not saved - either when you change notebooks or close CN - frankly, I don't think this is a valid criticism anyway.

For me, all the examples Alex listed earlier should be in the history. They are changes - whether the user intended them or not (eg they made a typo) is irrelevant. The only one I would argue about is screen->screenshot - in this case, the user may have just been slow in typing the full word, and CN may possible have saved the history a little too early. If the user did something definite after typing the word 'screen' however (eg moved focus away from the search field, which demonstrates that it wasn't just slow typing), than both should be included.

Chris

Hi Alex,
Hi Chris,

thanks to you both for your valuable input. This discussion on what to "save or not to save" is not an easy one. In regards, that history might not get high overall attention by users, i'd argue not to put too much effort into this. I stated my points and understand i was not successful in providing a usable algorithm. Two more simple approaches could be: (a) some way of telling CN, that i want to save that state - which can be difficult to be understandable by users (b) store everything as Chris suggests, even typos, but allow for clearing items not wanted - item delete from history.

Thomas

Chris, thanks a lot for your great comment!

I have the last suggestion to make regarding this issue. I think it is worth a try.
Let a new state be recorded into history when there's been at least a 3 (or maybe 5) seconds timeout
since last character was typed.

Previously I have discarded this technique as unreliable, but now, coming to think of it
more closely, the timeout is a good evidence that the user is interested in what's being
displayed in the list.

Thomas Lohrum wrote:In regards, that history might not get high overall attention by users, i'd argue not to put too much effort into this.

I have to agree - I'm not sure how many people are going to make use of the history function. Just thinking out loud, I think if you divide CN users up into two categories (that is, power users and non-power users), I think the history function may be of more interest to the former group, rather than the latter. With that in mind, I wonder if there may be an alternative to the history.

Specifically, what about the ability to save queries? If you often make use of the same search terms, then being able to save a search and simply select it later (from a dropdown for example), would be more useful - that way, you allow the user to define what should be saved, rather than trying to guess their intentions. One of the functions of a history list is to select a previously typed entry. If you are only ever going to select that previous entry once, than yes - a saved query list will probably not be all that useful (it would take you more time to setup that query than it would to simply select it from a history list). However, if you start to select that item multiple times, you make the prospect of saved list much more appealing.

Chris

CintaNotes Developer wrote:I have the last suggestion to make regarding this issue. I think it is worth a try.

I would say yes, I agree - it is worth a try.

Chris