Adaptation screen: Enter / Return keystroke

[eb1]

Adapt It Mobile has several keystrokes to help with navigation between edit fields:

• Escape / click on empty area of adaptation area: cancel the current adaptation
• Previous (<) and Next (>) buttons, Tab and Shift+Tab key on BT keyboard: accept the current text, move to next / previous empty edit field (similar to Tab, Shift+Tab in drafting mode for AI desktop)

There is also the Enter / Return key on the software keyboard. This key has been problematic, because mobile devices tend to use it as a form submit -- i.e., "Accept this input and close the software keyboard. I'm done editing." -- while Adapt It desktop has used this key like the Tab key (accept and advance). We've tried several approaches to get the Enter / Return key to work like AI desktop, but the software keyboard still has a tendency to close at weird times, because we can't really control the behavior from a javascript client.

We should consider using Enter / Return as it is defined in the mobile context -- to accept the current text, blur the edit field (lose the focus) and do not move to the next field.

[eb1]

Changed code to treat the Enter / Return as a "accept and close", per the issue description.

[adaptitbruce]

Hi Erik, Bill,

It's sounding like my hope, and Bill's, that the mobile app can utilize Enter key like AID does, is a forlorn hope.

I'll suggest something different. Maybe it may help, maybe it's crazy....

I think that if people used to AID have to learn something new, it will be easier to learn if there is a button which is very prominent, and which does the work that Enter or Tab did in AID. I feel that if AID users have to relearn several things at once, and they are opposites to what AID does, the confusion would be greater than just using Enter as a 'sign off' in the way you describe, but have an extra GUI widget that gets the phrasebox movement done. Then they are basically just learning that the new button does the moving, and Enter has reduced functionality wrt AID.

Would that make sense? It would mean that < and > could be kept for movement in the context close to the box location, like Bill suggests.

What do you think?

