I don’t know how it works in other countries but the solution that has been found is to propose specific accents or forms by keep pressing on the letter, as it is with punctuation.
It is very effective but I can imagine that it requires some additional hours of work.
Ok, that’s a… bit more than I expected But numbers seem favourable to us. That’s 28 in total (including ÿ). I think we can find places for all. It’s another question how convenient they are to use.
That image you linked seemed very interesting and probably fast to use. It would be awsome if Purism would code that in later version.
What you may notice is, all the accents are now grouped in a single view somewhat logically (the three ô/ö/Ô should be next to / on top of each other and all the others in lines). The ÿ is farthest from right handed thumb since it should have less use but it could be placed in several places.
I think I calculated that all the characters are in the views (there were a couple of doubles [is “period” = “.” or some coding?]), but someone should check that. So, only the last view (eschars) was edited of the Italian version.
@leo-numethik do you think that would work well (enough) for daily French writing?
I think this is the most useful way to think because it became simple to add specific additional letters. For example, I can easily access ñ, ğ, ø, ß, etc, that I use sometimes for spanish, german, nordic words or typical maths notations. And it is super fast to type, including punctuation. In a sense it brings all the latin and germanic letters and symbols and all that remains is a matter of sorting to match the usual dispositions from each country.
Yes this is great.
The last thing is about the placement of the main letters. We usually dispose it like this:
AZERTYUIOP
QSDFGHJKLM
WXCVBN
Otherwise it would be totally functional this way. Even if the Android’s way I experienced until now is very smooth and efficient, as I said before.
Thank you for your time @JR-Fi.
@uzanto How about it, could you take this further now and submit?
(About 76 million native speakers and about 235 million daily, fluent speakers and maybe another 77 to 110 million secondary speakers would thank you )
I’ll do it tomorrow, it’s just place the m next to the l and send the request to purism gitlab? @leo-numethik what’s the most common special character do you use in french? because it can be placed in the main view next to the n, maybe ç Ç?
Thanks. You are the expert of us. I’m a bit in the dark what is needed and only assume that the placement change (length of line / number of characters per line) needs to be updated/edited somewhere. This layout was a mockup based on it.yaml.
No ahah. I was talking about the âÂ, êÊ, îÎ and so on, as I didn’t see it on the @uzanto’s screenshots.^^
Your last proposition is the best that we can achieve for now in my opinion.
EDIT: actually, the çÇ is not useful anymore in the fifth panel in my opinion. But it’s also a thing of habits. Maybe another french speaker could tell us if it makes sense for him.
I edited it again [to the last version above] and removed çÇ from the eschar view because they were already used. Also, because I had miscalculated (one too many characters in that row), and replaced with " ’ ". It’s a double as well, but might speed up writing when you don’t have to search for it from another view… or would some other character be even more useful (this may go to the area of “over optimization” at this point - can be changed later depending on feedback)?
One of the things we will be missing very soon is some kind of “best practices”. ATM we can take a look at the other layouts to learn how to make a good layout, but as things get more fragmented (with more layouts), it’s getting harder to find the “best” way to create a layout and have a consistent UX over different layouts (of similar kind).
For the German layout, it was quite easy as it doesn’t need a lot of special characters. I just had to take an existing layout and modify it a little bit. But even in this simple case I had to decide if I wanted to keep the German umlauts in a special layer (with “äÄ” as the switch key) or put them on the main layout. I decided to keep them in a special layer to avoid cluttering the basic view and avoid shrinking the button size. But that was just my personal opinion! It’s probably neither good nor bad - just a thing of personal preference.
Some small points I noticed as I made the German layout (and that should be consistent over all layouts IMO):
Do we want the switch key between numbers and letters to be upper case letters “ABC” as in the original US layout or lower case letters “abc” as we have it in some layouts now?
The preferences key (globe symbol) should probably be consistent over layouts and use the “special” outline
The view/button named “eschars” comes from the Spanish layout. For German I renamed it to “dechars”, but maybe we want a more generic name there? What about “accchars” for accented characters?
Are there other things I missed?
My general understanding of the key color in the layouts is this: All keys that produce a normal character/letter output are “light grey” and other special keys as the “settings” key, “bachspace” key and keys that switch to another layers like “ABC”/“123” are “dark grey”. I hope that this inference I made is correct.
The only very different layout at the moment is the Japanese Kana layout. I tried to add some comments in the YAML file to document some of the special things done there - hope that helps a bit.
Excellent points. They may not seem relevant to individual user or at the moment but later one they might start to irk, so it’s good to get them settled now. I’m happy with your points being here and agree with them, but I think a copy should also be submitted to somewhere in git and/or dev mailing list, maybe(?).
(and btw. I thought “eschars” was from extra or especial characters… )
Good idea - but let’s wait a bit until we have some more comments in this thread and can make a list of initial “best practices”. @dcz: What do you think about a “best practice” document in the git repos?
Interesting… that’s an example of how different people interpret the same code in different ways… then I’ll take a note to correct this in the next MR for the German layout. Your interpretation seems reasonable
What I think would be even more useful than best practices is a basic introduction and format description. As I’m putting all my effort to pack new features in, and you guys have figured it out already, it would be extremely cool to have such a document.
If anyone is already working on best practices, tutorials or whatever, please make a MR in the keyboard repo. If we later decide to use the main docs, we can move the files there.
But numbers seem favourable to us. That’s 28 in total (including ÿ). I think we can find places for all. It’s another question how convenient they are to use.
)
