Meeting #3 2015-10-02

Owned by Monika
Last updated: May 24, 2016 by Elina
4 min read

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


 


To the extent possible under law, the yunity wiki contributors have waived all copyright and related or neighboring rights to the content of the yunity wiki. More information...

You have an account but can't edit or create pages? Write us in the open chatroom or in our yunity Slack!