I don’t understand what this means exactly. What I need to be able to do is to upload an image that I have created on my local machine. I enter the pathname, and by web magic it gets sucked up by the software and ends up inserted in the web page I am editing.
This seams like the lowest common denominator of image uploading. No matter where you get an image from or how you create it, you can always arrange to have a copy of it on your local machine.
Whatever you call it, the above is essential.
Aye, that’s what Helmar is referring to. We’ll have that in MVP.
I wasn’t sure what “picking an image from the end device” meant. It sounded like this was only envisioning grabbing a photograph taken by a smart phone, attached scanner, or whatever, directly (“end device”), not arbitrary files that got there by other means (like “save as image” from a schematic capture program, for example). Maybe the wording can be made less ambiguous.
I can see that even those of us who are very involved and very technically oriented are getting confused. I work with (real work, volunteer, friends & family, random people on the internet) people with a wide range of devices, skills, understanding of technical terminology, etc. Only a small percentage (mostly the programmers) understand what really goes on when you move an image file around. I’ll spell it out a bit differently.
and so on. There are probably a few more ways that I haven’t even thought of yet.
The key point is that some (let’s call it half) of these result in:
That is the group of users/images that we have all (I think) agreed will be MVP. Programmers - no problem. Power users - no problem. Others - some will “get it”, many will not. Trust me. I deal with the non-geeks every day. The simple act of browsing to a file is foreign to many people.
The next largest group is primarily what I would call the “online” batch:
This is the group that is taken care of by adding what I recommend we do soon but which is NOT (by general agreement) actual MVP. Trust me, having this will significantly increase the number of images successfully transferred in non-programmer communities. Doing this requires the server to capture the image via URL, which is not hard to do but is an extra step with security & other concerns, which is why it isn’t MVP.
The next group is “drag 'n droppers”. They don’t know how to find files in directories correctly. They don’t know (but likely could be trained) how to copy an image link. But they can find images on their device and copy/paste or drag 'n drop them from a folder “somewhere” (don’t ask them where, they don’t know) into a box on a web page. Most of the time this type of transfer works well, but my general experience is that programming the drag 'n drop mode is a bit more involved than the “browse for a file” mode.
The final group is “clueless beyond email”. They might be regular computer (desktop or laptop) users, but who get their images via email or cloud services and just have no idea about how to deal with files locally. (Trust me, they are out there. A lot of them. Too many of them.) Or they be “mostly phone/tablet” users who don’t understand their local file systems at all (Thank you Google & Apple for making everything so “nice” that people don’t even realize they are working with computer files…). These people can upload using built-in Apps (“share”) or email pictures around to everyone. But they don’t know how to do much else. Many of them can be trained to “find the file or find the URL”, many can’t (or at least not without hands-on training that we can’t do). But they can be told:
and then we can process the images automagically. That would be a really cool feature, but absolutely NOT MVP. It is also a feature that I have never seen in any big public systems, but I have implemented similar features in applications for my own customers.
That would be a really cool feature, however for a public site, that would have security implications: How do you make sure that only the user sends there? If anyone can send images to the user’s account, it could allow someone to do damage to the user (e.g. by uploading images that then appear as if the user had uploaded it, with content that gets that user in deep trouble; imagine someone sending child porn to such an address!).
At the very minimum, such a feature would have to be opt-in for the user.
Note that mail headers can be faked (it’s no problem to send an email using your email address as “From“ address), and is not encrypted (well, it can be, but those people who need such a feature are the least likely to know how to encrypt an email), making secure authentication particularly difficult.
What might work is a way to generate single-use email addresses for upload that are usable only for a limited time (similar to password reset links). That is, if you want to add an image per email, you click a link “upload by email” which gives you an unique mail address, valid for an hour, that you can use to send your image.
But that’s definitely not MVP.
I am a bit “wow”-ed by the idea of uploading via email. That’s a very creative approach. It reminds me of printing to a physical printer by emailing to it (I know a place that does this).
My initial thought was instead to generate a random code/password per user that wants this feature. Basically like 2-factor authentication, where the user has to verify that they are the sender using the verification code, perhaps by making it the subject of the email. Once a code is used, you could change it the next calendar day, in order to prevent someone from discovering a still-valid code in someone’s Sent email folder.
I don’t know how easy generating an email address valid for an hour is, but that could also work.
Yes, image upload via email does raise some security/authentication issues. I have used one system (for testing email across multiple client systems actually, not image upload) where for a while they used the “one-time email address” as the upload method. But then they changed it to an “always available, customer-specific” email address and presumably worked out some ways to prevent abuse - perhaps (just guessing) based on only accepting the messages if there was a recent login to the system. In any case:
For MVP we just need basic upload. I think we’re all agreed on that.
I hadn’t thought about email upload – interesting idea. It reminds me of my e-books. I can email books to my Kindle. Only whitelisted addresses can send that email in the first place, and when email from a whitelisted address arrives, Amazon sends me email asking me to confirm it’s ok before sending to my device. This is easier for the user than one-off email addresses or passwords/codes. It does assume that I am in control of my email, but that seems unavoidable.
But that is the basis of “pretty much the whole world except two-factor authentication”. It is the typical “opt-in” of CAN-SPAM compliance (our own announcements@ mailing list as a typical example). It is the basis of password recovery on websites large & small. My email-to-fax system does it to make sure I’m really trying to send a fax. etc. etc. etc. So it is a reasonable solution to this particular problem too. But agreed, NOT MVP.
Interesting. I would have considered the one-off mail address easier: Just click on the mailto, attach the image, press send, done. But the confirmation email probably is the more secure alternative.
This gives me the idea of a potential solution being the similar to how the printer1 at home does it - if you want to ‘print’ (i.e. in this case, upload), it can be done from a linked e.g. Google (or other cloud) drive, or if you’re e-mailing, there’s a setting somewhere that can be toggled for a list of approved e-mail addresses - if it’s not sent from one of these e-mail addresses, either it gets blocked in some way, or the user gets a notification saying that they have a ‘photo upload request’ or somesuch, whereupon they can accept or deny the request and (if they want), add the address to the ‘approved list’. (edit: Oops, I just realised that Celio already mentioned this bit, although not the bit below)
Perhaps if we end up having PMs/DMs (whether we will or not is a different question), these two features could somehow be tied together?
1 Yes, we have a printer that does this at home and yes, your comment made me laugh. No, it wasn’t actually that expensive a printer either 
In a perfect world, yes. But while that works great for a computer with a properly configured traditional email client, it doesn’t (generally, without add-ons and configuration that the same users that can’t figure out how to save their emailed pictures in a place where they can be easily retrieved to upload won’t know how to do) work for online use of Gmail and other web-based email systems and often even for traditional email clients if not configured properly with the operating system for mailto: activation. Plus if they can figure out how to attach then they can figure out how to browse and upload. While this all may be a convenience feature for some of us, my main reason for suggesting anything of this sort is for the people who all they know how to do with images is text or email or “share” them from their phone and so the best they can easily do is get it attached to an email “already ready to go” - they can start that way (“click on ‘email’ from the image in their phone” to start an email and then tap in an address) or forward (send from their phone to their regular computer, or get an image from someone else via email - and then enter a destination address). But throw an empty message at them, waiting for an attachment, and they are no better off then they were with “regular” upload.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.