Whoa...
1 view
Skip to first unread message
Ari
Dec 10, 2009, 1:58:10 PM12/10/09
to ATHENA Tix Planners
WHOA!!!
All this coding lingo, and references to programs and languages mean
absolutely nothing to the end user.
I think most of the people who have anything to benefit from a
ticketing system aimed at independents and non-profits should be able
to use the software on machines and consumer grade desktops and
laptops and operating systems that are up to 5 years old. If that
means a cloud-type system -- fine. Just make sure the interface is
fast. In the past, I've found Java-based web apps to be exceedingly
slow/buggy/annoying/unreliable. The only way I know that they're Java,
is that there's usually some sort of animated icon/logo that loads up
saying "Java" and/or an animated cup of coffee.
Whatever system Google uses for their online apps kicks ass. (though
I'm guessing it is exceedingly expensive and complex, despite seeming
very simple)
So yeah. My bottom line priorities, listed in order of importance:
1. Utility
2. Ease of use
3. Reliability
4. Cross platform/Old platform
Keep end users who know nothing (or close to nothing) about computers
involved in the development process. Keep rotating in new people who
haven't become accustomed to the software, and make sure they
immediately understand how to use it without any instruction (on
screen step-by step is okay, but it should be pretty self-evident how
to use it to someone who produces events). At that point, you will
have built a successful piece of software.
Kind regards,
Ari
All this coding lingo, and references to programs and languages mean
absolutely nothing to the end user.
I think most of the people who have anything to benefit from a
ticketing system aimed at independents and non-profits should be able
to use the software on machines and consumer grade desktops and
laptops and operating systems that are up to 5 years old. If that
means a cloud-type system -- fine. Just make sure the interface is
fast. In the past, I've found Java-based web apps to be exceedingly
slow/buggy/annoying/unreliable. The only way I know that they're Java,
is that there's usually some sort of animated icon/logo that loads up
saying "Java" and/or an animated cup of coffee.
Whatever system Google uses for their online apps kicks ass. (though
I'm guessing it is exceedingly expensive and complex, despite seeming
very simple)
So yeah. My bottom line priorities, listed in order of importance:
1. Utility
2. Ease of use
3. Reliability
4. Cross platform/Old platform
Keep end users who know nothing (or close to nothing) about computers
involved in the development process. Keep rotating in new people who
haven't become accustomed to the software, and make sure they
immediately understand how to use it without any instruction (on
screen step-by step is okay, but it should be pretty self-evident how
to use it to someone who produces events). At that point, you will
have built a successful piece of software.
Kind regards,
Ari
Justin Karr
Dec 10, 2009, 3:36:43 PM12/10/09
to ATHENA Tix Planners
Folks,
Just to clarify for those who may be confused, our intention is not to
use a Java applet (what Ari is referring to when mentioning the coffee
cup icon) as the front-end. Java will be used for the bulk of our
server software, but should be invisible to the user. Current plans
are to develop our user interfaces as many (including Google) do these
days, using standards-compliant, works-in-any-browser, web-based
technologies. One comment we have received on this (and from more
than one party) is that webpages do not offer the necessary
interactivity or security to function as an effective user interface
from the perspective of the ticket-seller (say in a box office or in a
call center) and that we should offer a "native" client (such as
Windows or Mac application) for those environments. That question is
probably one for the new devel list (punt...), but it raises a great
question for this, the planning list:
Who actually uses the ticketing system?
What are the different user roles and jobs who at some point come into
contact with a software ticketing system, generally and specifically,
directly and indirectly? We covered a lot of this at the community
design session (the notes will be posted shortly, promise...) but I
would really like to continue the conversation here.
I will frame this question by identifying what I think of as the
primary categories of users. Let me say that I am eager to hear that
this list is incomplete or even just wrong. Let me also say that
these broad categories are patently insufficient when it comes time to
actually design user interfaces. I want to know who the specific
users and what they will do with the system.
1. Ticket-Buyers: those who purchase tickets, including mainly
patrons.
2. Primary Ticket-Sellers: those who directly sell tickets, including
box office staff, tele-sales operators and the ticketing system's
website managers.
3. Proxy Ticket-Sellers: those who sell tickets through a proxy,
including group sales agents, travel agents and certain through-sale,
niche market ticketing websites like Givenik.com.
4. Resellers: those who buy tickets and resell them, including brokers
legitimate and otherwise.
5. Managers: those who organize the sale of tickets, including the
artists themselves, their managers (aka producers) and the managers of
the venue.
6. Interested Third Parties: or call it misc, including accountants,
market researchers and in a commercial model, investors.
Justin
Just to clarify for those who may be confused, our intention is not to
use a Java applet (what Ari is referring to when mentioning the coffee
cup icon) as the front-end. Java will be used for the bulk of our
server software, but should be invisible to the user. Current plans
are to develop our user interfaces as many (including Google) do these
days, using standards-compliant, works-in-any-browser, web-based
technologies. One comment we have received on this (and from more
than one party) is that webpages do not offer the necessary
interactivity or security to function as an effective user interface
from the perspective of the ticket-seller (say in a box office or in a
call center) and that we should offer a "native" client (such as
Windows or Mac application) for those environments. That question is
probably one for the new devel list (punt...), but it raises a great
question for this, the planning list:
Who actually uses the ticketing system?
What are the different user roles and jobs who at some point come into
contact with a software ticketing system, generally and specifically,
directly and indirectly? We covered a lot of this at the community
design session (the notes will be posted shortly, promise...) but I
would really like to continue the conversation here.
I will frame this question by identifying what I think of as the
primary categories of users. Let me say that I am eager to hear that
this list is incomplete or even just wrong. Let me also say that
these broad categories are patently insufficient when it comes time to
actually design user interfaces. I want to know who the specific
users and what they will do with the system.
1. Ticket-Buyers: those who purchase tickets, including mainly
patrons.
2. Primary Ticket-Sellers: those who directly sell tickets, including
box office staff, tele-sales operators and the ticketing system's
website managers.
3. Proxy Ticket-Sellers: those who sell tickets through a proxy,
including group sales agents, travel agents and certain through-sale,
niche market ticketing websites like Givenik.com.
4. Resellers: those who buy tickets and resell them, including brokers
legitimate and otherwise.
5. Managers: those who organize the sale of tickets, including the
artists themselves, their managers (aka producers) and the managers of
the venue.
6. Interested Third Parties: or call it misc, including accountants,
market researchers and in a commercial model, investors.
Justin
Aaron Bauman
Dec 10, 2009, 3:50:05 PM12/10/09
to athena-ti...@googlegroups.com
Probably some overlap w/ Justin's list, but I'll add:
* Event planners - overview, trends, marketing
* Development staff - CRM-related functionality, contributor reporting, list management
* Accountants - financial reporting, bookkeeping
/a
Justin Karr
Dec 10, 2009, 5:34:52 PM12/10/09
to ATHENA Tix Planners
Aaron,
Thanks for this.
In terms of Event Planners, do you mean the person organizing a show
to begin with (like a producer or a promoter) or do you mean a
different role, like the person planning an affiliated event like an
opening night or a gala?
Justin
On Dec 10, 3:50 pm, Aaron Bauman <aaronbau...@gmail.com> wrote:
> Probably some overlap w/ Justin's list, but I'll add:
> * Event planners - overview, trends, marketing
> * Development staff - CRM-related functionality, contributor reporting, list
> management
> * Accountants - financial reporting, bookkeeping
>
> /a
>
> On Thu, Dec 10, 2009 at 3:36 PM, Justin Karr <justin.k...@fracturedatlas.org
Thanks for this.
In terms of Event Planners, do you mean the person organizing a show
to begin with (like a producer or a promoter) or do you mean a
different role, like the person planning an affiliated event like an
opening night or a gala?
Justin
On Dec 10, 3:50 pm, Aaron Bauman <aaronbau...@gmail.com> wrote:
> Probably some overlap w/ Justin's list, but I'll add:
> * Event planners - overview, trends, marketing
> * Development staff - CRM-related functionality, contributor reporting, list
> management
> * Accountants - financial reporting, bookkeeping
>
> /a
>
Aaron Bauman
Dec 11, 2009, 9:32:32 AM12/11/09
to athena-ti...@googlegroups.com
I guess I'm thinking from the perspective of a service organization rather than a performance organization.
An Event Manager at such an organization might take on both roles you mentioned.
KinesisProject
Dec 11, 2009, 9:36:46 AM12/11/09
to ATHENA Tix Planners
Hi All -
I'm going to piggy back on Aaron's little list with my two-cents:
Ideally a separate Event Planner for an affiliated event (benefit/
event/gala/party - where the income is going to the same source/
producing company)
would be able to get into it and create a ticketing status to feed the
overall income of the produced show.
In the beginning of the week I created an identity on
brownpapertickets - it was pretty easy to use and easily explained...
except the API/Paypal part - seems like I would have to be a much
larger organization for it be worth bringing the sales directly into
my account.
Things definitely got confusing at that point in the set-up.
I'm glad you are separating the lists, I can manage developer speak
and would like to stay up-to-speed....but when I have my producer hat
on, I become "end user" and would rather know that I can move step by
step through a system that is organically built for my show-creating-
ticket-making-needs.
Congratulations on all of the work -
Melissa
On Dec 10, 5:34 pm, Justin Karr <justin.k...@fracturedatlas.org>
wrote:
I'm going to piggy back on Aaron's little list with my two-cents:
Ideally a separate Event Planner for an affiliated event (benefit/
event/gala/party - where the income is going to the same source/
producing company)
would be able to get into it and create a ticketing status to feed the
overall income of the produced show.
In the beginning of the week I created an identity on
brownpapertickets - it was pretty easy to use and easily explained...
except the API/Paypal part - seems like I would have to be a much
larger organization for it be worth bringing the sales directly into
my account.
Things definitely got confusing at that point in the set-up.
I'm glad you are separating the lists, I can manage developer speak
and would like to stay up-to-speed....but when I have my producer hat
on, I become "end user" and would rather know that I can move step by
step through a system that is organically built for my show-creating-
ticket-making-needs.
Congratulations on all of the work -
Melissa
On Dec 10, 5:34 pm, Justin Karr <justin.k...@fracturedatlas.org>
wrote:
Reply all
Reply to author
Forward
0 new messages