The Sponge Wiki

Match is the first module developed within the Knowledge Exchange Platform, meant to enhance team collaboration by providing:

• user submissions – either Resources or Assignments – that can be searched, matched with each other or consumed/taken by members
• notifications system, both in browser and by email
• profile pages with relevant information about users
• guided workflows for taking assignments / using resources / match making

The module is developed following the API/client architecture, which will also power the rest of the KEP app.

The backend is built using Rails-API and it exposes a RESTful API with token authentication, while the frontend is an ember-cli app.

Platform members can upload and edit two types of submissions:

Assignments are posts defining a specific task to be executed by its taker(s). An assignment has well defined requirements, such as location, necessary skills, languages etc., as well as rewards given by the poster to the person(s) that will complete the given task.

After submitting an assignment, there are a series of things happening on the platform:

• members that will be most compatible with it will be notified
• anyone who can access the post will be able to “bid” on it, so the owner will have to choose one or more users to complete the assignment
• if there are any priorities defined for it, the assignment will be accessible incrementally, as defined by priorities: work in progress

After modifying (updating) an assignment with new information, if any of the attributes that power the match making are touched (i.e. skills, languages and locations), the backend will recalculate matching scores to notify the newly matched users.

Resources are posts describing a shareable entity, such as information, skills, physical materials (furniture, tools, consumables, etc.). Resources owners can (and they should) specify one or more intentions they have with that specific resource (e.g. Brainstorm or Article writing), so visitors would know if they are qualified (and motivated) to take that opportunity.

Resources can be consumed in three ways:

• every time a member posts a resource with defined intentions, those intentions will generate a set of action buttons in the UI. The mentioned buttons will be contextually designed to transform a resource into an assignment built on the defined intentions (e.g. press action button “Article writing” and user will be transferred to the “add assignment” form with a few predefined values based on the starting resource).
• resources owners can consume their own resources over time, thus making it deprecated – then they can close the resource post as depleted or canceled.
• resources can be only available during a time span defined by the user who posts them, so when the time runs out they will be marked as unavailable.

The Knowledge Exchange Platform (KEP) has a built-in notification system that will alert users of various events by email or using the web UI.

The current state of notifications is:

• Web UI notifications: in progress
• Email notifications: done

Profile pages are platform sections that accommodate all the information on members. There are user completed sections, such as biography, skills, but there are also a few resources that are not in the scope of this page:

• user's avatar is collected from Libravatar API. There's a direct URL provided for avatar management.
• there's a digest of posted assignments and resources in the lower section of the page. This is automatically collected from the database.
• planned features for matching score (amount of manual matches done)

In order to enhance user interactions and avoid confusion around its specific features, Match provides visual assistance in accomplishing manual tasks, such as posting, and matching of existing entities. A set of visual cues are provided (work in progress) for the following tasks:

After posting a resource/assignment, a timeline will be visible on the top defining all the possible states the post can have. The current one is highlighted and the possible ones are clickable. This way, users can interact with the timeline to change current post's state (if and only if they own the post) without the need for extra buttons and interface clutter, also providing a visual logical sequence for observing post's life cycle within the platform.

Examples:

• Assignment can be: *draft*, *private*, *public*, *ongoing*, *done*, *closed*; transitions between them are regulated in such way that one cannot implement absurd workflows (i.e. change state from *draft* directly to *ongoing*)
• Resources can be: *draft*, *private*, *public*, *closed* (we plan to extend those a bit)
• *private* is a pre-public state where only members assigned as priorities can see the respective entity

Manual matching is a feature that allows members to suggest a possible match between two entities. For example, a visiting user can observe similarities between an assignment and a resource and (s)he can create a match; this means both owners of the two entities will be cross-notified by the other post matched against theirs, making the user that made the match a match maker. Match making is recorded within the module as a total score, based on the number of matches made and number of succeeded matches (i.e. owners that really connected as a result of the match), for further possible gamification purposes. A good example of this would be StackOverflow with its badges and reputation system.

This is the most obvious matching feature, where a member can create a match between one item from the left column (Resources) with an item from the right (Assignments).

Matching is triggered by pressing the “Match” action button in the “Actions” dropdown, then the platform will provide the following guidance:

• starting point (i.e. the item where user pressed on “Match”) is rendered simplified and on the center-bottom area
• the starting column is disabled while on match mode, inviting the user to select an item from the opposite column
• when selecting something from the other column, the details are rendered in the top-midle section, creating a small preview area for both match candidates
• * the second item can be switched as easily as selecting other items from the same column
• between the two middle sections (i.e. match base and match candidate) is a “Preview match” button, that will open a modal window with a comparison chart
• * on the comparison chart the details from both match candidates are rendered similar to e-commerce websites on “compare products” feature
• * here one can review the match details and decide if (s)he really wants to make a match

This is the other kind of match, where a member of the platform is able to suggest a Resource/Assignment to another user (while also suggesting the other user to the item's owner).

Concrete workflow is designed, but not fully implemented yet (this section will be updated when it happens).