|
|
-
A year has passed since we announced the thoughts behind having a new
API for the community. We spent a lot of time engaging you, crafting
code, building applications, and working on solidifying what turned out
to be a retro-revolution... read more at our our new developer community site.
|
-
We have wrangled all of the devs and gathered all of the content that you saw at the DC09 DevCon. Since we are community focused, we wanted you to have as much code and information that you'd need to get jump started for the RESTful API BETA so that you'll be able to discuss / communicate your ideas on consuming the REST API throughout the Social-Sphere. We've got much more to come with the upcoming launch of our developer community site and the general release of the REST API. Please take a moment to check out the goodies below - the whole dev team really "kicked out the ladder" so that we could give you real world, ministry focused code.
Application #1: F1Touch (Team Fire - iPhone) – 1st Party
Developers: Matt Vasquez, Chad Meyer
Description:
Our app is an iPhone application as a first party vendor open to all churches that opt in. Our application will provide the ability for church portal users to quickly look up congregants and contact them via phone or email as well as pull up Google maps to assist in directions to their house.
Content
Chad Meyer's blog post | Slide Deck | OAuth Lib
Application #2: Outreach (Team Air - Facebook) – 3rd Party
Developers: Ryan Champ, Jas Singh, Kelly Klein
Description:
Facebook is a social networking website with over 200 Million active users. How does the church engage, minister to, and help people through this social medium? Furthermore, is there a way to convert connections made in Facebook into potential church members?
We tackle the problem with a prototype of application that functions with the overarching concept of “Virtual Outreach over Virtual Church.” Not only do we aim to build an ecology of people helping each other, but by reaching out to people and helping them deal with issues that affect their lives, church ministers and lay leadership can build “social capital” and trust in the digital world. This, in turn, will make their invitations to check out the church family much more appealing. Prospects, thus invited via the Outreach app, will then be routed directly into the church’s Fellowship One database.
Content
Video | Slide deck | Code | OAuth Lib
Application #3: Listee (Team Earth – Expression Engine) – 2nd Party
Developers: Nathan Smith, Jingyi Wang
Description:
This module allows a web designer to easily include F1 data using the ExpressionEngine content management system. The benefit of this is that EE is a very popular CMS for high-end designers, because it's templating language is so intuitive.
Content
Video | Slide deck | Code | OAuth Lib
Application #4: IWANTTOSERVE.COM (Team Water - .NET MVC) – 3rd Party
Developers: Tim Hardy, Tudor Lupan
Description:
We’ve developed a “Needs board” application that allows church members (anyone with a WebLink login) to post needs and search needs to minister to each other. There is a tremendous need for a technical tool that can direct member’s willingness to serve to the valid needs of others. While several tools have attempted to provide this functionality, none have taken advantage of the tried-and-true community self-monitoring patterns established by services such as ebay. We’ve implemented a double opt-in system – the need submitter has to “Accept” a helper’s willingness to help, and the helper has to then “Commit”. Both the submitter and the committed helpers can then rate each other to curb service abuses once the need has been met or the due date expired. It completely leverages WebLink logins for authentication, and it contains a fully functional user profile editor
Content
Video | Slide deck | Code | OAuth Lib
Nick Floyd - Integration Architect
|
-
NOTE: THIS UPDATE ONLY CONCERNS THE FELLOWSHIP ONE RESTFUL API BETA OAUTH IMPLEMENTATIONYesterday a minor security threat was discovered in the OAuth protocol. The OAuth community is aggressively working on the issue and have released an advisory update on this on 4.23.2009 at 12:00 am PST. We have been in contact with them on the details of this issue. After a close look at the threat and considering the risks involved, we have determined that we will not suspend the use of OAuth in our API. Instead, we will immediately implement additional mechanisms to further protect against potential attack: - Shorten the request token life time
- Require any 3rd Party application to have a registered callback
- Require additional warnings and details on the token authorization pages to clearly explain the intent of the Consumer application
We take all security-related issues seriously. Although the REST API
OAuth implementation is only available in a beta environment right now,
we want to take mitigating actions.These changes to our OAuth Service Provider implementation will be deployed soon.
We purposely chose OAuth as our primary authentication mechanism because of the security and iron-clad structure it provides. We are even more encouraged by our choice in light of the quick response and reaction from the OAuth community. Since there are thousands of developers and applications behind this protocol, there are thousands of people behind our implementation.
We would like to thank Chris Messina, Eran Hammer-Lahav, and the rest of the OAuth community for being so transparent and quick to respond and collaborate to solve this issue.
Please do not hesitate to contact us directly with any concerns or questions that you may have: api [at] fellowshiptech.com
More information: see OAuth advisories updates
Nick Floyd
Integration Architect
|
-
With the up coming Fellowship One RESTful API we wanted to take the some time and look back on our other two APIs and reflect on what we intended them to be and what they actually became. We looked at the their interfaces, authentication, resources, versioning, protocols, logging mechanisms, "debuggability", etc... What we found out was that in the world of "API" nothing ever ends up like you intend.
Fellowship One Data Exchange: A very powerful XML RPC API that was specifically designed to address massive data import and export needs. It's ridged pinpoint interface allow users to build simple data presses, which move large amounts of data between disparate systems. A few years into the product's life we introduced the ability to do synchronous transactions - a decision that completely changed many consumer's usage patterns.
Serendipity
stepped in and instantly consumers began to use this brute force
application on websites to perform anything from profile updates to
seamless login patterns. After seeing how much the community found value in the login metaphor we've published docs and given presentations on the best practices of this approach. We now have 3rd parties writing web
applications and hosting web sites that do a myriad of things. Being a SOAP based .NET web service, consuming Data Exchange required the language to either have a library that constructs SOAP envelopes or that the developer understand that protocol and be able to construct a SOAP message manually. Another characteristic of this API are the logging and response mechanisms; both were intended to only be used / interpreted by the consuming application. Its authentication is based on simple credential / key maps.
Fellowship One Payment Gateway: A .NET SOAP based web service that gives churches the ability to submit giving / e-commerce transactions. The interesting thing about this service is that it was originally developed for internal consumption only and later opened up to external consumers for book stores, tithe applications, etc... another decision point that changed the way an established API was used. Payment Gateway answered a changeling question of: "how do I get all of my billing and payments to go through one channel and be able to report on the transactions going through that channel?" Much like Data Exchange, we saw it consumed in ways we couldn't have imagined. We used credential and signed key authentication for this API. Fellowship One RESTful API: A REST based web application that uses several open protocols and patterns to provide consumers access to secure resources. STANDARDS, PROTOCOLS, and PATTERNS - nothing else. Looking back, we could see where their is major value in sticking with something that is "tried and true." If we could use web based patterns and protocols for a web based API we could not only get instant adoption but gain the efficiencies and effectiveness of technologies that "just work." This next generation of API is, ironically based on foundations that have been in place for years. We chose MVC as the application architecture, OAUTH protocol for Authentication, REST and HTTP 1.1 as the transport. This API should give web developers an tool where all they have to think about is what to do with the resources. Thank you for partnering with us over the years; we have a lot of fun stuff up ahead and we hope to see you at the Dev track @ DC09!
|
-
Last night we released a very significant project that will impact everyone who uses Fellowship One; a total replacement for the Household/Individual detail pages. Accounting for over 35% of our web traffic, nearly 100% of our users access these pages in the course of a normal day. While the exposure of this project makes it significant, the underlying architecture is equally as important and is the aspect of product development that can be, but shouldn't be, overlooked.
It is always obvious when screen design changes, what is not so obvious are the scaffolding and foundation changes that must be considered. This is an area that is easily ignored when software development is rushed, on a tight budget, or farmed out since the end user doesn't see or typically understand what this is; in the end this will determine how easy it is to make improvements, support, and extend the functionality. We did not short cut this step! A significant effort was put into a solid foundation that will help us continue to build upon, reduce errors and support what you see. Database calls and render times were tested and re-tested to work toward an optimum performance; this was very important since we are displaying so much on one screen. The scaffolding was built in a way that will allow us to extend abilities to 3rd party vendors so they can begin building external solutions while keeping Fellowship One as the database of record. In short, the changes you see today are much more than just a pretty face; they represent a starting place for a big future.
As always, we hope you appreciate and enjoy the changes that were made.
Reminder: if you had been following the design conversations we had 5-6 months ago, you will undoubtedly notice that there are some things we have further improved upon, but also some aspects that are missing; this is an iterative process and you can expect improvements to come.Please be patient and make sure you let us know what you would like to see by submitting your ideas on the IDEAS tab above.
Check out the EDUCATION tab above for more information and direction to learning opportunities available.
|
-
 If your church uses Fellowship One Check-in, we have a special gift for you! One of our business partners, November Sundays, worked with us to develop a Check-in theme for Christmas. This theme has been uploaded into Fellowship One for you. Simply go to the Ministry tab and select Activity/Room Setup and Theme Manager to preview the themes and apply them to activities. (Note: To see Theme Manager, you must have Check-in Theme Manager security access rights.)
