Sunday, March 02, 2014
Saturday, January 25, 2014
iPad Pro
For several months now rumours have spread that a new type of iPad will be released this year - the iPad Pro. Variously sized at 12 or 13 inches, compared to the iPad Air's 10 inches, it would extend the iPad lineup further into larger dimensions.
All the rumours have focused on size, but Apple integrates both hardware, software and services, and to me the really interesting areas are the latter. What software and services should a 'Pro' device come with?
Clearly Apple could tailor existing iOS apps such as the iWork and iLife suites to larger screen sizes. But other apps could be ported from MacOS too - most notably, software development tools such as XCode or a sandboxed, stripped back Terminal with tools for scripting apps. After all developers are one of the largest groups of 'Pros'. I'm not suggesting that Apple will open up root permissions directly to the iPad - instead each app is likely to be a containerized and perhaps only have access to other data via iCloud.
iCloud itself could play a much larger role in a Pro device. It would enable each app to access a common document store, synced from iCloud. That enables a text document, image or video saved in one app to be opened up again in another one.
iOS itself could see some changes. A 13 inch device has 70% more screen space than the iPad Air - so could we see a window manager, enabling apps to be worked side by side? Lack of tiling apps has to be one of the major outstanding barriers to productivity on iOS. One way to do this might be to require applications to work in both full screen and iPad mini sizes.
An iPad Pro with the features above would be a great tool for professional use and a massive competitor to traditional PCs. It would also open up App Store to a new market and new possibilities. Much worthier of the Pro label than just a bigger iPad Air.
Posted by Chris Jay at 3:49 PM 0 comments
Sunday, July 25, 2010
Purchasing in the browser
One of the real benefits of App Stores versus the web is that purchases are so much easier - all you have to do is click on a link (and type your password to validate). Contrast that with the web, where every site has a detailed form to fill out - and sometimes you have to fill it out all over again, if "Verified by Visa" has anything to do with it.
Would it be possible to streamline procurement on the web? I think it could, using a browser-based "account store":
- Browser stores account details and exposes API for giving them to web page
- When web page calls API, the user is asked for confirmation (and can select which account to use). E.g. "This site wants to know your account details for a purchase - give them? If so, which account? Type your password to confirm"
- Account details are sent to page in standard format and used to automatically fill out form
This approach is simple and would work easily with existing sites, automatically populating all the fields. What's more, it allows the browser to help the user out - for example, listing all sites that have been granted access to their account details.
Unfortunately, once account details have been given out, it's difficult to control what the site does with it - they could be passed on to a bad guy, whether intentionally or not.
Here's a better approach:
- Banks could generate a new unique account number with each purchase. This account number would only work once and also has a brief expiry time, e.g. 1 hour.
- When a site requests your account details, the browser automatically requests your bank for a new account number, which is then given to the vendor. The vendor cannot then re-use the details or leak them to anyone else.
Posted by Chris Jay at 5:40 PM 72 comments
Labels: browsers