What iOS Can Learn from Unix
blog.inkmobility.com
blog.inkmobility.com
The marketers are a plague, they destroy everything.
> Android has intents which are a big step in the right direction. With a few tweaks to user experience they could solve this problem on the platform.
What tweaks would 'solve this problem'? As far as I can tell, Android intents work flawlessly for transferring content between apps. I can click an attachment on an email, open it in an editor, make changes, and then share that file back on a social network or another email. Each step taking only two taps. The speed of downloading attachments could do with some work in most cases, but that's just a hardware issue and will probably be far faster in another generation or two of hardware.
I have a feeling the author has never really used an Android device much? Or am I missing some key piece missing from intents?
1. No app discovery -- I want to find out about apps that can work with my content.
2. Action curation -- I want to see the actions that other people think are most useful when dealing with my content.
3. No "Return" actions -- eg. The context knowledge necessary to reply to the same message, or overwrite an existing file.
4. Cross device and cross OS: If this is done right, there's no reason for the action to be bound to just one device or even one person.
2. Each app defines what intents it can handle, so I don't think curation is necessary. The app select popup window is already curating that for you?
3. This context knowledge is provided inside every intent. Not all apps choose to use it, though. In some cases I'd guess the sandbox would get in the way as well. I'm not sure how much practical value this would have anyway? Can you explain it a bit more?
4. There is nothing stopping Apple from adopting Android intents, but obviously they won't. This is a 'pie in the sky' suggestion that won't happen for the same reason there is more than one flavour of Linux. It's like asking why you can't pipe results from your unix system to a Windows system - it just won't happen for political reasons.
- They are sometimes vague, and apps often advertise support for many intents they can't actually handle sanely. Trying to setup an email intent which actually only shows email clients is an example of this. The UX of showing a list of many apps which are not really good choices is pretty bad. I think the blame for this is largely on the apps themselves for not being more specific in their intent filters, but it still reflects badly on the platform.
- It loses the default choices on a regular basis. Updating an app which supports that intent and/or installing a new one seems to invalidate the default choice, which is really annoying. Especially in cases where you have e.g. installed a 3rd party browser, and now every time you click a link you have to choose which one to use.
- Once you have selected a default, you can't choose to use another one without digging through settings and clearing them for the app which has the default action set. Something like the right click and open with which we have on desktop operating systems would be great.
2. Once you've increased the scope beyond the apps on the device, work needs to be done to show the most relevant and useful actions.
3. Enabling flows like:
- Take file from one app, edit in another app, save back over the original file
- Take an email attachment, edit / modify in another app, then reply back on the same thread
4. But there is no reason a third party can't come in and make it happen.
I think the technical challenge may be too great for current gen OSes and browsers? Perhaps we will see a system like this arise on the 'next battlefield', whatever that might be.
Here's hoping someone works it out. The system itself is not that difficult to understand or to implement, it's the logistics of it that would be difficult and (by definition) need a lot more collaboration between corps than currently.
Web Intents [1] are a push in this direction, but adoption is extremely slow and does not look like it is going to take place.
According to Michael, it's creator, it uses Mach Ports to communicate between apps. Apple embraced it and included it with GarageBand.
http://createdigitalmusic.com/2013/09/audiobus-for-ios-7-upd...
It is a shame that we can't get more app functionality sharing in place, but really I don't know if we necessarily want to bring that much dependency management into the mobile space at large either.
Some of the UX around intents isn't great, but the core concept and implementation is very clever and doesn't get the attention and respect it deserves. Much like many aspects of Android.
[1]: https://developer.apple.com/library/ios/documentation/FileMa...
In my app, I went one step further and when the user doesn't have an app installed for the given file type, I recommend one, but that isn't a requirement. I keep track of what percentage of view file requests are fulfilled by an already installed app, and it is generally over 95%.
I think you guys should better understand Intents before you trash them (and actually try to replicate them on iOS). Why was the use of Intents so minimal in the Filepicker.io Android library? I replaced that library with a intents and have a much more robust application.
If there's a document viewer, it'll listen in for the file types it supports when you try to open a file (I think its a VIEW intent). It's all very impressive and very, very useful.
If iOS is so great and there is demand, Apple can sell us a license to run it on our device. My guess is that few would pay for this. More likely, the market would demand a windowing GUI, not an entire OS (e.g., one borrowed from CMU, FreeBSD and NetBSD; hello again Apple). Could developers respond and deliver one?
UNIX can do lots of things well. And well enough. That's probably why iOS relies on UNIX and not some other OS. But iOS won't let you do all the things that UNIX will let you do.
Conclusion: iOS is inferior to other, more open, more traditional UNIX alternatives. Apple does make a nice windowing GUI. And some very nice enclosures. Each worth a price, no doubt. But UNIX, the code that does the important stuff, has always been free.
To be truthful, my "requirements" include first and foremost, a great looking enclosure. There is a reason for that. I want be able to buy the enclosure separately. This is important.
In my vision, there would multiple sources for boards that might fit inside. Not every user might want or need the same computing power or peripherals.
Imagine, to take an example, if there were multiple RaspberryPi-sized boards. Then you could mix and match different available enclosures[1] with different boards.
1. We are seeing the market respond with many, varied enclosures for the Pi.
There are lots of development boards for sale to consumers, and there are dedicated people porting UNIX OS's to run on them.
What I don't see, generally, are reasonably-priced and attractive enclosures for these boards. The RaspberryPi may be changing this state of affairs, as the Pi enclosure market continues to grow.
Separating out the parts of the device, from the enclosure to the PCB to the OS to the third party software is, you might say, like the UNIX userland philosophy of isolating functions to their own individual utilities. This separation allows more flexibility and more power, in the example of the UNIX userland by allowing the user to filter and redirect output and connect utilities together with pipes.
What are the things Apple does well? Enclosures and graphics, in my opinion. (And controlling their users :) UNIX is not on the list. There are better UNIX alternatives than iOS. My opinion.
Or, as in the article, you can wait and hope that iOS can be improved to be more like those UNIX alternatives.
I don't understand being so hung up on the enclosure. Nothing's stopping you from fabricating new enclosures for Nexus 4s. You could even mass produce them, and repackage new Nexus 4s as a value-added service for people. You could, theoretically, buy up busted iPhones from ebay and repack them as Android devices - although it'd be much easier to buy one of the million fake iPhones from China, which are already basically reference Android devices.
On the UI side, Samsung was on the way to shipping their devices with an iOS clone around the time of the S2. If you want an Android experience which is very similar to iOS, you could even look at MIUI [1], which rips off a bunch of Apple's design philosophy.
In short, everything you asked for is already very possible, it's just that nobody is handing it to you on a platter. You could try to get rich enough to buy 51% of Apple, and redirect their whole corporate focus. Or you could pick an interesting project and start hacking ;)
Having concept of "files" to be able to open pdf you just downloaded from email/browser inside pdf reader?
They do need a filesystem and interoperable components. What they do NOT need is a hierarchical based filesystem that limits you to a directory trees. It's an organizational nightmare, and unless you've ever used git before it's a literal hell for the average user.
Instead, a flat filesystem with smart names, tagging, and metadata is the way forward. Subdirectories will be relegated to those who want them.
As for security, that excuse is nonexistent when Apple has the final authority to application interoperability and analysis. If an implementation is flawed, they can reject it at will and tell the developers to improve it.
Time to rethink the mobile OS as a whole.
You want to do something with an image, for example, and you're greeted with a huge list of apps that all claim to handle images. Not only is it hard to find the app you want, most of the ones in the list have nothing to do with the task you're trying to accomplish. Hardly user friendly behavior.
FWIW, I personally don't really mind the huge list and can find my way around it, but I'm a heavy Unix user that does most of his work in the terminal already. Most consumers are not.
Apple had once an approach to this in the old Classic OS, by a switch that would enable or disable some access and features in the OS (esp. Finder). While this wasn't a great success on the desktop (like any other easy-suites), it might be worth to rethink for the mobile platform.
(Edit: This would also afford to expose system calls to the end user, being the end of consumer haven.)
See "communicating with other apps": https://developer.apple.com/library/ios/documentation/iPhone...
In one app framework we built we had a fairly complicated parser and it could handle a pretty wide variety of URL paths and the supplied data. But there in turn lies the problem - each app must have a mechanism to handle the parsing and routing for these URLs.
They offer certain advantages, too, but this is no different from any other software-engineering tradeoff.
There's a reason why the winning kernel is a monolithic kernel, and the winning init system is one large God-daemon that replaces many smaller legacy daemons.
iOS doesn't work that way, and for good reasons.