Jump to content

Ben Newcomb

Level 1
  • Content Count

  • Joined

  • Last visited

Posts posted by Ben Newcomb

  1. gazumped - The issue I'm describing occurs without an existing lowercase counterpart.


    For instance, my existing tags that start with r might be:






    Then when I attempt to create ReadItLater, the autocomplete functionality finds those 3 when I type R and immediately changes it to lowercase, so what results is a tag that reads readItLater, because the first character was "case folded" to match the lowercase list while I'm typing, preventing me from creating anything that starts with uppercase R unless I arrow key left to replace it manually.  Even if later as I'm typing, there is no longer a match for "rea", it keeps the case folded version intact.  It's trying to correct duplication at the character level during entry instead of waiting to evaluate duplication when I'm finished writing the tag.


    This wouldn't be terrible if when I'm done typing the tag and there is no match found for the case folded version, it would revert to the explicitly typed text.  That might be another way to handle it.

  2. The Problem


    When I attempt to add a new tag to a note (as in one that I haven't used before), ReadItLater for example, Evernote automatically modifies my uppercase 'R' to a lowercase 'r'.  The list of existing tags that start with lowercase 'r' are in the suggestion list, but it won't let me create the uppercase 'ReadItLater' unless I arrow key left and replace the letter after I'm finished typing the tag.  The effect is the same from upper to lower and ultimately depends on the contents of the tag cloud.


    The Solution


    When the user initiates typing a tag in the "click to add tags" location and the trie is fetching results, don't case fold the text that is being typed to match a list result.  Exact matches would be fine and would still go a long way toward preventing duplication.


    The Case for Casing


    I realize this could be perceived as an edge case due to the irrelevancy for people with mature tag clouds, but I don't see that as ample justification to permit potentially confusing and/or frustrating both new and existing users that desire uppercase in their tagging system.  Tags are, from what I can decipher, case-preserving but case-insensitive when it comes to search.  In my humble opinion, varying case can be a powerful technique for separating concerns among other tags in the cloud, so I don't agree with other posts requesting all lowercase.  


    The users and the platform would benefit from fortifying the case-preserving use case with a fix to the client that reflects the intention for tags to be case-indiscriminate throughout the entirety of the lifecycle. It's also my belief that this change would increase the tolerance of deviations in naming behavior, ensuring the perpetual utility of the platform.


    The Screencast: http://screencast.com/t/CLGoNlEd


    Thanks for your consideration,


    Ben Newcomb


    I would like either your blessing(you got a few seconds to help?), or suggestions based on your experience that will elevate the discussion.  Does this sound good Mac users that want Mac level of attention to detail?  I know there are many Mac users that are from unix backgrounds, so naming using uppercase just makes it harder on you at the terminal.  Is that you?  "I use lowercase", you say?  Can we agree on a goal for clients to reflect the capabilities of a cloud platform?

    I use Evernote all day most days.  It doesn't always bite me, but I'm growing/changing my tag scheme rapidly right now so it bites me every day.  Please help me get this looked at by Evernote.

  • Create New...