As a web-app developer I want to let my users select existing images from their POD or upload new ones for special purposes - for instance when writing a blog post and then adding an image to it, in which case the user can either upload a new one or select an existing one.
Where should new images be uploaded to - and where should the user be looking for existing images?
It is very similar to mobile phones - if I want to add a photo to Facebook I can either select an existing one from my phone or upload a new.
I assume there exist some sort of standard for this purpose on Android/iOS - and I guess it would be beneficial for Solid to have a similar approach.
Further more, it would be nice, as an app developer, to be able to reuse some sort of standard Solid widget for selecting or uploading images (or documents in general).
How about a convention for some top level folders such as:
I stole that list obviously, which is why I think it makes sense. Most OS UIs seem to have a set of default containers similar to this. I don’t know if there’s an actual standard though.
There’s a question for me though. If I select something from a private folder to be published, should a copy be made in the public folder or should the access permissions be changed on the published item? My first thought is to copy, so all the data you’ve made public this way is easily identified. I think searching permissions is too complicated for most people.
I too think copying is probably the most understandable way to go. Similar to what happens if I publish an image from my mobile phone to Facebook - a copy is made.
I think the list should be divided by public and private items - unlike a mobile phone or tablet, it becomes rather important where you store your photos. In addition to this I’ve never liked the distinction between video and photos since I often record both on vacations.
In that light, I would suggest:
But maybe that is what you are already implying in your list - everything is private by default unless you put it under /public ?
I was thinking that under public you could repeat the names of the folders at the top level, while those at the top level would be private by default (except /public of course).
So in your example:
I’m not sure about merging pictures and videos into media. ‘Media’ isn’t that obvious to most people I suspect. I do the same though . No strong feeling either way, so something I’d like to hear more views on, and ideally some knowledge of how the general public would find this.
All that opens for a more general kind of process for registrering “things we want a standard location for” A place to register “My links”, “My notes”, “My photos”, “My pets”, “My RC models”, “My addresses” and so.
It also needs to play well with the personal profile card, which, as far as I remember, already have links to “My public folder” and similar.
A register would need to provide both “link relation” or RDF “predicate” for the standard locations as well as a suitable default standard location.
A second, related, question - where should apps store internal data, stuff which is not generally covered by the “My pets” etc. standard?
Should there be standard “/app/my-app-name” folders?
Seems like it is just another instance of a “My stuff” registration - this time only “My apps”.
Why would a user want standard locations? (not rhetorical) I think answering this would help. I already see answers implied just posted…
Let’s start with (no order)
- User can find their stuff intuitively when browsing (file system is implied).
- Locations are similar across OSes, devices, PODs.
- Whole subtree can be shared and others can browse it easily.
- Default permissions on high level propagated down, e.g., public is world readable, private is owner only, but others get messy quickly. This one seems to guide the public/private division, but what about other permissions? How about groups? E.g., family, friends, university friends, neighbours, dog club, cat club. And then can a picture belong to two groups at once? Of course, so let’s link. And I just implied permissions in the tree structure. Is this good or not?
and I just saw in the latest post
- An app can easily discover its own storage given a root.
Finally, if I can try to generalise answers so far, the tree structure implies links between the data and implies permissions.
The permissions problem regarding a shared photo for my dog club was probably what made Mark (happybeing) suggest copying the image when sharing it in another context, as it would soon be difficult to know, just by looking at a single image’s meta data, who actually has access to it.
If I have a private photo and then reference/link that from another place, that doesn’t make it (semi-)public in itself. You have to manually tweak the access control list for the photo before anyone else can see it.
But I am rambling here. Sorry. I don’t have any useful solutions - it seems like a rather complex area.
While I think the above are sensible and necessary starting points, there’s another way to do this, through ‘views’ of all the data we have that can leverage the semantics and other clues such as folder location (music v pictures v documents etc), access control (public v private v group v individual-x), links (related to x) and of course the resource name and content.
Essentially views that can be standard, or customised, or which are really just a nice UI for a search engine tailored for personal data stores, but which could of course reach out from pod to pod.
I don’t think this negates the value of a sensible folder structure, but I can see a decent search-view solution becoming many people’s primary UI (it’s an app!).
Why not a standard metadata file that map ontologies (image, document, videos) to actual folders?
App can do a search on that metadata file and know the location to put resources. And I think /profile/card can take this role.
Oh this looks likes registry table of windows.