[athena-tix-planning] Integration Standards and API

[Drew McManus]

I'm curious to know if there has been any discussion to date on issues
related to developing an API? It seems most of the conversation is
focused on developing end-user requirements and although that is
certainly a critical component, it is perhaps better addressed after
Athena's business and development plan are sketched out.

I think a good model to pursue something akin to what WordPress is
evolving toward which is providing core functionality that other
developers use to customize in their field of activity. In this
fashion, Athena can focus on producing the best possible core code
that other use to customize to suit client needs via CMS and end-user
requirements.

As an example, instead of looking at Athena to provide all aspects
related to individual seat selection, it simply needs to provide the
functionality necessary to refine that capability. Consequently, users
can develop that end-user interface in-house or via the services of an
outside provider.

What I envision is something that current ticket providers can use as
their core resource and customize based on user needs as opposed to
developing proprietary systems. Imagine how much more advanced back
and front end user features would be if they directed a much larger
share of ther development resources toward hose issues as opposed to
developing the proprietary systems currently in place.

Ultimately, Athena could become the source that provides a constantly
evolving and flexible foundation that lowers costs for everyone
involved right through to the ticket buyer.

--
Visit: http://athena.fracturedatlas.org/tix

You received this email because you are subscribed to the "ATHENA Tix Planners" group on Google Groups.

To post, email: athena-ti...@googlegroups.com
To unsubscribe, email: athena-tix-plan...@googlegroups.com
For more, visit: http://groups.google.com/group/athena-tix-planning?hl=en

[Aaron Bauman]

I think a combination of both approaches -- a robust API and a front-end client --  would best serve the community.

Ambitious, perhaps, but offering at least a simple front-end will be essential in accommodating smaller organizations who may not be able to afford a paid front-end client or an in-house developer. 

/aaron

[dharmaroad...@gmail.com]

I think only MUCH bigger arts organizations are going to be willing/able to commit budget resources to hiring a developer to flesh out an online ticketing system. And they will have to be PERSUADED to do this rather than use an off the shelf system that has no such start-up costs.

I'm not saying don't develop robust APIs. It's great if you can. but if you're trying to improve on existing solutions, you had sure as hell better provide improved end-user experience out of the box.

[Adam Huttler]

Our hope and expectation is that we’ll end up with both a very robust API and *multiple* options for the front-end implementation. Those will include our own turnkey hosted service along with “self-installed” options in popular languages/platforms like Rails or PHP (maybe even Drupal). Some of the latter will surely be free and open source, while others may be provided by 3^rd party vendors.

That’s the general idea, anyway…  If it plays out this way, then someone like Drew would have lots of options for integration.

[Justin Karr]

To add a little color to Adam's comment:

 

This is exactly the message we have been getting from people in offline conversations as well.  There is a lot of positive feedback about the Service-Oriented, Web Services API model that we have been promoting but in the end, people want it to come with a default configuration and a default interface.  They want something the can use - and more importantly *evaluate* - right out of the box.

 

Our plan had been to encourage partners to get involved and make interface-technology-specific front-ends such as a Drupal front-end, a Django front-end, a Rails front-end, etc.  We still hope to get people to do this, but our plan now is to also create a default, simple web-based interface.  It will be very standards-compliant and very bare-bones with the expectation that users will style it to suit their existing web applications.

 

But whatever we do in terms of user interface, everything is going to have an API.  This is a core design concept for ATHENA Tix.  We want users to extend, expand, integrate, reuse and generally tinker with the ATHENA system.  The modern (and relatively easy) way of doing this is with a Web Services API (see: Facebook, Google, Amazon, etc.)

 

Justin

 

 

From: athena-ti...@googlegroups.com [mailto:athena-ti...@googlegroups.com] On Behalf Of dharmaroad...@gmail.com
Sent: Wednesday, April 28, 2010 11:25 AM
To: athena-ti...@googlegroups.com
Subject: Re: [athena-tix-planning] Integration Standards and API

 

I think only MUCH bigger arts organizations are going to be willing/able to commit budget resources to hiring a developer to flesh out an online ticketing system. And they will have to be PERSUADED to do this rather than use an off the shelf system that has no such start-up costs.

[Drew McManus]

I think the idea of putting something out with a default config /
interface should be expected, I certainly wasn't suggesting otherwise.
In fact, it's very much like the WordPress model (even though they
still focus on blog-only themes). As someone currently working with
WordPress, I do hope that platform is at the top of the list when it
comes to the sort of options described by Adam.

dharmaroadproductions' observations are also very worthwhile but one
thing to consider here as it applies to Athena's business model is
support. A ticketing platform is a crucial component to any arts org
so the questions to consider are whether or not it is possible to put
something together within the first few years of release that is so
easy and fail-safe to use that it requires little to no service and
support.

All things being equal as they are now, I also agree with
dharmaroadproductions' categorization that only the largest budget
arts groups having the budget to bring in outside help to provide a
tailored ticketing solution. At the same time, all things related to
online development (ticketing, website creation, email marketing,
etc.) is rapidly changing for the better (Athena is, in-and-of-itself,
a representative example of this change).

It's not much different than the paradigm shift associated with Henry
Ford introducing the Model-T; meaning, what used to cost $1000 in one-
off development costs is now $100 dollars plus the final product is
far more flexible and continuously evolves, thereby bringing down
subsequent maintenance and upgrade costs. Granted, we're in the
beginning stages of this shift but it is happening and I'm looking
forward to seeing Athena become one of the leaders in this shift.