Alternatywna klawiatura SwiftKey od lat cieszy się uznaniem sporej grupy użytkowników Androida. Od początku jej głównym atutem jest zdolność przewidywania intencji piszącego oparta na dwóch filarach: słowniku przygotowanym przez autorów (w kilkudziesięciu językach, w tym w polskim) oraz bazie słów i fraz nieustannie modyfikowanej na podstawie indywidualnych zachowań językowych użytkownika. Polski słownik jest obszerny, ale nie idealny – co jakiś czas można trafić na brak oczywistego, wydawałoby się, słowa. Natomiast samouczący się mechanizm predykcyjny potrafi często pozytywnie zaskoczyć. Sam odnotowałem kilkakrotnie przypadek, kiedy mozolnie spreparowane zdanie, które po nieoczekiwanym błędzie zniknęło w otchłani cybernetycznej próżni, zostało przez SwiftKey ponownie odtworzone słowo po słowie. Nieco opornie idzie twórcom klawiatury wdrażanie innych udoskonaleń ułatwiających pisanie. Dość długo przyszło czekać na pożądany przez wielu mechanizm wpisywania przez przeciąganie, znany choćby z konkurencyjnego Swype. Również z ociąganiem podeszli autorzy do kwestii udostępnienia możliwości zmiany wielkości obszaru zajmowanego przez klawiaturę na ekranie. Po rezygnacji z dość topornie działającego mechanizmu skalowania przez przeciąganie, obecnie mamy do dyspozycji pięć predefiniowanych wielkości. Trzeba jednak podkreślić, że SwiftKey w układzie pełnym, z paskiem podpowiedzi i włączonym rzędem klawiszy numerycznych (nowość, którą przynosi beta 4.5), nawet w najmniejszym rozmiarze zajmuje znaczną część ekranu w układzie pionowym, co ilustruje poniższy obrazek:
Klawisze numeryczne dodane do zasadniczego układu klawiatury, to jedna z dwóch nowości wprowadzonych w publicznej wersji beta 4.5. Są nieco niższe od pozostałych i nie są obligatoryjne – można je usunąć korzystając ze stosownej opcji konfiguracyjnej. Jak było dotąd? Użytkownik miał możliwość przełączenia się na klawiaturę numeryczną, za pomocą przycisku w lewym dolnym rogu lub pojedynczego wprowadzania cyfr przez przytrzymanie jednego z klawiszy w górnym rzędzie.
Układ z włączonym rzędem klawiszy numerycznych ma dwa mankamenty. Po pierwsze, cyfry jako znaki alternatywne w górnym rzędzie liter stają się zbyteczne – aż prosi się aby zastąpić je innymi symbolami (nawiasy kwadratowe, sześcienne, tylda, itp.). Drugi niewielki mankament wiąże się ze specyfiką wprowadzania znaków alternatywnych w SwiftKey i ze znakami narodowymi, nieobecnymi w alfabecie łacińskim. Najlepiej wyjaśni to przykład. Jeśli przytrzymamy przez chwilę klawisz „R”, a następnie puścimy, w rezultacie wprowadzimy cyfrę „4”. Jeśli natomiast przytrzymamy klawisz „E”, pojawiają się nad nim dwa klawisze do wyboru. Jeden z cyfrą „3” i drugi z polskim znakiem „ę”. Jeżeli oderwiemy palec od ekranu, wprowadzona zostanie domyślna cyfra „3”. Wprowadzenie litery „ę” wymaga dodatkowego przeciągnięcia. Zmierzam do tego, że jeśli już cyfry mają pozostać znakami alternatywnymi w górnym rzędzie (przy włączonym rzędzie numerycznym), to przyznanie znakom narodowym atrybutu domyślności przyspieszyłoby pisanie.
Drugą nowością jest obsługa emotikonów, podobno gorączkowo wyczekiwana przez wielu użytkowników. Uaktywniamy ją przez dłuższe przytrzymanie nowego, dodatkowego klawisza, który znalazł miejsce po lewej stronie spacji – zwykłe kliknięcie wprowadza po prostu popularny „uśmieszek” w wersji z „noskiem”. Mówiąc szczerze, rozwiązanie zaproponowane przez twórców SwiftKey nie zachwyciło mnie. Do dyspozycji oddano nam nieprzebrane ilości symboli podzielonych na umowne grupy widoczne w zakładkach: ludzie, obiekty, przyroda, miejsca i symbole. Jedynie ta ostatnia grupa to klasyczne emotikony zbudowane w oparciu o znaki ASCII, brakuje jednak wśród nich popularnych w naszym kraju wersji bez „noska”, a zestaw jest nieedytowalny.
Pozostałe grupy zawierają symbole z przebogatego zestawu znaków Unicode. Co się z tym wiąże? Jeżeli użyjemy takich emotikonów w wiadomości SMS, do jej poprawnego wysłania musi zostać użyte kodowanie UTF, co znacznie skraca maksymalny rozmiar pojedynczej wiadomości, ponadto nie gwarantuje zachowania poprawności wizualnej przekazu na telefonach pracujących pod kontrolą systemu innego niż Android, choćby na starszych feature phone’ach. Podobny problem może dotyczyć plików tekstowych. O ile czcionki zainstalowane w Androidzie (i zapewne w większości dystrybucji Linuxa) zawierają odpowiednie reprezentacje egzotycznych kodów UTF, o tyle np. typowe czcionki w Windows, co udało mi się sprawdzić, prezentują zgoła odmienne od zamierzonych symbole lub puste kwadraty. Więcej nie zawsze znaczy lepiej. Przeładowanie poszczególnych grup emotikonami skutkuje zauważalnymi opóźnieniami w wyświetlaniu ich zawartości. Dotarcie do ostatniej, tradycyjnej grupy ASCII również trwa chwilę, bowiem każdorazowe włączenie trybu wprowadzania emotikonów domyślnie otwiera zakładkę pierwszej grupy (ludzie).
Nie zapominajmy jednak, że mamy do czynienia z wersją beta, a twórcy wyraźnie dają do zrozumienia, iż liczą na odzew użytkowników (do czego być może sam się przyłożę). Pozostaje więc mieć nadzieję, że finalna wersja nowej odsłony SwiftKey zostanie pozbawiona przynajmniej części niedoskonałości, które subiektywnie ośmieliłem się wytknąć.
Źródło: SwiftKey