Local fork seems to be the service that competes most directly with the service that we are currently developing. During our meetings with CSA managers this was also the only service that was mentioned. People who had experience using this tool had achieved varying levels of success.
With this in mind, we decided to do a detailed analysis of their CSA/Co-op Toolkit. This exercise will help us identify new ideas regarding site structure and organization, and it will enable us to learn from good and bad design decisions made and implemented by the localfork team. At the end of the day, this analysis will help us develop a service that is truly differentiated.
As you will note from my analysis below, we believe that there is a lot of opportunity for us to create a tool that is especially catered to the needs of urban CSA organizations.
A Little Background on Local Fork
Local fork is a lot more than just a CSA/Co-op Toolkit platform. It is an organization that is dedicated to stimulating local food networks. In their own words: “Local Fork is the first website where local food consumers, buyers, and producers can fully collaborate, network, buy, sell, advertise, and find needed services.”
The main services that Local Fork currently provides include: CSA/Co-op Toolkit, Locavore Guides, Local Foods Directory, Communities, and Videos. The focus of this analysis will be on the CSA/Co-op Toolkit, as this is the focus of our current project.
Information Architecture
The system is designed with two main account types: personal and organizational accounts. This simple structure provides the scaffolding upon which the entire system was built. Here is a brief overview of the main features and functionalities associated to each of these account types:
Each user of the system has his/her own personal account. Each organization also has its own organizational account. User accounts are created by individuals via a short registration process. Anyone with a user account can create a new organization account using a short registration process. They can also request to join an organization with an existing account.
The system is designed to separate Personal and Organization-related data. For example, when a user is logged into his personal account he is not able to access any data that is CSA-specific. To access this information he/she needs to view CSA-specific pages. This means that an individual’s calendar and volunteering information is only visible when he/she accesses his CSA’s page, which is several clicks away from his initial log-in.
Personal accounts can exist without being connected to a user, however, organization accounts are always created by, and linked to, users at a “personal” account-level. Personal accounts can be linked to multiple organizations. Similarly, organizations can be related to multiple personal accounts.
There is little to clearly differentiate when the user is in his own account versus when he is viewing a CSA page. The only noticeable difference is that the top navigation bar changes. I personally found this a little bit confusing, both the lack of contextual cues and the changing main navigation bar.
From a high-level standpoint we will likely structure our system in a way that is similar to Local Fork’s, we will also feature personal and organizational accounts. That said, we plan to create more linkages between the two account types to provide users with a more seamless, community-focused, and streamlined experience. We also will provide users with more contextual cues regarding their current location and will design a more effective global navigation system (likely using secondary navigation elements more consistently).
Member Management
Roles, Subscriptions and Status: The Local Fork system does not allow organizations to differentiate between their members role (admin, shareholder), subscription type (vegetable, half-share), and status (paid, waitlist). All of this information is encapsulated into the roles attribute. When users initially join an organization they are given the role of a “member”, or “subscriber”. After joining, their role can be changed to a wide variety of options such as: “shareholder”, “administrator”, “waiting list”, “historical shareholder”, “flower shareholder”, “winter co-op”, “owner”, “half-shareholder”, “paid in full”, “fruit shareholder”, “summer CSA”, “other”.
This is definitely an area where our design choices will differ from Local Fork’s current approach. Local Fork’s current set-up leads to potential conflicts and confusion since status items such as “paid in full” or “waitlist” cannot be specified to a specific type of share (e.g. vegetable, fruit, or flower share). It also limits the value that the system can provide in enabling CSA managers to track payments for multiple shares for the same member.
Adding New Users and Members: To add new members to a CSA the admin can either invite users to join the CSA, add the user directly to the CSA, or create an offline user. The first two options identical from the invitees perspective. The CSA admin inputs the invitees email address into a form that generates an email to that individual with a link to a registration page. In both cases the invitee needs to complete his/her own contact details.
The third option enables the admin to add an “offline” user to the CSA (essentially a user without an email address). Unfortunately, it does not allow the admin to add offline contact information for any of the “offline” users.
This is another area where we can innovate. We plan to offer more flexibility for the CSA admin to manage the contacts from his/her database. For example, we hope to provide CSA manager with the ability to create new members fully, including inputing all contact information. This will enable the system to better support offline users as well. CSA managers would be able to input these members’ contact information into a single system so that they would have a single source for all CSA-related contact information.
Ideally, we would even like to enable CSA managers to upload existing member lists in excel or csv formats. The system would add the members and send an email (to all members whose email is available) requesting that they confirm their contact information and privacy preferences. This same system could be used to help CSA managers transfer shareholder lists from one year to the next.
Payment Tracking and Processing
Local Fork offers limited support for payment tracking and processing, especially for CSAs that work with multiple partners. Though we noticed that an “order” features exists we were not able to understand how to use it.
We believe that we can add value here by enabling CSA managers to customize the set-up of their CSA to better support multiple partners. We plan to create a tool that supports tracking of sign-ups and payments for each type of share independently. Ideally, we would like to link the tool to an online payment gateway so that CSA shareholders could pay for all of their dues online.
Event Management
The event management tools in Local Fork are simple. They provide basic event and shift management capabilities. Admin users can create events, and request, approve and track volunteer sign-us. All members are able to see the events created by the admin users, and to accept volunteer requests. Event reminders can also be scheduled for volunteer signups.
Here we plan to differentiate our service by making it easier to use the calendar and providing additional logistical support. First, we aim to enable CSA managers to create repeating events. Next, we will enable all users to create events, though we will clearly differentiate CSA-organized events. We also hope to provide inter-operability with most calendar applications so that users can easily add commitments to their own calendars. From a logistical support standpoint we will provide CSA managers with the ability to print sign-out sheets for use at the CSA deliveries.
Privacy and Community
Local Fork currently does not allow its users to share their contact information with other members of their CSA. They are only able to share their contact information with administrators. The system is designed to enable the admin to send messages to members without even knowing their emails.
Our service hopes to provide a better platform for CSA members to be able to reach one another. We plan on allowing (and even encouraging) CSA members to share their contact information with other members. We would like to go so far as to ask people to add their pictures and addresses so that they can be added to a community map.
CSA Customization
Local Fork provides little opportunity for CSAs to customize their organization. I’ve already addressed above the opportunities we’ve identified associated to the subscription and payment tracking system. However, another important area for customization is the look and feel of each CSAs site.
We believe that CSAs would appreciate the opportunity to customize the look and feel of their organization’s pages. We haven’t defined how much customization we plan to include in our service, however, at the most basic level we will enable them to customize colors, fonts, and add logos and pictures.
Reporting
Unfortunately, we were not able to test the reporting functionality available in Local Fork. However, I can stress that reporting will be an important feature of our service. We are looking at mint.com as a design inspiration for our work in this area.
