Content - views

[Avsecz]

Regarding content: I think we should have 2 views:

Model list view

URL: /

• lists all the models in a table
  • table should have a search function - https://datatables.net/
  • columns of the table would be similar to the output of kipoi.list_models() python-sdk.ipynb

It would be also nice to have the models represented in a hirearchical directory-like structure.

Single model view

URL: /models/<model_path>

The following information should be shown in individual <div> blocks:

1. Shows the information about the model.
   • closely resembles the model.yaml file
   • link to the github folder
   • maybe show model the number of model downloads
   • everything that can have a URL should have it (like other web pages, paper DOI or user's github username)
2. README.md of the model
3. Nicely rendered dataloader.yaml
4. Small code snippet of how to use it in bash or python (with button - copy to clipboard)
   • kipoi predict <model> --source=kipoi ...
5. Comments (maybe require a github account to comment)

• https://disqus.com

6. Twitter feed (content related to the model)

• as on https://www.biorxiv.org/content/early/2017/12/19/171827

Comments

krrome's comment

Thanks @Avsecz I don't have much to add to that.. My thoughts:

• A nice short introduction into what Kipoi is / what the aims are and what we think it should be used for. with a very simple flow chart
• The serchable model overview table sounds great.
• in the single model view:
• Again, I agree with Ziga, plus:
• we should have only one model on the page and not concatenate the detailed views of all models.
• how about we generate (at least) most of the CLI commands for the respective model so that people can just click "copy to clipboard" and that's all they have to do run things.

Download tracker:

• How can we keep track of model downloads? We would need to add that to the model API and have a database somewhere where we can dump that info... Alternative to the DB we could have a simple REST backend on the web server that saves download stats in a file..

Avsecz's comment:

Agree.

Download tracker: I don't know yet how, but a request call to the webserver for every "model pull" sounds like a great idea. We can setup a simple Flask REST API with Mongo backend.

[zupan]

Majority of the requirements are already finished, but because there are some things left, I'm keeping this issue open with the attached checklist:

• Link to the paper DOI (GitHub usernames and emails are already rendered)
• Model Readme.md (Do we really want it, even if we link to it?)
• Comments
• Twitter feed (though I would have it only in the view with the model list. I think that model description will be too cluttered otherwise)
• Code snippet for the models (@Avsecz I would need that code example)

[Avsecz]

looks all good to me. we don't need the model readme.md for now