Scoping

[jvwong]

Requirements {#requirements}

• Data source: The system should draw preprint article data from
  • bioRxiv (Statistics 2020 - present)
    • New papers added: 3000 / month (100/day)
    • Abstract views: ~7 million / month
    • Full-text views: ~1.5 million / month
    • PDF downloads: ~2.8 million / month
  • medRxiv (Statistics 2020 - present)
    • New papers added: 1000 / month (33/day)
    • Abstract views: ~6 million / month
    • Full-text views: ~600 000 / month
    • PDF downloads: ~1.5 million / month
• ^§Data retrieval: The system should fetch data from
  • HTTP web services
    • By specifying the number (N) of most recent posts
    • By specifying a date range (start/end date)
  • On a regular schedule, in order to retrieve articles posted
    • Less than a day
    • Less than a week
  • Paged by cursor value
• Article index: The system should, on a per article basis
  • capture
    • in an index: title, authors, abstract
  • analyze text to recognize [optional]
    • organism [REACH, PubTator, …]
  • store
    • all of the above
    • doi, category (aka ‘Subject Areas’), date (as object), published (“NA”, doi), version
    • type (aka article categories): ​​New Results, Confirmatory Results, Contradictory Results
• Input: The system should
  • accept as input
    • free text
  • identify spelling errors
    • applying a common English dictionary
• Feed: The system should present the collection
  • as a feed of summaries
  • in a context-sensitive fashion
    • set
      • all: no input (default)
      • subset: with a query
    • chronologically
      • ordered in descending fashion
      • with relative timestamps and/or groupings
        • hours ago; yesterday; days ago; this week
• Summary: The system should present an
  • article metadata
    • title
  • links
    • to bioRxiv (latest) version
    • of published version, date [unlikely]
  • hints from per-article text analysis
    • organism
    • …
• Filter: The system should
  • Match articles by input token, precisely
    • as typed or spell-corrected
  • Prioritize items by
    • match relevance
    • date (default)
  • Retrieve collections in real-time
    • so filtering is
      • dynamic, comes back in real-time
      • iterative
      • feedback-driven
        • based on subset of collection
    • enabling
      • reduction
        • too many results
        • irrelevant results
      • expansion when too few results

Mockups

[jvwong]

• Notes from meeting today
  • Time
    • Really, the notion that something is recent is more important than exact or even relative dates
  • Repeated information
    • Showing duplicates has been observed as a problem
    • e.g. biorxiv versions
  • Focusing on key entities
    • How can we support more accurate filtering on organisms, diseases, medications, genes....
    • Idea: Work on pre-processing articles so as to improve the summary of an article
      • Organism, disease in article are tagged (e.g. REACH)
      • Other entities: Becomes difficult because now we're doing semantic mapping
  • How did I get here
    • Being clear, explicit about how a filter result was identified
    • avoid the 'I can't remember how I found something I saw'
  • What about PubMed data?
    • Lots of PubMed articles aren't included in bio/medRxiv or out of scope
    • Note that however, most bioRxiv go on to be published
  • Feedback / Feed-in from Biofactoid
    • How does this complement Biofactoid contributions
    • Idea: Highlight Biofactoid articles in feed, rich metadata (e.g. google) compared to simple article item

[maxkfranz]

• Value: Feed of all relevant articles v.s. feed of many relevant articles
• Frequency of updates & resultant feed length is important
  • Affects user visit frequency
  • Trade-off with number of results

[jvwong]

Switching gears to a 'Topic'-based feed as discussed here.

On Initial load:

Following selection of a particular topic:

[maxkfranz]

Great

Notes:

1. For the initial version, we need to ruthlessly simplify.
2. The sidebar on the left is really useful for an unrestricted search. Since we're focussing on fixed searches/topics for the first version, it would make sense to punt the sidebar for now and log it for future.
3. The initial load page doesn't need to show all the articles anymore. Showing all articles is useful for unrestricted search so that the user has a 'filter' mental model. For curated topics, the filter model doesn't matter. We could use the space to show a grid of all topics, with nice images to represent each topic -- like Apple Music does for genres.
4. The red, numbered dot is a good signifier for unread articles in categories, since it's familiar from mobile. For the particular topics/diseases that you aren't interested in -- most of them -- the red dots are noisy. Showing them only for hearted/subscribed topics may be more fitting.
5. Granularity of 'unread' status is important. We should show a blue dot next to unread articles.
6. The second screen, for topics, should have something like '< Back to topics' at the top of the screen. Or maybe breadcrumbs, like 'Topics > Obesity'. The user needs to be able to get back to the full list of topics to choose a different one.

[jvwong]

Another round...

Home

Content view

[maxkfranz]

Great. I think this is scoped out well enough for the next discussion call.

Some discussion points:

• Feasibility of some features (e.g. organism icons)
• Discussing the details of the next iteration of the design
  • Iconographic disease banners
  • Click v.s. scroll
  • First-time users on the first page (disease selection)
• Others...