Thanks again for your comments. I'm oing to go back and scrutinize those keyboards again. The result I ave so far is a bit better than what I was expecting but there is certainly romm for improvement.
- michael On Sun, Jan 8, 2012 at 10:26 AM, bob therriault <[email protected]> wrote: > Thanks for your response Michael. > > I agree with Bjorn that this work holds great potential and encourage you to > pursue it. > > Comments inline > > Cheers, bob > > On 2012-01-07, at 10:19 AM, Michael Dykman wrote: > >> Hi Bob, >> >> Comments inline. >> >> On Sat, Jan 7, 2012 at 12:29 PM, bob therriault <[email protected]> >> wrote: >>> Hi Michael, >>> >>> I think that your qwerty screen is excellent. >> >> Thank you. >> >>> On the number screen I think that the underscore [_] should be added to >>> allow for the entry of infinite and negative infinite into number vectors >>> without changing screens, also it would be useful to have y on this screen >>> if you are going to include x. >> >> The underscore is there, immediately to the left of the '1'. As for >> selecting which letters made it to the numpad, I wanted to squeeze in >> all the characters used for forming literals. The 'x' is provided for >> extended integers. Do you think providing 'y' should take precedence >> over having all the hex keys there? Space is pretty tight but I could >> gain some more by giving up on the oversized digits. Alternatively, I >> could just reduce the return key to standard size and put the 'y' in >> the vacated space. >> >> Thoughts? >> > > I see the underscore clearly now that you point it out :) . I think I would > reduce the return key size as this puts the x and y beside each other, but > thinking it through I am not sure it is needed at all and if it were there > would also be a case for m, n, u, and v. See comments on symbol screen below. > >>> I assume that the [...] key takes me to symbols, the [123] key to numbers >>> and the [ABC] key to the qwerty. >> >> Correct. The shift on the qwerty keyboard is really a caps-lock at >> the moment. I intend to convert it to the classic mobile tri-state >> shift eventually. >> >>>> If this is the case I think that you can change the [...] key that appears >>>> on symbols to a shift to take you to your two character primitive layout. >>>> This would allow you enter tacit code by just using the shift key (or >>>> shift lock if you prefer) and the symbol layout. >> >> I thought of that. In that case the 'shift' would produce identical >> results to swapping in the alternate keyboard unless I mistake your >> meaning. > > That is what I meant and that keeps all the primitives within one keystroke > of each other. It could be nice to have x and y included on the symbol > keyboard by making the lowest line smaller as this would allow explicit > programming in most cases without having to go back to qwerty. u, v, m, and n > would still not be available on the symbol keyboard, but there is only so > much space and most programming is done with x an y in verbs. > >> >>> I might also suggest making sure that symbols such as period [.], >>> semi-colon[:], and parenthesis [(] and [)] are kept in consistent positions >>> across screens to allow for muscle memory. It can be really frustrating to >>> have the symbol change location according to the screen. >> >> I did keep '.' and ':' consistent between qwerty and sym1, my idea for >> the numpad layout required a bit of a shift which I may rethink. The >> parentheses do deserve more consistent treatment.. thank you for >> pointing that out. > > Actually there is position change of '.' and ':' between number and > qwerty/symbol keyboards. I think that this could be pretty important, so you > may want to lock down size and position on '.' ':' space '(' and')' > >> >>> I think that is all that I see for now, but I am not a keyboard designer, >>> so take this very much as a crowd source approach to design :) . >> >> I am no keyboard designer myself. It's the crowd-sourcing I am after >> in this forum. Thank you very much for your comments. >> >> Given the wild popularity of mobile devices, I think it is important >> to get J onto a mobile device to broaden it's popularity. I used to >> carry a CE-device with J and it often struck me how the conciseness of >> J made it an ideal language for mobile use. >> >> - michael > > Some of these ideas extend further into visual gui and touch interfaces as > well. Keep up the good work. > > Cheers, bob > >> >> For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- - michael dykman - [email protected] May the Source be with you. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
