OpenWetWare:Software/Feature requests

Please add feature requests/comments to this page. The list is prioritized by the Steering committee. The most important features are implemented by the senior tech developer. See this page for the features currently being implemented.

Information contribution

Top priorities

1. Publish to OpenWetWare button for private wiki's and external wiki's
2. Seeding of user pages upon account creation
3. Auto-generation of lab notebooks

Full list

Tools that encourage contribution of new content / improve existing content

• Hooks for Genbank, SwissProt etc.
  • Initially, this might be just an extension to Biblio to allow referencing by accession number. Eventually, this could pull in info from databases.
  • See also http://blogs.nature.com/wp/nascent/2007/07/scientific_blogging_plugins.html
• Protocols
• Courses
• Lab homepages
• Reviews
  • Conversion of the PLoS One Topaz XML to wiki markup (with references included).
• Lab notebooks
  • A private wiki (or public) wiki that was specially geared to be a lab notebook (include a calendar, etc). I know people have pretty nice private lab notebooks so would be good to get the best practices collected and then have them automatically implemented. A "publish to OWW button" (see below) would allow pages to be moved to OWW when ready.
• Front ends for existing databases (e.g. how biblio interfaces with pubmed)
• Better UI for using biblio
• "Publish to OWW button" - publish from a private OWW wiki to the public OWW site with one click
• Lab backups -- labs should be able to have a backup (independent of the complete backup) of all their lab/specific pages as well as all the files they've uploaded.
• "Tell user about this edit"
  • One of the more annoying things about the wiki is that when I post a reply to someone on a random talk page I don't know for sure that they will notice it. A lot of time I end up emailing them "I replied to your comment, follow this link", just to be sure. Would be nice to include a feature on the edit page that had a box to type in the username of anyone you wanted to get an email telling them about the edit. (would include a link, etc). People could opt out of receiving the emails in the their preferences, and the email itself could explain how -- so don't think it would bother people too much or anything.
  • Something like the Subscribe to Comments plugin for WordPress.
• Tables that aren't horrifying to use.
• Incentive mechanisms:
  • Automatically generated special page gathering best contributions awards ( most visited protocols, most linked protocols, most edited pages, most active users ...)
• Automatic seeding of user pages from information provided at signup.
  • Forms for automatically creating your userpage (e.g. a better 'getting started')
• Document conversion to wiki format
  • Converting_documents_to_mediawiki_markup
  • List of Editing tools on Wikipedia
• Change the comment button to reflect chat style comments.
• WYSIWYG editor
  • Wikiwyg
  • Kupu

  Rich web text editing with Kupu

  • TinyMCE
  • FCKeditor
  • WICK web input completetion kit
  • wikEd is a full-featured in-browser text editor that adds enhanced text processing functions to MediaWiki edit pages. Currently it works only for Firefox and other Mozilla browsers.
  • Xinha Here! is a Firefox extension that opens a Xinha HTML editor in your browser allowing you to edit the data in a WYSIWYG on any website without copying and pasting to secondary HTML editor
• Better collaborative writing tools
  • Tools to enable wiki-Reviews

Information management

Top priorities

1. Notifications to users of relevant changes
2. Tags and categories including personal tagging of pages

Full list

Tools that better organize existing content and make it more valuable to the community

• Content Visualization / Browsing
  • Use of mindmaps to browse OWW content
    • see MediaWiki extension (wikimindmap) based on Open Source project FreeMind.
    • Other MediaWiki extension
    • WikiMindMap.org example on 'Ribosome'.
    • Mind maps would also be a great way to display literature with citations-graph.
• Tags/categories
  • Vincent 13:32, 8 July 2007 (EDT): easier way to add categories to a page (drop-down menus + dedicated text field when editing a page)
  • Vincent 13:32, 8 July 2007 (EDT): ability to define a watchlist/RSS feed based on a 'Category' (or set of Categories)
• Watchlist improvements
  • What my lab members / friends have edited
  • Automatically add every page I've started, or every page that friends have started.
