{"action":"created","issue":{"url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/issues/129","labels_url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/issues/129/labels{/name}","comments_url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/issues/129/comments","events_url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/issues/129/events","html_url":"https://github.com/adapt-it/adapt-it-mobile/issues/129","id":121285823,"number":129,"title":"Adaptation screen: Enter / Return keystroke","user":{"login":"eb1","id":1458944,"avatar_url":"https://avatars.githubusercontent.com/u/1458944?v=3","gravatar_id":"","url":"https://api.github.com/users/eb1","html_url":"https://github.com/eb1","followers_url":"https://api.github.com/users/eb1/followers","following_url":"https://api.github.com/users/eb1/following{/other_user}","gists_url":"https://api.github.com/users/eb1/gists{/gist_id}","starred_url":"https://api.github.com/users/eb1/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eb1/subscriptions","organizations_url":"https://api.github.com/users/eb1/orgs","repos_url":"https://api.github.com/users/eb1/repos","events_url":"https://api.github.com/users/eb1/events{/privacy}","received_events_url":"https://api.github.com/users/eb1/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/milestones/10","html_url":"https://github.com/adapt-it/adapt-it-mobile/milestones/Milestone%200.5.0","labels_url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/milestones/10/labels","id":1396587,"number":10,"title":"Milestone 0.5.0","description":"Issues found during alpha testing","creator":{"login":"eb1","id":1458944,"avatar_url":"https://avatars.githubusercontent.com/u/1458944?v=3","gravatar_id":"","url":"https://api.github.com/users/eb1","html_url":"https://github.com/eb1","followers_url":"https://api.github.com/users/eb1/followers","following_url":"https://api.github.com/users/eb1/following{/other_user}","gists_url":"https://api.github.com/users/eb1/gists{/gist_id}","starred_url":"https://api.github.com/users/eb1/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eb1/subscriptions","organizations_url":"https://api.github.com/users/eb1/orgs","repos_url":"https://api.github.com/users/eb1/repos","events_url":"https://api.github.com/users/eb1/events{/privacy}","received_events_url":"https://api.github.com/users/eb1/received_events","type":"User","site_admin":false},"open_issues":1,"closed_issues":11,"state":"open","created_at":"2015-11-05T22:38:36Z","updated_at":"2015-12-09T16:33:41Z","due_on":null,"closed_at":null},"comments":3,"created_at":"2015-12-09T16:31:34Z","updated_at":"2015-12-10T10:39:07Z","closed_at":"2015-12-09T16:33:41Z","body":"Adapt It Mobile has several keystrokes to help with navigation between edit fields:\r\n\r\n- Escape / click on empty area of adaptation area: cancel the current adaptation\r\n- 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)\r\n\r\nThere 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.\r\n\r\nWe 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.\r\n"},"comment":{"url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/issues/comments/163573674","html_url":"https://github.com/adapt-it/adapt-it-mobile/issues/129#issuecomment-163573674","issue_url":"https://api.github.com/repos/adapt-it/adapt-it-mobile/issues/129","id":163573674,"user":{"login":"GraeCost","id":9832480,"avatar_url":"https://avatars.githubusercontent.com/u/9832480?v=3","gravatar_id":"","url":"https://api.github.com/users/GraeCost","html_url":"https://github.com/GraeCost","followers_url":"https://api.github.com/users/GraeCost/followers","following_url":"https://api.github.com/users/GraeCost/following{/other_user}","gists_url":"https://api.github.com/users/GraeCost/gists{/gist_id}","starred_url":"https://api.github.com/users/GraeCost/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GraeCost/subscriptions","organizations_url":"https://api.github.com/users/GraeCost/orgs","repos_url":"https://api.github.com/users/GraeCost/repos","events_url":"https://api.github.com/users/GraeCost/events{/privacy}","received_events_url":"https://api.github.com/users/GraeCost/received_events","type":"User","site_admin":false},"created_at":"2015-12-10T10:39:07Z","updated_at":"2015-12-10T10:39:07Z","body":"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?),\n\nI am not convinced by your reasons for an extra button.\n\nTo back track a little:-\n * 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\n * 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.\n\nWhen 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.\n\nWhen 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.\n\nOn 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.\n\nSo 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.\n\nExcept that mobile devices (Android, iOS) DON'T HAVE A Tab KEY!!\n\nWhich is probably why Erik provided two buttons for < and > to accomplish what AID does with Tab (or Enter).\n\nScreen 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.\n\nIn 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.\n\nSomeone 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.\n\nA 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.\n\nI have not really reached a definite conclusion here, but I hope I have provided some helpful thoughts.\n\nAll the best,\n\nGraeme\n \nOn 10/12/2015, at 3:52 PM, adaptitbruce <notifications@github.com> wrote:\n\n> Hi Erik, Bill,\n> \n> It's sounding like my hope, and Bill's, that the mobile app can utilize Enter key like AID does, is a forlorn hope.\n> \n> I'll suggest something different. Maybe it may help, maybe it's crazy....\n> \n> 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.\n> \n> 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.\n> \n> What do you think?\n> \n> -- Bruce\n> ----- Original Message ----- \n> From: Erik Brommers \n> To: adapt-it/adapt-it-mobile \n> Sent: Thursday, December 10, 2015 3:31 AM\n> Subject: [adapt-it-mobile] Adaptation screen: Enter / Return keystroke (#129)\n> \n> \n> Adapt It Mobile has several keystrokes to help with navigation between edit fields:\n> \n> a.. Escape / click on empty area of adaptation area: cancel the current adaptation \n> 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) \n> 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.\n> \n> 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.\n> \n> —\n> Reply to this email directly or view it on GitHub.\n> —\n> Reply to this email directly or view it on GitHub.\n> \n\n"}}