View Single Post
Old 01-04-2012, 09:46 AM   #40
pruss
Evangelist
pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.pruss ought to be getting tired of karma fortunes by now.
 
Posts: 461
Karma: 819417
Join Date: Nov 2004
Quote:
Originally Posted by DiapDealer View Post
People often make the mistake of thinking that adding user configurable-options is a very simple process and can be easily accomplished. It doesn't work like that. Especially on simple devices with limited resources. Choices add overhead... decisions that need to be made before graphics, text or menus can be rendered on the screen. Every decision (configurable setting) slows things down. Also, the more configurable software is, the buggier it tends to become. Things become bloated. Updates and bug-fixes start getting few and farther between. Cats and dogs living together—mass hysteria!
There are simple and there are complicated user configurable options. Selecting what to show at the bottom of a screen is a simple one. Something that involves rendering a single line of text per screen does not noticeably slow down any modern device, no matter how limited, assuming all the data is available in the code already, or can easily be made available.

Quote:
Yes, I exaggerate, but there really is no such thing as a simple user-configurable option. User Choices are the antithesis of stability... and always have to be balanced against each other.
I agree that there are stability concerns whenever you make things more complex, but the amount of complexity we're talking about here is very small. Major mobile open source projects like Plucker and AstroInfo for PalmOS and APV PDF Viewer for Android that I've worked on are very configurable (I add tons of configuration options when I join a project), while remaining fast (Plucker is fast enough that I haven't been able to switch to Android as my main ebook platform, as I haven't yet found an Android ebook app that matches Plucker's abilities to search and load large files), pretty stable and not very large. Plucker is a good example here, as it runs on devices much more limited than early Kindles. The latest version I have is only 278K for the binaries and probably doesn't use more than about 80K of heap RAM (and that's being conservative), and I normally underclock my PalmTX to 200mhz for it (compare to a Kindle 2 with 32mb RAM and a 500MHz processor).

One real issue with complex configuration stuff is that users get lost in many pages of configuration, and that's probably been an issue in the projects I've been on. But that's easily handled by having a separate Advanced section.
pruss is offline   Reply With Quote