(Azerty keyboard) @ and # typing are deactivated in Dynalist?

🐛Bugs
1

Steps to reproduce

Typing @ or # anywhere in Dynalist web or Dynalist desktop
(AltGr is involved on my systems: Azerty keyboard)

Expected result

Character @ or # appearing, and tag feature activated

Actual result

typing @ : nothing at all, as good as deactivated
typing # : full text of list item is turned to bold

Environment

Two computers (desktop, notebook) Windows 8, French, Azerty keyboard (probable cause?) - tried french and belgian layouts, same problem.

Additional information

Tried Opera, Chrome, desktop version of Dynalist, same problem.

Additional comments

2

Can’t reproduce this.

Tags are on the document-level: if you are in a document that has no tags in it yet, there will be no tag completion because there’s nothing to complete.

Try this:

  • Enter a @ or # tag and hit enter
  • On the next line, type @ or # and see if the tag dropdown appears
3

Do you use an AZERTY keyboard?

> Enter a @ or # tag and hit enter

I’d like to. That’s exactly the problem. As mentioned in my post, it’s impossible for me to TYPE a @ or a # when I’m in Dynalist.

4

To be perfectly clear, my problem has nothing to do with the tag dropdown list. It has do do with the impossibility to type the two characters needed for the tag creation or management: @ and #.

I suspect that Dynalist developement has not properly taken AZERTY layouts into account. These keyboard layouts rely on AltGr to type many special characters like #, @, ^, }… and when in Dynalist, all special characters using AltGr seem to be entirely deactivated. Only characters NOT relying on AltGr are available.

This is something I have never encountered in more than 30 years of computing… and it frustrates me because Dynalist seems to be so outstanding, and i can’t use it! :frowning:

5

cc: @Erica #20charlimit

6

I got down to the root of this after exchanges with Erica.

It was not very well explained (sorry but it’s true) that the root problem is that Dynalist shortcuts using Ctrl+Alt+[upper numeric], which are used for formatting headings (Ctrl+Alt+1, Ctrl+Alt+2 etc…), actually REPLACE the relevant AltGr combinations because of the way keyboard combinations work.

So on an Azerty belgian keyboard for example, AltGr+2 (used for typing “@”) is actually the same action as Ctrl+Alt+2, and thus typing @ is impossible. Typing AltGr+2, instead, calls some heading format shortcut.

Seriously. Don’t mess with AltGr. We need it. The whole world is not made of QWERTY users. And if you really want to mess with it, at least EXPLAIN in plain terms the Ctrl+Alt issue, instead of proposing half-baked band-aids like changing only a couple of shortcuts if you have a french or czeck keyboard.

Takeaway message, the solution for all AZERTY users is to change ALL of the Ctrl+Alt+numeric shortcuts in the options. What I did. Pfew.

7

Thanks for your reply.

First of all, please do not act like we’re here to make your day harder. That doesn’t help with communicating or solving the problem.

You said:

