After a few days of using the device, my conclusions:
It works fine to read documents (pdf books) and watch movies (even on a screen connected via HDMI, which is a plus). You can play simlpe games. You can surf the web (minus Flash).
If you do not want to buy an Android phone (or get locked into a telco contract), you want a bigger screen but dont want to spend a bomb then this device is for you.
I do not recommend the Palroid because of these major flaws (based on the experience with the specific device I bought)
- Dropping wireless connection.
- Stdby mode drains the battery in few hours. My Nexus One can stand 2 days stdby (with regular but not extensive use).
- The g-sensor does not work properly for games.
- You can charge only with the power adapter.
- Anrdoid 2.1 (From other feedback I could read there will BE NO UPGRADE to 2.2!)
I will wait until early next year when the dust around Android 2.3 settled, 3.0 is getting clearer and after finding out which device is future-proof (can be updated), before getting another Android device.
As an IT company you know feedback is vital and can be crucial to maintain a level of quality. Either you collect feedback a) directly from your users (person to person, email, phone, ticket system,..) or b) let the deployed software talk to you directly. How many time some piece of software crashed or did something wrong and you – as in case a) – dont bother to do anything and just restart the application and continue your work ? Many times I guess, only if the software really does not wok anymore, we would feedback and complain. So all these valuable small (and lost) incidents that appear isolated to a enduser would help to increase the quality of the software if we just would feedback (manually).
But most of us are also not happy if the software talks back to its vendor directly because we either fear it would transfer personal data or just would tell the vendor that you are using some pirated version of its application.
Producer: Display it clearly and ask for approval to transmit bug data to a central server. Show what you going to transmit. Make it optional.
Consumer: Let the software talk back. It will not help you this time, but with truckloads of bug reports flowing back the software, it will ultimately gets better and benefits everyone.
Sample (what Thunderbird sends back after crashing)
Application Launch Time
9/6/2008 2:33 PM
Monitor Configuration Version
Talkback Configuration Version
32-bit Windows exception
Information Collection Time
9/6/2008 2:47 PM
[ 0] 20 00 00 00 2B 00 00 00 00 C0 5F 5F 00 B0 44 36 [ …+…..__..D6]
[ 10] 00 80 2A D6 00 A0 0C B5 00 00 FE 7F 00 C0 6B 79 [..*………..ky]