Emulators and 'mental displacement'
Summary: Somehow or other, I found myself working on a white paper this past weekend rather than basking in the heat of a British Bank holiday. No sympathy is required (or expected) as it was actually rather thought provoking to try and elucidate the whys and wherefores of GUI development for the embedded space.
Somehow or other, I found myself working on a white paper this past weekend rather than basking in the heat of a British Bank holiday. No sympathy is required (or expected) as it was actually rather thought provoking to try and elucidate the whys and wherefores of GUI development for the embedded space.
I was trying to find a term to describe the use of emulation tools that attempt to recreate an embedded device's behaviour on a PC during the design stage of an application.
'
Free Image: Wikimedia
While this approach can help to try and represent the application in its final form, it can never truly emulate the operation with a smaller screen (for a mobile device) with a touch screen (for a kiosk) or via limited keyboard (for any combination of the two) can it?
My argument was that an additional human factor is needed. Therefore the developer needs to extend a degree of 'mental displacement' to imagine how the device might work in final deployment.
When Googling the term to find out if I had reinvented the wheel and used an expression already in existence or come up with a real gem, I found that 'mental displacement disorder' was as close as I was going to get. So let's move on shall we?
In practice, what you need to remember is that integrating software on hardware is tougher with embedded than it is with desktop systems because there is just so much variety in terms of the hardware itself.
Open source could provide an invaluable link here because if you have a collection of binary drivers they may not necessarily work in every place you want to put them so...
To fix this, you need the source code for re-fitting the drivers to get them to work on your hardware. Even when you have a working proprietary driver on one hardware configuration, it might not work on a later version.
So being locked in to one set of proprietary drivers is bad news here then - and being able to tap into an open community's repository of code samples and components could help the mental displacement process hugely here.
So I didn't get to coin the next industry killer term, ah well – back to Urban Dictionary for me then. I know my level.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Never ceases to amaze me that that pretty obvious statement is so often ignored.
Take hole in the wall cash machines for instance, has it never occurred to anyone that the user might have trouble seeing the screen with the sun blazing directly onto it? Or that an audio message "PLEASE TAKE YOUR CASH" might just be a teenie invitation to a mugger?
I'll take that as an "I agree" comment from you then :-)
The argument extends though from this point doesn't it? I mean, what if we're talking about mobile phones that we should be kind of pretty used to developing for by now.
Shouldn't we be getting that right?
Or will that never be the case because of a) too many different hardware configurations, form factors, platforms and applications and b) the ever growing number of units that the manufacturers produce and the differences in battery life, screen size, keypad etc. that they all have.
Food for much thought I think.
Adrian
lol, I think the government should convene a panel of 'certified stupid people' to test new products, and insist any new gadgets have to be useable by the panel before they can be marketed.
@andy: "I think the government should convene a panel of 'certified stupid people' to test new products" -- ahh, that sounds suspiciously like the Numpty Panel http://bit.ly/numptypanel ;)