This post really shows how old I am, because I immediately thought “does anyone actually compose on a mobile device?” The experience is so bad I limit my own mobile compositions to message responses like “k” and “lol”.
I wrote this comment on my phone and it was an awful experience 🙃. But hey, at least my keyboard app suggested a silly emoji…
I’ll continue to do my “real” writing on my desktop for now. Integration apps like KDEConnect have been enough for me to get by, but they aren’t perfect either.
Bloody hell yes. I have to select text on my phone all the time and that little hovering Android context menu is utterly atrocious. How that passed any UX process is completely beyond me.
- It hovers over text, rather than appearing in a predictable location like every other context menu in the OS does.
- The menu just doesn’t appear sometimes. Usually when the selected text is large or near the edge of the screen or the screen is zoomed in.
- It’s unstable. Every time you bring it up, the context sensitivity might add additional options. That context sensitivity is good, but it also means that one has to scan the menu for the desired option every single time, no matter how proficient one gets.
- It’s uncustomisable. One of my most-used options requires me to select the text and wait for the menu, tap the three-dots to open the second layer of the tiny little context menu, scroll that tiny sub-list past a bunch of less-commonly used options to the option I use all the time, then tap on that. The menu is sorted arbitrarily, not even alphabetically, and is completely unmodifiable.
- And what is given sort-priority over my actually used context menu items? “Share”. I can share text with two taps, which I will never do, but the action I use dozens of times a day requires three taps and a scroll to find it.
I’d be interested in trying the system this guy is talking about. Anyone know if Eloquent is installable at this point?
The last section makes me think they can’t be bothered to take it into production. It’s weird; they spend all these words describing the problem and their solution then conclude with but 🤷♂️ no-one really cares.
Not really that weird.
It’s a common occurrence.
It’s a passion project that someone or a team spend a lot of time and energy on, likely thinking that the advantages of implementation will be so obvious that it’ll just be out into production based on its self-evident merits or improvement on existing practices.
Then it hits the concrete wall of reality, where there’s actually lots of friction and barriers in the process of trying to get the project into production and implemented. Management just doesn’t want to go ahead with it for whatever reason, and people don’t seem to be as enthusiastic about it and clamoring for it as the dev/team thought they would be, despite it solving a number of common issues they have with a product/service.
So the dev/team can either go home and forget about it, starting a new project, or write a manifesto remembering and defending the project they’ve spent many hours on.
It almost reads like a PhD thesis defence. At least that PhD then gets recorded, filled and archived, and despite it potentially having no immediate real-world impact, possibly someone down the line might access the extensive work and research already done here, and use it to further their own project, and fingers crossed that project has more success in making a real-world change than this one.
TL;DR: I imagine his management don’t want to go ahead with implementation for whatever reason, but because the research and any coding was done during his time at Google, he can’t just go and create his own app or implementation, or approach another more willing company for implementation. But by providing the research and element summaries, and points for how a better system might work, he not only memorialized his hours of work on a “dead end” project, but allows others in a less captive situation the advantage of taking his summary and using it to actually try to get change happening elsewhere.
