5 ms·

IMHO, interoperability between apps is the main benefit of Android against iOS (see Intents in Android). I can take any photo, URL or file and open/share it in

by juriga 14y ago

IMHO, interoperability between apps is the main benefit of Android against iOS (see Intents in Android). I can take any photo, URL or file and open/share it in/to another app. The OS and app developers take care of which apps support which resources, so as a user I'm always presented with a sensible list of apps currently available on my device. I'd say the notion of a file with a specific file type is too abstract and technical for most use cases for casual users. The UI should group pieces of data as human-understandable resources (i.e. a "picture" can be a .jpg, .png etc.). With this level of abstraction, a user can be expected to understand when presented with a list of apps: OS: "What do you want to do with this URL?" User: "Share to Twitter/Facebook/My other browser"

MatthewPhillips 14y ago
Don't you see the problem with this? By allowing the app, rather than the user or the system, to own the file you wind up with multiple copies. App A shares data with App B. The user makes some changes and App B saves its new copy. It doesn't send the data back to the originating app. It could, but then the user would have to manually do that and save it in App A again. This is horrendous! People are confusing the poor UI that we have for files (file pickers) with thinking that files themselves are a bad abstraction.
- brettcvz 14y ago
  seconded
- jpxxx 14y ago
  I understand what you're saying, but you need to illustrate an actual problem beyond "technically there's two" that this causes in mobile workflows for typical consumers. That the current Send-To idiom is limited is not under dispute. That it's worth changing is what's worth discussing.
  - MatthewPhillips 14y ago
    The 2 copies are not guaranteed to be in sync. If I modify data in App B, App A now has an old copy. I shouldn't have to explain why this is undesirable.
    - jpxxx 14y ago
      Relax. :) Now we're getting to the crux of the situation. Let's talk spreadsheets. That's a pretty data-freshness-critical thing, yes? Jennifer gets an e-mail with an Excel attached. She previews the Excel, decides it needs an edit, and taps Send-To -> Numbers (the most common current scenario). A duplicate is created and shipped over to be owned by Numbers. She makes edits, then clicks Send To -> Email. The correct version goes out. The updated version remains in Numbers. The user assumes that Numbers has the spreadsheet, because that's where she was making changes. The copy in the Mail Attachments archive remains old but it's never invoked a second time and the workflow never takes in stale data. The only scenario in which Send-To causes problems is in the case of two applications that have equal abilities to process a given filetype AND roughly equal chances of being invoked by a user, and how often is that going to be coming up on a telephone or an tablet? You could always build a file locking system at the app-level or OS-level or cloud-FS level, but then we're back to Who's Freshest?, the hardest game of all to win. Apple chose not to play this game and pushed all the filesystem yuckiness out onto a rarely-traveled edge of a regular user's possibility space. It's not ideal, but what is?
      - drone 14y ago
        Why do there have to be two copies of the file? Could there not be only one copy of the file, with two "begin pointers" that are dated? When a user decides that they no longer need an older version, the older section can be purged. Obviously, this could result in quite large files, and we start wanting to do smarter edits to the contents, but I'm not sure having two distinct copies of the data serve the average user any better than one with two internal copies of the data? Obviously, there are technical challenges, but let's just assume for a minute that years of database and similar use case-driven development have solved many of the basic issues already.
- juriga 14y ago
  This is a very good point. Merging file changes between applications is not a trivial task and usually applications just end up saving their own copy (as you mentioned). For example, if I share a photo from the Android Gallery app to Instagram, add some trendy filters and share the modified photo in Instagram, I end up with three copies in the filesystem: The original, and two copies made by Instagram to preserve both the original and filtered version. After all, Instagram doesn't know/care whether the photo came from a camera or from another app, so it always saves a copy of the original. Also, each time I share the photo to Twitter, Facebook or other cloud service I create another copy with different resolution, (re)compression and even dimensions, which is saved to the service out of my reach. I guess having multiple unsynced copies of the same information is a problem that won't be solved as long as we want to have the ability to distribute information freely. One interesting development would be better content-based matching of files (e.g. Google similar image search, content-based indexing of photo subjects in Google Drive).

by juriga 14y ago

MatthewPhillips 14y ago

Don't you see the problem with this? By allowing the app, rather than the user or the system, to own the file you wind up with multiple copies. App A shares data with App B. The user makes some changes and App B saves its new copy. It doesn't send the data back to the originating app. It could, but then the user would have to manually do that and save it in App A again. This is horrendous! People are confusing the poor UI that we have for files (file pickers) with thinking that files themselves are a bad abstraction.

brettcvz 14y ago
seconded
jpxxx 14y ago
I understand what you're saying, but you need to illustrate an actual problem beyond "technically there's two" that this causes in mobile workflows for typical consumers. That the current Send-To idiom is limited is not under dispute. That it's worth changing is what's worth discussing.
- MatthewPhillips 14y ago
  The 2 copies are not guaranteed to be in sync. If I modify data in App B, App A now has an old copy. I shouldn't have to explain why this is undesirable.
  - jpxxx 14y ago
    Relax. :) Now we're getting to the crux of the situation. Let's talk spreadsheets. That's a pretty data-freshness-critical thing, yes? Jennifer gets an e-mail with an Excel attached. She previews the Excel, decides it needs an edit, and taps Send-To -> Numbers (the most common current scenario). A duplicate is created and shipped over to be owned by Numbers. She makes edits, then clicks Send To -> Email. The correct version goes out. The updated version remains in Numbers. The user assumes that Numbers has the spreadsheet, because that's where she was making changes. The copy in the Mail Attachments archive remains old but it's never invoked a second time and the workflow never takes in stale data. The only scenario in which Send-To causes problems is in the case of two applications that have equal abilities to process a given filetype AND roughly equal chances of being invoked by a user, and how often is that going to be coming up on a telephone or an tablet? You could always build a file locking system at the app-level or OS-level or cloud-FS level, but then we're back to Who's Freshest?, the hardest game of all to win. Apple chose not to play this game and pushed all the filesystem yuckiness out onto a rarely-traveled edge of a regular user's possibility space. It's not ideal, but what is?
    - drone 14y ago
      Why do there have to be two copies of the file? Could there not be only one copy of the file, with two "begin pointers" that are dated? When a user decides that they no longer need an older version, the older section can be purged. Obviously, this could result in quite large files, and we start wanting to do smarter edits to the contents, but I'm not sure having two distinct copies of the data serve the average user any better than one with two internal copies of the data? Obviously, there are technical challenges, but let's just assume for a minute that years of database and similar use case-driven development have solved many of the basic issues already.
juriga 14y ago
This is a very good point. Merging file changes between applications is not a trivial task and usually applications just end up saving their own copy (as you mentioned). For example, if I share a photo from the Android Gallery app to Instagram, add some trendy filters and share the modified photo in Instagram, I end up with three copies in the filesystem: The original, and two copies made by Instagram to preserve both the original and filtered version. After all, Instagram doesn't know/care whether the photo came from a camera or from another app, so it always saves a copy of the original. Also, each time I share the photo to Twitter, Facebook or other cloud service I create another copy with different resolution, (re)compression and even dimensions, which is saved to the service out of my reach. I guess having multiple unsynced copies of the same information is a problem that won't be solved as long as we want to have the ability to distribute information freely. One interesting development would be better content-based matching of files (e.g. Google similar image search, content-based indexing of photo subjects in Google Drive).