Crazy Ideas
The Shape Of iPhone Applications
2008-02-04
With the iPhone SDK coming soon, I'm looking forward to a new kind of application, one that installs in two or more places and uses the mobility of the iPhone to extend the Macs that we currently have on our desks in a new way.
Many iPhone apps will offer this:
The app installs on the phone and that is it. It runs on the iPhone and doesn't talk to anything. Think of games, utilities, and the like. Of course the iPhone has internet access, so we'll also see apps that do this:
Safari already does it, so it's no big deal. Weather, stocks, and other simple gather-the-data-and-display-it apps will be numerous. There will be others that have a server end and an iPhone end:
The Google map application does this. Note that Google/Apple writes the code for both ends of the connection; if you don't have both, nothing happens. There is no browser in use here, and not necessarily any standard protocol. But most software developers don't have a huge server infrastructure like Google. And there are all sorts of scaling and billing problems with this kind of application if you are a small shop. So what do you make?
What I'm thinking of is an application that looks like this:
This is one application from one vendor that comes in two parts: one part that is installed on the iPhone and one part installed on the Mac. There are no scaling problems since for each customer only a few iPhones connect to a few Macs. The customer owns both ends. Billing is also not an issue, since it's not the Mac that is a precious resource here. This kind of app extends what I have on my Mac to my iPhone. Quicken could do this (but I bet it never will). Back up software could do this to tell me what had happened and get my response.
Another type of application could look like this:
The iPhone accesses data on the internet and the home Mac to get its job done. The Mac supplies personal information, maybe passwords, home address, account information, and the internet servers supply the other data needed. The idea here is that the Mac has the personal knowledge and the internet servers have the world knowledge. The two are combined to do things that could not be done in any other way.
Probably a better way of doing the same thing given the much larger storage and bandwidth of the home Mac is this:
Apple is already doing this with iTunes, but nobody else is. The iPhone can now use all the accounts that the Mac can, so there is no extra work. Privacy and billing are handled by the same mechanisms that the desktop uses.
Let's say you were running Delicious Library on your home Mac. With an app from Delicious Monster running on the iPhone you could access your media library in real time. With that, you could use your iPhone to lend things out, look up books you found on your travels to see if you already had them or needed just that one to complete a set. You could add voice annotations to books that you have at home. You could browse your home media collection and compare what you paid with those in front of you at the thrift store. Or compare what you see with what is currently selling on eBay and be sure you don't already have it. And a zillion other applications that create value by extending the personal desktop computer to the mobile hand.
Many iPhone apps will offer this:
The app installs on the phone and that is it. It runs on the iPhone and doesn't talk to anything. Think of games, utilities, and the like. Of course the iPhone has internet access, so we'll also see apps that do this:
Safari already does it, so it's no big deal. Weather, stocks, and other simple gather-the-data-and-display-it apps will be numerous. There will be others that have a server end and an iPhone end:
The Google map application does this. Note that Google/Apple writes the code for both ends of the connection; if you don't have both, nothing happens. There is no browser in use here, and not necessarily any standard protocol. But most software developers don't have a huge server infrastructure like Google. And there are all sorts of scaling and billing problems with this kind of application if you are a small shop. So what do you make?
What I'm thinking of is an application that looks like this:
This is one application from one vendor that comes in two parts: one part that is installed on the iPhone and one part installed on the Mac. There are no scaling problems since for each customer only a few iPhones connect to a few Macs. The customer owns both ends. Billing is also not an issue, since it's not the Mac that is a precious resource here. This kind of app extends what I have on my Mac to my iPhone. Quicken could do this (but I bet it never will). Back up software could do this to tell me what had happened and get my response.
Another type of application could look like this:
The iPhone accesses data on the internet and the home Mac to get its job done. The Mac supplies personal information, maybe passwords, home address, account information, and the internet servers supply the other data needed. The idea here is that the Mac has the personal knowledge and the internet servers have the world knowledge. The two are combined to do things that could not be done in any other way.
Probably a better way of doing the same thing given the much larger storage and bandwidth of the home Mac is this:
Apple is already doing this with iTunes, but nobody else is. The iPhone can now use all the accounts that the Mac can, so there is no extra work. Privacy and billing are handled by the same mechanisms that the desktop uses.
Let's say you were running Delicious Library on your home Mac. With an app from Delicious Monster running on the iPhone you could access your media library in real time. With that, you could use your iPhone to lend things out, look up books you found on your travels to see if you already had them or needed just that one to complete a set. You could add voice annotations to books that you have at home. You could browse your home media collection and compare what you paid with those in front of you at the thrift store. Or compare what you see with what is currently selling on eBay and be sure you don't already have it. And a zillion other applications that create value by extending the personal desktop computer to the mobile hand.
|
Microsoft Will Eat Yahoo, But...
2008-02-03
That's my take on the Yahoo/Microsoft takeover. The original image was stolen from The Fail Blog who claim to have stolen it from Fark.
Yes it will go through. Yes the Yahoos will hate it. Yes the results will not be pretty. It's a huge opportunity for all the other players in their respective spaces to welcome customers and their money with open arms and great products. Google still has the small issue of creating new products that generate income to deal with, but it will be good for them. Apple will keep focusing great products on the customer.
Fake Steve sums it up best.
Apple's Coming iTunes Switcheroo
2007-08-25
In more than a few years, but in certainly less than a decade, Apple is going to pull a switcheroo on the record industry. Apple will force the record companies to pay hard cash to sell their catalog of music through iTunes. It's their worst nightmare come true.
That probably sounds far-fetched, but it's not. Back in the dark days of the internet everyone wanted to be a portal because that is all there was: fledgling companies able to provide access, growing out of BBSs and mom and pop ISPs. Get bigger and get more customers at any cost so you can keep replacing all your equipment twice a year to keep up with the growth.
One of those players was America Online and their way of keeping customers was to pay others for content. That's right: AOL would pay other companies to make what we would today call web pages that drove customers to use their portal. And it worked, so well in fact that one day AOL said no more. You pay us now. And they did, because at that time there was no better place to get traffic to your company than through AOL.
There is another example, closer to home: your local supermarket, game store, or practically any retail establishment. Any company that has a product and wants to sell it in that store has to pay for shelf space and has to live with the store's draconian return and payment policies. Or else they get no shelf space and have to build their own stores (like Apple did).
It's just a matter of time. I'll take a wild stab at a year that I think it will happen: 2013.
Silicon Distribution
2007-07-11
What if Apple distributed Leopard on silicon?
A DVD, and particularly a DVD drive, is a huge thing compared to the size of everything else that goes into a computer or computerized device. If Apple wants to make its laptops much thinner and smaller it has to leave out the DVD drive -- but then how do customers load software, or even boot a new version of the OS?
I believe that all the computers that are supported by Leopard have USB 2.0, so that would be the preferred method. Shipping and storage are a large part of the costs associated with software distribution, and much of that could be saved if a USB key instead of a disk and box were used. So although the silicon solution may appear expensive in raw materials the hit may be much less than imagined once the whole picture is taken into account.
Silicon distribution also has some other advantages. USB sticks can be stocked empty and programmed locally -- in-store for instance. Unsold sticks can be reprogrammed. Customers can recycle the sticks as well or just use them for their own purposes. Take them back to the Apple store once they are out of date for a refund so they can be reused.
Third party software that's sold on a DVD is a problem. But that can be solved with another computer that does have a DVD and a network link.
A DVD, and particularly a DVD drive, is a huge thing compared to the size of everything else that goes into a computer or computerized device. If Apple wants to make its laptops much thinner and smaller it has to leave out the DVD drive -- but then how do customers load software, or even boot a new version of the OS?
I believe that all the computers that are supported by Leopard have USB 2.0, so that would be the preferred method. Shipping and storage are a large part of the costs associated with software distribution, and much of that could be saved if a USB key instead of a disk and box were used. So although the silicon solution may appear expensive in raw materials the hit may be much less than imagined once the whole picture is taken into account.
Silicon distribution also has some other advantages. USB sticks can be stocked empty and programmed locally -- in-store for instance. Unsold sticks can be reprogrammed. Customers can recycle the sticks as well or just use them for their own purposes. Take them back to the Apple store once they are out of date for a refund so they can be reused.
Third party software that's sold on a DVD is a problem. But that can be solved with another computer that does have a DVD and a network link.
Apple, Intel, And Customized CPUs
2007-06-29
We know that the CPU inside the Apple TV is a slightly custom version of a standard Intel CPU, but why stop there? Why doesn't Intel make all manner of customizations to its processors for Apple? Or for other companies for that matter?
It would work like this. Apple analyses its code and identifies a small number of operations that, if they were faster, would have a significant effect on the speed (or the apparent speed) of their computers. Intel implements the changes, Apple used the chips, and everyone is happy. Nobody is unhappy because their code does not rely on that particular operation as much as Apple's does and there are no downsides to the change.
Or it could get more competitive. Apple has Intel add extra instructions that improve performance for selected, important code. If the CPU does not implement those instructions, then the Apple code just does it using generic code. In this way the new machines are faster, of course, but importantly, are faster than equivalent Windows machines because their software does not know about the new instructions. They could be fully documented and still not give anything away.
This would also mean that Apple code could know if it were running on a genuine Apple machine. It would deliver slower performance on clones than on Apple hardware because the Apple hardware would run the special CPUs.
There is no reason that this has not been done already. Apple makes iPods and iPhones too and they would benefit greatly from such a performance/battery efficiency boost. TenSilica does a nice business adding special instructions to CPUs for exactly this purpose.
I Will Be At Macworld On Thursday
2007-01-10
For no particular reason, I have five packets of poppy seeds to give away at Macworld when I visit on Thursday. I'll be giving one packet to each of the first five people (or groups of people) who tell me that they read my blog.
The challenge -- and this is what makes it an even field -- is that none of you know what I look like.
[Update: I escaped without detection]
Aperture: An Idea For a History Browser
2006-12-27
If I am viewing an image in Aperture, how do I know how I got that image?
Aperture has no "reveal master" function, so although I can see the master just by pressing M, I cannot go directly to that master in its project. By looking at the filename in the inspector I can find all the images associated with it and paste that name into a filter and find them that way, but that is long-winded and incomplete.
What I really want is a history view added to the current two browser views (thumbnail and list). A history browser would look something like this:
The thumbnails for the current project or album are displayed vertically down the center of the browser, arranged in whatever order is currently selected. Horizontal lines could separate the image rows, but I am not sure that would add anything.
To the left of each thumbnail is a chain of ancestors. To the right is a tree of descendants. The tree extends vertically to show multiple descendants. Arrows point left to right to show descendency.
Metadata by default shows what each is, where it is, and when it was created. And there is a badge to show the masters. Masters created from other masters show the original master as an ancestor.
By clicking on a thumbnail you see the image in the viewer. There is a way of refocussing the history browser on a selected image so that its enclosing project or album is shown in the vertical strip.
Aperture has no "reveal master" function, so although I can see the master just by pressing M, I cannot go directly to that master in its project. By looking at the filename in the inspector I can find all the images associated with it and paste that name into a filter and find them that way, but that is long-winded and incomplete.
What I really want is a history view added to the current two browser views (thumbnail and list). A history browser would look something like this:
The thumbnails for the current project or album are displayed vertically down the center of the browser, arranged in whatever order is currently selected. Horizontal lines could separate the image rows, but I am not sure that would add anything.
To the left of each thumbnail is a chain of ancestors. To the right is a tree of descendants. The tree extends vertically to show multiple descendants. Arrows point left to right to show descendency.
Metadata by default shows what each is, where it is, and when it was created. And there is a badge to show the masters. Masters created from other masters show the original master as an ancestor.
By clicking on a thumbnail you see the image in the viewer. There is a way of refocussing the history browser on a selected image so that its enclosing project or album is shown in the vertical strip.
An Educational Two For One
2006-07-08
Since Mac OS X is based on a multi-user OS, all that is needed is the ability to handle two keyboard/mouse pairs and associate them with the users correctly. In an educational setting you can place the eMac facing one student and have the other either sitting opposite with the second screen's back to the back of the eMac, or side-by-side, both facing the same way. The additional cost is small: use existing monitors, keyboards and mice. Now the educational system would be spending half as much per student.
What I don't know is what this would take software-wise. Although the OS is multi-user and the file system is multi-user, and fast user switching is supported, the applications are not so savvy. One option would be to bring the OS and applications up to scratch (Leopard?) Another is to use virtualization to support the second user: just create a new machine and do it on the other monitor. All that remains is to associate the mouse and keyboard appropriately.
The Bagelturf site welcomes Donations of any size