eb1
commented
8 years ago Changed code to treat the Enter / Return as a "accept and close", per the issue description.
Open eb1 opened 8 years ago
eb1
commented
8 years ago Changed code to treat the Enter / Return as a "accept and close", per the issue description.
adaptitbruce
commented
8 years ago 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
commented
8 years ago 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:-
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
commented
8 years ago 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
commented
8 years ago 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 https://github.com/adapt-it/adapt-it-mobile/issues/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
commented
8 years ago 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 https://github.com/adapt-it/adapt-it-mobile/issues/129#issuecomment-163487284.
Adapt It Mobile has several keystrokes to help with navigation between edit fields:
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.