Download presentation
Presentation is loading. Please wait.
Published byDouglas Stevenson Modified over 9 years ago
1
CMU MHCI - GM Network Project19 May 2004 ROADCASTING GM Car Network Project Jim Garretson Whitney Hess Jordan Kanarek Mathilde Pignol Megan Shia
2
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Overview Service Design High-level interaction Scope Scalability Design Rationale Lightweight interaction Search vs. Browse XM Expert Analysis Implementation Details Future Plans Agenda
3
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Service for cars in 2010 that uses ad-hoc networking to make radio collaborative and more engaging. Overview
4
CMU MHCI - GM Network Project19 May 2004 ROADCASTING More than just the most popular songs: commentary from cars close to you be your own DJ automatically play the songs that everyone tuning in will like Overview
5
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Every GM car with Roadcasting can receive Roadcaster stations and influence the songs played (within limits set by the broadcaster) has the ability to broadcast songs to other cars with Roadcasting Overview
6
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Overview Service Design High-level interaction Scope Scalability Design Rationale Lightweight interaction Search vs. Browse XM Expert Analysis Implementation Details Future Plans Agenda
7
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Example scenario. Service Design
8
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Every broadcaster has three levels of involvement: Managed - broadcaster determines what is played and when Guided - broadcaster determines what is played with input from the audience Unmanaged - broadcaster is not active and the collective audience chooses what is played Service Design: High-level interaction
9
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Every listener has two levels of involvement: Active - listener votes for songs to be played Passive - listener does not vote (but still influences the station through his/her profile) Service Design: High-level interaction
10
CMU MHCI - GM Network Project19 May 2004 ROADCASTING In Managed and Guided modes, no votes are sent out to the audience In Unmanaged mode, prompts for voting are sent out to the audience and Active listeners determine the next song played. Service Design: High-level interaction
11
CMU MHCI - GM Network Project19 May 2004 ROADCASTING We have limited the scope of our development to service and interaction design. We will not be addressing: broadcasters how they select individual songs to be played how they might find music on the network how they might broadcast other media (video) listeners how they manage multiple drivers/profiles how XM, FM and Roadcasting cooperate Service Design: Scope
12
CMU MHCI - GM Network Project19 May 2004 ROADCASTING When a station has no listeners, the station selects music based only on the broadcaster’s preferences. When a station has one listener, the station recommends music based on both the broadcaster’s and listeners’ preferences. As the number of listeners increases, they collectively influence the music recommendations. However, the broadcaster can always override recommendations. Service Design: Scalability
13
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Service Design: Scalability
14
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Overview Service Design High-level interaction Scope Scalability Design Rationale Lightweight interaction Search vs. Browse XM Expert Analysis Implementation Details Future Plans Agenda
15
CMU MHCI - GM Network Project19 May 2004 ROADCASTING In-vehicle systems must not demand a driver’s attention in order to function. We designed the broadcasting and listening interactions to afford a variety of attention levels. The system will even function without any user input. Design Rationale: Lightweight Interaction ManagedGuidedUnmanaged ActivePassive Broadcaster Listener
16
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Search vs Browse Technical limitations led to our decision to incorporate browsing rather than searching in the interface. BUT, for future iterations, what are the implications of both searching and browsing with respect to Roadcasting? We performed a literature review to answer that question. Design Rationale: Search vs. Browse
17
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Literature review findings and implications Finding When browsing, people care more about navigation and information organization. When searching, product details are more important. Design implication For browsing: efficient navigation and organization of the categories and stations is essential. For searching: users should be presented with detailed information in order to ensure that the correct song/station was found. Design Rationale: Search vs. Browse
18
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Finding Search rate for specific items was greater than search rate for general items, but not statistically significant. Design implication Browsing for a specific song or station might be just as preferable as searching. Finding Browse function had higher success rate than search function, though not statistically significant. Failure rates were even. Design implication Users may be more likely to find the song/station that they are looking for by using menus. Design Rationale: Search vs. Browse
19
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Finding Successful product locations took more time than unsuccessful attempts, whether searching or browsing. Design implication Success is more difficult to judge than failure. Design Rationale: Search vs. Browse
20
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Music domain conclusions Finding CD store shoppers alternate between search and browse as there are advantages to both modes. Design implication Building a system that allows seamless switching between searching and browsing would be most appropriate. Finding The ability to listen to song clips would then support a natural way for users to verify they have selected the right song. Design implication When listeners vote, instead of just showing the song title and artist name, also play a short (5 sec) sound clip. Design Rationale: Search vs. Browse
21
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Finding Music shopping and selection is surprisingly visual. Design implication Possibly an album of the song that's currently playing? Design Rationale: Search vs. Browse
22
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Problem with XM Each station is identified by both a number of a unique name, forcing the user to memorize which station is associated with which number. Design solution Since we are not implementing a search function, stations can be identified by either name or number, not both. This is more appropriate for non-persistent stations. Problem with XM Current song title playing is truncated if it is too long instead of using entire display. Design solution Make efficient use of screen real estate. This will give users more detailed information about the stations. Design Rationale: XM Expert Analysis Problem with XM It isn’t clear how to set presets or how to access them. Design solution Eliminate presets. This is possible since system is already knowledgeable of user’s music tastes Problem with XM Visual attention to the display is required while scrolling through stations. Design solution Allow scanning through stations so that users can hear each song being played as they scroll to find a station they like. This will make navigation more natural and spontaneous.
23
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Problem with XM Categories are not organized in a meaningful way Design solution Organize categories according to user preference. This will reduce the amount of scrolling a user will need to do in order to find a category she enjoys. Problem with XM Stations are organized by channel number, and in no understandable order. Design solution Organize stations according to user preference. This will reduce the amount of scrolling a user will need to do in order to find a station she enjoys. Design Rationale: XM Expert Analysis Problem with XM Stations sometimes play a strange order of songs: Paul McCartney -> Kiss -> Joe Cocker. Design solution System should suggest next song to Broadcaster that has a similar tempo to what is being played. This will keep the tone of the station somewhat steady. Problem with XM Stations play the same artists repeatedly. Design solution In Unmanaged and Guided modes, system should suggest songs and artists that haven’t recently been played.
24
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Good aspect of XM Stations play rare versions of songs that most listeners haven’t heard. Design implementation Look for alternate versions of Listeners’ owned songs on Broadcaster’s playlist – remixes, covers, live versions, etc… Good aspect of XM Stations use celebrities, sound collages, and DJs to strengthen station identity. Design implementation Provide opportunities for Broadcaster to automatically or manually play a recording of her station identification. Design Rationale: XM Expert Analysis
25
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Overview Service Design High-level interaction Scope Scalability Design Rationale Lightweight interaction Search vs. Browse XM Expert Analysis Implementation Details Future Plans Agenda
26
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Prototype architecture Implementation Details
27
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Implementation Details Collaborative filtering Listener preferences are created based on the listener’s MP3s or iTunes library data. The listener’s preferences are sent to the broadcaster when the listener tunes in to a station. (For now) a simple Pearson correlation is calculated from all audience preferences, and determines which songs, artists and genres are most preferred by the listening audience.
28
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Implementation Details Station flavor A broadcaster can set restrictions regarding the type of music his station plays. This ‘station flavor’ determines what songs the broadcaster has that can be played. This station flavor is also broadcast as part of a station’s identity, so a listener’s tuner can know which stations she is likely to prefer based on her preferences.
29
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Implementation Details Audio rendering Songs are pulled from the station playlist and sent to listeners. MP3 files (or live voice from the broadcaster) are multicast to the audience using the Java Realtime Streaming Protocol.
30
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Implementation Details Polling A listener can press her voting buttons at any time. These votes are visible to the broadcaster, so allowing him to conduct polls on-air and see live results from his audience.
31
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Overview Service Design High-level interaction Scope Scalability Design Rationale Lightweight interaction Search vs. Browse XM Expert Analysis Implementation Details Future Plans Agenda
32
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Future Plans: Timeline
33
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Future Plans: Next Steps Continue to address low-level design issues Two-member teams: Jordan and Whitney will look into the specifics of how voting will work and how Broadcasters will talk over their music or between songs. Should Broadcasters hit an “On-Air” button to broadcast their voice? How do they propose a vote on music content? Can they pose a question on non- music content (i.e., trivia)? Megan and Mathilde will look into interruption issues for Broadcasters and Listeners Should Listeners be notified of new stations as they enter the network? Should Listeners see a timeline indicating remaining/elapsed time of a current song? How will Broadcasters and Listeners be notified to make a vote? How will Listeners switch between Active and Passive modes?
34
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Future Plans: Next Steps Issues to be tackled by the entire group Should the Broadcaster know how many people are listening to his station? Should the Listener see station stats (i.e., signal strength, location, popularity/reputation)? How are stations uniquely identified? How do Broadcasters set the flavor/format of their station?
35
CMU MHCI - GM Network Project19 May 2004 ROADCASTING Questions Questions?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.