If you are interested in having a custom theme developed for your church, your children's ministry, or a special event, please visit www.NovSun.com, or contact Andy Mullins directly at andy@NovSun.com.
|
-
We started the conversation here, in this blog forum, re: the replacement of Household/Individual. The goal was to see the "whole picture", make it easier to add/edit/delete details, and provide an intuitive user interface that was easy and enjoyable to use. Our dev team took this project as a challenge to show off a development style that keeps them focused, accountable, and delivers what the user asked for; they blew me away!
Working with the dev team intimately on screen design, we then immediately shared those with you and many other stakeholders to identify exactly what was needed. Everything was broken down into “whole” tasks and allotted out every two weeks; quick 10 minute meetings were held every morning to identify progress and roadblocks. There were constant reviews to validate that what was being built was in align with the vision. Did it work? The proof is in the pudding, four short months later, with other projects that still demanded developer time, the first release of Household/Individual 2.0 is ready for the big time and I am excited! Replacing these legacy pages is important for a lot of reasons:
-
Establishes another key building block that plays to our vision for F1
-
Everyone, no matter your role, is exposed to these pages so improvements here are felt across the board
-
Household/Individual detail pages account for more of our bandwidth than all other pages combined; improvements here impact our overall performance
-
It is our constant goal to improve visibility to your congregation; this takes a big step in that direction
If you had been following the design conversations we had 4 months ago, you will undoubtedly notice that there are some things we have further improved upon, but also some aspects that are missing; this is an iterative process and you can expect improvements that further flesh some details out over the coming months.
Check out the EDUCATION tab above for detailed information, instruction, and direction to play with the new design in a safe environment.
|
-
WOW! I just counted 'em up and we have had over 5000 views of the video blogs highlighting the Household/Individual replacement. We have also had over 100 comments, which brings me to the point of this posting... we have enough clarity to move forward in many areas, but a small handful of questions still exist. I have created a survey that highlights the three areas we need more information. The survey is a little wordy and has some graphics you will want to review, but overall shouldn't take you more than 5-10 minutes to complete; this short time can have a huge impact on your future usage of these highly used pages. Please, please, please take the time to do it. --> Household/Individual 2.0 Survey <--
Thanks in advance!
|
-
-
The project known simply as "Household/Individual 2.0" is a key building block in the overall re-design of Fellowship One. We are excited to share our design ideas based wholly on your feedback of our product over the last several years. We can’t afford to simply build this stuff in the dark and then spring it on you, so we are sharing this design step with you to help foster a better design/workflow/experience; your feedback is very important! Please take the opportunity to shape this project by reviewing each of the following videos and commenting as you can. In addition, please ask others who have an expertise in the area to review it and comment.
Thanks.
Forward: Household/Individual 2.0 Overview
Chapter 1: Household Members
Chapter 2: Involvement
Chapter 3: Giving
Chapter 4: Contacts and Notes
Chapter 5: Comm's and Addresses
Chapter 6: Basic Info
Chapter 7: Attributes
Chapter 8: Requirements
Chapter 9: Forms
Chapter 10: Gears, Groups and Dupes
Giving from Fellowship Technologies on Vimeo.
|
-
-
-
-
-
|
|
|