Soft touch buttons (virtual buttons) usablilty

by Craig Mitchell » Tue, 07 Dec 2010 13:34:43 GMT


Sponsored Links
 Most phones now have soft touch buttons (including the new Nexus S).

I really struggle with soft touch buttons.  They are too close to the
screen for me.  And for some reason, on my N1, I have to press them
right at the top for them to register, so I'm often pressing controls
on the screen rather then the buttons.

I've noticed a few complaints about this.  However, I would be
interested to know if some phones work better then others with the
soft touch buttons.

Has anyone tried a few phones with soft touch buttons and noticed a
difference?

-- 
.



Other Threads

1. Android App Resolution

Hi all

Need help on android app resolution,
Since everyone know that android OS is on all different resolution
there will be problem on designing the interface.

- What the best resolution you use when you design the background
image?
- How to make the background image fit all different phone
resolution ? (I search around it say something like DP or SP)
- What layout the best you all used? (Since it say avoid absolute)

Thanks :)

-- 

2. Autodiscovery for Activesync

I recently found out why autoprovisioning doesn't work for my
Activesync server on Android.
It turns out Android's implementation is only doing a small portion of
the procedure described in this whitepaper:
http://technet.microsoft.com/en-us/library/bb332063%28EXCHG.80%29.aspx
When I use this page: https://www.testexchangeconnectivity.com/Default.aspx
to test my server, it confirms that everything is in working order.

I went looking for the source on http://android.kernel.org and found
the source of the email application done by Marc Blank:

            // There are up to four attempts here; the two URLs that
we're supposed to try per the
            // specification, and up to one redirect for each (handled
in postAutodiscover)
            // Note: The expectation is that, of these four attempts,
only a single server will
            // actually be identified as the autodiscover server.  For
the identified server,
            // we may also try a 2nd connection with a different
format (bare name).

            // Try the domain first and see if we can get a response
            HttpPost post = new HttpPost("https://" + domain +
AUTO_DISCOVER_PAGE);
            setHeaders(post, false);
            post.setHeader("Content-Type", "text/xml");
            post.setEntity(new StringEntity(req));
            HttpClient client = getHttpClient(COMMAND_TIMEOUT);
            HttpResponse resp;
            try {
                resp = postAutodiscover(client, post, true /
*canRetry*/);
            } catch (IOException e1) {
                userLog("IOException in autodiscover; trying alternate
address");
                // We catch the IOException here because we have an
alternate address to try
                post.setURI(URI.create("https://autodiscover." +
domain + AUTO_DISCOVER_PAGE));
                // If we fail here, we're out of options, so we let
the outer try catch the
                // IOException and return null
                resp = postAutodiscover(client, post, true /
*canRetry*/);
            }

It's the part where the autodiscovery process should query the SRV-
record _autodiscover._tcp.domain.com which is missing and messing up
any possibility for a clean autoprovisioning.

I'm not a developer myself and am hoping some of you are.
Is there some way to mature the email application in Android and get
the full procedure implemented?

-- 
.

3. Video Reset when orientation changes

4. aapt and Android library projects

5. SetContentView error - Android

6. honeycomb email search

7. Fwd: List onItemSelectedListener not working