• Better UI for editing the sidebar / very confusing at the moment for new users
• Add protocol to my notebook
  • Could have a button on protocol pages that would automatically put a link to the protocol on a sub-page of the userpage like User:Jasonk/Protocols. This could also automatically add the protocol to the user's watchlist.
• OWW community related information
  • tools to improve networking (friends list, collaborators list, automatic google map showing where the users are)
  • user profile template
• Case sensitivity (Can we turn it off?)
• Way to add more structured data (form for adding protocol)

Publishing

Tools that allow for dissemination of OWW content to other sites / outlets

Top priorities

1. Wiki to Word/PDF converter
2. Move last tiem edited to the top of the page / consider color coding for when it's been edited recently
3. Pligg system for article ranking

Full list

• Publish to Nature Precedings
• DOI - output an OWW page and give it a DOI with one click
• Display a printable version of a subsection of a wiki page. This was suggested by smd on Wiki questions page.
• RSS feed digests
  • So we have the capability to provide RSS feeds of labs or projects (see Endy:Screening plasmid RSS feed.), though it's not especially obvious how to set it up. However with every edit showing up it overwhelms the ol feed reader -- would be nice to provide a daily digest. LifeHacker does this so might be model there on how to implement.
  • Also in general, it would nice to have the feed icon show up on the actual article page, rather than only on the history page (where no one just browsing the site sees it).
• Wiki to PDF converter
  • Reshma 15:11, 23 May 2007 (EDT): At a panel discussion on use of wiki's in education at MIT yesterday, there were several comments from educators that while wiki's were great for collaboration, they aren't great for putting together proper reports. For example, they said that if a group of students start writing stuff up on a wiki, eventually they have to move everything to a Microsoft Word document in order to make a report that was submittable for the class assignment. My guess is that part of this sentiment is psychological ... since the wiki feels like a work in progress, users don't feel as much need to clean up errors and spelling mistakes. And part of this sentiment is the practical problem of it being hard to print out a wiki page and make it look "polished". Right now, since we can compose latex docs on the wiki that look "polished", it shouldn't be very difficult to write an extension that goes from wiki markup direct to a latex-generated PDF. It might be useful to be able to generate a "polished" version of a page.
    • Jason R. Kelly 18:05, 24 May 2007 (EDT): This would be especially valuable for the Reviews section. If you wanted to submit a review periodically for peer-review and publication in traditional journals then it would be nice to be able to dump it straight from the wiki.
• --Johncumbers 14:57, 7 July 2007 (EDT) pligg/digg for OWW cool stuff
• --Johncumbers 14:57, 7 July 2007 (EDT) move the last edited by date to the top of the page, important to see if following a protocol, and more useful to have it here for OWW than for wikipedia, for example.
• --Johncumbers 14:57, 7 July 2007 (EDT) heat map to change color of page/text if edited frequently, again good to know if it's current or past info. (just an idea really)
• Links or buttons to post each page to Digg, del.icio.us or reddit.
  • Would this be useful? It is very common on many news and blog sites.

Scientific Credit

Tools to provide or establish credit for particular ideas or contributions.

• Time stamps
• DOI for page on request
• Searchable histories
• Scoring of contributions to particular pages

Backend

Infrastructure

• User management system - overall works well, but there are some open bugs that need to get sorted out.
• Search
  • wiki search should search the OpenWetWare namespace
  • put Google search box to the left sidebar (this would require developing a new default skin)
  • Google search code: current hack modifies one of the MediaWiki core files, so the changes are lost after upgrade to a new version. It would be nice to create a script that automatically fixes it for new installation by automatically adding in the google code via sed or something of the sort (see admin/mwcreatelinks.sh on the server)
• "View source" instead of "Edit" tab for anonymous users (to be able to read the wiki text)
  • currently only protected pages show "View source"
  • viewing source is possible by appending ?action=raw to the page URL which is not very convenient
• chat
  • currently implemented as a WikiChat extension which works but doesn't scale well with number of simultaneous users
  • one options is Meebo Rooms, see sandbox for demo
