Patent Application
20100228740
The present disclosure relates to a method and system for allowing a plurality of users to interact with a playlist and specifically for allowing listeners to vote on items within the playlist using their mobile telephones and based on the votes, the playlist can be reordered.
Increasingly media is bought, dispersed, enjoyed and manipulated in digital formats and following this shift, playlists for enjoying the media are also increasingly popular. The use of digital media, especially compressed digital media, has made it possible for users and machines to create playlists easily.
People often use their media playing devices to automatically add music to a queue. In some cases this automatic selection is random, and in other instances algorithms produce more sophisticated playlists that are better suited a user's tastes. Some of the sophisticated playlist algorithms, can for example, take into account the similarity of songs based on their musical characteristics, or based on the feedback of the population at large, or based of the tastes in music of just one user. In some cases, these playlists can generate a great playlist, but in other situations the playlist might be lacking.
Good playlists are especially tough to create when the playlist is made for a group of people at a social gathering. The playlist algorithms have no method of understanding the mood of the listener(s) or the tastes of the population. A subset of the population frequently doesn't have the same tastes in music or movies as the population at large so even playlist that rely on this data would benefit from knowing the tastes of the specific people “enjoying” the playlist. Accordingly, there is a need to be able incorporate the influence of those listening population into the playlist to truly optimize the playlist.
Examples of potential situations where a need exists for a population to exert influence on a playlist include at bars, pubs, restaurants, parties, or social gatherings in general. In each situation, media, such as music, can really enhance the atmosphere of any social event. Whether a jukebox fails to play any songs that a group of patrons enjoy, or a friend at a party cannot put a decent playlist together, these are just a few of the examples when the influence of the local population that is actually listening to the music can make a big improvement. Accordingly, the present disclosure addresses the deficiencies in the art as set forth above.
Additional features and advantages of the concepts disclosed herein are set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the described technologies. The features and advantages of the concepts may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the described technologies will become more fully apparent from the following description and appended claims, or may be learned by the practice of the disclosed concepts as set forth herein.
The present disclosure describes methods and arrangements for facilitating community ranking of items in a playlist as well as host devices and tangible computer-readable media for directing the operations of a host device for performing the same functions. A playlist host device transmits information to a plurality of user devices such as metadata related to media items in a playlist. The metadata includes the order of the playlist, community ranking information, song title, and artist name among other items. The user devices send, and the host device receives, votes related to a media item. The votes can be positive or negative and based on these votes the host device can reorganize the playlist to take into account the preferences of the community, such as a collection of people at a party, restaurant, bar or any other gathering of people. In some embodiments, portions of the playlist include a vote-independent region and a vote-dependent region wherein the host device reorganizes the vote-dependent region based on received votes.
Songs are added to the playlist in conventional fashion such as by selecting media items from a media library using a graphical user interface on the host device. Permission can be given to allow authorized users or guests to queue songs remotely from their user devices. Requested songs can be treated as positive votes. Songs can also be automatically added to the playlist by a program on the host device for that purpose. Songs added by a program can be treated differently than those that are requested by users, for example, by adding program requested songs to the bottom of the playlist and adding user requested songs to the playlist in a higher position. In some embodiments the playlist has at least one set portion, which is not susceptible to adjusting the positions of the media items in this portion and at least one adjustable portion, which is susceptible to adjusting the positions of the media items in this portion.
Also described is a processor-implemented method for facilitating community interaction with a playlist on a host device, wherein the host device sends a playlist on a host device to a plurality of portable devices for display on a graphical user interface, and the host device receives from at least one portable device a positive or a negative vote for a media item in the playlist. Based on the received votes, the media item's position in the playlist is adjusted such as by promoting songs with positive votes and demoting songs with negative votes. Songs with enough negative votes can be removed from the playlist.
In some embodiments, the portable devices connect to and communicate with the electronic device over a local area network, which can be utilized by guests at a social gathering, but communications are not limited to this medium. Examples of potential electronic devices include, but are not limited to jukeboxes, home radios, karaoke machines, and personal computers.
In order to best describe the manner in which the above-described embodiments are implemented, as well as define other advantages and features of the disclosure, a more particular description is provided below and is illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the invention and are not therefore to be considered to be limiting in scope, the examples will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Various embodiments of the disclosed methods and arrangements are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components, configurations, and steps may be used without parting from the spirit and scope of the disclosure.
One method for using a portable media player to interact with the host device is described in U.S. application Ser. No. 11/314,291 entitled “Portable Media Player As A Low Power Remote Control” and invented by Ko et al. which is assigned to Apple Computer Inc. of Cupertino, Calif. and is herein incorporated by reference in its entirety. This disclosure next introduces general details about possible device embodiments.
With reference to
Although the exemplary environment described herein employs a hard disk or other memory such as memory from Fusion-io, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs), read only memory (ROM), a cable or wireless signal containing a bit stream and the like, may also be used in the exemplary operating environment.
To enable user interaction with the computing device 100, an input device 190 represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. The input may be used by the presenter to indicate the beginning of a speech search query. The device output 170 can also be one or more of a number of output mechanisms known to those of skill in the art. For example, video output or audio output devices which can be connected to or can include displays or speakers are common. Additionally, the video output and audio output devices can also include specialized processors for enhanced performance of these specialized functions. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device 100. The communications interface 180 generally governs and manages the user input and system output. There is no restriction on the disclosed methods and devices operating on any particular hardware arrangement and therefore the basic features may easily be substituted for improved hardware or firmware arrangements as they are developed.
For clarity of explanation, the illustrative system embodiment is presented as comprising individual functional blocks (including functional blocks labeled as a “processor”). The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software. For example the functions of one or more processors presented in
The logical operations of the various embodiments are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (2) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (3) interconnected machine modules or program engines within the programmable circuits.
The present system and method is particularly useful for group collaboration in making and managing playlists and is generally illustrated in
Through use of their portable device 206, 208, 210, 212 users interact with the playlist to request new songs, submit votes of for or against a song, move songs up or down the playlist, skip songs, repeat songs, or otherwise remotely interact with the playlist in any way that they would while interacting directly with the host device. Additionally, many users interact with the playlist at once. For example, users of devices 206, 208, 210, and 212 all interact with the playlist to generate a community driven playlist. Votes that are cast are tallied and affect the order of the playlist or the songs that will be played. In such a way, the described system allows community input into the playlist.
Devices 206, 208, 210, and 212 communicate with the host device using any convenient electronic communications medium; however wireless communications are depicted in
The network device 204 can support a wireless network. The wireless network can take the form of, for example, a “WiFi” interface according to the IEEE 802.11 series of standards. Other wireless network standards could also be used, either in alternative to the identified standards or in addition to the identified standards. Such other network standards could include the Bluetooth standard.
The network device 204 can send and receive wireless network signals that can be received by the host device 202 and portable devices 206, 208, 210, and 212, which are equipped with antennas configured to receive and transmit wireless signals. Such antennas may take a variety of forms, such as antennas printed on a standard printed circuit board and are well known to those skilled in the art.
In other embodiments the network device 204 may not be necessary. For example, in the case of the Bluetooth standard, direct communication between the portable electronic device(s) and the host device is enabled. Again all devices are equipped with an antennae configured to send and receive wireless signals.
Regardless of which communications medium is employed, whether wired or wireless, a communication interface is used to send and receive electronic communications signals, demodulate the data sent in the form of packets or cells and translate the data into a format usable by the processing device or translate the data received from the processor over a bus and modulate the data into the appropriate format for the chosen communications medium.
As described above, users interact with the host device using a portable device or device.
After access is granted, the portable device displays a welcome message received from the host device, as illustrated in step 310. The welcome message explains how to use the system, confirms to the user that they joined the desired host device or displays any other relevant information. Next the portable device requests playlist information at step 312 and receives and displays the information at 314. The playlist information includes any useful information regarding the playlist including, for example media items and various meta data, but in some embodiments, information such as previously played items, currently playing item, queue items, item name, artist, album, genre, and ratings are contemplated.
Communications between the portable device and the host device over a network is initiated through a discovery protocol such as BONJOUR. Also known as Zero Configuration Networking, BONJOUR uses standard IP protocols to allow devices to automatically find each other without the need for a user to enter IP addresses or configure DNS servers. Implementation details may be found in the following patent applications, which are hereby incorporated by reference in their entirety: (1) “Method and Apparatus for Configuring a Wireless Device Through Reverse Advertising,” application Ser. No. 10/102,321, filed Mar. 19, 2002; (2) “Method and Apparatus for Supporting Duplicate Suppression When Issuing Multicast DNS Queries Using DNS_Format Message Packets,” application Ser. No. 10/102,174, filed Mar. 19, 2002; and (3) “Method and Apparatus for Implemented a Sleep Proxy for Services on a Network,” application Ser. No. 60/496,842, filed Aug. 20, 2003.
The discovery protocol can facilitate communications between two devices on a network by identifying the devices to each other. In the case of a host device, it can advertise over a network using multicast or broadcast that it supports playlist hosting and any other service such as perhaps audio streaming to other devices on the network. In addition to the availability of the service, the device can publish the name of the device providing the service, the network address of the device, and one or more configuration parameters that are related to the service. The registration of the service can also include security, encryption, compression, and other capabilities and/or parameters that are necessary for communicating with the device.
The portable communications device can listen for incoming configuration packets, and create a service advertisement announcing the fact that it is listening and ready for configuration. This announcement can be made using DNS Service Discovery, or any other Service Discovery protocol known to those skilled in the art.
After the portable device has located the host device, it will request and the host device will receive the request for pairing in step 406. The host device can in turn request credentials from the portable device at step 408. If the credentials are accepted, the host device can grant access at step 410 and send a welcome screen at step 412. More than one personal device can be paired with the host.
Once pairing is complete, the host device can receive a request from the portable device for playlist information at step 414 and deliver the playlist information at step 416. Steps 414 and 416 can be continually repeated to update the playlist information on the portable device.
Now that the portable device and the host are paired, the portable device can be used to remotely manage the playlist.
Associated with the queued items 508-512 are icons 518 and 520 that allow users of the paired portable devices to vote a song up 520 or down 518. Presumably votes are cast as an indication of preference. For every positive vote cast by selecting icon 520, the song's voting score 516 is raised one integer; for every negative vote 518, the song's voting score 516 is lowered one integer. While for purposes of this example, votes are counted as integer adjustments, any adjustment that allows a voting algorithm to keep track of the relative popularity of song based on votes received from the paired portable devices can be used.
The order of the queued songs 506, 508, 510, 512 can be affected by each song's voting score 516, although in
Associated with the queue items 618 are icons 622 and 624 that allow the user of the host device to vote a song up 624 or down 622 directly at the host. For every positive vote 624, the song's voting score 620 is raised one integer; for every negative vote 622, the song's voting score 620 is lowered one integer. While for purposes of this example, votes are counted as integer adjustments, any adjustment that allows a voting algorithm to keep track of the relative popularity of song based on votes received from the paired portable devices can be used.
The order of the queued songs 618 is affected by each songs voting score 620, which again, represents the total score based on input from any paired portable device that has sent a vote to the host and any votes cast directly with the host. Songs receiving positive votes and thus having increased voting scores are advance in the queue so that more popular songs will play earlier than less popular songs. Likewise, songs receiving negative votes can have reduced voting scores and are demoted in the playlist. It is also possible that songs can be voted off the list if they achieve a poor enough voting score.
In addition to voting, the order of a playlist can also be modified by adding new songs to the playlist. Songs can be added at the host according to any well-known method in the art. Many media managing software applications exist for both personal computers and jukebox type devices and these applications can be used to manage the playlist or to allow new songs to be added to the playlist directly at the host.
Songs can also be added to the playlist remotely. Referring again to
Whether a song is selected from the host's library or a song is selected in the playlist, a details screen can be viewed for that selection as seen in
Song recommendations can be made via any number of methods now known in the art. In some embodiments the song recommendations can come from the portable device itself, or from the host, or even from a remote server. The user can also select a recommended song to be added to the playlist.
Songs can be added to the playlist in at least three different ways. As illustrated in
Songs being queued automatically 906 by an algorithm or process running on the host device can also be distinguished and put into the auto queue 918. This can allow the system to give priority to all songs requested by users over songs automatically queued.
Not only can songs be placed into different portions of the queue based on who requested them or how they were requested, but the songs can be treated differently as well. For example, songs added by users might be immune to removal from the playlist since at least one person requested the song while songs auto-queued can be voted off the playlist.
In addition to voting and adding songs, the present system can also include other features. For example, in some embodiments request limits can be established. To prevent one person from filling up the queue with requests, an optional limit should be configurable by the host. Also, an additional option could allow the host to choose whether or not songs can be re-requested after they have been played.
In some embodiments, remote guest users can add tracks from the community playlist to a wish list of songs to purchase later. This process would be similar to tagging a song playing on an HD Radio. When the portable device accesses an online store, a link from each tagged song would allow the user to purchase the song from an online store.
In some embodiments, banning a user can be useful. If a user hogs the queue, or requests undesirable songs, the host may wish to block the offending user out of the system. This would require requests in the system list to be identifiable by user. It would also require a user interface for banning the user, and managing the list of previously banned users.
In a similar fashion, in some embodiments the host can be a karaoke machine or other host operating in a karaoke mode. Users can pick songs and enter their names into the host operating as a kiosk. The host can play a requested music video on a monitor with lyrics for the currently playing song as is well known with respect to present day karaoke machines. Audience members could vote on the quality of the person's performance using their portable devices and the host can track and display the voting progress on the screen, for example, as an overlay it in the corner of the music video. If the performer received enough negative votes, then the performer can be voted off and their song ended. The host could also display the next performer in another corner of the secondary monitor.
In some embodiments, guests can share their own music storage on their portable device with the host device. To enhance the playlist, guests could be allowed to send tracks from their own library to the queue. This would allow music outside the host's library to be played. After a song is played, any trace of the streamed song anywhere but on the guest's device can disappear if not already owned by the host.
In commercial settings it could also help to promote a Jukebox pay-as-you-listen workflow, where guests may buy a song on-the-spot in order to hear it. Depending on the environment, either the guest or the host can retain the purchased song. In some embodiments a commercial interface is contemplated which will provide an interface for a monetary transaction in order to select a song from the host. This embodiment is similar to a Jukebox today where a user pays money to listen to songs. In this context the user can pay and select the songs to be played from their portable device.
In some embodiments guests can view a profile of a requester of a given song. The user could view other songs by that requester, add the guest as a friend in a social network, or tag songs from the guest's “favorites” list for later purchase.
In some embodiments the auto-queuing algorithm can select songs for queuing for every user's library to enhance the pool of listening choices. Additionally the auto-queuing algorithm can be coupled with a similarity algorithm or collaborative filter to select songs that are deemed similar to each other. Using a collaborative filter to access guest's libraries that are connected to the system can help automatically steer the music towards the tastes of the crowd.
Other features can be added such as a message board to accompany the playlist. Users could comment on the party in a live feed.
In some embodiments, a centralized host is not necessary. In such embodiments, a portable device can originate a playlist and other portable devices can join the playlist as if the portable device was the host. If the portable device acting as the host leaves the party, the other portable devices can continue to share the playlist. This embodiment can be especially useful in situations where the portable devices are not communication over a local area network, but directly, for example using the BLUETOOTH standard.
This embodiment can also be useful in a situation wherein a group of users end up together, for example, on an airplane, and desire to create a kind of ad hoc community playlist. Other portable devices can share the playlist with the originator, but part way through the flight, the originator might want to watch a movie and leaves the community. Others participating in the communal playlist can still interact with it without needing the originator device to host the playlist. This can be carried out in a number of ways. When the originator leaves the community, the media management program hosting the playlist can assign another device as the host. Alternatively no host device is needed. Each device can have a local store of the playlist in its RAM and the community of portable devices can update the other devices in the community using multicast communications or other communication method that shares information with multiple users. Each portable device can then update its own copy of the playlist. While sharing the playlist, it can also be necessary in this scenario to share media as well as described infra.
By way of example only, an exemplary use scenario will be discussed to make the operation of the system more clear. One example of a dynamically generated playlist is the PARTY SHUFFLE playlist or the ITUNES DJ playlist in the media management software ITUNES distributed by Apple Inc. of Cupertino, Calif., which provides a continuous mix of music. Songs can be added to ITUNES DJ automatically by ITUNES or manually by the user. The user can then reorder songs.
A source playlist option limits the available library of songs for Party Shuffle auto-selection. By default, ITUNES DJ selects randomly from the user's entire library. There is also an option to “Play higher rated songs more often”, which weights auto-selection by a song's star rating in ITUNES.
The user can specify the number of visible songs in the ITUNES DJ play history, and the number of upcoming songs that should be visible in the queue. A “Refresh” button, when pressed, replaces all auto-selected songs in the queue with a new semi-random set. Songs that were manually added to the queue by the user are left untouched.
When a user wants to view or control ITUNES DJ remotely using their portable device, the user instructs their device to find instances of ITUNES on the local network that have ITUNES DJ guest access turned on. When guest libraries are available, a selection is made available for joining that “party.” The ITUNES library name is displayed, along with the optional welcome message specified in ITUNES DJ settings, if available.
If a user selects a library that has a password set, the portable device prompts for a password using a single-line, text-input screen. If the password succeeds, it can be saved on the portable device to avoid having to enter the password in the future. If the prompted or saved password fails, a message will be presented to the user asking him/her to try again. If three consecutive password attempts are unsuccessful, the user is backed out to the Settings list.
Turning on guest access in ITUNES advertises a new BONJOUR network service, with type “._remote-jukebox._tcp”. When a user opens the settings menu on the portable device, it scans for services with this type on the network and presents each to the user. Each service is resolved immediately to collect more information about the server for display and connection.
The library name and welcome message are specified in the host-info. These two fill out the table cells that populate the library selection screen on the portable device. Selecting a library attempts to login to the host to fetch a session-id for further transactions. If the host-info specifies that the server requires a password to login, any stored passwords are first attempted for authentication by the portable device. If those fail, or none are available, a user-prompted password will be used and stored for future connections. Passwords are sent without encryption from the portable device to ITUNES, but in some embodiments they can be encrypted.
Once connected the user can vote to influence the order that songs are played. Songs are ordered by voting scores. The song with the highest net positive votes is first in the queue. If songs have the same score, then the time it was added is used to break the tie. The first song in the playlist is the first one played. The act of requesting a song automatically gives that song a +1 vote score—this represents the vote for the person who requested the song. People can vote only once for a song. Doing this will either increase or decrease the vote score and the songs are automatically reordered after a vote is cast. If a user requests a song that is already in the queue, this acts the same as giving the existing song a positive vote. Users are allowed to change their vote.
Another aspect of the disclosure involves a user being able to modify their vote score to be more or less than a +1 vote. For example, the system may store information about user votes such that if a user votes periodically and typically votes with the majority, they can gain more credibility in the system such that when they vote, their vote accounts for, for example, 1.2 or 1.5 votes. In this respect, users with more experience with this system can have their votes weighted more than standard votes. This can invoke an enjoyable competition amongst users to try to enhance their effect on the playlist outcome. Similarly, other users may vote rarely or may commonly vote for less desirable media items in relationship to others in their group and have their vote reduced to be less than the standard vote. In another aspect, users can enhance or decrease the effect of each vote by other mechanisms such as by paying a fee or performing some other function that allows them to increase the value of each individual vote.
This process can also work in the reverse, for example, if a user votes often or numerous times for the same media item in an attempt to unduly enhance its position in the playlist, the system can recognize these efforts and reduce the value or the per vote effect on the playlist order. Similarly, other mechanisms can be applied to affect somebody's vote. For example, a motion detection device within a mobile device may identify that the user is not only voting but perhaps using the mobile device while dancing, walking or in some other fashion that can be connected with the currently played music. In this respect, users can have their vote enhanced based on their participation with the songs that are being played. In other words, those that may have their devices while dancing can have their votes increased in effect which those sitting on the sidelines and not dancing, as would be indicated by the lack of motion associated with their mobile device, may have their votes adjusted accordingly.
Therefore, there are a variety of approaches which may be applied to vary and adjust the voting capabilities of individual users to further enhance the mechanisms disclosed herein for creating playlists and adjusting media items in particular playlists.
If all votes for a requested song are negative the song is removed from the list. Thus, a requested song can only be removed from the list if the person who requested it has changed their vote to a negative one. However, auto-selected songs can be voted up or down by any user. Thus, voting down an auto-selected song that has 0 votes automatically removes it from the list.
In some embodiments, the order of the playlist can be adjusted without explicit voting. As discussed above, using devices having motion detecting capability, the system can learn if party guests are dancing to a song that is currently playing. Based on this information the host can rearrange the playlist to promote similar songs in the playlist or queue songs that are similar in the playlist.
The playlist is divided into three parts: history, current song, and upcoming. The history lists songs that have already played in ITUNES DJ. The current song is the single active song in the playlist. The upcoming portion is divided into three parts: forced, voted, and shuffled. Forced songs appear immediately following the current song. Songs in this section can be reordered at the will of the host. Voted songs are grouped together and follow the forced songs in the playlist. Songs in this section cannot be manually reordered, though a song could be pulled out of the voted group and promoted to the forced list by the host. Shuffled songs are automatically added by ITUNES and can also be reordered manually or by voting. Songs in this section will always follow voted songs, unless manually moved up in the list to the forced section of upcoming songs. Thus in this example, portions of the list are vote-independent and other portions are vote-dependant.
Reordering can be done via ITUNES's standard user interface, or by using the user interface for the ITUNES DJ playlist on the portable device. If a guest requests a song that is already in the forced list, the vote is absorbed by the infinite power of the forced song, since it is already scheduled to play anyway.
To visually display the vote score of a song the ITUNES DJ playlist, ITUNES has a column to represent the vote score for each song. Each upcoming track is also presented with buttons to vote up and vote down each song. Unlike voting from the portable device, where each device can only register one vote per song, voting from the ITUNES user interface will register each vote uniquely and always increment the total number of votes. This allows kiosk-style operation of ITUNES, where guests without a portable device may still express their opinion by voting at the ITUNES host.
When a portable device successfully connects to ITUNES, it immediately presents a Now Playing screen when the ITUNES library is playing or paused. The Now Playing screen allows authorized paired portable devices to adjust player settings and transport controls: play, pause, skip forward or back, scrub the current song, adjust volume, and change speakers. A guest portable device, on the other hand, has no control over the player. It can only request and vote for songs. There is no transport, volume or routing control by guest portable devices.
Visually, transport controls can be replaced with a single button allowing the user to Request a Song. Pressing this button presents the user with a view of all songs in the library that are available to ITUNES DJ (limited by the source selection in ITUNES).
The ITUNES DJ playlist on the portable device can display each song with its artist, title, and album art. It can also display each song's voting score and number of votes, and can encourage the user to vote by presenting a control in each cell.
The voting control starts off displaying a neutral state, with both positive and negative vote options available. When the positive side of the control is selected, the user song is given a positive vote. Likewise, when negative side is selected, a negative vote is applied to the song. Each subsequent selection on the voting control toggles the vote from positive to negative and back.
When a vote is registered on the portable device, it can be immediately delivered to ITUNES to update the song ranking and ordering. To prevent song ordering from changing under the user while he/she is interacting with the list, ordering changes can be postponed until the interval since the last touch event has exceeded 2 seconds. After three seconds, the list can reorder, delete or insert tracks animated to their proper new locations in the list.
The current song can be displayed with highlighting so that it is distinguished from the rest of the list. Scrolling the list to see upcoming songs pins the table cell for the current song to the top of the list, leaving upcoming songs to scroll under it. Scrolling the list backwards to see history scrolls as otherwise expected, potentially pushing the current song off the bottom of the screen.
All users (guests and hosts) can be presented with a “Request a Song” button when viewing the ITUNES DJ playlist. This encourages the user to queue songs frequently, enhancing the ITUNES DJ experience.
Selecting the “Request a Song” button causes a drawer to be presented over the application. The selection of songs should be limited to the scope of the source playlist, set in ITUNES.
When a guest picks a song, the drawer is immediately closed. This prevents guests from adding more than one song at a time. When a host picks a song, the drawer remains open until a “Done” button is pressed. This gives additional convenience to the host, also making it easier to use ITUNES DJ for personal listening. When the drawer is closed, the list is automatically repositioned to center the newly selected song in the middle of the screen.
Tapping on a song in the ITUNES DJ list takes the user to a song details screen. The song detail screen presents the same set of information visible on the playlists. Instead of displaying the voting control, two explicit buttons expressing negative or positive preference, are presented below the song detail. Tapping one or the other sets the user's vote positive or negative.
Authorized users are also presented with two additional buttons, reading “Play Now” and “Play Next”. “Play Now” replaces the currently playing song with the one visible in the details screen. Selecting “Play Next” adds it to the queue following the currently playing song.
Also visible in the details list is a section recommending related songs to the user. Each song in the recommend list will have a ‘+’ accessory that, when clicked, will request the song in ITUNES DJ, and pop the view back to the list, displaying the newly added song.
While throughout the above description the technology has been described as pertaining to music, any media item can be used with this system. It is fully contemplated herein to be able to create and remotely manage lists containing any number of different media types such as, but not limited to, video, movies, still images, or any other file or combination of files that can be joined to a playlist. Accordingly, music as it is mentioned above should be considered as no more than an embodiment of the presently described system and method.
Embodiments within the scope of the present invention may also include tangible computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such tangible computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium or a non-tangible computer-readable medium in the wireless or signal per se context. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the tangible or intangible computer-readable media. Tangible media excludes wireless interfaces or signals per se and must have a hardware component such as RAM, ROM, a hard drive, or other physical storage for the memory.
Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
Those of skill in the art will appreciate that other embodiments of the invention may be practiced in network environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed environment, program modules may be located in both local and remote memory storage devices.
Communication at various stages of the described system can be performed through a local area network, a token ring network, the Internet, a corporate intranet, 802.11 series wireless signals, fiber-optic network, radio or microwave transmission, etc. Although the underlying communication technology may change, the fundamental principles described herein are still applicable.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. For example, the principles herein may be applied to an online store accessible wirelessly by a portable media playback device or by a personal computer physically connected to a network. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the present disclosure.
