Ticket #2153 (closed defect: invalid)

Opened 7 years ago

Last modified 7 years ago

"Stop download" button on clipboard doesn't work

Reported by: jfuhrer Owned by: Eben
Priority: high Milestone: Trial-3
Component: interface-design Version:
Keywords: Cc: eben, tomeu
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

OFW: Q2C18 Build: 505

The context menu for clipboard selections includes a "Stop download" button for downloaded files. In addition to showing up on clipboard entries that are not downloaded files (#2005), it also doesn't work. I selected "Stop download" twice on a pdf file I was downloading at 17 and 37% of the download, respectively, and the file continued to download.

Change History

Changed 7 years ago by tomeu

This action is not yet implemented and is not trivial at all. My opinion is that this menu option should be hidden and implemented post trial2.

Changed 7 years ago by jg

  • milestone changed from Untriaged to Trial-3

Seems like a plan to me.

Changed 7 years ago by marco

  • cc eben added

We need to figure out what we want to do with downloads in Gen1. Is the current clipboard solution acceptable or are we going to implement notifications?

My feeling is that using notifications would not improve the experience in a critical way. On the other hand downloads are a very important task, so the time spent to improve them might be well spent.

Changed 7 years ago by tomeu

  • cc tomeu added

Changed 7 years ago by marco

  • owner changed from dcbw to Eben
  • component changed from sugar to interface-design

Eben, what do you think?

Changed 7 years ago by Eben

#2555 goes into detail (including an attached image) about the design for in-progress Journal entries. I think this is a logical place for downloads to appear, since they will appear then when complete anyway. The question remains if we need them to be somewhere in the frame all the time, if we want a notification to alert the kid when the download completes (even if it isn't persistently in the frame), and if using the clipboard is acceptable.

One thing I will definitely say is that, if we do use the clipboard, we need to make sure that it doesn't become the paste target when it's added. That is, to maintain predictability, we want the paste target to always be the last thing copied. I'd prefer not to mess with the clipboard metaphor at all, yet I see the usefulness of having it readily available. What do others think? Could we get away with simply using the Journal, perhaps with a small audio notification or something when it finishes?

Changed 7 years ago by HoboPrimate

Some food for thought: What is different, from the user point of view, of copying a file from the browser, and copying an object from an activity?

Changed 7 years ago by Eben

Well, I've been considering this, actually. I do have an answer, though I'm not sure just how much it clarifies.

I'd say that the main difference is one of permanence. When I copy something, I expect that the image or text etc. is a transient object, that will remain until I paste it again, or perhaps until it gets pushed off of the clipboard. Items that are placed in the clipboard don't appear in the Journal unless explicitly told to. On the other hand, at least traditionally, downloads are an action which result in a permanent file on disk, which for us is the Journal. Since we do all saving implicitly anyway, I'd expect that downloads are also automatically logged as new entries in the Journal.

Changed 7 years ago by HoboPrimate

I think you cleared it up very well (for me at least).

There should be a way to notify the user that a download began, that's for sure. And it makes some sense (from the user perspective) if it was the Journal's job to do that notification. What if when starting a download, the main activity would be switched to the Journal to show what has just begun to be downloaded to it?

This kind of notification system could work for various other information as well. For example, if battery charge is critically low, it would change to the Home view with the battery tooltip being shown in full. If the "net" went down, would switch to the Home view, showing the Circle or Triangle icon disappearing.

Possibly, so has not to be so obstructive to the flow of the users work, after showing these alerts for some second, the user would be brought back to what he was doing (in case of downloading files, to Browse).

Also, it would be good to automatically tag downloaded files as such.

Changed 7 years ago by HoboPrimate

Oh, and in the short term, I would recommend that downloads are handled like they are now (but not being automatically focused to be pasted, like Eben said), with the option to Put into the Journal grayed out(since it already is in the journal) or even removed, to make it more clear that it is being downloaded to the Journal.

Changed 7 years ago by HoboPrimate

"...to make it more clear that it is different than the other temporary clipboard objects."

Changed 7 years ago by Eben

  • status changed from new to closed
  • resolution set to invalid

This has been replaced by in-progress entries in the Journal, and as such is no longer valid.

Note: See TracTickets for help on using tickets.