Are There Good Touch Screen Controls for Access?
TC
application is written in Access 95. It has many little features, but
its main job is to let the gate attendant look up people quickly and
decide whether or not to let them in. The current application works
surprisingly well, but the customer wants better performance, a better
user interface, and a few new features. The current application runs
on a PC in the gatehouse. If the customer is satisfied keeping the app
on the PC, I believe their requirements can be easily satisfied with a
newer version of Access.
However, they want to consider getting away from the PC and running
the app on hand-held touch screens, which the guards will carry into
the street as they engage drivers. I've concluded that this is
feasible -- there is nothing difficult about maintaining a wireless
connection or designing an effective user interface for an iPad sized
device. Unfortunately, the standard controls available in Access are
not very good for touch screens. In particular, I find that list boxes
which require scrolling are very difficult to use. It should be
possible to replace them with some kind of control that lets the user
"roll" up and down through a list. It would also be nice to have tab
controls that let the user drag pages open rather than clicking on
tabs.
Does anyone know where I can get controls like these, or any other
controls that are specifically designed for touch screens, and which
work well with Access? Has anyone used Access for a touch-screen app?
And if so, can you give me advice on the pros and cons of using Access
for this kind of development?
-TC
Albert D. Kallal
So, I used these touch based systems, and I used them with Access.
And in fact until you start to think about how software can and should work
is about the time you start asking questions like yours!
I can well say it took me about two good solid afternoons to figure out how
to make Access Web applications navigate the way I want. Things in web
browsers are so really very different than the typical form to form to form
navigation in typical Access desktop applications.
However, I have run some of my Access (web) applications on the above
mentioned devices.
A few things:
In the case of the iPad and Access, you are either going to be using some
remote desktop software, or you going to be using a web based application
(Access 2010 web services). In both of these cases, it not very likely that
the multi touch gestures can or even would be transmitted back to the
desktop or web based software correctly.
With the web then of course the pinch zoom and scroll works great with
Access on my iPad. However those gestures do not work for combo or list
boxes.
On the windows 7 phone, combo boxes on most web sites are converted into a
VERY cool touch scroll (gesture based) UI for picking a combo box. However,
Access web combo boxes do not display that UI BECAUSE Access combo boxes
also allow text (keyboard) typing. If we could disable the keyboard on those
combo boxes, then combo boxes would translate to a cool gesture based
selection process.
However for remote desktop software, it just not going to work this way.
However, you can still optimize your software (windows RDP or web) for a
touch based device. You have to change your approach and build a nice
"larger" continues forms in place of a list box (I mean, even in regular
access, it often hard to tell the difference between a sub form and a list
box anyway).
Along with larger rows, and providing larger target touch buttons such as
"edit" to view a row, you can do a passible job. This web based Access form
for example works quite well on the iPad:
http://www.kallal.ca/searchw/search3.png
The above is part of a soundex search example I have in Access that can run
in a web browser. The above sample code and article can be found here:
http://www.kallal.ca/searchw/WebSoundex.htm
In other words, the multi touch ability and those natural gestures you use
in native iPad or phone applications will not really work over a remote
connection to your desktop software (sure the pinch zoom and pan to scroll
around on the screen does, but not selecting of combo or listboxes). So,
even in the case where you did or could purchase some touch controls, you
could not be 100% sure such controls would work in web or remote desktop
software. I do not think that the iPad RDP clients to windows being sold
supports multi touch + gestures right now anyway that windows 7 desktop now
supports.
However, you can still optimize your applications for touch by providing
large buttons for navigation and edits. You can provide nice large continues
forms (in place of a list box). You can ensure that the number of names in
the list is minimal. You can ensure that navigation is kept to an absolute
minimum. You can ensure (in fact must ensure) that typing is kept to an
absolute minimum. And for things like date or time, you want them to be
defaulted.
In the following video of mine, I went to GREAT lengths to eliminate the
dance from mouse to keyboard and then back to mouse to allow the user to set
the start time and the end time. In fact, I can set the start time of 2 PM
and end time of 7 PM with JUST TWO mouse clicks. So, I find this form fun to
use in regular Access let alone on my iPad.
http://www.youtube.com/watch?v=AU4mH0jPntI
The time picker in above is just standard Access list boxes.
While touch devices like iPad have a REALLY cool time picker wheel on the
screen that you spin and rotate with your thumb, they are somewhat slow to
use and they do not appear when using a web browser.
In fact I find my above ONE CLICK time pick in that web form is much faster
than the gesture based time pickers. In the above video, you note I am
using access, but I made it TWO SIMPLE touches or mouse clicks to set the
start + end time from 4 pm to 8 pm (it takes just two quick touches on the
iPad). Of course if the minutes need setting, then that is two additional
touches, but is still far better than the gesture time picker on the iPad
anyway.
In fact the same much goes for any other type of pick list etc., and you
really cannot afford to have the user have to type much with these types of
devices. In fact holding an iPad and attempting to type on it is near
impossible. So if you cannot make most of the task an easy touch affair then
the whole project will become a failure. You must reduce and attempt to
build forms that are 100% choice based and not need typing.
And if you going to use Access, then you have to forgo most of the gesture
and motion based UI tweaks that these new touch systems have. I do admit
they are really nice.
So, you can still optimize your applications quite well despite not having
some of those new controls.
Access web services are a possible here. Unfortunately the Access web and
client combo box allows typing and that is NOT what you want. The reason
being is when a comb box is hit on my windows 7 phone, it goes full screen
and displays a really nice gesture based scrolling screen. (on the iPad
this does NOT occur). However, since the Access combo box ALSO allows
typing, then this cool UI does not appear when I using my wp7 phone and the
keyboard thus launches and you stay in the browser.
So, my advice is to forgo the nicer UI touch based options. If you really do
need the cool touch controls then you have to write a native iPad
application. In fact this is why so many people prefer the native
Applications such as eBay or YouTube or IMDB move database since then they
can use mostly gesture based navigation. This results in a far more fluid
application and likely explains the 18 billion dollars apple making on JUST
their iPhones and iPads software last year.
So, I do not think you will get anything close to the fluid response of
these devices using remote desktop software and Access. The smooth scrolling
would have to be transmitted over the connection, or some special support
built into RDP.
However, as web standards evolve, I believe in the future that Access web
will eventually be the best choice in terms of using Access on these types
of devices due to new emerging web standards.
For now, you have to just design your forms with caution, or build a native
tablet or phone application.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
TC
wrote:
Mr. Kallal,
Thank you. This information is gold. I haven't fully processed it yet,
but you've set me in the right direction.
-TC
David-W-Fenton
news:CHWmp.14292$sP1....@newsfe07.iad:
> I do not think that the iPad RDP clients to windows being sold
> supports multi touch + gestures right now anyway that windows 7
> desktop now supports.
Does any RDP client support them? When I connect to Win7 with RDP,
ti runs in reduced functionality mode, even with the highest
resolution/highest bandwidth settings. I assume this might be
different if I were connecting from a Win7 machine -- that is, to
get the Aero UI, you'd have to be running a version of Windows that
is also running Aero, because that's the only way the GDI-to-GDI
commands can be sent directly.
I don't know how the Mac RDP clients work at all, since there is no
possibility whatsoever of any direct GDI-to-GDI commands. But I
assume the client is smarter than VNC (which just sends bitmaps).
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
David-W-Fenton
news:CHWmp.14292$sP1....@newsfe07.iad:
> In fact the same much goes for any other type of pick list etc.,
> and you really cannot afford to have the user have to type much
> with these types of devices. In fact holding an iPad and
> attempting to type on it is near impossible. So if you cannot make
> most of the task an easy touch affair then the whole project will
> become a failure. You must reduce and attempt to build forms that
> are 100% choice based and not need typing.
>
> And if you going to use Access, then you have to forgo most of the
> gesture and motion based UI tweaks that these new touch systems
> have. I do admit they are really nice.
>
> So, you can still optimize your applications quite well despite
> not having some of those new controls.
If they can't type, then it's a read-only application, right? This
seems to me that it would make many Access applications completely
inappropriate for use on these devices. Or, at least, only a small
part of the functionality would be appropriate for use through these
devices. That seems to me to indicate that you'd need two different
UIs, one for your read-only users (optimized for portable devices
like iPad and smartphones) and the other for the people who do the
actual work in the database (i.e., entering data; and, yes, I mean
to be pejorative there). Seems to me the natural separation would be
to implement as web forms the UI for the mobile device users, and
use regular client forms for the desktop users. Naturally, anything
that would be usable by both sets of users would be implemented as
web forms.
Thoughts?
TC
wrote:
> "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com> wrote innews:CHWmp.14292$sP1....@newsfe07.iad:
Mr. Fenton,
For my application, your analysis is exactly right. I envision a
complete user interface using regular forms for desktop users. Only
one form would be necessary for the mobile device users.
Kallal & Fenton,
If I understand the advice I'm being given, it sounds like the best
tablet UI will come from a web application. A remote desktop approach
is feasible, but not quite as good.
This is unfortunate for me because I know nothing about Access web
applications. In my limited brain, Access is for developing desktop
apps, not web apps, and I've carefully ignored every attempt by
Microsoft to blur that line, from Data Access Pages through Access
Services. For this project, I will have to bring myself up-to-speed
quickly.
-TC
James A. Fortune
PDC08 session PC03 indicated that there is a Touch Platform API, but I
don't remember if it was available for Vista or Windows 7 only. I
think most of the touch laptops use one of those anyway. I haven't
tried using multi-touch with any version of Access, but that's where I
would start. I'm mostly finished viewing the PDC08 sessions, but I
haven't viewed any of the PDC09 sessions, so more recent information
might be available.
James A. Fortune
CDMAP...@FortuneJames.com
The Frog
I used to work extensively with security hardware. Access control is
of course a primary component of this and having an effective
gatehouse / guardhouse / control room / head-end is vitally important.
What I also learned in my years in this area is that most guards or
operators have about as much interest in learning new things or doing
the 'right thing' as a dolphin has chance of riding a motorcycle. Back
in around 2000 / 2001 we developed our first 'mobile' version of some
of our interfaces for handheld devices (iPaq's running CE if I
remember correctly). We tried remote desktop type approaches, web
pages and native built apps (the dev kits used to be free, I dont know
if they still are or not).
In the end what we found is that the most rapid way to develop a
mobile front end is through a web interface, but it was not a
particularly robust approach for the given scenario. The remote
desktop suffered terrible problems, particularly with the need to re-
authenticate all the time making it run like a dog, and the guards
simply didnt want to use it. Building a simple native app took a
little longer than building for a web interface, but it was much more
reliable. The reason for this difference in reliability came from the
(at the time) lack of 'push' capability that a website could deliver.
For example if you have a guard manning a boom gate, and a car pulls
up, the driver presents their access card to the reader, the web
interface didnt know anything about it even though the server did - so
the guard had to press a single button on the web interface to affect
a refresh and guess what - they just dont do it. I was stunned beyond
belief. A single button for crying out loud.
When we made a simple mobile native client we were able to 'monitor'
the events that were happening on the back end db (I think we were
using SQL Server 2000 at the time, it might have been 7.0). We had two
forms, one for the guard to login and select a gate to monitor, which
then switched to the second form displaying the details of the person
who just badged their card and two buttons for allow / deny. As the
driver badged their card the info was directly 'popped' up onto their
handheld device and things worked well. Simple scenario and two very
different outcomes.
The point I am making is this: When you are developing an app,
particularly for specialised roles, you have to consider the
operational needs of your target audience very carefully. I did not do
the development work on that particular app, I wrote the specification
that formalised the development and final tool. If I were to do this
again I would not use a web app or remote desktop in these scenarios
at all. I would have a machine somewhere on the network that
'broadcast' (not a broadcast packet) the required information to the
handheld devices across the network. I would have the handheld devices
'register' themselves with this machine (lets call it a server for
arguments sake) with their ip address and a suitable authentication
token, generate a 'session' key probably by using diffie hellman, and
have a native app 'listening' for this broadcast info. In the native
app you can then respond to that info any way you wish. Maybe there is
a simpler way with some kind of web-service that runs a continuous
feed of data that an app can consume. I would want to explore those
possibilities.
Access is a great tool for may tasks, but mobile is not one of them.
The only truly robust solution for mobile is to actually build a
mobile app (in my experience). This involves a data provider (the back
end that can 'push' information) and a data consumer which is the app
itself. Its been a while since I played with all those security
hardware toys and I can feel the memories bubbling back up. Maybe
something more will come to mind now that it has been stirred. Out of
curiosity what is the system (hardware) you are working with?
Cheers
The Frog
Albert D. Kallal
news:Xns9EBF88A1DDAE7f9...@74.209.136.92...
>>
>> So, you can still optimize your applications quite well despite
>> not having some of those new controls.
>If they can't type, then it's a read-only application, right? This
>seems to me that it would make many Access applications completely
>inappropriate for use on these devices.
Well, they can type, but your point still stands well.
So it just that some things are not ideal. For example if you touch a Access
combo box on a form with a tablet (or smartphone), the device senses that
keyboard input is possible, and then a huge keyboard pops up that covers 50%
or more of the screen. For some of those touch options I would rather not
have the keyboard pop up on the screen. At the end of the day tablet
devices are really great for consuming content, but not great for forms that
need lots of data entry. If one can make everything on the form a point and
shoot choice, then it works very well.
>That seems to me to indicate that you'd need two different
>UIs, one for your read-only users (optimized for portable devices
>like iPad and smartphones) and the other for the people who do the
>actual work in the database (i.e., entering data; and, yes, I mean
>to be pejorative there).
Yes, the above is quite much how I also see this. These devices are great at
consuming content and not creating content. A computer sales rep I know
about 3 months ago switched over to using a iPad all day long in place of
his laptop. He uses remote desktop to his windows computer for some company
email and to get at some documents etc. However during the day of checking
emails and status of sales orders works etc, he not doing much data entry.
And in a pinch he can respond to some emails that do not require a much
typing. So this is very much read only work most of the time, and the
instant you need to edit a letter then the on screen keyboard simply sucks
at that this kind of task.
>Seems to me the natural separation would be
>to implement as web forms the UI for the mobile device users, and
>use regular client forms for the desktop users. Naturally, anything
>that would be usable by both sets of users would be implemented as
>web forms.
>Thoughts?
I think that of all of the office programs (Excel, Word, PowerPoint etc.),
Access moves to the web the best. The reason for this that Access
applications are built around forms which translates rather well to web
based forms in a browser. I mean, Excel or even a word processor on the web
has to scroll and move around a ton of text around on the screen where
Access does not.
So, once web forms are built, they run well on both desktop and on these
devices. While Access client forms are great, I have to admit that most web
form works (built with any system) well enough for most types of Access
applications and users.
The real issue is good touch applications require VERY good response. As
noted this explains why so many people prefer to download + install
applications on their iPhone or iPad since they are so much more fluid then
just a 100% web based system. So I do think that a native application is by
far the best in terms of user experience on these devices. The scrolling and
native screen controls like combo box and date pickers etc. are optimized
for touch.
However, next in line is RDP and I think RDP works better then the web in
terms of quick response and is quite much like windows desktop.
The web systems however are great from a easy deployment option.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Albert D. Kallal
news:Xns9EBF88A1DDAE7f9...@74.209.136.92...
>>
>> So, you can still optimize your applications quite well despite
>> not having some of those new controls.
>If they can't type, then it's a read-only application, right? This
>seems to me that it would make many Access applications completely
>inappropriate for use on these devices.
Well, they can type, but your point still stands well.
So it just that some things are not ideal. For example if you touch a Access
combo box on a form with a tablet (or smartphone), the device senses that
keyboard input is possible, and then a huge keyboard pops up that covers 50%
or more of the screen. For some of those touch options I would rather not
have the keyboard pop up on the screen. At the end of the day tablet
devices are really great for consuming content, but not great for forms that
need lots of data entry. If one can make everything on the form a point and
shoot choice, then it works very well.
>That seems to me to indicate that you'd need two different
>UIs, one for your read-only users (optimized for portable devices
>like iPad and smartphones) and the other for the people who do the
>actual work in the database (i.e., entering data; and, yes, I mean
>to be pejorative there).
Yes, the above is quite much how I also see this. These devices are great at
consuming content and not creating content. A computer sales rep I know
about 3 months ago switched over to using a iPad all day long in place of
his laptop. He uses remote desktop to his windows computer for some company
email and to get at some documents etc. However during the day of checking
emails and status of sales orders works etc, he not doing much data entry.
And in a pinch he can respond to some emails that do not require a much
typing. So this is very much read only work most of the time, and the
instant you need to edit a letter then the on screen keyboard simply sucks
at that this kind of task.
>Seems to me the natural separation would be
>to implement as web forms the UI for the mobile device users, and
>use regular client forms for the desktop users. Naturally, anything
>that would be usable by both sets of users would be implemented as
>web forms.
>Thoughts?
I think that of all of the office programs (Excel, Word, PowerPoint etc.),
Access moves to the web the best. The reason for this that Access
applications are built around forms which translates rather well to web
based forms in a browser. I mean, Excel or even a word processor on the web
has to scroll and move around a ton of text around on the screen where
Access does not.
So, once web forms are built, they run well on both desktop and on these
devices. While Access client forms are great, I have to admit that most web
form works (built with any system) well enough for most types of Access
applications and users.
The real issue is good touch applications require VERY good response. As
noted this explains why so many people prefer to download + install
applications on their iPhone or iPad since they are so much more fluid then
just a 100% web based system. So I do think that a native application is by
far the best in terms of user experience on these devices. The scrolling and
native screen controls like combo box and date pickers etc. are optimized
for touch.
However, next in line is RDP and I think RDP works better then the web in
terms of quick response and is quite much like windows desktop.
The web systems however are great from a easy deployment option.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Albert D. Kallal
news:3b59ec1e-4cd3-4ca0...@a17g2000yqn.googlegroups.com...
>Kallal & Fenton,
>If I understand the advice I'm being given, it sounds like the best
>tablet UI will come from a web application. A remote desktop approach
>is feasible, but not quite as good.
Well, actually, you can read my other comments. I think RDP is better then
web in terms of response and in fact RDP would give and allow you to use the
Access as your development tool.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
David-W-Fenton
news:e5ae8795-5600-47e7...@m7g2000vbq.googlegroups.com
:
> The remote
> desktop suffered terrible problems, particularly with the need to
> re- authenticate all the time making it run like a dog
Sounds like a configuration error on the terminal server.
David-W-Fenton
> "TC" wrote in message
> news:3b59ec1e-4cd3-4ca0...@a17g2000yqn.googlegroups.
> com...
>
>
>>Kallal & Fenton,
>
>>If I understand the advice I'm being given, it sounds like the
>>best tablet UI will come from a web application. A remote desktop
>>approach is feasible, but not quite as good.
>
> Well, actually, you can read my other comments. I think RDP is
> better then web in terms of response and in fact RDP would give
> and allow you to use the Access as your development tool.
...as would an A2010 app using only web forms/reports and deployed
with Sharepoint 2010 and Access Services.