Now this is dangerous....

Anything goes, eh?  You folks are indeed brave for opening yourselves up to an "anything goes" forum. :)

So, I'll have a go at it.  Rest assured, I am a nobody in the industry, so you can take this at face value.   The EOS is a great console.  I had an opportunity to briefly see one up close a while ago.  Now I have designed a great number of graphically-rich user interfaces for a number of software/hardware packages that utilize touch screens exclusively - and as a brutal critic, I noticed one thing that stood out right away on this unit.  The touch screens showed the windows mouse cursor as I touched the screen.  *grabs a rolled-up newspaper*  Bad ETC.

I hope that the unit I saw was an early one and you have since removed said detail.  For reference, if you are using a Microsoft development platform for your XPe work, then you can remove the cursor using straight code.  Otherwise, you can replace the default windows cursor set with blank ones (available all over the net and probably from your touch screen supplier).

Now your response would probably be - as would that of many - "It's a great console, who cares about a mouse cursor?!"  To which I would reply that you are correct - except - that as a general rule, the greatest products made today are labeled as such because they never neglect the details - no matter how small.

So there ya go.  My penny's worth of critique.

 



[edited by: Snarl at 9:09 AM (GMT -6) on Thu, Jun 21 2007]
Parents
  • Thank you for your comment.

    Our goal with the user interface on Eos has been, since the beginning of the project, to ensure the user never has to use a mouse while programming on the console.  I would hope that we have come close to achieving that goal.

    That being said, some of our users are still more comfortable using a mouse for some operations such as navigating the browser or changing tabs.  For that reason alone, we still have the cursor available on the interface.  In future releases, we hope to make navigating even easier to move people even further away from using a mouse.  Aside from that, some features on the interface, which add a bit of convenience to users using the off-line software, require a mouse or an external touch screen.  We felt these off-line features should not be taken out of the console software, so they were left in as alternate ways for a user to do things and thus the cursor still exists for that as well.

    Besides that, if for some reason, the touch screens were to break (which shouldn't happen...they are of a very high quality), we don't want to leave our users without a way of using the console. 

    In the future, I would expect we would hide the cursor in certain situations, but only after we receive more feedback on the console to understand the situations when cursor would not be used.

    Again, thank you for your comment.

    -Derek 



    [edited by: doc_blume at 2:38 PM (GMT -6) on Fri, Jun 22 2007]
  • Foolish me.  I should have assumed that there would be an actual reason for leaving the cursor in.  Although I am surprised to hear that some folks actually prefer a mouse to a touch screen in that environment.  I would think however that one way to address the desire to use a mouse either out of operator comfort or touch screen failure - would be to code the software so that if it detects a mouse different than (or in addition to) the touch screen "mouse" in the device manager (as I assume that your touchscreen driver emulates a virtual mouse), that it would enable the cursor, and if it detected only the the touch screen "mouse", then it would hide the cursor.  Wouldn't that allow the best of both worlds without sacrificing anything?

    Just thinking out loud.  Thanks for the reply.

     



    [edited by: Snarl at 5:31 PM (GMT -6) on Sat, Jun 23 2007] [edited by: Snarl at 5:29 PM (GMT -6) on Sat, Jun 23 2007]
Reply
  • Foolish me.  I should have assumed that there would be an actual reason for leaving the cursor in.  Although I am surprised to hear that some folks actually prefer a mouse to a touch screen in that environment.  I would think however that one way to address the desire to use a mouse either out of operator comfort or touch screen failure - would be to code the software so that if it detects a mouse different than (or in addition to) the touch screen "mouse" in the device manager (as I assume that your touchscreen driver emulates a virtual mouse), that it would enable the cursor, and if it detected only the the touch screen "mouse", then it would hide the cursor.  Wouldn't that allow the best of both worlds without sacrificing anything?

    Just thinking out loud.  Thanks for the reply.

     



    [edited by: Snarl at 5:31 PM (GMT -6) on Sat, Jun 23 2007] [edited by: Snarl at 5:29 PM (GMT -6) on Sat, Jun 23 2007]
Children
No Data
Related