I have a user that doesn’t want to use the mouse when using a Servoy application.
I noticed some situations that mouse is needed while user don’t want to use it.
It would be nice if Servoy could be used mouseless.
I noticed some situations where mouse could be avoided, but mouse needs to be used.
I have to check now if my whole application is mouseless, and where I see that mouse is needed, but can be avoided, then I’ll post it here.
It all may sound strange to you all, but my customer has used DOS application for more than 20years and working with Servoy is now 1 step to far.
Perhaps other developers have the same problem with customers, so I would be happy if you could post here your experience with Mouseless Applications in Servoy.
The first situation I noticed is that when using a combobox, a mouse needs to be used and in my opinion it could be avoided.
When stepping into the field the combox is shown.
With cursor keys you can go up/down to select a record.
But a ENTER or mouseclick is required to return the selected value.
I think that also on TAB the selected value from the combobox must be selected and the focus must go to the next field
The topic you linked to, I do not consider as serious.
My request is serious.
My customer is using DOS application now and has to use a new Servoy application soon, but they want to work only with keyboard, because of the speed to enter data (they must enter a lot of data and almost all of this data are numeric values).
I’ll notch up one level to semi-serious then Make a layout with a black background. Use a a bright orange or green font. Pack in as many fields as possible. Select your insert mode. Get the menu plugin from iT2Be (or use Servoy 4) and map function keys to methods. For your tab example, put a method on field exit that saves the data. Should be quite doable.
martinh:
The first situation I noticed is that when using a combobox, a mouse needs to be used and in my opinion it could be avoided.
Hi Martin,
We don’t do mouseless interfaces but try to minimize mousing. Don’t want to give our users un-necessary RSI (Repetitive strain injury).
In the case of the combobox, I can operate them from the keyboard in Servoy 3.5.6 on Mac OS X as long as they are included in the tab order, but I don’t find them elegant.
Since it works well with the keyboard, we make extensive use of the standard popupmenu plugin that comes with Servoy. We often let users select between selecting values and performing actions.
martinh:
When stepping into the field the combox is shown.
With cursor keys you can go up/down to select a record.
But a ENTER or mouseclick is required to return the selected value.
I think that also on TAB the selected value from the combobox must be selected and the focus must go to the next field
This is becoming very urgent.
Potential customers will not use Servoy because if this.
martinh:
When stepping into the field the combox is shown.
With cursor keys you can go up/down to select a record.
But a ENTER or mouseclick is required to return the selected value.
I think that also on TAB the selected value from the combobox must be selected and the focus must go to the next field
This is becoming very urgent.
Potential customers will not use Servoy because if this.
I’ve tried but I can work perfectly with keyboard only.
In my version (3.5.6) when I am in a combobox, and I press TAB on a highlighted value, my field remains empty and the selected value is not placed in my field.
The focus is going directly to the next field in the tab-sequence.
In my version (3.5.6) when I am in a combobox, and I press TAB on a highlighted value, my field remains empty and the selected value is not placed in my field.
The focus is going directly to the next field in the tab-sequence.
Martin
Yes you have to hit enter to select a value. That’s how comboboxes work. I tried in a few apps and enter appears to be the de facto standard.
ENTER is on the keyboard. That doesn’t require use of the mouse. I’ve seen both behaviors in different apps, so I guess there’s not a “standard” for the way a combobox should react to a tab, but I tend to think what Servoy is doing is as valid and correct from a UI point of view as accepting the change on a TAB.
I expect you could work around this if you were willing to directly manipulate some Swing components in your code, but that’s probably more effort than it’s worth.
You could, however, totally avoid the combobox if you feel this is insurmountable and offer another more keyboard friendly way to select from a list. Depending on the type of list, you could use buttons, or popup menus as suggested earlier.
Look at the preferences of Servoy Developer.
That is indeed working on ENTER, but there is also a difference.
When you select the tab ‘Locale’ and go to the combobox ‘Standard Locale’ there you see that when moving through the combo, the value in the field is changing also. So when pressing TAB on such a field, then the field already has the correct value.
Within my Servoy application the value doesn’t change, while moving in the combobox. Why doesn’t this work the same? If it would work like in the preferences, it would be ok for me also.
Is this some setting?
Or does it something have to do with autoSave=Off?
I’m missing the point. In my client (mac) I can use both the space and the enter to select a value, no need to use mouse. In preferences the same applies in my case. LAF could influence it, I think
I have a Windows Vista Client.
See screenshot, in the combobox there is value A18H selected, but the field still contains A40M and when I use TAB, the field remains A40M.
Space is not working. Is that some Mac behavior?
I have datamanagers who have to be using the Servoy application all day long and thus I make sure that they can keep their hands on the keyboard as much as possible and ALSO don’t have to do repetitive things like hit the down arrow key a bunch of times to select something. Therefore I incorporate two design elements to keep to simple typing as much as possible:
I use type-ahead fields in almost all situations where the user will be selecting from a list of some kind. Type ahead is much more intuitive to someone who is used to doing their work with a keyboard, it is faster for data entry and involves just ‘regular’ keys. Someone who comes from a DOS background I think would quickly learn to appreciate that type ahead fields simply save on typing as after just a key stroke or two you hit the return key.
With good use of Servoy’s inbuilt function of using the number keys in conjunction with the Command key (Control on PCs), you can use the available 10 combinations to run global methods that can perform almost all the things that people often use mice for. Examples are jumping from tab to tab, portal row to portal row and adding or updating records. With proper naming of elements and a few global methods these actions can be executed properly no matter where your user is currently in your solution.
Someone pointed me to a blog post of renowned UI guru Bruce Tognazzini.
It refers to an article he actually published in AppleDirect, August 1989 .
It’s named Keyboard vs. The Mouse, pt 1
2 things stands out in that article:
We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
Test subjects consistently report that keyboarding is faster than mousing.
The stopwatch consistently proves mousing is faster than keyboarding.
This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.
And further in that article:
Command-Key Illusion. Since users do experience the illusion that keyboarding is faster, there is market pressure to supply them with “shortcuts.”—even when using “shortcuts” will actually slow them down. What I generally recommend is supplying as many “shortcuts” as demanded by the market—the real market, not the programmer in the cubicle next to you. But only if these “shortcuts” are not to the detriment of the user of the Macintosh visual interface. This leads to two important guidelines:
Guideline: The keyboard interface must not dictate the design of the visual interface.
Guideline: The work to design and build the keyboard interface should not sap resources that are needed for the creation of the visual interface.
In other words, don’t rape the primary interface for the benefit of so-called “power-users,” who may well end up achieving lower productivity by using the keyboard interface anyway. This is a major problem right now.
Interestingly enough he (or is it Buxton?) says that this doesn’t apply for the editing (cut/copy/paste) shortcuts.
All in all an interesting little read.
Yes the windows look and feel has the default behavior of changing the selected value as you go through the list
Other os’ses like Linux and the Mac dont do that by default
And for once i think Windows is wrong. If i go through the list then i dont change the value yet! What happens on windows when you press escape? right you dont go to the previous value because the value is already changed!
thats just stupid
another thing is why is it when i use the mouse to scroll over the values the selection does change in the list but the selected value not… Why is there that change in behavior, on windows laf, when you do it with the keyboard and mouse?
Also for Servoy a datachange on every selection change is horrible. So we made it so that it is consistent over all solutions
Now the question is do we want the TAB to be also an Enter?? What do the users of servoy think?
Should we really have an enter moment? That you really select the value just like if you would do it with the mouse (mouse click)
or should tab be auto enter?
Good item for discussion at Servoy World! Personally I’d go along with the tab selection as that is similar to other types of fields: after typing to move on you tab. In this case after ‘selecting’ you tab and in both cases it means the value is ‘entered’.
But what’s this ‘for once i think Windows is wrong’ business?
most of the time i think apple/mac is doing something stupid
which mostly they really do!
But combo boxes really have different kind of behaviors all over the place even different browsers on the same platform behave differently in this area.
john.allen:
Good item for discussion at Servoy World!
Unfortunately I haven’t seen your reply earlier (I came directly to SW after my holiday, so I haven’t been online for 3 weeks), otherwise I really would have liked to talk to you
