3 ms·
I totally disagree. Building a handheld application requires getting into the mindset of the UI that it requires. I say this having worked on handhelds for, u
by sanj 18y ago
I totally disagree. Building a handheld application requires getting into the mindset of the UI that it requires. I say this having worked on handhelds for, um, 15 years now.
And you're badly undervaluing delight.
Let me give a concrete example from my own work.
A buddy an I wrote a text-adventure parser so you could play stuff like Zork and HHGTTG on the Newton. It worked really well and was reasonably popular at least partly based on the interface.
Understand that you always have access to a keyboard on the Newton -- there was even an external one.
But what we did was to have a word automatically entered on the input box when you tapped on that word above in the description.
That was scads faster than tapping something out. And made users wicked happy.
- comatose_kid 18y agosanj, Your comments have been pretty insightful. Would you mind sharing a little more about your background wrt handheld development?
- sanj 18y agoSure. I ended up with a Newton from school when Apple was dumping the MP100s. A buddy and I started writing stuff for them -- some games and a VT100 emulator. Bits of them here: http://web.archive.org/web/20041210150544/http://www.scrawlsoft.com/ http://web.archive.org/web/20041210150544/http://www.scrawls... The game I mentioned is here: http://web.archive.org/web/20030811081833/scrawlsoft.com/products/yazi/info.html http://web.archive.org/web/20030811081833/scrawlsoft.com/pro... When the Newton disappeared on 1997-02-27, we got call from the guys at Palm (mostly ex-Newton folks) to lure us to code for the PalmOS rather than WinCE. We only wrote one neat bit: http://www.powermedia.com/pilot/index.shtml http://www.powermedia.com/pilot/index.shtml About a year after that I helped cofound PatientKeeper, http://www.patientkeeper.com http://www.patientkeeper.com, where I wrote the first 7ish versions of the handheld app before we hired some really talented engineers to hand it off to. I spent the next several years writing the server side of that system while watching them take ideas I'd had to new, amazing places. My last project there resulted in this: http://www.patientkeeper.com/news_and_events/press_releases/2008/02132008.html http://www.patientkeeper.com/news_and_events/press_releases/... Which, by my calculations, represented ~70% of their $45m FY08.
- ComputerGuru 18y agoThanks for sharing your experience in this field. But (and forgive me if I'm mistaken) your application was a special exception where the option of using the touchscreen UI made more sense, just as the Nintendo DS has a usability edge with its touchscreen. But for the more-general "productivity" applications - from email clients to word processors to graphics design software (where the "word bias" isn't an issue), I don't see touchscreens being the more efficient way to go. In my opinion, delight is great, but not when it comes at the expense of productivity. For games and leisure, productivity is a non-issue and - you're absolutely right - delight and simplicity should be the developer's number one focus. But for productivity tools, making things easier and quicker to get done is the most important thing. There's nothing more frustrating than banging out an email on a touch-screen keyboard; for productivity tools, increased productivity is the delight.
- sanj 18y agoSo perhaps point #8 should be: don't use a touchscreen when you shouldn't.