The curious case of disappearing Polish S
medium.com
medium.com
That one of the developers at Medium could run into such a glowing example of one of the many reasons it's nasty to override browser behaviour, and take the lesson from it that oh hey, we just need to make our override logic more complicated... the blindness and idiocy and sheer bloodymindedness of this response I just can't even.
Medium: YOU'RE DOING IT WRONG.
In-browser WYSIWYG or markdown editing is not good UX design. Period. Full stop. It's never been better than an offline text editor, and when you try to present a cross-browser experience, this is what inevitably happens.
But.
It pains me to say this: what else would you want to have happen when a user presses Ctrl+S?
Are they really wrong, here? Wouldn't a user expect a "save blog" on Ctrl+S? How would I explain to a non-tech user why Ctrl+S works in Word, Excel, Powerpoint, but not in Medium?
1) I'm old enough that I've programmed the computers with the front panel switches bit by bit, but I've never used "Ctrl-S" as the "fast save" when writing documents. I don't know actually anybody who does. Autosave in Word functions as it should (not needing any user action) since at least 1998. My code editors and IDEs all do autosave too before compiling. What's the auctual benefit of ever using Ctrl-S in the middle of writing?
It becomes a mental tic, an "I've finished the paragraph" instinct. And I'm very glad medium handles it.
Can you explain this? Is it common to use an IDE that autocompiles every time it autosaves?
I, for one, used to have this habit. The notion of "not knowing anyone who uses Ctrl + S" is a bit funny - are you really aware whether people around you do this or not? How does it come up?
[Dr. Watson's voice] He does that thing again!
My first reaction: How else do you save?! You mean you actually take your hands off the keyboard, and click the floppy icon in a toolbar? Or even.. click on File > Save? Seriously?
I think this assumption as a very strong population bias.
With the people I work with.. it's all about keyboard shortcuts. If you don't know your basic keyboard shortcuts, you're too slow. But then again, I work around people with super customized Vim and EMacs configs and people who live in Photoshop/Illustrator all day. You just can't be productive in those environments without keyboard shortcuts.
For me, users who don't do "Ctrl-S" to save are certainly a minority.
For this particular default I see no problem in overriding it. I'm sure there's only a minority that routinely uses ctrl-S to save a lot, but essentially nobody uses ctrl-S to save a web page that contains a document they're in the middle of editing, given how esoteric that is and how unlikely it is to produce a useful result.
That's not to say that overriding defaults is good in general. But there's no need to be consistent about it. Overriding ctrl-S is totally different from overriding the arrow keys, for example.
I ought to keep a shortcut to that on my desktop.
It often wrecks the layout, but I tend to print to PDF rather than deal with saved html files.
Regarding the .webarchive, I think IE supports another type of "web archive", with a .mht ending.
No fucking excuse.
Too used to G+ which fails in this case.
And not to mention google plus, that swallows Ctrl+PgDown and Ctrl+PgUp, which happen to be shortcuts to move through tabs. So you are moving through tabs, then you suddenly stop, and you have to reach for the mouse.
But what's really silly is that the browser actually allows a webpage to override such a basic shortcut like F5.
Worst of all, I can't seem to find a way to alter the keybinds, or (more importantly) the mouse-5-means-go-back gesture.
I agree with you that websites shouldn't override useful browser behavior, but I'm OK with websites restoring CTRL+S to it's rightful meaning of saving my work.
Ctrl-S says to your browser "I want to save this".
I find the save dialog useless for web browsers as well, but I think preventing its use is a bad idea in general. Overriding the browser's shortcut is uncomfortable. For example, wordpress likes to capture cmd+<number> to change the font style, but that's how I usually change the active tab. It also disables ctrl+tab, the other way I use to escape while the text area is active.
People use their browsers and have their workflow in them. Breaking them needs to have a really good excuse. http://xkcd.com/1172/
On second thought, I'll be glad when I don't have to know that.
I think browsers need option to disable key hijacking.
I dunno; I really preferred the alternative I used to have: reading email in a proper email client. The only reason I use the web client now is that it's easier when I'm also using my phone to read mail away from my computer. And I'm strongly considering just returning to desktop-only email; that's how much I miss reading mail in gnus.
And I think there was some trouble with IMAP at the time too, so the path of least resistance was to just use the web client on my desktop. But, as I noted, I'm thinking of going back.
The very same bug used to be present in early Windows mobile GPU drivers - with global hotkeys making it impossible to enter Ł (with Intel GMA 950) and Ć (with ATI Catalyst). Being a Polish geek, I used to earn lots of free dinners from frustrated friends who were forced to copy-paste those letters on their brand new laptops. Funny how the same bug recurs in different types of software due to an obscure locale-dependent edge case - and it's much less known than, for example, the Turkish dotted/dotless I.
Not just the early ones, no :)
Polish competitive Scrabble player here. It's not so much hate as a love-hate relationship. While it can be frustrating to be left with a vowelless rack containing a Ź in the endgame, for the most part these letters are quite desirable. Indeed, three of them (Ą, Ę, Ó) are vowels worth 5 points each, and only two of them (Ć and Ź) don't appear in any two-letter word. Even the Ź is fairly easy to get rid of, given an open enough (read: not completely blocked) board. They're nowhere near as irritating as the Q (and to a lesser extent Z) in English Scrabble.
Did we? I dare to say that your historical account is inaccurate. We stuck to our traditional layout for a while. What does it matter if the keyboard wasn't customized in physical sense anyway? You should be looking at the screen, not at the keys. If I recall well, Polish typewriter layout (PN-87) was still available on Windows 95/98. The now prevalent >Alt + something< one was called "programmer's layout", and the name itself indicates that it wasn't originally thought of as everyman's layout.
Domestic software certainly used the typewriter layout - for instance http://pl.wikipedia.org/wiki/TAG_%28edytor_tekstu%29, once a very popular word processor for PC, last version released in 1996.
The typewriter layout finally got extinct, but what spelled its ultimate demise was the internet, I believe.
Early netiquette actually forbid using Polish diacritics, because of encoding issues - in that era you could never be sure whether the other person would read "gwóźdź" or "gw░¶d¶", so it was considered good practice to stick to Latin characters only.
Meaning that users didn't get to feel the pain of having to press Alt + whatever all the time, and so they got hooked on default QWERTY.
As the last of Mohicans, I use the typewriter layout to this very day (for typing in Polish; I alternate), only I had to recreate it myself (using Microsoft Keyboard Layout Editor)*
It allows for much faster typing in compare to these inconvenient right-Alt shortcuts. Swapping Y with Z by itself is a win for a Polish speaker (writer), given that Z is much more common in Polish. While its frequency is at mere 0.07% in English, it reaches 4.9% in Polish, placing it in the top 10. Thus putting it under the weakest finger of all - your left pinky - isn't very considerate.
-------
* Funnily enough - I'm not flame baiting - when I decided to try Linux, hailed for its customizability, I found out that recreating my favorite layout wasn't as easy. I got lots of advice on various forums, but noone had a simple receipt for me. Admittedly this was few years back.
It's way worse: it's installed by default up to (at least) Windows 7, along with a silent (no feedback!) Left Alt-Shift shortcut that switches the keyboard layout. Press it unknowingly and BAM - suddenly your diacritics don't work anymore and Y/Z are swapped. Annoys the hell out of an Average User.
PS. I'm not saying that the layout was bad - just that there shouldn't be a magic shortcut for a "break my keyboard now!" feature.
PN-87: http://commons.wikimedia.org/wiki/File:KB_Polish_QWERTZ_PN87...
214 is some computer-era invention: http://charsetplus.tripod.com/Keyboard/Latin/PL-214.htm
I agree that the alt + shift shortcut is sneaky, but Microsoft wasn't exactly known for its great UX expertise.
It's been frustrating the hell out of not-that-savvy users who would often restart their machines to "fix the keyboard" :)
This is really interesting.
As a late-comer to Polish (native British), I've only learned on the right-Alt layout, and the typewriter layout initially gave me The Fear just looking at it.
Then I tried to see how quickly I could type Łódź, and yeah, I think you might be right about the pain - the typewriter layout looks like it should work much better.
For what it's worth, I'm an unconventional - yet effective - touch-typer, and use my left ring-finger for both the Z and X keys. Typing my ZŻŹs isn't too painful.
Type "Szczecin" (my home city) 10 times, and then "Sycyecin" - that's the feeling you'd get on PN-87 :)
Obviously QWERTY isn't a very good keyboard layout to start with. Putting all the letters of the word TYPEWRITER in the top row (to make it easier for the first salesmen to demonstrate the product) wasn't done with everyday user's convenience in mind, English or otherwise.
Hence all these alternatives, such as the most popular Dvorak layout (but also Colemak and plenty others). Which are, however, optimized for English, so a Polish typist wouldn't probably benefit from switching all that much.
The workaround is typical of web stuff as well: deal with the symptoms one by one while leaving the underlying problem unquestioned.
Webapps may need low(er) level access to keyboard for legit reasons too. Years ago I was working on webapp that teaches 10-finger typing. It needed to know 'pressed' states of keys like Shift and Alt. There were various browser differences to work around. Luckily the app didn't need to support Polish layout.
I get a nag screen when videos in the browser go full screen, telling me loud and clear that expected behaviour is changing and telling me how to get control back. When a website overrides keyboard controls, the first I know about it is when I can't scroll properly, or switch to another tab, or go back, or close the window that's yelling at me and making my machine thrash ...
Disruptively changing modes without notification violates fundamental rules of interaction design, affordances and basic security. How is that okay?
Split out commerce and media while you're at it.
The present model's working increasingly poorly for me.
Even if the browser is providing your entire desktop experience, you should be able to switch applications or close them in a predictable way.
When was the last time ANYONE truly used Ctrl-S to save the webpage as HTML? And why would my inability to do it with a keyboard shortcut be a dangerous problem?
Perhaps it's my windows upbringing, rather than mac, but Ctrl-F4 / alt-F4 are my preferred window/app closers, and I wish dearly I could unmap the other shortcuts sometimes.
But I see I'm in the minority here, thinking software should be predictable and leave the user a sense of control, so feel free to disregard my opinion.
But of course the OP continued to make the same mistake, which I pointed out way up at the beginning of this branch.
Don't break user controls.
Seriously. Fucking. Annoying.
The tendency of sites to also force all links to open in a new tab is similarly annoying. I've got the means to choose. Leave it to me.
Another argument for disabling JS pretty much everywhere.
The annoying thing is: if there were a header the browser could send to the server - "JS is turned off" - it'd be trivial to serve a pre-rendered full HTML response.
It's what plenty of e.g. Angular sites do to support the various search engines. Adding one more item to the list of "serve a prenderefndered view if X is true" checks wouldn't do any harm.
Looking at your code, you're also blocking Win+S on Windows and Ctrl+S on Mac for no good reason.
Extrapolating from your experience: What about shift key?
When you decide to block default behaviour, do your research, not everyone is on a Mac with American layout.
How is it that we're well into the 2010's and I still can't get (my own) emacs keybindings in Firefox/Chrome without some silly extension that doesn't work 100%?
I can download uzbl, dwb or any other browser like it and edit my keys as I see fit, for emacs/vim keybinding behavior, without limits.
I don't know about Medium, but I also find that most websites have these hidden shortcuts and you can't even re-map those. Why is there no choice in all this? Browser developers and websites can spend hundreds of thousands of dollars on UX/UI research, but can't figure out that I might want to re-map some keybindings.
I've seen the slashes-as-parentheses on many (mostly older) documents before, but never knew why. Suddenly this makes so much sense. Unfortunately what makes less sense is official translators still using // for () these days.
Currently living in Germany I actually find our approach to special characters really elegant. I was surprised how much different are German (and French) keyboards.
I wonder whether these different layouts can affect for example your programming prowess.
The Russian keyboard layout is similarly annoying as the keys are simply not where you expect them. On most systems you can install a phonetic keyboard driver and kinda roll with it - that is, until you have to use a real Russian keyboard, at which point you have to re-learn from scratch.
Oh, and don't get me started on AZERTY and QWERTZ. What were they thinking?!
The point is that on some layouts you can start typing right away; on other, you have to jump through hoops and get frustrated. Not that we can do anything about it now. Historical reasons.
In fact, on the German keyboard, the circumflex (ˆ), acute accent (´), and grave accent (`) keys all compose with the next entered character. (That is, á is entered by pressing ´, then pressing a.)
Windows also offers an "international" keyboard mode which allows composition in a way similar to the German keyboard. [1]
Even early US computers (and typewriters before them) had relatively varied keyboard layouts, but somehow[1] they still managed to converge into the standard 104 key layout that we have today in the early 90s (and that is a quarter of century ago). What we have missed is the extension of that convergence into international community.
> There's no technical reason to not just have composable meta-keys, excepting maybe the pure number of existent diacritics [0].
> In fact, on the German keyboard, the circumflex (ˆ), acute accent (´), and grave accent (`) keys all compose with the next entered character. (That is, á is entered by pressing ´, then pressing a.)
Dead keys are fairly good solution. Indeed I counted 19 dead-key diacritics on my countrys official standard keyboard (which almost nobody uses).
[1] IBM PC/Wintel monopoly probably helped
(I'm half joking, half serious - I grew up with a qwertz DE nodeadkey layout which certainly doesn't look sane from the outside either and exclusively use the US one now)
Honestly, Polish pronunciation isn't that tricky, trilled Rs aside.
What're their names? Wikipedia has a great guide:
It goes both ways; for example, how many Poles have well and truly mastered all of English's tenses?
Heck, personally I think getting the definite and indefinite articles right consistently is a hard enough struggle.
just saying.
Things get really hairy in the browser when you start talking about JavaScript, the keyboard, and international support.
For example, there is no way to know what keyboard layout a user is using. With Primrose, I guess based on the user's default language, but even that isn't perfect as a lot of not-US English speakers just show up as "en", with no further locale description, so I also provide a select list with all of the available choices.
It's very difficult to know with certainty what character a user is intending to type. KeyCode 51 with no modifier keys is "3" on most keyboards, except French, where it is "#" (they essentially swap the casing of the number row).
The number pad numbers send different keycodes than the number row numbers, but the number pad arrows (if you turn off the numlock) send the same keycodes as the arrow keys.
In languages with deadkey support for diacritics (such as French and German), the deadkey keyCode isn't sent until the second key is typed. Then, they are sent in rapid succession.
There is absolutely no way to know what is going on with IMEs.
And there is no reliable way to interact with the soft keyboard on mobile devices. Some versions of soft keyboards don't send the arrow key keyCodes. There is no standardization of what keys should be available, so you can't guarantee that your user will easily be able to type your shortcuts (I know of only one keyboard on Android that even has CTRL or ALT). And it's nearly impossible to know how much space the soft keyboard is going to take up on the screen (you can figure it out on Android, eventually. It's impossible on iOS.).
So, you have one of two choices, if you're trying to implement any sort of browser-based application that involves heavy use of the keyboard.
Option 1: You can either create a hidden, surrogate text area in which the user actually types, unbeknownst to them, and run a sync process between the content they type and the content you display. This has several problems: you have to wait for keyUp to activate shortcut commands. The sync process can be costly (especially in the context for which Primrose exists: WebVR) and it is difficult to keep the cursor view in sync when dealing with mouse/touch interactions. Oh, speaking of pointer actions, you have to make sure your surrogate text area is positioned exactly under the displayed text field, with the text appearing the same apparent size as the displayed text, because when it gains focus the browser will scroll the view to it.
But it will work, except for certain use cases. It won't work well on mobile, and it won't play nicely with WebVR (which is the entire point of Primrose, anyway), especially for Asian users using an IME.
So Option 1 isn't a good option.
Option 2: completely reimplement the key input stack, i.e. create all the keyboards and soft keyboards and IMEs your users will ever need. Completely ignore what the OS and the browser tell you, take only the raw keyCodes, and reconstruct what is happening. It's a lot of work, a lot to debug, but at least there is a path to actually solve every problem.
It also has a rare property of coming with two alphabets - cyrillic and latin.
And on top of that you must use the same criterion for the S-C language, not counting Slovenians, Albanians, Macedonians, etc who know the language but don't use it much anymore.