The document provides an update on the Project Group PUSHPIN. It summarizes that some members have left while others have been removed due to poor work quality, leaving 11 students remaining. It also outlines the goals of being self-organizing, having clear roles and responsibilities, and following industry best practices. Finally, it describes the purpose of the meeting as getting a description of the customer's general idea so work can be shifted to the group.

1. Project Group PUSHPIN
Idea description
16.02.2012
Wolfgang Reinhardt & Tobias Varlemann

2. Update on members
some left
some have been extracted based on insufficient quality of their work
11 students remaining
Amit, Vitali, Pranav, Ksenia, Sharath, Wilfred, Jan, Junaid, Pragati, Muneeb,
Kaleem

3. Goals of a project group (reminder)
self-organization to the greatest extent
systematic assignment of roles and responsibilities
process oriented personnel placement like in industry
regular presentations of work progress
creation of interim and final reports
working on the edge of science
typically 20+ hours per
creating new value as software products week during
implementation phase

4. Purpose of this meeting
Description of the general idea that we (as customers) have
shifting work from us to you
now
it’s
your
turn

5. Overall architecture (very abstract)
Mobile
Web Application Multi-touch table
Application
Analytics core
different analyzers, databases, application logic
Hadoop Cluster

6. Architecture requirements
modular development
reusable components
capability of working with different input formats
data access via secured web services / APIs
Hadoop backend, map/reduce paradigm for solving problems
reusing existing algorithms
adapting and improving them when needed
follow best practices / industry standards

7. Analytics core
download papers (Mendeley, APIs)
extract papers (zip files)
gather papers (uploaded BibTeX files)
analyze their content
PDF2Text, Language detection, POS, Lemmatize, header-footer-removal, number
removal, clustering, similarity detection, plagiarism detection a.m.m.
see the idea description document
reuse components from Tobias’ master thesis & open source software

8. Web application
will be the most used interface to PUSHPIN
sign-up & sign-in
edit user profiles
connect social media accounts
follow other people
activity streams (user, affiliation, research domain, topic, tag)
upload papers
tagging, bookmarking, liking of objects

9. Web application II
visualizations
networks
metrics
graphs
side-by-side comparison of objects
plagiarism visualization
visual recommendation rationale
faceted full-text search
annotated search results, “find similar”

10. Mobile application
access to the PUSHPIN data
share user profile (digital business card)
find researchers nearby
access your publications
share them
authentication at multi-touch table

11. Multi-touch table application
different authentication methods
large scale-visualizations
find yourself in the network
compare documents / researchers
explore similarity between objects
see maps of affiliations, cooperation networks
send files from mobile to table and vice versa

12. Intended work organization
Wolfgang(
Reinhardt(
Customer(
Tobias( Johannes(
Varlemann( Magenheim(
Development(manager( Consultant(
N.N.(
Junior(Project(Leader(
N.N( N.N.( N.N.( N.N.( N.N.(
Text(Processing(PO( Recommendations(PO( Visual(Analytics(PO( Web(application(PO( Multitouch(PO(

13. User stories
Ben is a researcher at the University of Maryland. He has heard of the
PUSHPIN system and wants to explore its functionalities. Ben navigates to
the PUSHPIN web application and signs up for an account using an OAuth
with his Mendeley account. Ben fills in some basic questions about his
research interests, his social media handles and his affiliation while the
PUSHPIN system grabs Ben’s publications from Mendeley in the
background. Ben surfs the PUSHPIN application and finds the profile of Tom
who is working at the Hong Kong University. As Tom is researcher in a very
similar research domain and they have met before, Ben starts following Tom
on PUSHPIN. Tom receives a notification mail telling him that Ben is now
following him and he decides to follow him back. After Ben’s publications
have been analyzed by the PUSHPIN infrastructure, Ben receives first

14. User stories
Ben is a researcher at the University of Maryland. He has heard of the
PUSHPIN system and wants to explore its functionalities. Ben navigates to
the PUSHPIN web application and signs up for an account using an OAuth
with his Mendeley account. Ben fills in some basic questions about his
research interests, his social media handles and his affiliation while the
PUSHPIN system grabs Ben’s publications from Mendeley in the
background. Ben surfs the PUSHPIN application and finds the profile of Tom
who is working at the Hong Kong University. As Tom is researcher in a very
similar research domain and they have met before, Ben starts following
Tom on PUSHPIN. Tom receives a notification mail telling him that Ben is
now following him and he decides to follow him back. After Ben’s
publications have been analyzed by the PUSHPIN infrastructure, Ben

15. Feature descriptions
Connextra format
In order to < business value >
As a < role >
I want to < feature >
forces you to think of WHY you want that feature
in FDD you implement certain features in an iteration (only what is necessary for
that feature)

16. Mockups
create Mockups for your applications
core UI elements
user flow (when the user clicks here, then ...)
link to user stories and feature descriptions (at least one mockup for each feature)
use whatever tool you want to use
Balsamiq Mockups / Microsoft Visio / amm
http://speckyboy.com/2011/02/23/10-completely-free-wireframing-and-
mockup-tools/

17. Next steps
read the written idea description
https://trac.cs.upb.de/pgpushpin/wiki/IdeaDescription
sit down together and discuss the idea
if you have questions mail us
use the trac
prepare discussion items for the next meeting
system for doing
derive requirements on the architecture that
derive feature descriptions
develop more user stories
derive modules of the architecture and apps that you’ll have to implement

18. Next steps II
Wed, 22.02.
ask the customer
present user stories and requirements
further develop features, user stories and requirements
Thu, 23.02.
ask the customer
Wed, 29.02.
ask the customer, present results

19. Next steps III
Thu, 01.03.
show first prototypes
sequence diagrams
preliminary architecture
how and where to store information
finalize responsibilities
starting shoot for the real implementation phase

20. wolfgang reinhardt university of paderborn
social media sna
twitter recommendations
awareness
research networks
bibliometrics
artefact-actor-networks
ginkgo
research 2.0
www.isitjustme.de www.ginkgosem.com
@wollepb @wollepb @wolfgang.reinhardt
@wollepb @wollepb @wolfgang.reinhardt
@wollepb @wollepb @wollepb