Open GoogleCodeExporter opened 8 years ago
I plan to change the typer so that you type text in a sort of "overwrite" mode
--
instead of having two separate places for input and output, there will be only
one,
where the color (or whatever) of the text changes as you type it. In this mode
it
would be a lot easier to do blind mode or similar than the way it's currently
set up
(because with the current setup I'd want to use minimum edit distance or
something as
a metric, but then I'd have a headache figuring out exactly what keys to count
as
errors etc.).
Original comment by tristesse
on 9 Jan 2009 at 5:39
Similar to Typeracer then? That makes sense. Maybe you could have three options:
1. Highlight current character - as hi-games.net and many others do.
2. Highlight current word - like typeracer.
3. Do not highlight - aka blind mode.
Personally, I have always found programs that highlight the current character
highly
distracting. I find that it's really difficult to focus on the word when the
character is bright red (or whatever), but for a typist who is learning it is
probably helpful to begin with.
Anyway, good luck tristesse and thanks again.
Original comment by simonhar...@gmail.com
on 9 Jan 2009 at 5:50
I would say that hi-games does not highlight. It has separate input only the
lines of
the input and text display are interwoven. Typeracer highlights in the text but
it
too has separate input.
What I wanted is to have the text display BE the input (as if you're typing in
overwrite mode) so that your eyes only ever have one exact place to focus. For
example you'de be able to set the foreground / background / decoration of text
that's
been typed, untyped text, and errors, etc. Maybe have an optional "cursor" of
some
kind. To me this sounds perfect but if people (like yourself) find it too weird
or
distracting I suppose I could also work on interwoven text/input like on
hi-games,
since that's pretty close to what I want anyway as you can "practically" view
both
text and input without really moving the focus of your eye.
I don't like the current way where the input is all the way at the bottom. I
only did
it that way because it was very quick and easy. I always just look at the text
anyway
and merely use the change of color in the periphery as a visual cue to hit
backspace.
So basically that whole box of text input where I type is a waste of space for
me anyway.
Original comment by tristesse
on 10 Jan 2009 at 3:06
It makes sense to overwrite the text as you have said. As long as there is an
option
to have the text not change at all - the blind mode.
Another suggestion, I can put this as a new issue if you wish. An option to
hide your
speed. This would enable the user to focus exclusively on accuracy.
Original comment by simonhar...@gmail.com
on 11 Jan 2009 at 4:13
Well some kind of marker has to be there to show you where you are in the text.
Whether that will be done by a cursor of some kind or change of text/bg color,
would
be a user option.
Hide your speed? Like from all the tables? I'm not sure I would ever implement
such a
thing. I wouldn't say it would "enable" the user to focus exclusively on
accuracy,
because the user is already enabled to do that. It's more like putting one more
obstacle between him and the "temptation" that is looking at the WPM numbers?
If he
doesn't care about WPM then he doesn't care. If he cares, then it's a difference
between looking or toggle the option back on to look... If accuracy is all that
matters then simply put 100.0 as an accuracy demand on all texts and 0.0 on
WPM. That
too "forces" a focus on accuracy, much more adamantly than hiding WPM data
(which
would be collected anyway, and is nice (better, imo) for seeing progress in
"the long
run"). If one find oneself being tempted or psychologically affected by
glancing at
the WPM numbers, then maybe change the order of the colums (by dragging) and
manually
hide them beyond the view of the tables...?
Original comment by tristesse
on 11 Jan 2009 at 7:19
Yes, I realise now that suggesting hiding speed was a bad idea. As you say, the
accuracy requirement can be adjusted very easily (I have mine set to 99%).
"Well some kind of marker has to be there to show you where you are in the text.
Whether that will be done by a cursor of some kind or change of text/bg color,
would
be a user option."
Ah yes. But the point of the blind mode I suggested is that there is no cursor,
no
highlight, just the text. It is equivalent to working on a typewriter, writing
copy.
You have the text to be copied to your left and you read the copy whilst
typing. Once
you have reached the end of the text, you check for errors. In this way, if you
make
any errors, you have to practice correcting them next time. This is quite
different
from being alerted to errors at the time. Of course there must be a way to let
the
typist check their current position in the text, maybe the control or a
function key
would highlight the next character to be typed (if you were distracted).
Original comment by simonhar...@gmail.com
on 11 Jan 2009 at 9:19
OK, I think I fully understand what you mean by complete blind mode now, but
unfortunately I don't think such a mode will be easy to implement.
What I had in mind was plain text that you type in overwrite mode. A simple
cursor
(like a thin line underneath the current character) to show you where you are.
No
feedback on errors at all (except at the end). In my mind this is very
unobtrusive
and indeed similar to password fields which will generally give you a "*" as you
enter a character to give you *some* visual feedback that you actually have
typed a
single character (didn't miss the key, didn't mess up and type 2 chars for 1),
etc.
The reason "completely blind" is hard, apart from the user-interface perspective
(users thinking "am I typing at all? what's going on"), is that what if you
type an
extra character (or miss one) in the beginning, and then you will be off-by-one
for
the entire remainder of the text. All the subsequent words and characters won't
match
up and they will all be counted as errors with the naive approach to finding
errors
one can use if one can assume that the user knows where he is when he's typing.
Like
I mentioned in the first comment, there are algorithms (like minimum edit
distance)
to find how many "edits" (deletions, insertions, changes) are necessary to
change one
text into another and one could equate that as number of mistakes, but in its
plain
form it doesn't give you exactly where the errors occurred and sometimes it's
hard to
determine (combinations of both inserts, deletes, and changes near each other).
But
this is one of my fundamental principles behind amphetype -- to give info on
mistakes
and problem words. However, it sounds like a nice thing to think about.
Original comment by tristesse
on 11 Jan 2009 at 9:53
Hi all,
I'm a new user to Amphetype. I am using it to learn and get faster with the
Dvorak
layout. While I do see the point of something like this, wouldn't it be a lot
simpler
(and basically achieve the same purpose as the original poster wants) to just
provide
an option to disable the Backspace key? If this is done, perhaps we could also
add
another accuracy rating for those who don't use this option, which reports
accuracy
(allowing backspace) and true accuracy (which would be the same as the current
accuracy rating). So, say if you made typos on half of a text, but corrected
them
all, your accuracy (allowing backspace) would be 100%, but your true accuracy
would
only be 50%. This could be useful to allow you to see how many typos you were
able to
catch!
In my opinion, I think a blind mode would end up being under-used, and it
doesn't
actually equate (as the guy on 43things and the original poster claim) to how
typists
had to learn on a typewriter - after all, you could still see the things you
had
typed by looking at the left hand side of the line you were typing. Truly blind
typing would have been equivalent to using no ink, which I don't think anybody
ever
did. It seems to me like trying to type blind would be as useful as typing
without
switching your computer on, i.e. purely as a muscle memory trainer, and even
then,
the validity and usefulness of such a method is questionable.
I therefore honestly think that having an option to make Backspace do nothing,
is all
we need to accomplish the original poster's purposes.
Original comment by ashley.k...@gmail.com
on 13 Mar 2010 at 1:24
Original issue reported on code.google.com by
simonhar...@gmail.com
on 6 Jan 2009 at 6:19