Music as a Background Service
Typically, music players have been allowed to run as a background service. That is, when you close the window the application continues to play music in the background. This blueprint is meant to talk about what that could mean for UX in BeatBox and raise questions to think about.
-- Contributor meeting decision --
On clicking the close icon, beatbox should:
- Minimize if it's playing music and stay in the dock/taskbar
- Hide the main window and finish the process if it's music import or sync or something like that
- Quit if music is paused and BeatBox is not doing anything else
When BeatBox is minimized and the user pauses music, it should wait for a while, and if the user doesn't hit play, quit
Past proposals:
-- Close is Quit. Period. --
At the moment, close means quit. For most applications this is the correct behavior. Only applications that perform some sort of background service should be allowed to run in a windowless state. This does apply for a music player, but it adds some complications to UX. When does close mean quit? When music is not playing? What if you are importing from external storage? Does close mean, "Disconnect from a network share?" Where do we draw the line of what parts can run in the background?
-- BeatBox Knows Best. --
We could employ some cleverness here. That is, close means quit only when BeatBox isn't doing anything. In other words, lets say you're listening to some music. You close BeatBox, and the music continues to play. Pause BeatBox (from anywhere, sound menu, gloobus preview, whatever) and it quits. Importing a CD? Paused the track? BeatBox stays open until the CD is imported, then quits. In other words, BeatBox will only quit if it is idle. This is the most hands-off approach for the user and let's BeatBox take care of memory management itself.
-- The User Knows Best. --
All cleverness aside, I as the user am the most capable of knowing when I want to quit or close. So the solution in this case is to add a separate quit item to BeatBox's UI. In this way, I know for a fact that I am terminating that process. Plain and simple... if you know about that Quit button at least.
Keep these three in mind as separate and valid arguments for each case. Don't think that they were put in a certain order to draw a certain conclusion. I am only arguing each side and making assertions about each. They all have their good points and bad points.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
I think "BeatBox knows best" would be the best solution, but not quite how you explained it.
BeatBox will close/quit like normal, except if:
Doing file operations (saving metadata)
Importing/
In an important transaction (music store purchase)
In the case of one of the above (or similar cases), it will hide the window, but will stay open until all operations are finished. If the user wants to reshow BeatBox while the operations are finishing up, they can do so using the soundmenu.
The window will quit like normal if music is playing (no special hide scenario when music is playing). The user shouldn't have to pause the music before clicking exit.
So, long story short, when the user clicks exit they intend to exit and we will do just that. However, the user cannot know if/when background processes are running when they close and therefore we will have a safety net for those cases.
I agree. When you want background music, you minimize BeatBox to the dock. And BeatBox icon in the dock should indicate, that it's currently playing music or paused (or doing something else in background).
I think that Beatbox should exit only when it's idle, as said above, but if the user pauses the track and Beatbox exists when he/she tries to resume the song it would do nothing. I dont think that exiting when closed even if the user it's playing music because when I work with something I want to have as less windows as posible, also if they eventually remove the mimize buttons from the windows this can't be done. So I think the best is to stop Beatbox only when the user stops the song, and not when pausing it, and if he/she uses the multimedia start button if there's no music player open then it opens your default music player. ~sheosi
Well, now we've ditched minimizing (http://