• WikiSpeller - spellcheck extension
• MediaWiki 2.0
• Journal impact factor is a measure of importance of scientific journals. Something like this could be used to measure the success of the OpenWetWare?
• Semantic Web
• Wiki data
• MIME types not working for kml/kmz files
  • a simple fix didn't work
  • examples of the problem: http://openwetware.org/wiki/Institutions.kml and http://openwetware.org/images/a/a8/OpenWetWare.kml
• Change owwdump and owwbackup scripts to work with all subwikis, or create a wrapper like admin/update-all-wikis.sh. If you put it into each wiki's images/dumps directory, then the dump will also be protected by the same mechanism as the wiki. Thus all subwikis can get a copy of their own dump.
• Adapt the OpenID client plugin for Wordpress to work with WordPress MU

Old discussions

1. Watch a group of pages (similar to Recentchangesfilter) for even pages that don't exist yet (i.e. all calendar pages) or be able to choose to receive email on changes. Perhaps a calendar specific email notifying system.
2. BC 19:04, 24 April 2006 (EDT): Since you can get the xml link for a google calendar, we could actually just use a google calendar for OWW and embed the xml into a wiki page with some formatting.
3. Ilya 00:40, 9 May 2006 (EDT): Display a printable version of a subsection of a wiki page. This was suggested by smd on Wiki questions page.
4. Najaf 15:00, 15 June 2006 (EDT) Maybe this is the wrong section to mention this, but has the possibility of allowing members to upload software that might be of use to the community been considered? It would be great if groups such as ours could post free/open-source software within openwetware instead of something like SourceForge.net.
5. RS 19:06, 5 July 2006 (EDT): Just came across UniWakka (a scientific wiki) which has these features.
6. Reshma 11:55, 6 September 2006 (EDT): One problem that we're soon going to face with courses is how to archive off the old version of a course. You could just update the course pages every year and rely on the history files for old version, but in the case of courses, it might be nice to have an complete snapshot of the course after it is finished. For instance, move all the BE.109: pages to BE.109/2006:.
   • Austin Che 12:15, 6 September 2006 (EDT): Why not just plan ahead and put everything that might be dated under a page name with a date?
   • Reshma 13:35, 6 September 2006 (EDT): Too late ... I didn't plan ahead and so now I need this feature.
7. Ilya 15:55, 8 February 2007 (EST): from questions page by PaulGrayson - "any lab seriously using openwetware will want to maintain a complete local backup of their contributions, so how about a way to download all of the uploaded files as well? Eventually it might be important for you to make it possible for a lab to get a complete backup of its files with a single click."
8. Ilya 18:20, 19 April 2007 (EDT): (via Jason) auto conversion of PLoS One papers in XML format to wiki
9. Reshma 12:42, 2 June 2007 (EDT): A bot to delete pages marked with the {{deleteme}} template.
   • Austin Che 13:25, 2 June 2007 (EDT): There's deleteBatch.php maintenance script that deletes a lists of pages from a file of page names which I generated via this. Should be easily automated.

Implemented feature requests

