After the research phase of the context menu, is the design phase. Myself along with a few other from the Firefox UX team met to do some ideation and brainstorming. We generated many ideas and then consolidated them into a few main themes. The first of these themes is what I call ‘drag-and-share.’
I noticed during my research that users would commonly drag content they wished to do something with (e.g. drag an image to their desktop). This habit is built in to how people use computers. Now that act of dragging content in and of itself was not the end goal, that content was often shared in some way. So we asked, why make the users go through multiple steps to drag to holding location, load a new page and drag to place they can share – what if dragging content triggered sharing options? That’s what drag-and-share is all about.
Below is a link to some slides of several design concepts for this feature. I welcome any and all feedback – do so by email, contact form or comment below. Thank you! Once the design of this feature is complete, I will build it as an add-on for people to try 🙂
seanbolton.me 
1. Icon Tray could be interesting, but with the possibility to change sides. Or is it based on some kind of future FF flow? (or some now, even?)
2. Anchored Menu seems like the logical, low friction, low travel option and it could be implemented alongside another option.
I would love to read something more about how “Share Icon with Sub Tray” differs from “Paperclip” one.
The “Share circle” seems gimmicky and does not feel consistent with other UI features in Firefox right now. So that’s the only that gets “no, thank you” from me.
(Apologies in advance for the length.)
Without a little more description, I feel unclear on how exactly some of these are to work.
For instance, in #2, does the menu just follow you as you drag or does it only occur when you release? If it only appears when you release, what if you were trying to interact with the page in a different manner? Perhaps you missed your drop target? Perhaps you were trying to invoke the menu but accidentally *hit* someone’s drop target. What if it was an accidental drag (and release)? Even as a tech savvy user I still accidentally do that. This might be more confusing for a non-savvy user. Some people, like my [easily tech-confused/frightened] mom, accidentally drag stuff more frequently as well.
#5
I have some of the same questions and concerns about this as #2. (Actually you can just go back and reread them.) I’m still not sure what to think about the “…” for radial (sub)menus. Perhaps with with some actual use I would more easily come to accept them, but they are a necessary evil due to the nature of radial menus which is not as much of an issue for the other flatter view options. I don’t like that extra step that’s invisibly hidden (What’s there again? I forget/I don’t care. I’ll do something else or just forget it.).
#1
Was going to compliment this one because it creates a nice large surface area to drag to, however, that doesn’t matter as much because you still have hit the specific action icon of desire. If you miss it, your mission has failed (so the one-shot succeed or fail nature ends up counting against it).
Not a fan for a few reasons, one being that window sizing adversely affects action icon locations. I *need* (or really want) that icon to be where I know it’s going to be. But the window size affect the list excessively. If it’s too short, tough luck for the bottom of the list. There are a couple obvious disadvantages (I think) to this approach, such as extensibility, made more apparent below.
#3 & #4
What’s the difference between #3 & #4? The icons and their location?
These are my favorite – partly because I had this pretty well this same idea years ago. 🙂
It’s an action target. You drop content on it and you get to find out what you can do with what you just dropped.
“Did you drop text? Here are your options.” Flickr and Youtube won’t show up. Twitter will, but if the text is too long the preview will clip it (or turn it red and not allow a send so it can still be edited).
The icon location should be up top for a few reasons:
– The top of the browser window is stable in the user’s mind. I know where the location bar and search bar, etc are going to be, so anchor it there and I’ll know where to look. If you ask a user to resize a window, they are likely to drag around the bottom right corner. (I think some OSes might not even allow you to resize by dragging the top edge or corner.) The bottom corner’s location is much less certain and reliable.
– The resting place for the cursor is perfect. If we auto sort actions or allow the user to manually sort, the most frequently used actions will be at the top of the list, so making the drop target at the bottom forces the user to move up almost constantly.
The icon question seems problematic to me – with the current suggested icons I mean. The paperclip seems to communicate “attachment” which is too specific and inaccurate. The dots & connected lines say (to me) “share” (usually socially – FB, etc) which is *more* accurate, but still off the mark. Maybe I’m wrong and that icon is more general, but that’s my impression at the moment.
One possibility with this approach that I think is awesome is the manageability of multiple objects. I drag object 1 from the page into the queue. Now I drag objects 3-6 into the queue. Now I navigate to a different page and drag object B into the queue. Now I email them to Frank.
The queue is also responsive to the action selected. If I have multiple types of objects in the queue and click Youtube (obviously one of them is a video or I couldn’t do that) then the other files would indicate their unavailability. Perhaps become grayed out with an X over the top. If an action only supported a limited number of objects (i.e. “You can only share one image at a time.”) then the first occurrence would remain normal, or receive a highlight, and the others would become unavailable. Clicking would change their state – share *this* not that.
What if you dropped a specific type of object that Firefox knows about? Let’s say you’re looking at your address book and you drag one of your contacts to the action icon, now you can call them or chat with all registered software. Firefox sees the type of content in the object and looks to see what’s registered. I believe there’s some standard (web activities?) that we’re using in FxOS for this type of association.
I would also see no reason that we couldn’t support dragging files from the filesystem. Firefox also knows how to receive files dropped on it. Now I don’t have to go to Youtube or Flickr to upload from the desktop.
Oh, another advantage that I can see from this approach is a better story for multiple actions. If there a significant list of potential actions for an object, the radial approach can become problematic.
After thinking about the icon question more I think I can articulate a bit more where I’m coming from…
Even now, in your Share list there are the ‘saving to desktop’ and ‘saving elsewhere’ options. These are obviously not sharing actions. And I think there are other services that would benefit our users and groove well with this concept that are not sharing.
Some examples might be:
– uploading an image to an editor
– uploading a Word file to a document editor
– acting locally on an object – like the send-to-vlc extension
I think there are some services we will likely want that are already on the fuzzy end of “sharing”. I feel these non-sharing actions (listed and implied) would be a logical progression for this drag&drop target functionality you’ve illustrated.
I would then encourage a rethink on the share branding (icon & name) to be more general. I think this would be a good direction for everyone (users and Mozilla), but think it’s important to make the change near inception rather than suffer for it later on.