Ubuntu One's "publish" and "copy web link" items are redundant and confusing

Bug #956663 reported by Pablo Almeida
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Ubuntu One Client
Triaged
Undecided
Ubuntu One Client Engineering team
ubuntuone-client-gnome (Ubuntu)
Won't Fix
Undecided
Ubuntu One Client Engineering team

Bug Description

NOTE: I tried to assign this to ubuntuone or anything related but launchpad keeps saying that there's no such package.

Currently, to share a file with a friend on Ubuntu, you have to copy the file to the Ubuntu One folder (or another syncronized folder), right-click the file and select "Publish" and then right-click the file again to select "Copy web link". This sequence is the same almost every time, and even when you just want to share a file that's already syncronized, you still have to publish and then copy the link. I think this could be simplified for ease of use. I've come up with some solutions:

1) Always copy the file to the clipboard after publishing a file (and tell the user in the notification). This is potentially annoying if the file is big and has not uploaded yet, and the user copies something in the middle of the upload and wants to paste after the publishing is done. This is probably rare enough to be overlooked, but I don't know.

2) Create a new menu entry: "Publish and copy the link". This would do the same as 1), but the user would know what will happen in advance, but this will cause the menu to become even more cluttered, and it is already confusing enough as it is. This could also replace the current "Publish" menu, but then we would need a new menu to stop publishing, so it's not a good deal.

3) Keep the usual menus, but, after clicking "Publish", the user would be asked "Copy the link to the file (for sharing) after publishing?" in a simple "yes/no" prompt. Additionally, a "Set this as default and never ask again" checkbox would do good.

description: updated
Micah Gersten (micahg)
affects: ubuntu → ubuntuone-client-gnome (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntuone-client-gnome (Ubuntu):
status: New → Confirmed
Revision history for this message
Dylan McCall (dylanmccall) wrote :

What if the "Copy Web Link" option was always enabled, and just did the extra step of publishing if necessary? That would basically do the same as your yes/no prompt. I expect common the Stop / Start publishing text (and the notification when the file is published) would do well enough communicating what's going on.

Revision history for this message
Dylan McCall (dylanmccall) wrote :

Okay, I'm attaching a branch that implements this feature. Here's a screenshot!
http://ubuntuone.com/4ABQuoSSdeSgFrRVzdst9V
I copied that link using the Publish and Copy Web Link option, too. (Yes, a little cheeky :b)

It wasn't quite as simple as I'd expected. Syncdaemon doesn't give us an on-success callback when we tell it to publish a file, and making that change would be rather invasive, so I had to get a little creative. I implemented this feature using a new function in file-watcher.c:

void file_watcher_notify_when_published (FileWatcher *watcher, const gchar *path, NotifyWhenPublishedCBFunc callback);

That function tells the watcher to keep track of the given path and, from its existing file_published_cb, it runs the callback _once_ when the requested file has been published.

Since I was testing this, I noticed some finicky behaviour with the context menu. If I choose Stop Publishing, all the options for the given file are disabled permanently. Also, in some cases, after publishing a file the context menu still shows as if the file is unpublished I refresh the view.
I'm pointing those out because I tested both versions, and those problems are not new. Same problem in the current release. So, in case you notice them now, my changes (most likely) have not caused those problems.

Revision history for this message
Pablo Almeida (pabloalmeidaff9) wrote : Re: [Bug 956663] Re: Ubuntu One's "publish" and "copy web link" items are redundant and confusing

That would be interesting, but since "Publish" would no longer be an
user-initiated action, a "Stop publishing" option would not make much
sense, and then people would start thinking that there's no way to stop
sharing without having to delete the file. Also, this would give the false
impression that the link has always been available, giving the user who
uses Ubuntu One only for synchronizing the false impression that his/her
files are public.

2012/4/23 Launchpad Bug Tracker <email address hidden>

> ** Branch linked: lp:~dylanmccall/ubuntuone-client-gnome/publish-and-
> copy-link
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/956663
>
> Title:
> Ubuntu One's "publish" and "copy web link" items are redundant and
> confusing
>
> Status in “ubuntuone-client-gnome” package in Ubuntu:
> Confirmed
>
> Bug description:
> NOTE: I tried to assign this to ubuntuone or anything related but
> launchpad keeps saying that there's no such package.
>
> Currently, to share a file with a friend on Ubuntu, you have to copy
> the file to the Ubuntu One folder (or another syncronized folder),
> right-click the file and select "Publish" and then right-click the
> file again to select "Copy web link". This sequence is the same almost
> every time, and even when you just want to share a file that's already
> syncronized, you still have to publish and then copy the link. I think
> this could be simplified for ease of use. I've come up with some
> solutions:
>
> 1) Always copy the file to the clipboard after publishing a file (and
> tell the user in the notification). This is potentially annoying if
> the file is big and has not uploaded yet, and the user copies
> something in the middle of the upload and wants to paste after the
> publishing is done. This is probably rare enough to be overlooked, but
> I don't know.
>
> 2) Create a new menu entry: "Publish and copy the link". This would do
> the same as 1), but the user would know what will happen in advance,
> but this will cause the menu to become even more cluttered, and it is
> already confusing enough as it is. This could also replace the current
> "Publish" menu, but then we would need a new menu to stop publishing,
> so it's not a good deal.
>
> 3) Keep the usual menus, but, after clicking "Publish", the user would
> be asked "Copy the link to the file (for sharing) after publishing?"
> in a simple "yes/no" prompt. Additionally, a "Set this as default and
> never ask again" checkbox would do good.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client-gnome/+bug/956663/+subscriptions
>

--
Pablo Almeida
http://www.google.com/profiles/pabloalmeidaff9

Revision history for this message
Pablo Almeida (pabloalmeidaff9) wrote :

Yes, yes, I'm aware of these issues. As of now, if you try to publish a
file that's not sincronized yet, it will get published and give us the
link, but the link won't work. Then, if you stop publishing and publish
again, to get a new link, it will either not let you do that (the options
are all gone, as you said) or it will give you the same link (which still
won't work).

Anyway, I'm excited to see this in action!

2012/4/23 Dylan McCall <email address hidden>

> I'm pointing those out because I tested both versions, and those problems
> are not new. Same problem in the current release. So, in case you notice
> them now, my changes (most likely) have not caused those problems.

--
Pablo Almeida
http://www.google.com/profiles/pabloalmeidaff9

Rick McBride (rmcbride)
Changed in ubuntuone-client-gnome (Ubuntu):
assignee: nobody → Ubuntu One Desktop+ team (ubuntuone-desktop+)
Changed in ubuntuone-client:
status: New → Triaged
assignee: nobody → Ubuntu One Desktop+ team (ubuntuone-desktop+)
Changed in ubuntuone-client-gnome (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.