Practical Goal: Modern and Global Text Input For Every User (Input Methods, Emoji, Touch)

[Eike Hein]

Hi everyone!

Text input is the foundational means of human-computer interaction: We
configure or systems, program them, and express ourselves through them
by writing text. It's how our software is made, and it's how it's
consumed. It's how users and developers connect with each other.

Yet text input in our software is not complete, and it's not as strong
as it could be. Some cannot use our software to write text at all.
Others are not doing it as efficiently as they could be, or with as much
joy.

The good news is that improving this is within our reach. If we care to
do so.

I propose that we spend time and effort on:
* ... enabling more users to write their language in our software
* ... allowing all of our users to input text with greater efficiency
* ... bringing more joy to text input by improving support for emoji
* ... making text input act consistently across different input devices
* ... addressing key defects in our software related to global text

Achieving these goals in all our software will require the involvement
of at least interface designers, artists, translators, shell
programmers, library programmers, application programmers, and users. I
therefore think it's an appropriate goal to set for our community as whole.

Here is what we would do:

(1) Improve support for Input Methods

Input Methods are software that helps convert input events to text
output. Many languages (e.g. a variety of Asian languages) require an
Input Method to be written at all. Others can still benefit from Input
Methods that provide e.g. word completion or spell-checking. Emoji input
can also run through Input Methods.

There is a sizable community that has developed Input Method software
for free systems. KDE/Qt software supports some of this software
already. However, this support is poorly integrated/surfaced. Input
Methods are treated as something that may-be-installed, not as part of
the bedrock our systems rest on. Installation and setup require expert
knowledge - this should not be necessary. Once in use, integration seams
make the user experience very painful.

To improve support for Input Methods, we would:
* Make them a required dependency
* Evolve Plasma's System Settings and panel indicator UIs for keyboard
layout management toward managing input languages and input methods
* Spend time on the UI for managing active input methods at runtime
* Think about how to guide our users toward the use of input methods
that can improve their typing speed and accuracy

It's interesting to add that users who require Input Methods to write
their language are currently under-represented among our users compared
to other systems, because we support them poorly. Fixing this will grow
our community and help us achieve other goals in the future!

(2) Improve support for emoji

Via the improved support for Input Methods, we can add a globally
accessible emoji input panel and also surface it in our libraries and
applications by putting emoji buttons in our line edits and text field
context menus and enabling them in our applications where it makes sense.

(3) Improve the convergent text input experience

Our physical and virtual keyboard systems (on both desktop and mobile)
currently don't have equal support for Input Methods, and they also
behave differently, are configured in different ways, and do not share
any state, so it is sometimes not possible to start text input on one
keyboard and continue it on the other without starting over. This needs
fixing.

(4) Improve global text support in our application software

Many of our apps currently lack key features to make them viable in
certain language spheres, e.g. control over the CJK font or full-fledged
RTL support in text editing applications. Some even have more basic bugs
like search fields that don't search until you type n characters - when
in some writing systems an entire person's name can be just one
character. Or they choke on non-English file names.

Here we should collect common problems and their solutions, form
checklists, and work together to make our software pass them.

---

This is not a vague goal. This is a concrete development drive, with
well-definable work items and clear metrics for measuring success. It's
realistic and achievable in finite time.

It's work that lends itself to both cross-project team-building within
the community and easy distribution of task items to sub-teams or
individuals.

It's work that will grow our skillset and competency as a community in a
new area: It will contribute to our institutional knowledge as a
community of makers.

It's a great fit for a development sprint.

Inclusivity and end-user focus are both emphasized in our KDE Manifesto.
This work will read against both of them, by making text input available
to more users, and making it easier for all.

Doing this will grow our developer and user community.

And it's going to impact every one of the users we already have.

Let's make text rock!


Cheers,
Eike

PS.: If you want to know more details on 1-3, a talk I gave at Akademy
this year goes into pain points and solutions at greater depth:
https://conf.kde.org/system/attachments/99/original/Input_Methods_in_Plasma_5.pdf