Tuesday, 18 October 2011
Monday, 14 February 2011
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?
Wednesday, 22 September 2010
Every week (or every other week) at the same time, 15 min-ish. Most of the time, there was not much to talk about, except the occasional "recently I have been having isolated tasks, I would like to work more together with people" and David would assign me tasks accordingly where possible. Read about 1:1 meetings from Michael Lopp:
Thursday, 9 September 2010
Wednesday, 16 June 2010
Apparently, there was one identical implementation: Enumerable.Range! It's come with C# 3.0.
Saturday, 15 May 2010
1. Steve Jobs' arguments about why they don't support Flash on iPhone and iPad: http://www.apple.com/hotnews/thoughts-on-flash/
2. Adobe's passive-agressive response: http://blogs.adobe.com/jnack/files/AdobeAppleAd.pdf
3. Adobe's CEO answering on the topic: http://blogs.wsj.com/digits/2010/04/29/live-blogging-the-journals-interview-with-adobe-ceo/tab/liveblog/
I agree with the CEO guy on that the technological issues are not enough of an issue to ban flash development for iPhone. As far as I know, iPhone doesn't support Java neither:
Jobs: "Java's not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain." (source)
It doesn't take a Java fan to say it is very unfair to Java. Java's still serving us very well in many levels. (Altough Java programmers getting paid more IS a sign that it is dieing, Java is not only a programming language (*).)
Apple does have the tendancy to provoke a closed community with a sense of eliteness, and it has so far worked good for them. If they (and with 'they', I mean both customers and producers of iPad and iPhone) are fine with less applications then there is not much to say. Indeed, Jobs' manifest may be targeting only the Apple customers who demand Flash, telling them not having Flash is just another way to separate them from the crowd.
They must be making huge moneys from the app store, and freely available flash applications on the web would not help much. I wonder how many of those applications on the store would be obsolete if only iPhone supported flash?
I also am long disturbed with the Flash monopoly on rich internet applications and hoping to see what people will do with HTML5. But that's another topic.
Thinking Adobe had bought Macromedia only a few years ago, and Macromedia's Flash is now Adobe's most discussed product, It surely was a good buy.