Monday, 14 February 2011

How I would like the software to work.

As a developer and naturally a user of software, these are the primary general feature points I would like all the software in the world to have.

I realize these things I will ask for are definitely possible and practiced in various platforms with extensive number of technologies, but I want to be able to take them for granted for all the software out there. Whether they'll be implemented in lower level systems like operating systems, or will they just be some commitee standards, I don't care. Just like almost every interactive software nows what keyboard is, I want them to recognize these notions as well.

1. Generic interaction abstraction. With all these new mobile devices and different interaction methods, we need a way to make our applications work on all these. This is not only a cross-platform development tool like Java, or being able to run a piece of code on different hardware. But it's a way to smartly adapt these applications to those devices' interaction capabilities. Some devices have double touchscreen (see here), some devices have a dialer-keypad on them. Developers should make use of a framework with extensive dictionary of interaction technologies available, to make something roughly like this possible:
Step 1: This app is made with Java, so it'll work everywhere with Java runtime.
Step 2: This app preferably uses multi-touch interface with three input points.
Step 3: If the system doesn't have a multi-touch interface with three input points, the app can fallback to a traditional mouse-pointer interaction system, but then it'll put a few buttons on the corner of the screen to make up for the multi-touch capability.
Step 4: If the system doesn't have any pointer input available at all, the app supports all the features by using only arrow keys on the keyboard. Even if the user experience is marginally distressed, features are still available.
Step 5: The app ideally uses a 30-hz 16M-colour screen. But if the screen this system has is only a 0.5-hz e-ink screen, let the app know that so it can adapt the screen-layout in a way that will not require as many screen refreshes.
Step 6: The app ideally uses a 3D surround sound system for sound output. But if it's not available, stereo will do. Also, if a earphone is available, let the app know so it can make use of its auditory illusion tricks to fake 3D sound. If only mono sound is available, just don't run the app because it won't make any sense.

Yes, this should all be available within single development platform, preferably in a declarative way. Instead of porting everywhere, we can just define how our app translates to different devices' interaction ways and the platform (/middleware) will do the rest.

2. Application hibernation. As a user I should be able to hibernate a running service or GUI application with a single click, and it should be saved in a persistent memory like a harddisk. All the visual state and data, everything. Then I should be able to revive it back all with a single command, down to a half-way mouse click event that was about to happen. Again, this is surely possible via various technologies, but still we don't see any applications that can do this. Even firefox reloads every tab when you restart using the option "save tabs". It goes only half the way.

3. Dependency injection in a broader scale. How do we integrate our applications? We use configuration files, environment variables (the PATH god), registry entries. This is all practical but hassly and ridiculous at the end. I want something like unix terminals' nice "pipe" (|) feature or microsoft console's similar (>) sign. But not only for forwarding the standard input/output streams, for all the kinds of multi-part or sophisticated, synchronous or asynchronous inputs and outputs an application can process or present. Something between dependency injection frameworks, activex guids, mime type-related default applications, somewhere over there. Maybe something like this:
Rule 1: Dear firefox, please don't try to save my passwords on yourself, just interface with this awesome little app that can do it for you. Safari, please also do the same. (assuming that little app supports (let's say) IWebPasswordsStore.
Rule 2: Dear system, when that little app says it wants to write to persistent storage, it just wants to use my encrypted online virtual drive associated with my here-registered google [:)] account.
Rule 3: Dear system, give this powerpoint application a secondary monitor so it can present the slides on that monitor. But I don't really have a second monitor, I just want those slides to show up on my remote classrooms projector where I am connected with skype.

Am I just flying too high?

1 comment:

Weeble said...

UI abstraction - tough problem. I *think* we agree that writing to the lowest common denominator is not feasible - the differences between device capabilities is large and widening. You simply can't write (for example) a control point for a music player with identical UI for an XBox on a wide-screen TV, a Wii on a projector, a laptop with a mouse, an iPad and an smart-phone. Sometimes the best compromise is to have a powerful and flexible framework that knows about all of these things and exposes the capabilities of the underlying device to the application in a way that it can choose what to use. Sometimes that's too expensive or unwieldy and application developers are better off writing their application with a clean separation between logic and UI, and then writing completely separate UI layers tailored to each platform and its particularly capabilities. I believe that's what the Mono guys have been encouraging people to do as they develop managed APIs that directly expose the native features of iPhone and Android.