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:
public
documents
downloads
music
pictures
videos
Or similar.
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.
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:
public
media
music
documents
public/media
public/music
public/documents
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.
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!).
. 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.