NOTICE: You are viewing a page of the openwetware wiki. Our "dewikify" feature makes a wiki page appear as a normal web page. In April 2017, this feature will GO AWAY and this URL will redirect to the source URL on our wiki. We're sorry for the inconvenience.

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.

Contents

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

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

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

Scientific Credit

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

Backend

Infrastructure

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.
  3. Modify show/hide extension so it works when printing. Even better, allow show/hiding without the extension at all using just css/js.
  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.
  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

Priority 2

Priority 3


Tags

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
  13. Mimulus
  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
  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:

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

Other

--JK

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