where I sent you a link to the help page (http://help.dynalist.io/locale-shortcuts/), you said that you’ve read it and thought it’s not relevant.

The first paragraph wrote

If you’re using a keyboard layout that’s not English, default shortcuts may interfere with your normal usage such like typing a certain character in your language. For this consideration, we’ve changed some shortcuts for the following keyboard layouts.

I think it clearly describes your problem (you’re using an non-English keyboard layout, and you’re having trouble entering certain characters). I agree it doesn’t explain why this option is needed, but I don’t think it’s necessary to teach people a history and technical lesson on our help center page.

Your second point seems to be that

Well, we never intended to. There are so many keyboard layouts in this world that we cannot design a shortcut system that work for all of them. After we designed the shortcut system, it’s bad to change it either, since many users have already gotten used to the existing shortcuts.

So after discovering the keyboard layout problem, we added this option. It worked fairly well. From time a time a user would ask us about it and go home content with the solution. An example: Translations - Language option - #2 by Milosz_Mista

We have nothing against non-QWERTY. If anything, we tried to embrace them by adding these options so it’s possible for non-QWERTY users to use Dynalist. It makes us sad and hurt that you think we’re messing up with AltGr.

Thanks the patience and understanding. Have a nice day.

3 Likes
8

Yes! Excellent reply … don’t let curmudgeons get you down.

9

OK, maybe in my frustration, I came across as a jerk. That was not my intention and for that, I apologize.

Let me first say that I’m in absolute awe before the fantastic Dynalist system, which has the potential to be the very best Todo system out here. Maybe it already is. I’m not familiar enough with it yet, to make such a statement. But I love it.

Also, I’am amazed at the fastness of your (Erica) responses to me. You seem buzy as a bee and able to do a hundred things all at once. This is great and I appreciate the will to help.

This said, if you focus on the substance of my criticism rather than on the tone, you’ll see that I’m also trying to help you actually! Because I think you don’t understand the very nature of the issue.

Most potential Azerty users trying out the Dynalist demo out of curiosity, trying to type @ or # as explained in the tutorial, and seeing that it’s simply impossible, won’t even ever go further than that. They’ll just say “it’s broken, it doesn’t work, no use, next please”. They’ll just move on to the next thing. They’ll be lost to Dynalist.

Because among Azerty keyboards users, how many other testers of the demo are gonna be like me, willing to go the extra mile trying to understand WHY I couldn’t type @ or # in the Dynalist demo?

  • checking that the keyboard is not defective
  • trying the desktop version - no go
  • trying on another computer - no go
  • trying with a different keyboard - no go
  • trying with different browsers - no go
  • googling about the Dynalist keyboard options
  • subscribing to have access to the keyboard options
  • try the french layout and see it doesn’t help
  • consult several pages which at first glance, seem to describe an entirely different problem (because it doesn’t specifically mention the AltGr issue and seems at first glance, to be entirely focused on problems with heading format shortcuts)
  • asking for help by email
  • asking for help on the forum
  • when not understanding what I’m explained, insist until I finally get to the bottom of it and realize the misunderstangings

You have to be really motivated. This has taken me more than 3 hours, and I went through it because I was able to see the potential of Dynalist. Who else is gonna go through the same process?

> From time a time a user would ask us about it and go home content with the solution.<

Yeah, the couple of users who, like me, were so eager to get to know Dynalist better, that they went the extra mile to solve the issue. I bet that there were many more out there, actually, but you never heard from them, for the reasons I explained…

From an Azerty keyboard user perspective, you guys DO mess with AltGr. Once again, let me explain that on our keyboards, AltGr+2 for instance, is a basic, necessary combination which is used by absolutely everyone, everyday, to write email adresses. It’s not some “shortcut” with options, it’s typing a basic character. One shouldn’t have to change options in a software to be able to type such a basic character.

When i said that you guys didn’t properly take the Azerty layout into account, what I mean is that you choosed to implement -by default- Ctrl+Alt shortcuts, which automatically break the use of the equivalent AltGr characters typing on Azerty keyboards. You could have chosen to make default Ctrl+Shift instead, which is what you tell Azerty users to switch to.

I guess it’s far too late to change the default formatting (headings) shortcuts of Dynalist since all your early users would be hurt by such a move.

So here is my 100% constructive criticism: right from the start when someone is accessing the Dynalist demo, or first access to Dynalist after subscribing, put a friendly warning similar to “Hello, welcome to Dynalist. If you’re in Europe and/or don’t use a QWERTY keyboard, some characters typing may be deactivated in Dynalist. You’ll have to change some shortcuts in the options to access all characters on your keyboard, explanations on this page /link/”

Have nice day.

Oh and @Kamal, no need for name calling. I don’t think that it’s showing a more constructive attitude than my own. And it adds about zero to the discussion.

1 Like
10

True, labeling someone as a person is never a good idea. Rather, the language came across as curmudgeonly.

1 Like
11

I accept that.

1 Like
12

Okay that disqualifies you from being a curmudgeon. :grinning:

1 Like
13

I see. The warning would be much more appropriate if we can try to detect what the keyboard layout the user uses. For example, it’s possible to “sniff” what browser the user uses, but it’s not currently possible to know what keyboard layout one uses.

I think the message helps, but to solve the problem you pointed out, it’s not enough. Have you noticed the onboarding messages (a few gifs with tips) that we display? About half people finish them, and about half just close them right away. I think it’s because people tend to want to jump onto it without further wait… figuring it out while using it is more “efficient”.

Speaking of messing up with AltGr, in that sense we also messed up with all Mac users. We decided to make Alt+C toggle visibility of checklists and Alt+N toggle visibility of notes. Little did we Windows user know that Alt+C and Alt+N are used to enter symbols on a Mac (relevant bug report: "Toggle notes" shortcut doesn't work on OS X). We should really get to fix all that too.

The best solution I can come up with is to leave these set headings and set color label shortcuts empty (no shortcuts by default), and let the users figure how to coordinate the shortcuts. I think the shortcuts being crowded is a result of treating all shortcuts as equally necessary for everyone, where in fact some people do not need some shortcuts and thus should not suffer from the conflict of shortcuts.

The problem with this solution is that shortcut customization is Pro-only right now. It’s pretty bad, in my opinion, to tell users that in order to fix shortcuts, you need to upgrade and customize the shortcuts. It’s not an easy decision to just make another feature free either (some would argue Dynalist is a little too free right now).

The above is our current status/progress on this issue. I know in the end it’s our responsibility to solve this problem, but maybe you can suggest something that could help us out.

Lastly, I apologize if I assumed your intention earlier.

3 Likes