Closed
Bug 838007
Opened 12 years ago
Closed 11 years ago
[E-Mail][User Story] E-Mail audio/music attachment
Categories
(Firefox OS Graveyard :: Gaia::E-Mail, defect, P2)
Tracking
(blocking-b2g:-, b2g18+ affected)
People
(Reporter: pdol, Assigned: dkuo)
References
Details
(Keywords: feature, Whiteboard: [LOE:L])
Attachments
(1 file)
(deleted),
application/pdf
|
Details |
UCID: Email-143 User Story: As a user, I want to be able to attach one or more audio files (based on currently supported MIME types) to new emails or within replies to emails so that I can share content with my recipients.
Updated•12 years ago
|
Summary: [B2G][E-Mail][User Story] E-Mail audio attachment → [E-Mail][User Story] E-Mail audio attachment
Comment 1•12 years ago
|
||
Proposed flows updated and available at https://bug838006.bugzilla.mozilla.org/attachment.cgi?id=710545
Comment 3•12 years ago
|
||
(In reply to Rob MacDonald from comment #2) > Created attachment 710548 [details] > Proposed ux flows for search in music > > Draft flows for global search in music. Sorry - wrong bug. Please ignore! :)
Comment 4•12 years ago
|
||
This will need to be primarily addressed in the music app via its implementation of the 'pick' web activity; the bug filed for that is bug 836497.
Depends on: 836497
Summary: [E-Mail][User Story] E-Mail audio attachment → [E-Mail][User Story] E-Mail audio/music attachment
Updated•12 years ago
|
Whiteboard: u=user c=email s=v1.1-sprint-1 → u=user c=email s=v1.1-sprint-1 p=2
Updated•12 years ago
|
Whiteboard: u=user c=email s=v1.1-sprint-1 p=2 → u=rmacdonald@mozilla.com c=email s=v1.1-sprint-1 p=2
Updated•12 years ago
|
Assignee: nobody → dkuo
Assignee | ||
Updated•12 years ago
|
Whiteboard: u=rmacdonald@mozilla.com c=email s=v1.1-sprint-1 p=2 → u=rmacdonald@mozilla.com c=email s=v1.1-sprint-1 p=2 [LOE:L]
Updated•12 years ago
|
Whiteboard: u=rmacdonald@mozilla.com c=email s=v1.1-sprint-1 p=2 [LOE:L] → [LOE:L]
Assignee | ||
Comment 5•12 years ago
|
||
Rob, I have some question about the proposed ux flows in attachment 710548 [details] and attachment 710545 [details] page 4. 1. This bug is for attaching music files to email, I would consider attachment 710545 [details] is the expected wireframes for implementing. In the wireframes, when the user is trying to attach music files in email, the music app should list "all songs" in ascending order and wait for further inputs to search, right? 2. If so, I would consider attachment 710548 [details] should be the wireframes for general searching in music app. In the mix page, the user should be able to search and get results from artists, albums and titles/songs. But then I saw we will also support searching in different filters, I am a little confused that if we already provide the ability for users to search in all filters, and the ui also indicates what filter are the results belong to, does music need to support searching on every pages with different filters? Currently Jim and I are implementing the searching and attaching features in music app, these two features are related base on the new wireframes, so I would like to clarify these questions first then we can make a right design and implement, thanks.
Comment 6•12 years ago
|
||
Clearing tracking-b2g18 flag from User Story bugs. This flag is for bugs that we would take fixes for in the 1.x branch. Feature work should be officially slotted into a release instead with leo+. If this story is intended for v1.1, please nominate for leo? blocking.
tracking-b2g18:
+ → ---
Comment 7•12 years ago
|
||
(In reply to Dominic Kuo [:dkuo] from comment #5) > 1. This bug is for attaching music files to email, I would consider > attachment 710545 [details] is the expected wireframes for implementing. In > the wireframes, when the user is trying to attach music files in email, the > music app should list "all songs" in ascending order and wait for further > inputs to search, right? You have the correct attachment, however, I have updated this document and moved it to Dropbox. The file is available for download here: https://www.dropbox.com/s/5giljes7ao9gyrg/email-attachments.pdf Pages 8 and 9 deal specifically with music / audio attachments and are pretty much aligned with what you discuss above. One issue with found in our UX reviews, though, was that it's difficult to select multiple files when confronted with such a potentially long list. As a result, we were considering limiting selection to only one item at a time, which changes the flow slightly. (that's why it's marked as "in progress"). So basically, the user would view a full list of tracks, in alphabetical order, and tap on one to attach it. To add multiple files, the user would have to attach a second file from the message view. Let me know if you have any thoughts on this. Otherwise, it's on my list for an update this week. > 2. If so, I would consider attachment 710548 [details] should be the > wireframes for general searching in music app. In the mix page, the user > should be able to search and get results from artists, albums and > titles/songs. But then I saw we will also support searching in different > filters, I am a little confused that if we already provide the ability for > users to search in all filters, and the ui also indicates what filter are > the results belong to, does music need to support searching on every pages > with different filters? The latest music search wireframes have also been relocated to dropbox and are available here https://www.dropbox.com/s/yepxm9hogne8apy/music-search.pdf In the new version, the search is the same across all top level views. So the same search filters are used for the Home, Artists, Albums and Playlist views. I hope this helps!
Comment 8•12 years ago
|
||
I just wanted to highlight that the current and future versions of this spec will be available at this location: https://www.dropbox.com/s/5giljes7ao9gyrg/email-attachments.pdf Thanks! Rob
Comment 9•12 years ago
|
||
Version 0.5 of the spec is now available from Dropbox with detailed annotations and edge cases. The URL is unchanged: https://www.dropbox.com/s/5giljes7ao9gyrg/email-attachments.pdf Please contact me with any questions or concerns. - Rob
needed to be +'d for 1.1 work since its a feature/user story
blocking-b2g: --- → leo?
Comment 11•12 years ago
|
||
-- Mass Edit -- These user stories are not P1, therefore not blockers to shipping. We will track for now and look into how to keep tabs on these going forward.
Reporter | ||
Updated•11 years ago
|
Target Milestone: --- → 1.2 FC (16sep)
Assignee | ||
Comment 12•11 years ago
|
||
Fixed by bug 838008.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•