Have the iPad linked to a bluetooth keyboard.
It seems that there's no way in avoiding some kind of a input interface coming up when you select a field (even if that interface isn't an actual keyboard) depending on how you want to enter data. If you already have things in value lists and you want to avoid a keyboard I would suggest the popup menu. When you select a popup menu on an ios device you still get the input interface of a scroll through picker for the value list, but it's not an actual keyboard. Also, with the popup menu it disables the ability to switch to the keyboard (as opposed to a drop down list which would give you the option to switch to the keyboard).
The only way you can truely avoid a keyboard or scrolling picker is to use a checkbox set or radio buttons. With these two settings you're interfacing directly with the field. The down side is that if you have a large value list it could eat up a lot of screen real estate.
Hi Chris, and Malcolm too …
Thank you both for taking your time to answer.
I did noticed already sometimes agor that a linked bluetooth keyboard actualy did disable completely the screen keyboard.
But that's not a really practical way for a mobile solution as soon as you get out of range, that is why I was looking for a more "software" idea.
I have to check now how, and if, I can replace most or all of the drop down's by pop up's, checkbox or radio set's buttons.
The screen of the iPad is not that big anyway, so it involves also redesigning the user interface.
Thanks again for your contribution.
I'll let you know how it works.
Good luck on your project.
Something else I thought about that may be a bit more work (depending on how many menus you Have), would be to build your own picker layouts using checkboxes and radio buttons.
The idea is:
- turn your fields that have value lists into buttons
- attach a script to the button that takes you to a layout that has only that field with a checkbox or radio button version of the value list that normally goes in drop down list or popup menu form for the field.
- The user can select the values they want and because it's a checkbox or radio button set you don't get a keyboard or scrolling picker.
- put a button at the bottom (or top (or both)) of the layout that returns the user to the original layout
If you only have a handful of lists then this may not be a terribly time consuming task and would make for a possibly more smooth user experience (It's only a theory so I don't know for sure ). If you have a lot of fields to fill in though I could see it being more of a pain than a help.
Just thought I'd throw that out there. I think I remember one of my co-workers that does filemaker coaching describing a similar process for a client so if I get a chance I can ping him to get his 2 cents.
Thanks again Chris …
After reading your answer, I was trying to figure out how to design this with a "keep it simple and stupid" user experience in mind.
You may know that in a restaurant business, you have to deal with workers not necessarily computer minded, so I always kept the number of layouts to minimal (on the Mac version of course).
Actually, they work in a single layout with different tables appearing in portals.
This way, they only have one working environment, and the learning curve is almost reduced to just minutes.
They never get lost with multiple windows/steps as it is usually the case in such applications.
I need to re-think this logic for the iPad, and i'm just starting on it.
You understand now why the screen keyboard was simply taking too much space, but anyway, it will never be possible to fit a complete 21" Mac screen full of data and buttons on a 10" iPad.
So, re-designing the way to work within the application is a must in this case.
And this process is not only writing a few new scripts or shortening several menus, it's really more a global re-thinking.
And before being able to enter the process, I had to know about this keyboard problem to find the direction to follow.
You helped me a lot already !
I'll do a test with your ideas, it's probably the way to go.
Keep in touch…
Thanks for your time.
I know what you mean as far as keeping it simple. After replying to your post I sat down and created a quick concept file of the idea of the manual picker for a fmg ipad application (it's always nice to have an example file on hand to show co-workers, clients, etc). I attached it to give you an idea of how it would work. There's some other simple things in there that also may be of help like the background object size that enables scroll lock (if you grab the background and try to move it around it won't move), the offset for font rendering (only certain fonts render on ios devices and when they do they're not always where you placed them). Nothing fancy, just simple stuff that make the user focus on the data and not the interface.
ManualPicker.fp7.zip 6.6 K
Layout switching may be solution. It offers an easy way to present lists that are too long to present as checkboxes or radio buttons. It isn't difficult for users to understand, especially if the behaviour is consistent and reliable. Whatever you do, don't use multiple windows. The iPad will only display a single window at a time and switching windows is slow ( too much razzamatazz ).
Recently I developed a system that uses Bruce Robertson's virtual list technique to provide users the ability to make multiple selections when the value lists were too long to display as checkboxes. We did not want the overhead of creating a value list table. We also wanted to use FMs built-in value lists. His method allowed us to use a single layout for all the value lists. You may want to have two layouts: one for multiple selection and one for single selection. I used a single layout and passed an extra parameter to signal whether is was a single or multi-selection.
You get a lot of scope with this method because it provides access to finds, sorts and sub-summaries. To make things look nice I also did sub-summary reporting on the first character of the word when the number of items exceeds 50. That displays A-Z headings with the items beneath them. I allowed users to perform finds on the value list because some lists were very long (hundreds of items). It's a tech-savvy workplace and I taught them to do suffix searching using the first three letters of a word. For a restaurant environment you could use buttons on the layout to provide simple push-button filtering tools.