Design meeting report
By Ed Mitchell 12th December 2011
Having established the high level principles in communications and design, the Project Sharing Engine project is breaking out into its consituent working parts to answer the various questions arising. There are some high level decisions being made this week which we will report on in due course, you can see them emerging in the notes below.
This is the meeting report from the Transition Technologist design meeting to break the project down or you can read it on the project wiki.
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)
3. 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
ii. 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
4. 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!
5. 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)