-- Bruce
----- Original Message -----
From: Erik Brommers
To: adapt-it/adapt-it-mobile
Sent: Thursday, December 10, 2015 3:31 AM
Subject: [adapt-it-mobile] Adaptation screen: Enter / Return keystroke (#129)

Adapt It Mobile has several keystrokes to help with navigation between edit fields:

a.. Escape / click on empty area of adaptation area: cancel the current adaptation 
b.. Previous (<) and Next (>) buttons, Tab and Shift+Tab key on BT keyboard: accept the current text, move to next / previous empty edit field (similar to Tab, Shift+Tab in drafting mode for AI desktop) 

There is also the Enter / Return key on the software keyboard. This key has been problematic, because mobile devices tend to use it as a form submit -- i.e., "Accept this input and close the software keyboard. I'm done editing." -- while Adapt It desktop has used this key like the Tab key (accept and advance). We've tried several approaches to get the Enter / Return key to work like AI desktop, but the software keyboard still has a tendency to close at weird times, because we can't really control the behavior from a javascript client.

We should consider using Enter / Return as it is defined in the mobile context -- to accept the current text, blur the edit field (lose the focus) and do not move to the next field.

—
Reply to this email directly or view it on GitHub.

[GraeCost]

Hi Bruce et al (hitting Reply for this email inserted a weird looking address in the To: box - presumably something related to replying to a Git-hub email?),

I am not convinced by your reasons for an extra button.

To back track a little:-

• It has been normal for decades for the Tab key to advance to "the next object/item in sequence". This has been the norm in spreadsheets, tables in wordprocessors, databases, HTML forms on the Internet
• It has been normal for the Enter key to mean something like "finished editing so record/post the changes now". This has been especially in modal dialogs in Windows, Mac, etc. but also other places.

When I write "normal" I don't mean completely universal because there are exceptions to the above two generalisations. But a large proportion of software treats Tab and Enter like that.

When I came to AID, pressing Enter to step to the next empty adaptation struck me as odd. On the other hand, it was a bit like "finished editing so record/post the changes now", so to me it is perfectly understandable that you programmed AID to use the Enter key for this.

On the other hand, if one looks into the actions "behind the scenes" when Tab is used to step to the next spreadsheet cell, or the next wordprocessing table cell, or the next field in a database layout, it does have the effect of finishing whatever was being done to the cell or field, storing the updated content of that cell or field, and then stepping on to the next cell or field in sequence.

So if mobile devices make it hard to implement using the Enter key for the same purpose as AID uses it, then I think that is a good spur on for us to bring the user interface of AIM into the current era of mobile devices and how their users have become accustomed to using them.

Except that mobile devices (Android, iOS) DON'T HAVE A Tab KEY!!

Which is probably why Erik provided two buttons for < and > to accomplish what AID does with Tab (or Enter).

Screen space on a smartphone is already very limited, so it doesn't strike me as helpful to add an extra button that accomplishes the same job as the > button.

In addition to this, mobile devices and their operating systems are different in many ways from desktop devices and their operating systems, so I think it is unrealistic to expect AIM to have a user interface that exactly matches the user interface of AID.

Someone who chooses to use AIM is very likely to have made that choice after using a smartphone (or tablet) for some time with other apps (whether system supplied or downloaded from an app store), so that sort of user would already be familiar with Android or iOS and would not be phased by an AIM that performed in a similar manner to other apps on that mobile system.

A user coming from AID to AIM without first becoming familiar with Android or iOS would be in the minority - and it may only be expatriates like translation consultants who are suddenly faced with AIM on a mobile device (because their consultee uses it) without first becoming familiar with mobile devices.

I have not really reached a definite conclusion here, but I hope I have provided some helpful thoughts.

All the best,

Graeme

On 10/12/2015, at 3:52 PM, adaptitbruce notifications@github.com wrote:

Hi Erik, Bill,

It's sounding like my hope, and Bill's, that the mobile app can utilize Enter key like AID does, is a forlorn hope.

I'll suggest something different. Maybe it may help, maybe it's crazy....

I think that if people used to AID have to learn something new, it will be easier to learn if there is a button which is very prominent, and which does the work that Enter or Tab did in AID. I feel that if AID users have to relearn several things at once, and they are opposites to what AID does, the confusion would be greater than just using Enter as a 'sign off' in the way you describe, but have an extra GUI widget that gets the phrasebox movement done. Then they are basically just learning that the new button does the moving, and Enter has reduced functionality wrt AID.

Would that make sense? It would mean that < and > could be kept for movement in the context close to the box location, like Bill suggests.

What do you think?

-- Bruce
----- Original Message -----
From: Erik Brommers
To: adapt-it/adapt-it-mobile
Sent: Thursday, December 10, 2015 3:31 AM
Subject: [adapt-it-mobile] Adaptation screen: Enter / Return keystroke (#129)

Adapt It Mobile has several keystrokes to help with navigation between edit fields:

a.. Escape / click on empty area of adaptation area: cancel the current adaptation
b.. Previous (<) and Next (>) buttons, Tab and Shift+Tab key on BT keyboard: accept the current text, move to next / previous empty edit field (similar to Tab, Shift+Tab in drafting mode for AI desktop)
There is also the Enter / Return key on the software keyboard. This key has been problematic, because mobile devices tend to use it as a form submit -- i.e., "Accept this input and close the software keyboard. I'm done editing." -- while Adapt It desktop has used this key like the Tab key (accept and advance). We've tried several approaches to get the Enter / Return key to work like AI desktop, but the software keyboard still has a tendency to close at weird times, because we can't really control the behavior from a javascript client.

We should consider using Enter / Return as it is defined in the mobile context -- to accept the current text, blur the edit field (lose the focus) and do not move to the next field.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[eb1]

Reopening to back out the code changes.

The code changes are commented out, should we reconsider. I'm moving this out of the 0.5.0 release milestone.

[adaptitbruce]

On 10/12/2015 3:31 AM, Erik Brommers wrote:

Adapt It Mobile has several keystrokes to help with navigation between
edit fields:

• Escape / click on empty area of adaptation area: cancel the
  current adaptation
• Previous (<) and Next (>) buttons, Tab and Shift+Tab key on BT
  keyboard: accept the current text, move to next / previous empty
  edit field (similar to Tab, Shift+Tab in drafting mode for AI desktop)

There is also the Enter / Return key on the software keyboard. This
key has been problematic, because mobile devices tend to use it as a
form submit -- i.e., "Accept this input and close the software
keyboard. I'm done editing." -- while Adapt It desktop has used this
key like the Tab key (accept and advance). We've tried several
approaches to get the Enter / Return key to work like AI desktop, but
the software keyboard still has a tendency to close at weird times,
because we can't really control the behavior from a javascript client.

We should consider using Enter / Return as it is defined in the mobile
context -- to accept the current text, blur the edit field (lose the
focus) and do not move to the next field.

—
Reply to this email directly or view it on GitHub
#129.

I resisted this earlier, but I think now that trying to make it work
like AID is not worth the effort. If AIM "takes off" in the way we hope,
lack of total workflow compatibility with AID will not be an issue.
Better, perhaps, to be compatible with how mobile apps in general work.

--Bruce

[GraeCost]

Yes, I agree with you Graeme. Right thinking on your part, I've no
problems with this now. --Bruce

On 10/12/2015 9:38 PM, GraemeAdaptIt wrote:

Hi Bruce et al (hitting Reply for this email inserted a weird looking
address in the To: box - presumably something related to replying to a
Git-hub email?),

I am not convinced by your reasons for an extra button.

To back track a little:-

• It has been normal for decades for the Tab key to advance to "the
  next object/item in sequence". This has been the norm in spreadsheets,
  tables in wordprocessors, databases, HTML forms on the Internet
• It has been normal for the Enter key to mean something like
  "finished editing so record/post the changes now". This has been
  especially in modal dialogs in Windows, Mac, etc. but also other places.

When I write "normal" I don't mean completely universal because there
are exceptions to the above two generalisations. But a large
proportion of software treats Tab and Enter like that.

When I came to AID, pressing Enter to step to the next empty
adaptation struck me as odd. On the other hand, it was a bit
like "finished editing so record/post the changes now", so to me it is
perfectly understandable that you programmed AID to use the Enter key
for this.

On the other hand, if one looks into the actions "behind the scenes"
when Tab is used to step to the next spreadsheet cell, or the next
wordprocessing table cell, or the next field in a database layout, it
does have the effect of finishing whatever was being done to the cell
or field, storing the updated content of that cell or field, and then
stepping on to the next cell or field in sequence.

So if mobile devices make it hard to implement using the Enter key for
the same purpose as AID uses it, then I think that is a good spur on
for us to bring the user interface of AIM into the current era of
mobile devices and how their users have become accustomed to using them.

/Except that mobile devices (Android, iOS) DON'T HAVE A Tab KEY!!/

Which is probably why Erik provided two buttons for < and > to
accomplish what AID does with Tab (or Enter).

Screen space on a smartphone is already very limited, so it doesn't
strike me as helpful to add an extra button that accomplishes the same
job as the > button.

In addition to this, mobile devices and their operating systems are
different in many ways from desktop devices and their operating
systems, so I think it is unrealistic to expect AIM to have a user
interface that exactly matches the user interface of AID.

Someone who chooses to use AIM is very likely to have made that choice
after using a smartphone (or tablet) for some time with other apps
(whether system supplied or downloaded from an app store), so that
sort of user would already be familiar with Android or iOS and would
not be phased by an AIM that performed in a similar manner to other
apps on that mobile system.

A user coming from AID to AIM without first becoming familiar with
Android or iOS would be in the minority - and it may only be
expatriates like translation consultants who are suddenly faced with
AIM on a mobile device (because their consultee uses it) without first
becoming familiar with mobile devices.

I have not really reached a definite conclusion here, but I hope I
have provided some helpful thoughts.

All the best,

Graeme

On 10/12/2015, at 3:52 PM, adaptitbruce <notifications@github.com
mailto:notifications@github.com> wrote:

Hi Erik, Bill,

It's sounding like my hope, and Bill's, that the mobile app can
utilize Enter key like AID does, is a forlorn hope.

I'll suggest something different. Maybe it may help, maybe it's crazy....

I think that if people used to AID have to learn something new, it
will be easier to learn if there is a button which is very prominent,
and which does the work that Enter or Tab did in AID. I feel that if
AID users have to relearn several things at once, and they are
opposites to what AID does, the confusion would be greater than just
using Enter as a 'sign off' in the way you describe, but have an
extra GUI widget that gets the phrasebox movement done. Then they are
basically just learning that the new button does the moving, and
Enter has reduced functionality wrt AID.

Would that make sense? It would mean that < and > could be kept for
movement in the context close to the box location, like Bill suggests.

What do you think?

-- Bruce
----- Original Message -----
From: Erik Brommers
To: adapt-it/adapt-it-mobile
Sent: Thursday, December 10, 2015 3:31 AM
Subject: [adapt-it-mobile] Adaptation screen: Enter / Return
keystroke (#129)

Adapt It Mobile has several keystrokes to help with navigation
between edit fields:

a.. Escape / click on empty area of adaptation area: cancel the
current adaptation
b.. Previous (<) and Next (>) buttons, Tab and Shift+Tab key on BT
keyboard: accept the current text, move to next / previous empty edit
field (similar to Tab, Shift+Tab in drafting mode for AI desktop)
There is also the Enter / Return key on the software keyboard. This
key has been problematic, because mobile devices tend to use it as a
form submit -- i.e., "Accept this input and close the software
keyboard. I'm done editing." -- while Adapt It desktop has used this
key like the Tab key (accept and advance). We've tried several
approaches to get the Enter / Return key to work like AI desktop, but
the software keyboard still has a tendency to close at weird times,
because we can't really control the behavior from a javascript client.

We should consider using Enter / Return as it is defined in the
mobile context -- to accept the current text, blur the edit field
(lose the focus) and do not move to the next field.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#129 (comment).