Smartphone user, know your typing speed!
In previous posts about Oktodon, we have repeatedly mentioned the speed of printing, which we managed to achieve , and received many questions about how much we need to train for this.
At a certain stage, this question was asked by us, and the only way to get an answer is to test. In this article I will tell you how we learned to type on our own keyboard and make an application for Android , where everyone can find out their typing speed and compete with other people using other input methods!
')
The original intention is to follow the example of other keyboards (like MessagEase games ) to make a learning application with several levels:
The artist armed himself with a photo of the animal Octodon Degus and made us an art, and I took up programming. Having a little experience with gamedev under iOS, I thought that the native Android-framework tools would be enough to make a small game with a primitive animation of sprites. However, I wascruelly mistaken. Several days wasted led me to a forum with a whole thread of obscene messages regarding strong brakes and glitches when working with 2D graphics, which I encountered.
Putting the rake aside, I did what I had to do right away - googled the wonderful AndEngine engine. To solve most problems, I had enough examples from the AndEngineExamples repository. There are also many tutorials and a large user forum .
We will post this program with some modifications simultaneously with the release of Octodon, but for now it teaches our testers at the first stages and waits for its time.
In parallel with the development, we decided to contact the recognized specialists in Logitech keyboards and ask how they evaluate the new keyboards. In response, we were sent a testing methodology (about how we conducted tests on it in the following posts), including the use of a special online service . However, it did not work on Android browsers, and the counterparts found on the web and on GooglePlay were very few and provided either little data, or generally allowed to use only the keyboard built into them.
We came to the conclusion that you need to write your own, especially since we already have a ready level for working with texts from a learning game. It remained to add the ability to quickly load their texts and, to track speed, the ability to measure the main indicators of printing:
In the final concise “Typing Test” application, the user pre-writes his name, input method, selects text and training time, receives a log with statistics on the output. You can make a screenshot and tweet accounts. There is also a separate level with canonical text about piranhas , where you can try to set a new world record.
We think that the idea of measuring print speed will be interesting to many, so we decided to put the application on GooglePlay and plan to develop this application further, but independently of Oktodon. As a service where you can measure input performance on any keyboard and for any language where these results can be visually compared and analyzed statistics.
App on GooglePlay
Collecting statistics was very necessary, we also for marketing reasons. If we test the Octodon on random people for a short time, then, of course, we will get far from impressive results. There are many reasons why this happens: the input method is new, the user is in shock,what kind of button accordion is on the phone , etc. But without material evidence, this sounds unconvincing, both for consumers and for investors.
The learning curve is a very weighty argument in such a dispute; it allows you to show the supposedly painful learning process in real light. With sufficient sampling, it shows the real dynamics - a certain training time develops into a certain printing speed.
Each test session was conducted on a random text of 5 existing ones, the time limit was 3 minutes. Below are graphs of the data collected. On the X axis, the total time spent on user typing is noted.
By words per minute:
By accuracy:
Here is a graph for the speed of all available data without scaling:
From the graphs we can draw several conclusions:
At the moment, in order to improve the layout, we started collecting statistics on the time between pressing different pairs of directions of joysticks and think what to collect in addition to this (we will be glad of your ideas and suggestions).
In the next posts we will tell about our mass testing of input methods on users, the process of creating layouts for the Octodon, also you will find an overview of the back-typing keyboard AlphaGrip . Stay with us! :)
UPD: sources on GitHub - github.com/kotlyarovsa/Typing-Test
At a certain stage, this question was asked by us, and the only way to get an answer is to test. In this article I will tell you how we learned to type on our own keyboard and make an application for Android , where everyone can find out their typing speed and compete with other people using other input methods!
')
Training application
The original intention is to follow the example of other keyboards (like MessagEase games ) to make a learning application with several levels:
- Training individual letters. The user gets acquainted with our layout, alternately mastering the rear joysticks.
- Practice words and common letter combinations. The user learns that the layout is optimized for the most frequent dyads / triads (for example: no | on | at | er | the | and, etc.)
- Word training The user types small texts / poems and gradually turns from a novice into a full-fledged user.
The artist armed himself with a photo of the animal Octodon Degus and made us an art, and I took up programming. Having a little experience with gamedev under iOS, I thought that the native Android-framework tools would be enough to make a small game with a primitive animation of sprites. However, I was
Putting the rake aside, I did what I had to do right away - googled the wonderful AndEngine engine. To solve most problems, I had enough examples from the AndEngineExamples repository. There are also many tutorials and a large user forum .
A bit of code on how to just start developing a game (for beginners).
After connecting the AndEngine source to the project (the process is described in detail in the links above), I created several successors for the BaseGameActivity class. This base class contains a set of virtual methods that allow you to perform the necessary actions at the right stages of the application life cycle. Plus various methods for getting managers (Font \ Texture \ SoundManager, etc.). In our heir activity we write:
To navigate between the menu screens, I create child scenes with the necessary content (a separate activity is created for the game itself and other large items) and add the following code for the Back button to work correctly:
All work with resources (loading pictures, fonts, sounds, creating a scene and its layout) is in a separate ResMan class.
Next, it remains to create activity for the game in the same way and connect game graphic elements. There are some subtleties (for example, to be able to change the color of the text, the font used must be initialized in white), but in general the engine is extremely easy to learn.
MenuActivity code
public class MenuActivity extends BaseGameActivity implements Scene.IOnSceneTouchListener { private Camera mCamera; private MenuResMan resMan; // @Override public Engine onLoadEngine() { this.mCamera = new Camera(0, 0, UIConstants.CAMERA_WIDTH, UIConstants.CAMERA_HEIGHT); return new Engine(new EngineOptions(true, ScreenOrientation.PORTRAIT, new RatioResolutionPolicy(UIConstants.CAMERA_WIDTH, UIConstants.CAMERA_HEIGHT), this.mCamera)); } // @Override public void onLoadResources() { resMan = new MenuResMan(this); resMan.LoadResources(); } // @Override public Scene onLoadScene() { mEngine.registerUpdateHandler(new FPSLogger()); final Scene scene = resMan.LoadScene(); scene.setOnSceneTouchListener(this); String lang = getApplicationContext().getResources().getConfiguration().locale.getLanguage(); testingModel.ChangeLang(lang); return scene; } @Override public void onLoadComplete() { <...> } @Override protected void onCreate(Bundle pSavedInstanceState) { <...> } @Override protected void onStop() { <...> } To navigate between the menu screens, I create child scenes with the necessary content (a separate activity is created for the game itself and other large items) and add the following code for the Back button to work correctly:
code
@Override public void onBackPressed() { Scene scene = this.mEngine.getScene(); if(scene.hasChildScene()){ scene.back(); } else{ this.finish(); } } All work with resources (loading pictures, fonts, sounds, creating a scene and its layout) is in a separate ResMan class.
ResourceManager code
public class MenuResMan { private BaseGameActivity activity; private BitmapTextureAtlas textFontTexture; public Font textFont; private BitmapTextureAtlas backgroundTexture; public TextureRegion mainBackgroundRegion; public Sprite mainBackground; public void LoadResources() { BitmapTextureAtlasTextureRegionFactory.setAssetBasePath("Menu/"); // backgroundTexture = new BitmapTextureAtlas(512, 1024, TextureOptions.REPEATING_BILINEAR_PREMULTIPLYALPHA); textFont = new Font(textFontTexture, Typeface.create(Typeface.DEFAULT, Typeface.NORMAL), UIConstants.TEXT_FONT_SIZE, true, Color.BLACK); activity.getTextureManager().loadTexture(backgroundTexture); activity.getTextureManager().loadTexture(textFontTexture); activity.getFontManager().loadFont(textFont); mainBackgroundRegion = BitmapTextureAtlasTextureRegionFactory .createFromAsset(backgroundTexture, activity, "mymenu.png", 0, 0); //480x800 <...> } public Scene LoadScene() { Scene scene = new Scene(); mainBackground = new Sprite(0,0,mainBackgroundRegion); scene.attachChild(mainBackground); Rectangle textBackground = new Rectangle(0,0, UIConstants.CAMERA_WIDTH - UIConstants.BORDER_WIDTH*2, UIConstants.CAMERA_HEIGHT - UIConstants.BORDER_WIDTH*2 - headerBackground.getHeight() ); speedText = new ChangeableText(UIConstants.TESTING_BORDER_WIDTH, UIConstants.TESTING_BORDER_WIDTH, headerFont, " ", 10); textBackground .attachChild(speedText); scene.attachChild(textBackground); // <...> return scene; } public MenuResMan(BaseGameActivity activity) { this.activity = activity; } } Next, it remains to create activity for the game in the same way and connect game graphic elements. There are some subtleties (for example, to be able to change the color of the text, the font used must be initialized in white), but in general the engine is extremely easy to learn.
We will post this program with some modifications simultaneously with the release of Octodon, but for now it teaches our testers at the first stages and waits for its time.
Statistics collection
In parallel with the development, we decided to contact the recognized specialists in Logitech keyboards and ask how they evaluate the new keyboards. In response, we were sent a testing methodology (about how we conducted tests on it in the following posts), including the use of a special online service . However, it did not work on Android browsers, and the counterparts found on the web and on GooglePlay were very few and provided either little data, or generally allowed to use only the keyboard built into them.
We came to the conclusion that you need to write your own, especially since we already have a ready level for working with texts from a learning game. It remained to add the ability to quickly load their texts and, to track speed, the ability to measure the main indicators of printing:
- Time - training time, for the subsequent calculation of "X per minute"
- CorrectEntries, IncorrectEntries, FixedMistakes - the main counted triple from which everything else is calculated
- TotalEntries = CorrectEntries + IncorrectEntries
- ErrorRate = (IncorrectEntries - FixedMistakes) / Time
- KeySpeed = (CorrectEntries + FixedMistakes) / Time - a metric better known as CPM
- RawSpeed = TotalEntries / (5 * Time) - a factor of 5 is used everywhere, as the average word length in the English language, i.e. indicator means words per minute, but without regard to errors
- Speed = KeySpeed / 5 is the main metric, better known as WPM , the standard for estimating print speeds.
- Accuracy = 100 * CorrectEntries / TotalEntries - Percentage Accuracy
In the final concise “Typing Test” application, the user pre-writes his name, input method, selects text and training time, receives a log with statistics on the output. You can make a screenshot and tweet accounts. There is also a separate level with canonical text about piranhas , where you can try to set a new world record.
We think that the idea of measuring print speed will be interesting to many, so we decided to put the application on GooglePlay and plan to develop this application further, but independently of Oktodon. As a service where you can measure input performance on any keyboard and for any language where these results can be visually compared and analyzed statistics.
App on GooglePlay
Learning curves
Collecting statistics was very necessary, we also for marketing reasons. If we test the Octodon on random people for a short time, then, of course, we will get far from impressive results. There are many reasons why this happens: the input method is new, the user is in shock,
The learning curve is a very weighty argument in such a dispute; it allows you to show the supposedly painful learning process in real light. With sufficient sampling, it shows the real dynamics - a certain training time develops into a certain printing speed.
Each test session was conducted on a random text of 5 existing ones, the time limit was 3 minutes. Below are graphs of the data collected. On the X axis, the total time spent on user typing is noted.
By words per minute:
By accuracy:
Here is a graph for the speed of all available data without scaling:
From the graphs we can draw several conclusions:
- The most important for us is that even with the reached print speed of 40-45 WPM, the learning curve does not tend to flatten out, which means that the practical limit of learning has not yet been reached.
- The speed of learning is individual for everyone, however, in about an hour a person reaches 20WPM comfortable for work. Which is about one and a half times the speed of the average user (according to our testing) on the on-screen qwerty keyboard.
- After switching to blind printing, it takes about an hour to restore its previous speed.
- Accuracy is also individual, and depends primarily on the user's attention and his desire to write without errors.
At the moment, in order to improve the layout, we started collecting statistics on the time between pressing different pairs of directions of joysticks and think what to collect in addition to this (we will be glad of your ideas and suggestions).
In the next posts we will tell about our mass testing of input methods on users, the process of creating layouts for the Octodon, also you will find an overview of the back-typing keyboard AlphaGrip . Stay with us! :)
UPD: sources on GitHub - github.com/kotlyarovsa/Typing-Test
Source: https://habr.com/ru/post/217095/
All Articles