1. RS 13:22, 13 March 2006 (EST): Inclusion of content from parts of pages. Currently you can include content from a page into the current page using {{:Page name}}. It would be nice to also be able to include content from a subsection of a page like this {{:Page name#Topic name}}. This may require a software modification rather than an extension (and thus be beyond our capabilities), but I thought I would put the request here anyway.
   • Austin 13:30, 13 March 2006 (EST): Can you give an example where this would be particularly useful? You can always put the subsection into its own page and include it both from the 'content page' and the 'including page.'
   • RS 13:37, 13 March 2006 (EST): Well the case I just encountered was wanting to include {{:Synthetic Biology:Vectors/Single copy plasmid#Layout}} on the Synthetic Biology:Vectors/Wishlist under the pSB5* heading. I could spin out the information to a separate page, but ideally I would like to leave it on the original page and just include it elsewhere.
   • Austin Che 19:26, 5 April 2007 (EDT): You can now do this with the DynamicPageList extension, e.g. {{#dpl:title=Synthetic Biology:Vectors/Wishlist|include=#pSB5*}}.
2. Allow users to add custom links to their sidebar.
   • Austin 15:11, 15 June 2006 (EDT): Implemented at User:Austin/Extensions/UserSidebar
3. Modify show/hide extension so it works when printing. Even better, allow show/hiding without the extension at all using just css/js.
   • Austin 20:44, 18 April 2006 (EDT): Perhaps something like this would be useful for implementing using only css/js: http://www.bobbyvandersluis.com/articles/unobtrusiveshowhide.php
   • Austin Che 13:13, 29 March 2007 (EDT): Done. Implemented as OpenWetWare:Toggle
4. Allow importing of an entire other wiki into OWW. You can dump all pages including revisions of a wiki with dumpBackup.php into a xml file. Ideally, a script should go through and add some prefix to all page names and all the wiki links. Then import into OWW and you have a copy of another wiki under a sub-namespace.
   • Austin 20:41, 18 April 2006 (EDT): Implemented at User:Austin/Extensions/dumpRewrite
5. Dgreenf: Could a "watched" page email you whenever there are changes to that page? This would make it easier to keep up with lab announcements, conferences, etc.
   • Reshma 17:51, 24 October 2006 (EDT): This feature already exists. Simply click on the "my preferences" link at the top right corner of any wiki page and then choose "Email me when a page I'm watching is changed". Note that you have to have email enabled via the wiki for this to work. Let me know if you have any trouble with this.

Please post any ideas you have about OpenWetWare software development here.

Features and priorities

This is the list of prioritized features that came out of the 3-8-06 meeting. They're listed in the order in which George is going to be working on them. Also included are the folks George needs to talk to in order to nail down exactly how the feature is going to work.

Priority 1

• Bulk image upload (Austin)
• Better support for "scientific" markup ie formulae etc (?)
• Easier user account creation (Sri, Jason)
• Ability to make categories invisible (?)
• "Cite this page" support
  • Austin 14:45, 2 May 2006 (EDT): I've installed http://meta.wikimedia.org/wiki/Cite/SpecialCite.php now that we're running MW 1.6. Each page in the toolbox now has a cite this page link (actually only pages in the main namespace).
• Improvements to current support for turning wiki pages into static pages (Austin)

Priority 2

• User-defined sidebar

Priority 3

• More data conversion tools
• Semantic Mediawiki integration
• Support for tagging

Tags

• Using "tags" (similar to sites such as delicious or flikr) so end-users could help categorize protocols with minimal effort. This idea was suggested by Ishan.

Proposed implementation

In thinking about this issue some more, I think Austin might be right. We may want to initially try to use Categories as tags and see how that works. It seems like the easiest thing to do as it requires no new functionality in MediaWiki. It seems that the easiest way to enforce this is to only have a single layer of categories and no subcategories. We could also avoid tags like E. coli protocol. For example, the page Preparing electrocompetent cells would get tagged with Category:Escherichia coli and Category:Protocol so that it would fall under both categories. This would enable users to collect together pages in different groupings. Someone viewing the category Escherichia coli would see equipment pages, protocol pages, material pages, and information pages. I think for our purposes, this might be a more useful application of categories. This would also have the advantage that some pages whose categorization is ambiguous could be labelled with multiple tags. For example, Miniprep could be tagged with Category:DNA and Category:Escherichia coli and Category:Protocol.

Some useful categories off the top of my head (please edit)

1. OpenWetWare
   • for community related pages
2. Protocol
3. Equipment
4. Material
5. In vivo
6. In vitro
7. In silico
8. DNA
9. RNA
10. Protein
11. Escherichia coli
    • and one for every other species
12. Reference
    • For information resources like listings of online tools and the genotypes pages.
13. Mimulus
    • and one for every research area (like Synthetic Biology)
14. Course
    • to indicate class-related pages
15. BE.109
    • to indicate pages related to a certain course
    • note that BE.109 should not be a subcategory of course because there might be pages that are useful for BE.109 and thus tagged as BE.109 that are not actually true Course pages.
16. Organization
    • to indicate pages that are maintained by a certain organization
17. ICSB SC
    • and one for every other organization (like BE Board and SfGS)
18. MIT
    • and one for every other institution
19. Wittrup
    • and one for every other lab
20. Microfluidics
21. Flow cytometry
22. Microscopy
23. Measurement
    • would something like this be useful for collating measurement methodologies? I'm not sure
24. Safety
25. Quality/data management categories (to dynamically generate to-do lists)
    • Needs attention
    • Needs formatting
    • Needs content
    • Needs categorization
    • Great page

Later, if this scheme proves useful and maintainable, we could consider trying to customizing the mediawiki software further by renaming Categories to Tags.

Such an approach may also help the generation of tailored Special:Recentchanges pages.

--RS

I really like this idea, though I am concerned about the implementation and usefulness to the user. Just for clarification I'm going to call what you've descibed above "categories" and make a distinction between that and "tags." In tagging a user has a set of labels that are specific to them, so they can create a categorization scheme that is most useful to them personally. For instance, I may want to tag only the e.coli protocols I actualy use as "E.Coli" and then I can click on that tag and bring up my personal list of favorite e.coli protocols. just to be clear, this is different from categorizing in that I only bring up things I have labeled, not every protocol categorized as "E.Coli". The reason I like this better is that I think it will be more useful to the user, and as a result, the user will be more inclined to bother categorizing things (in other words, I think it scales better).

OK, so tags may be more useful to the user, but what about generating protocol pages for the larger community to browse through? Its clear how the categories scheme allows dynamic generation of protocols pages, i.e. if Category = E.Coli and Category = Protocol then include a link in the E.coli protocols page. Well, tags enable something similar (and perhaps better), they can aggregate all the tags associated with a page and look at the most popular tag and assign the page under that label on the main protocols page. Or more complicated things like creating heirarchical categories simply by clustering the tags on pages, see Flikr's biology clusters as an example. The big downside to using tags in my opinion is that it will require some serious changes to the software to implement them in a way that is convenient for the user. --JK

Also, it's worth noting that since each article has its own URL, we could do this in the framework of existing tagging sites such as del.icio.us -- could at least be a way to easily explore if this whole thing is useful anyway.

There has been a some discussion about implementing tags for wikipedia, so maybe we could get some development help?

I like the tag idea a lot but until we find a nice way of implementing it within OWW, I think the usefulness of categories merits implementing them.--BC 17:49, 22 February 2006 (EST)

Semantic MediaWiki extension seems to accomplish a lot of this:

• Semantic MediaWiki
• Semantic Wiki
• Live demo 1 and live demo 2

--Ilya 13:31, 26 April 2006 (EDT)

Other

• Discussion boards similar to these found on the Fluwiki site. Actually, there are a number of cool things on the Fluwiki site that might be worth implementing:
  • Better RSS feeds
  • Easily changeable site viewing options.

--JK

• Multiple image upload (or upload of a directory of images).
  • This would be very desirable. There are some posts on the mediawiki message boards saying that this is on the list of things to do so maybe this could be done in collaboration with the mediawiki community?
• Tailored Special:Recentchanges viewing so that you could look at all the recent changes associated with a particular namespace like BE.109 or Synthetic Biology or the Mimulus Community. It helps new users track those changes that they care about more easily.
  • Austin 15:48, 26 April 2006 (EDT): Done
• Ilya 01:06, 2 May 2006 (EDT): WikiMedia announced software development ideas for the Google Summer of Code 2006.
• Bookmarklets --Ilya 16:00, 5 February 2007 (EST) (via John)
• Wildcard search --Ilya 13:26, 6 February 2007 (EST) (via John)

Criteria for prioritizing features

1. Front end/Back end
2. Impact to the user experience on OWW.
3. Likelihood of increasing contribution or new users
4. Alignment with Mission of OpenWetWare
5. Open Science proof of principle
6. Indirect benefits to other users on OWW