Interview and Focus
Group Outcomes
Sajid Sadi
MAS 965 Relational Machines
Contents
ƒ A lot of this was covered in the proposal
ƒ Basically talking here about highlights
Interview Targets
ƒ Sponsors
ƒ Talked to Cisco, Accenture, and Sony reps
ƒ Other newcomers to the lab
ƒ Interviewed some UROPs about lab
ƒ Communication and Development Office
ƒ Finally managed to talk to them last week
ƒ Talked to web manager about integration and
interests
Focus Groups
ƒ Technical: Badge and deployment details
ƒ Meta-level: keyword selection, user interaction
issues, services
Agenda/Questions
ƒ Visitors
ƒ Problems they face
ƒ What they want
ƒ What they need
ƒ What they expect
ƒ Badge folks
ƒ What features are needed to support other
research
ƒ What is technically feasible
ƒ C*D office
ƒ Wants, needs, politics…
What We Have…
ƒ List of keywords specified by advisors
ƒ Very low cross-subscription rates
ƒ Lack of context makes most keywords useless
ƒ Trails for very generic interests
ƒ Interest expression
ƒ Research the PLDB, which contains no
associative data
ƒ Ask C*D office to facilitate contact
ƒ “Poll” groups during a visit to find real
interests
Sponsor Interview outcomes
ƒ Fairly informal and opportunistic due to time
constraints and availability
ƒ Different sponsor “ages”, but outcomes uniform
throughout
ƒ Confusion about specific activities of groups
ƒ Long term sponsors will likely have less
knowledgeable representatives present during the
event
ƒ Cynicism about ability of system to direct
successfully
ƒ Multifaceted utility will help acceptance
Sponsors: Relational Aspects
ƒ Envision system to be something like highly
knowledgeable C*D personnel
ƒ However, there was a lack of understanding about
the proactive nature of the system compared to
the normal actions of the C*D office
ƒ May need to see system in action
ƒ Issues of minimum introductory period
ƒ Need to overcome cynicism born from decades of
promises made by AI community (to which this
project will be mentally compared)
Focus Group on Target Description
ƒ Extensive analysis of PLDB entries at syntactic and
semantic levels
ƒ Indicates several issues
ƒ Entries focus of distinctiveness, while this
requires a metric for similarity
ƒ Entries are descriptive, not declarative
ƒ Widespread repurposing of words
ƒ Highly context-dependent usage
ƒ PLDB parsing is basically out
ƒ Lack of semantic association data in PLDB Æ
hard to use for humans
Other Approaches
ƒ Use synonyms for association formation
ƒ Repurposing requires context metric
ƒ Use common sense framework
ƒ Same issue + incorrect impressions from
repurposing
ƒ Use ACM keywords
ƒ Lack of granularity within ML domain of work
ƒ Parse papers for keywords
ƒ We don’t write about all the things that are
important
ƒ C*D office had tried this, to no avail
Chosen approach
ƒ Less draconian than the rigid ACM framework
ƒ Much more draconian than current free-for-all
system
ƒ Allow some limited number of new keywords for
expressing distinctions per group and project
ƒ …
ƒ But require a minimum number of selections from
the preset general keywords
Focus Group on Badge Capabilities
ƒ Badge is no longer a good display platform
ƒ Move display and search functionality from badge
to kiosk network
ƒ Addresses sponsor comment on added functions
ƒ “Find User” feature now works from kiosk
ƒ Upshot: location data makes it easy to track
compliance regardless of vote
ƒ New system for ad-hoc grouping based on
inter-person interaction (Jon Gips)
ƒ But increases stress on the kiosk system
Relational Requirements
ƒ Generally same as before
ƒ Incorporate a natural language agent capable of
explaining “thought process” at final point of
contact (kiosks)
ƒ Trust maintenance is key
ƒ There is a feeling that this problem is
unsolvable
ƒ Incorporate location data for smarter suggestions
that exclude visited groups, which shows a level
of “personal attention”
ƒ Attempt to “hold” attention
ƒ Address person by name: show awareness of
individual