Coco meeting #3, 02-10-2015
Present: Doug W (Minutes), Raphael F (Mission and Vision), Raphael W (Development), Martin S (User Needs), Sara P (Design).
Apologies: none
[Meeting begins 15:45]
RF: Presents 'Pages' mockup for shops, NGOs, businesses, etc. It would support comments, 'stars' + reviews, hearts (instead of 'likes'), photos, connections (e.g.. you → your mum → the store), etc.
MS: Discusses 'Events'. When looking for people to participate in events, there should be a feature to 'assess character' (i.e. reliability, etc.). Begins subject of user trust. In FoodSharing there currently exists the 'trust-banana' system, presents trust metrics mockup.
- RF: A 'vouch' (personal review) would be higher than a 'star' (simple feedback for food baskets.)
- MS: Although 'stars' seems harsh (i.e. a member could be 'two-star-quality'), previous FoodSharing experience suggests it is necessary (as people being unreliable has proved problematic). Presents a proposed 'trust algorithm' – which could include 'gives', 'receives', 'reliability', 'stars', etc. A combined value could be calculated.These measurements and calculations could be used to filter when searching (e.g.'my basket only available for members with a minimum of 80 % reliability')
- RF: Confirms that reliability has been a known issue for FoodSharing so far.
- SP: How would reliability be calculated?
- RF: Calculations of both giving and receiving... precisely how still being discussed.
- MS: Platform relies on trust and user metrics are important, hence the platform should provide appropriate prompts for feedback. Having 'connections' visible on profile can provide evidence the profile represents a real person. Have user metrics view-able on profile?
- RF: Thoughts about icon: should be humanistic. For example; 'sharing' could be two hands holding, 'receiving' could be a hand receiving a heart and 'giving' could be a hand releasing a heart. A clock could represent reliability. Presented the use of 'spider diagrams' to present different user metrics (such as reliability, gives, etc)
- RW: Spider diagrams and user metrics could make things 'game-y' and induceunwanted competition.
- MS: Suggested a neutral 'trust-o-meter' which always returns to neutral ('OK') with time. Prevents your mistakes from following you for the rest of your account history. Eases entry for new users.
RF: Personal wall could contain personal interactions like 'giving' or 'receiving', personal connections as well as comments and photos, etc.
- MS: Wall/profile would also show communities and groups that that person is a member of.
- RF: Wall could have preferences about what is displayed.
- MS: Personal feed on a wall – 'like-able' or not?
[Discussion]
MS: Starts talking about communities and groups...
- SP: Has to regularly explain the difference to others – perhaps use clearer names?
- MS: Groups are any group of members, communities have 'food-sharing' rights and are more structured – perhaps connected to a page. Groups are looser and interest related people can form them as they like.
- RW: Doesn't want to make things so complicated for the user (in terms of pages, communities, groups, etc, etc). However, the differences aren't so hard technically.
- MS: Whatever the term, a 'groups' purpose should be immediately obvious.
- SP: Thinks it's complicated to have both. Perhaps better not to have any user create a community?
- RF: No, any user could create a group or community.
- RW: What about having no pages - only communities?
- RF: No, pages are for useful for stores, etc. Keep pages. But communities and groups?
- RW and RF: Perhaps a useful distinction would be just to keep. Just keep communities regional?
- MS: One page for Germany, with other pages for communities all over Germany linked on the master page.
- RW: Countries not defined in current development model, only areas.
RF: First blog post published. Email translators soon so they can get started translating. We should involve other developers – is development team ready for remote developers?
- RW: No problem to inform remote developers, but development team not yet ready to keep contact with, inform or /include them at this moment. Gather details for when we can incorporate them. Not easy to get involved right now, but we are working on documentation to include them.
- RF: Important to address the fact that a lot of work will be done on a distributed basis later on and we need to think about how we enable that now: make the project understandable. FoodSharing Newsletter going out soon. We need to be transparent about our finances – publish our expenditure online. We should have a project name decided by tomorrow – this will allow the progress of the legal processes (and Beatas colleague is willing to help!)
SP: Now using Justinmind (usable offline) - but can't share... will sort out later. Presents multiple mock-ups.
- RF: Motion towards circular icons over square?
- RW: We have the technology.
DW: Presents proposed structural model in an aim to help organise the team here and prepare for later, distributed work.
RW: Brief update from development... things going well, 2 different APIs, not so much else to share (for humans)
[Meeting ends 16:30]
Drawing 1: Page mockup
Drawing 2: Profile and Trust metrics mockup
Drawing 3: Current structure with proposed changes
