OpenWetWare:Software/Ideas

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 (?)
• 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)

User management

To do:

• Reject and Approve boxes should be radio buttons - these are mutually exclusive actions. Approve should be selected by default. --Ilya 14:04, 26 April 2006 (EDT)
  • George 14:21, 26 April 2006 (EDT): Agreed.
• E-mail dropdown box should be logically connected to Reject and Approve actions (we don't want to send a reject email to someone we gave account to and vice versa), or eliminated altogether - a simple button to edit email text should be enough. --Ilya 14:04, 26 April 2006 (EDT)
  • George 14:21, 26 April 2006 (EDT): Sri has mentioned having an option that allows you to edit an email as well as not to send one. I'll throw in some javascript to automatically select the template based on the decision but other options, like selecting a different template altogether, should still be available.
• Austin 10:31, 26 April 2006 (EDT): Who has permission to access the user management pages?
  • George 15:15, 26 April 2006 (EDT): That's up to you. Easiest thing would be to place a password on the directory.
  • Austin 15:47, 26 April 2006 (EDT): It would be nicer to have it integrated with OWW users and into MediaWiki. So if you either hook in and write an extension like special page for mediawiki or just grab appropriate credentials from where ever mediawiki does, then it would be possible to check if the person has sysop privileges (as any sysop can create accounts anyway).
  • George 16:05, 26 April 2006 (EDT): Sounds good, I'll work on that after getting the other things fixed up.
  • Sri Kosuri 22:47, 26 April 2006 (EDT):I don't think this is a good idea for a couple of reasons. First, I have been encouraging George to keep it as independent from altering the wiki code as possible. The less hooks there are to the mediawiki code, the less we have to maintain. Second, for now at least, I'm not sure it makes sense to give all sysops the ability to add other users... especially if it becomes really easy in general to add users. I like the ability to control a new user's first experience by telling them to go the getting started site (et cetera).
  • George 06:23, 27 April 2006 (EDT): This option could be implemented as part of the UMS without affecting wiki but it's up to you if you want to have it.
• Austin 10:31, 26 April 2006 (EDT): The email sent on approve/reject contains a mime part of text/plain which contains HTML which really is annoying to read in my mail client. Either eliminate the text part so that my client forces HTML or much more preferred, eliminate the HTML part and ensure that the email only contains text.
  • George 15:15, 26 April 2006 (EDT): Forcing HTML is probably not a good idea, I'll strip the text of all formatting for the plain text version. Thanks for bringing this up.
• Austin 21:46, 26 April 2006 (EDT): Not sure if /um.php is supposed to go anywhere (when clicking on logo)
  • George 06:17, 27 April 2006 (EDT): The link should point to "um.php" not "/um.php". I'll change that with the next update.
• Austin 21:46, 26 April 2006 (EDT): It would probably make most sense to have the default screen show all user's full info by default (or have a button to show all/hide all).
  • Sri Kosuri 22:47, 26 April 2006 (EDT): I don't agree. I like it the way it is.
  • George 06:17, 27 April 2006 (EDT): I don't think showing full profiles by default is very convenient if you have a lot of requests. I'll add show/hide all link but keep them hidden by default. This kind of speculation is better solved once the system has actually been used I think. We'll see what will be easier.
• Sri Kosuri 22:47, 26 April 2006 (EDT): George, can we make it such that the admin email also gets a copy of the application. This is in case this software ever goes down, we have a backup to accounts that were possibly not added.
  • George 06:17, 27 April 2006 (EDT): Yep. The request that is stored in the UMS database is currently not deleted after being approved or rejected, its status is just changed such that it doesn't show up in the pending requests anymore. That gives another backup source if something happens to the wiki db. But e-mailing the details is also good in case it never makes it to the database.

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