Scratchpad development planning 2011-1-10

The following notes were taken by Simon rycroft. Please add your own notes, and make comments inline (signing them if necessary).

Present:

 * Edward Baker
 * Simon Rycroft
 * Ben Scott

Meeting plan
We tried to talk over the following key areas:
 * Current modules
 * Theme
 * Additional functions for Scratchpads 2.0
 * Time plan
 * Information architecture (schemas/data structure)
 * Workflows

Discussed

 * We need to ascertain what the Scratchpads can currently do. What functions currently work well, and what functions are too complicated for any of our users to understand.
 * What workflows do we currently provide? What workflows would be useful with the current provided content types?
 * Can there be different workflows for biological classifications & normal taxonomy terms. Ben 17:33, 12 January 2011 (UTC) Can they be called tags to create a clear distinction?
 * Identify duplication is functionality - for example there are multiple maps / location methods on the site. This should be reduced to one.
 * We should allow maintainers of sites to enable/disable features to keep the sites as simple as possible for each use case.
 * Taxonomy extensions could be a feature to disable on specific sites that do not need it (this could greatly simplify some sites).
 * Species/Taxon pages
 * Could the iSpecies widgets be curated on one single site/proxy, meaning that multiple sites will benefit from the curation performed on a single site? Note, the interface for this could make it appear that everything is being done on each site, and not on a single central site.
 * Problem: if one maintainer hides an item, but another site wants it. Is there a better way of doing this - using flickr tags? Only using scientific data sources so the data is of a higher standard.
 * Only enable the production of "Custom widgets" on specific sites, and not by default.
 * How can we display the "Custom widgets"? The design would be better if every widget was the same width.
 * External widgets should display the logo of the data source.
 * When adding a widget, users need to be able to preview it before adding it to the page.
 * See Widgets for an idea on widget functionality.
 * Theme
 * We want to only keep the left sidebar, and where possible, keep it as clean, simple, and small as possible. Too many sites currently have far too many links in both left and right sidebars.
 * Limit the items that can be displayed in the LHS. Only allow menus & classification blocks.
 * If we have one main menu, LHS navigation can be based upon the section user is in.
 * It was agreed that we all liked the BBC website, and that design inspiration could be taken from that - especially for the way the widget interface could work. We should also come up with a list of other sites that we like - List of website designs we like
 * Having a slide down admin menu at the top could work well. For example, the content add menu could be moved here.
 * The "About this site" page was discussed, particularly how we can simplify its addition and linking of content to it. This led on to:
 * The concept of a "Page" was discussed (not to be confused with the Drupal content type "Page"), and specifically how we can link all output to it.
 * Pages can be:
 * Content types that are not primarily atomised data, e.g. Blog posts, Pages, Possibly forum topics, News items, Galleries
 * Reports (produced by Drupal views)
 * Taxon pages (produced by either Mado, Panels, Views, or a new module)
 * Automatic creation of menu items. Pages would always be created as children of the page that is currently being viewed.  Advanced users will be able to tweak this.  This will help to ensure that all pages are in a menu, and therefore findable.
 * We will be able to view "Orphaned content", which will be nodes that are not associated with a Page, and therefore may not be findable. Note, most data nodes (Specimens, Locations, Images may fall initially into this category).
 * Specimen, Biblio and other content types could have their own default Pages to ensure that even data content types are findable. The links to these would be primary links, and would only be made visible to Anonymous users once there is data to view (links would be visible to logged in users, and the pages would contain a message explaining how to add content, to help remind them to add data to the site).
 * Specific pages will produce additional sidebar or topbar navigation to the pages related to them (most likely child pages).
 * A "My Data" page or subsection of the site will allow users to quickly and easily find data nodes (Specimens, Locations, etc).
 * The idea of linking nodes to nodes was discussed.
 * We need to identify the key relationships that different content types will require (e.g. Specimens -> Images of the specimen). This will allow us to ensure that the user interface for linking content types in specific relationships will be as slick as possible.  We will however allow users to link any content type to any content type - Ben Scott expressed his reservations about this, which were duly noted. Ben 17:21, 12 January 2011 (UTC) My reservation was having an interface for linking any content to any other content. If we identify where these internode relationships are necessary and have them part of a simple workflow, I think this'll work well.
 * We should be using Daphne Duin for the requirements capture.
 * Functional additions were mentioned in brief:
 * APIs
 * RDFa
 * HTML5
 * Can there be default pages added?
 * About us / Contact us / Sitemap
 * Video
 * Can we provide video as part of 2.0. In what format - FLASH, HTML 5, Both? What does youtube do? --Edward baker 10:01, 14 January 2011 (UTC) There was a guy when I was in Illinois who was interested in audio too (useful for birds, grasshoppers, etc) - so perhaps a generic media solution would be a good idea.
 * Development methodology
 * Wherever possible modules & themes will be written which can be released to Drupal.org - which will then be used & tested by the DO community. Where we have very specific requirements, sub modules will be written to tweak these contributed modules. Ben 17:33, 12 January 2011 (UTC) It might be a good idea when we're developing this to identify & write the releasable modules first & tweak them later - get as much external testing time as possible.
 * Pages should wireframed & designed prior to build.

Simon Rycroft

 * Make a list the current Scratchpad modules, including the following details:
 * Estimate of time taken to upgrade
 * Whether the module is purely backend and can therefore be upgraded ASAP
 * Who is responsible for the upgrade
 * Gather current workflows from the current Scratchpads
 * Investigate/arrange requirements capture with NHM scientists

Next meeting
Due to ViBRANT's opening meeting, the next development meeting is scheduled for 2010-01-24.