Anno domini 2014, pocket devices have reached the power level of common personal computers if not superior, but low costĀ airline companies use theĀ atomic mass asĀ unit of measure Ā to check the weight of the hand luggage, which means I have to make a choice: the clothes necessary to survive the cold of Sweden (yes, in August) *or* my laptop.
I go for the drastic one, the laptop will stay home for the holiday, then I take off.

I’ve reached my destination, and during an idle time I come up with an idea for a new article, but my trusted laptop is 1800km far away in Rome … but it’s 2014, and a Galaxy Note 2 has got everything it takes to take on a simple task such as word processing, right?
Well no
We’re talking about WordPress 3.9 web and it’s mobile responsive interfaceĀ forĀ the backend admin panel to make contents. If you startĀ drafting an article with an Android device, using Google Chrome meaning the ultimate browser when it comes to web standards, these are some of the difficulties you will stumble upon your way to the publish button.
Impossible to paste formatted text
Maybe you want to quote something from the web, or a first draft was done in EverNote and something else was written in Gdrive, you mayĀ want to paste already formatted text in the visual editing tab to tweak contents later.
If you taphold in the point where you want to past things and then hit the paste command you will face an error popup advising to use a physical keyboard shortcut, the “please” is just for saying as there is no actual choice here.
The only way around this error is to useĀ the text only tab, which means we’ll be losing all bolds and stuff, including hyper links.
Error popup blocking with no way out
The error popup about the paste operation is a blocking modal, meaning that until you tap the OK button you won’t be able to do anything, but the popup box has a fixed width and more importantly isĀ position:fixed
Ā which means there is no way to scroll horizontally and reach the button.
The Note 2 is big enough to display theĀ button when rotating the device in landscape, but what would happen on a smaller device? The only option would be to navigate back the browser’s history, thus losing all work done so far, much blasphemy goes here.
Writing in landscape is impossible, the smartphone is mistook for a tablet
Virtual keyboards do a great job guessing which key you want to press given thatĀ there isn’t enough space to display a key as big as a thumb, thus a certain amount of error is in place because keys are really closeĀ to one another.
With landscape keyboard error possibility drops considerably thanks toĀ wider keys that are easy to press with both thumbs, which isĀ more usable to draft faster a text that is longer than an SMSĀ or a tweet, so I confidently tap theĀ content’sĀ Ā textarea
Ā , rotate the Note and I’m about to faint:
The header that in portrait mode was in position:absolute
is now fixed
, stealing away the little vertical space available, which is due to the smartphone breakpoint being set to a maximum of 600px of window width, a size that a 5,5, inches smartphone can easily overcome in landscape mode, only that the vertical space available is not 1000px but less than 400px.
Other than checking the window width it would be best to also check the orientationĀ that for media queries is based anyway on the ratio between height and width meaning it can confirm that the given width belongs to a tablet,Ā and thus if there is enough vertical space to accommodate sticky elements.
Width and orientation togetherĀ to check the device type are the only lifeline in a market where smartphones and tablets borderline gets blurred.
If we want to be even moreĀ meticulous we could also cross check theĀ window’s aspect-ratio to handle the interface when the virtual keyboard shows up.
Having to scroll both page and textarea is confusing
The heightĀ of the textarea is bigger than the windows, which implies that to see all contents I found asking myself many times if I had to scroll the page, the textarea or both.
Using viewport units it’s possible to make the textarea height never exceed theĀ browser’s height, this way once centered the textarea we can scroll just one thing:
it’s not compatible with oldest versions of the Android stockbrowser predating kitkat, yet giving a chance to the users of the other browsers that can be installed freely isn’t better than nothing?
Full screen edit view is not optimized
I get hold of myself from the chock of the landscape keyboard, get back to portrait and go for the last hope, the full screen edit view, which disappointsĀ me right awayĀ :
The page must be scrolled horizontally in order to see a whole line of text, the top bar is way too much big, also it still displays the title field which is kind of unnecessary in this context.
But there is a good tip in the right bottom corner: “StahpĀ writing.“.
Yes because this interface crafted with media queries makes it uselessĀ to trick the server with the user-agent, there is no way to see the desktop version.
Unfortunately to make “mobile” a web resource targeted to productivity, such as the WordPress backend admin panel, getting everything on a straight column with float:none
Ā is not enough.
Usability should come before the aesthetic, even if the design looks great on photoshop or in the narrowedĀ desktop browser, truth can be painfully different for the user that tries to get some work done without a computer.
And the Android app?
It displaysĀ only the articlesĀ matching the language the CMS was installed with, users that have a multi language blog like me using polylang are left empty-handed.
Will you write again a WordPress post using a smartphone?
No.