Sharing Engine/Design Meeting 1

Ttech group skype: PSE design meeting Tuesday 6th December, 22:00 UK time, Wednesday 7thDecember, 09:00 AUS time Attendees: Laura Whitehead Jim Kirkpatrick Ed Mitchell

Meeting purpose: - agree design elements and process for stage 1a

ACTIONS:

• ALL: start using tickets in TRAC - set up tickets for your actions here
• JK: Define project item IA
• JK: read Paul Mackay's stuff about the IA
• EM: contact Paul Mackay about IA and web standard IA for project items
• EM: share project definition for feedback with CoP/TN
• EM: put together CoP update for CoP and blog
• EM: finish budget report
• EM: start and finish funders report
• ALL - started by JK: workflow for webmaster widget set up and embedding
• ALL - started by LW (?): workflow for project item entry workflow
• LW: wireframes for widget display options
• LW: wireframes for item entry
• LW/JK: widget module re-writing requirements to be defined to enable us to do stuff
• LW/JK: discuss technology used to run initiative website overlay for entry process
• LW: consider ways to enhance project item find-ability (related to IA and entry)
• EM: write project item moderation workflow

NEXT MEETING:

• Topic: Design status meeting
• Date and time: Tuesday 20th December, 20:00 UK time, Wednesday 21st December 07:00 Aus time

AGENDA:

All had read Jim's 'process and behaviour summary' doc, also seen here:

http://www.transitionnetwork.org/blogs/ed-mitchell/2011-12/pre-design-phase-technical-meeting-report

AGREED: all principles in the doc

Project high level structure broken into these elements:

1. Information Architecture: 'Project' item definition and relationships to other data elements in the TN system and on the web
2. Widget set up: webmaster process and requirements for widget generation and embedding on participating site
3. Item Display: Widget and items on participating websites, project items on TN website
4. Item Entry: Widget set-up, submission workflow, process and related forms on participating websites
5. Moderation: content process and presentation, roles involved
6. Infrastructure: TN website and services, databases, trasnport etc.

NOTES BY PROJECT ELEMENT:

1. Information Architecture for project item:

a. Strategy

• i. No clear boundary between what is and what isn't a TT project, much discussion in CoP meeting with many examples of opaque-ness. To date, we have assumed the projects submitted on TN.org are TT projects, and approved. As we open this up to the web with the widgets, we need a more granular definition to reflect the wider reach afforded by the PSE - therefore:
• ii. Allow any projects to be submitted and make TT projects differentiated from 'other' projects
• iii. Keep flexible and open and inclusive
• iv. Use the data related to the widget to associate a submitted project to an initiative, and ask the user if it is a TT project
• v. Give the webmasters the responsibility to easily 'approve' a project, raising its status in the system from 'pre-approved' (see 1.c.ii)
• vi. Minimise webmasters' workload to approve an item with a simple workflow and no editing requirement (much like spam checking comments in Wordpress)

b. Definition of 'what is a Transition project for the Sharing Engine project?'

• i. Any project can be added to the Transition Network Projects Sharing Engine via widgets on participating websites. Participating websites have to be registered as Initiative Websites on the Transition Network Initiatives Directory. But anyone can add a project through these widgets. And not all of those projects have to be 'Transition Projects'. Therefore the person submitting their project information via a widget on an initiative website will be asked to identify whether the project is directly related to that Transition Initiative or not with a simple check box. This will set a 'flag' on the project item, and those that are specifically related to Transition Initiatives will be identified as 'Transition Projects', those that are not will be seen as 'Other'. This flag can be reset by the submitter, initiative webmaster, or Transition administrator at a later date.

c. Project item definition

• i. start with very minimal, core, or slimline data item that can be expanded upon at a later date in the project and/or the user experience
• ii. work done to date by Jim as starting point: a 'slimline' or 'core' item: quick and easy to add, minimal detail as follows: - minimal amount of required information to minimise waffle and moderate-able info
• - include some form of web standard vocabulary/ISO/something we can share with others (e.g. Project Dirt, Transition Drupal, GEN database, Wiser Earth)
• - item status to represent 'approved', 'pre-approved', 'transition', 'other' project item statuses (see moderation points below)

2. Widget set up by webmaster

a. Requirements

• i. participating website must be an entry in a registered Transition Initiative in the Initiatives Directory
• ii. with TI information, we have location and webmaster email address for widget pre-population and moderation workflow
• iii. widget needs unique id and to be tracked

b. Workflow

• i. needs to be defined

c. Widget choice

• i. see 3.a below

3. Display (of project item):

a. Widget options on initiative websites

• i. basic: latest projects - as stands now
• ii. interactive widget: tabs to enable search by theme, location, other
• iii. interactive page: bigger one to match a website page size to be added as separate page in initiative website

b. On TN.org

• i. in TN projects directory, different types of project item to visually defined as per 1.c.iii as above

c. Find-ability of projects in directory and on widget

• i. currently by theme with tagging, but theme a bit blunt, and tags not visible - need enhancement
• ii. needs to be more user-friendly on TN.org
• iii. will relate to IA (1.c)

4. Entry (of project item):

a. Starts with a big clear button on the widget, which opens an overlay over participating website

b. Design

• i. clear and carefully though through workflow to ease addition
• ii. use this work to enhance TN.org simultaneously
• iii. use TN.org design in elegant iFrame overlay on participating website

c. Technology

• i. use overlay on participating website to avoid issue of trying to fit into an infinite number of design varieties
• ii. widget module needs re-writing to enable some of our stuff
• iii. authentication remains an open issue
• iv. more

5. Moderation (of project item):

a. Principles

• i. post-moderated
• ii. appears immediately on widget and on TN.org
• iii. Presentation rules to reflect item status as per 1.c in the IA
• iv. webmaster seen as responsible for items from their sites as they would their comments
• v. keep item information slimline to avoid webmasters having to do edits or getting into wrangles with submitters

b. Workflow

• i. to be defined and shared!

6. Infrastructure

a. Satellite vs Monolith

• i. as per Jim's doc
• ii. to be held in Jim's head while design stage (1a) is underway
• iii. currently looking at a Satellite format to avoid swamping TN.org and other good reasons
• iv. currently no budget for setting up VS style 'satellite' service would be covered by the 'website maintenance' budget stream from Nominet Trust which is being shared by Ed with Laura for general site maintenance (on which the PSE rests)