Last week I served on the jury of a murder trial. It was fascinating, sad, eye-opening and unnerving.

While at the City and County building I did a bit of poking around at City Council's Office and the Mayor's office trying to learn how difficult it would be to get the agendas and minutes from city council meetings (as a start) in order to build a social site based on civic interaction.

The idea would be to do some geo-mapping and keyword mining to connect users to issues, bills, zoning changes and other community actions that are relevant to them and to let users search for, subscribe to and interact on civic issues.

My thinking was to make the entire platform open - probably based on OpenSocial, and allow developers to write applications for features such as polling and surveys, petitions, etc... Also, to make the profile information itself based on OpenID Server / Consumer so that pretty much the entire infrastructure would be open and receptive - with the only major effort being collecting and mining the civic data, rather than building yet another profile management system.

It might be a challenge to collect the data because it doesn't sound like there's a standard nationally for the storage model for civic information of this kind. But, at least in Denver, based on preliminary research, I think it is possible to get the data.

I would be curious to hear what people think about this idea.

A quick note to announce that in an ongoing effort to offer tools for writers we are now in Beta on a Writing Sample tool.

This has not yet been released to the community at large, so please give it a try and let me know what you think. I've added the ability to leave comments, ratings, etc... in the hope that it will be useful as a Writing Workshop tool. If this gets interest, we can build out additional functionality with categories for a more involved writing workshop.

If anyone has suggestions on ways to approach said workshopping tool. Please comment.

Our FaceBook Application (Beta) is off and running:

http://www.facebook.com/apps/application.php?id=5741619609

Already a good preliminary response from our beta users - featured artists were the first to be invited.

See our stats install stats:

The last couple weeks I've taken a fairly wide detour out to the Facebook Platform. I was intrigued by the idea of a social network that lets other developers write applications to enhance it. It's a notion that we've bounced around ourselves - facilitating a platform that allows developers to distribute tools for photographers, bands, artists, and so on. So, I was interested to see how the facebook model worked. Of course, I'm also always interested in building modules that help spread Enfuse's reach through the "distributed" and "embedded" web.

Inevitably, building an app that is actually useful in a social context, that is viral and interesting - and that preserves the integrity with which we want to represent the content our users have entrusted us with takes time. Scope can tend to creep quickly. That, plus a few technical problems such as unpredictable session expiration, trouble with FBML (as compared to iFrame) based Canvas Pages, mediocre (at best) documentation and very few Cold Fusion - based implementations to learn from all swallowed a lot more time than I had anticipated.

Note: I did find a few Cold Fusion resources, notably Facebook Rest Client CFC v1.0 by Andrew Duckett and some sample get and setFBML functions by Cory Johnson did help. It turns out that Cory also had trouble with FBML based Canvas pages and I'm curious to know whether he ever worked that out, and if so, how. Cory, if you're listening...give me a holler.

One such 'aha' moment came when I understood the difference between coding for the canvas vs. the profile page. In truth, the profile page mostly houses FBML which is set in place using the API. Most of the work is done on the Canvas page which can be more or less independent. Of course, any activity on the Canvas can be used to generate FBML to the profile - but once set, the profile FBML the requires an application setFBML call to be updated. The markup on the profile can also be changed independently of user action by using an infinite session and a Chron Job on your application's server. Meanwhile, the Canvas can be as dynamic as you can build it - especially in an iFrame - within the limitations of the Framework.

A few key lessons I learned were to limit the necessary trips between the two servers - to limit what I needed to get from Facebook to as little as possible and to get as much as I could up front rather than to make numerous requests throughout the flow of the application. This meant doing a lot more client side by storing data in JSON objects, using more JQuery, Flash and Javascript interface elements and tuning the interface to as few pages (requests) as possible. Additionally, it is very useful to know which API calls allow "Infinite Sessions" - keys which can be stored at the application level as compared to request based session keys with unpredictable and sometimes very short lived authorizations. Assuming you want to build it taking into account the few users who may not want to allow the application to stay logged in (a default option).

A site that offered some other tips on Facebook "Gotchas" was a resource I read more than once. In fact, the quality of the documentation had me reading just about everything over and over again, trying things several times before it would click.

We're now in Beta on ArtFusion - an application that lets users rate, keyword, comment on a different piece of art a day and provides reports and search capabilities on previous artwork and a new interface to other featured art by the rated artists. At its core it is based on the "Art of the Day" Google Gadget we built a while back - but as a social utility. Contact me if you're interested in trying it out before its released to the Facebook base.

Over the long run, my hope is that a well-tagged, user-rated art database will really help potential buyers browse and purchase. Only a few changes will be required to roll all the functionality of ArtFusion back in Enfuse and integrate it into the Google Gadget as well.

I've wanted to implement a project management tool for a while now. It seemed a natural fit for us. Choosing the tools that we want to incorporate into our offering is more about deciding what types of interactions we want to foster. Similar to how we filter what types of user information we gather, we also want to guide users toward productive creative enterprises. Its important to choose the right tools - too many open-ended message boards, posting forums, etc... and the site can spin quickly into flames and meandering. That's not good for anyone... mostly it hurts the prestige of the users who are trying to present professional artist portfolios.

Even when you leave a single user-defined field available, people will manage to junk it up with prankster data, ie: "Balls Salad" in the User Detail field. Not only has it been inserted into the selections, but others have chosen it - either for fun or on accident, the result: now we can't remove it without forcing it out of the profiles that it is already associated with.

I digress... Recently, I found Project Tracker by Joe Danziger on RIAForge - a great resource for Open Source Adobe Rich Internet Applications. According to Danziger "Project Tracker is somewhat of a clone of the Basecamp application created by 37signals. It is designed to let you manage and collaborate on your projects.

There are some fairly software-centric concepts built into it - for instance, the categories for issues, but in general I think it makes a good collaboration tool for a variety of endeavors, including film production, event coordination, and any multi-person creative endeavor. Project Tracker was built to be fairly self-sufficient, so I added a few features (which I need to document and send to Danziger). I added the ability to search projects and request to join and the ability to accept / decline join requests. I also ported the user data to work with our existing tables and made the username lists link to profiles and fuse mail instead of exposing email addresses.

The main thing I'd like to add in order for this to work better as an art collaboration tool is a "Resource Manager" for itemizing needed items - from sound equipment to video production, to singer, bassist, etc... But otherwise, its a fairly decent tool - and not bad for a 1.0 Beta.

Though I could daydream all day about other features, and may add some as it grows, I don't want to get carried away. In order to facilitate the kinds of community that we are hoping to build, we don't need to have the best project management tool, or the best event calendar (although ours could use some work) - we just need to make sure that we have the right tools, not too many, not too open - ended, then build the community around the talents, endeavors and portfolios of the base.

Well, that's quite a rant just to introduce the private beta launch of Enfuse CoLab. In order to field test it, we're using ti to help organize Art Week - an Art District on Santa Fe event. We will make it available to the public soon.

Plugged a little enhancement in for events this week. On the event detail page users can now RSVP for the event. If others have already RSVP'd everyone can see the Yes | No | Maybes stats.

I can see how some events work better for an RSVP feature than others. But, I can't really see how it could really hurt any event. I would imagine that most people will recognize that this is only one marketing forum for the event - so, they won't get turned off by a low RSVP count. However, a high count might just be the push they needed to decide to go.

The real motivator for adding this, or I should say, the trigger that pushed it up the priority pole was seeing this site: BookTour - "a free online service that connects authors and potential audiences of all sorts, from book groups to civic organizations, from bookstores to corporate events. Authors create their own page (biography, books, tour dates and availability) and any group looking for speakers can find them and contact them directly to arrange for an appearance."

Looks like a useful site. A good idea. And in truth, not far from what we've been trying to build for the wider artist community. So, I thought that adding an RSVP feature would help with events such as lectures, book-signings, and other more inter-personal event types. That reminds me, I better add a couple of event types to the list.

The broader issue that this highlights is that we always struggle between focusing on a specific type of user, and in building our tools so that they can be used for a variety of broader purposes. I figure that if the tool is usable, it will end up being creatively tweaked by our users in ways that we hadn't thought of anyway. In the end, I believe that the arts as a whole benefits from cross-pollination, so I stay broad. Inevitably that means that other, more focused tools, may hit the mark better in some cases.

Here's a little preview into something we'll be rolling out eventually to our userbase - fully functional blogware. So, what's so secret about it? Well, we may need to iron out some kinks first. So, we're not going to advertise it widely, but, if you are reading this, consider it an extra exclusive invitation to setup your own blog by going here: The Blog Builder.

Our hope is that the art and culture savvy members of our community will become a vital voice of civilization in the blogosphere. Wouldn't that be cool? They could join the likes of:

• Art
• Books
• Design
• Literature
• Music

How quickly will this list be growing? How many people read this thing?

Once we've got a bit of usage, we plan to release blog functionality in conjunction with an already underway profile page redesign. Watch for that in the next month.

Launched a new tool today that I'm very excited about. Try it out!

The Curriculum Vitae Builder is one of those features that I've long thought about but had to regularly postpone due to other more pressing needs. But working with JQuery (a javascript library) made the build far less complicated. I was able to crank it out in a couple of short preliminary experimentation sessions and one longer push. The tool itself is fairly straightforward, choose a category and enter information supporting that category. Then, add / delete categories and sort as desired. So, from a data perspective, it was very simple. The complexity arose client-side in manipulating the form elements dynamically. That's what JQuery helps with. But, I'm not here to sing the praises of the library.

Here's why I'm so excited about this tool. I want Enfuse to be a valuable tool for artists and entertainment professionals, and providing a tool for a CV brings us closer to that. Many artists (such as writers) don't get a lot of value from Event / Performer type tools. There was no good way to detail achievements such as publication history, relevant work experience, education, anything... but now there is. I hope this will be a major milestone for our toolset.

Now, I'm thinking about usability a bit. I believe that CV is a term most people (especially in the industry) recognize. But I don't really know that for sure. So, I have called it Resume Builder in the Main Menu, but have called it Artist CV or Curriculum Vitae elsewhere. From a consistency standpoint, that's problematic. I'd rather call it the same thing everywhere. But, I want people to find it and use it. I am very excited about the possibility of seeing lots of the CVs of our user-base. I think it would be very interesting to see the diverse backgrounds and accomplishments of our users.

A quick update. I was just chatting with our design editor (See his blog) about the CV tool and had an interesting usability discussion. I'm going to go ahead and include our dialog below because I think its a very interesting insight into some of the issues that we deal with:

[13:06] design editor: Curriculum Vitae?
[13:06] design editor: so I build it a piece at a time
[13:06] design editor: using the category drop down?
[13:06] publisher: yeah
[13:07] design editor: you have a finished product somewhere
[13:07] design editor: ?
[13:07] publisher: hopefully, its got good usability
[13:07] publisher: my profile just has one category so far
[13:07] design editor: interesting...
[13:07] publisher: http://www.enfusemagazine.com/community/profiles.cfm?user_id=327
[13:08] design editor: my initial reaction is that it's not the best way to build a cv
[13:08] publisher: why do you think that?
[13:09] design editor: well, i would think that if you're going to have pre-defined categories to begin with then it is more intuitive to simply have those all laid out on a template for the user to fill in the ones that are applicable
[13:10] publisher: i see
[13:10] design editor: It was just my first take really... when I got to the page it 's what struck me
[13:10] publisher: that's good
[13:10] publisher: i can see that
[13:10] design editor: I like the way it works though
[13:10] design editor: on your profile
[13:10] publisher: I had thought about what you're saying, but worried that there are so many different user types and so many of the fields are not applicable. That most people will just choose a few. Or at least a few at a time.
[13:11] design editor: it doesn't stand out as something separate from the page
[13:11] design editor: so i don't think i'd call it a c.v. builder
[13:11] design editor: it looks more like something to integrate into how a user builds their profile in general
[13:11] publisher: k... not sure what to call it
[13:11] design editor: do you see what i'm saying though
[13:11] publisher: in order to express what it does
[13:12] publisher: i do
[13:12] publisher: i also have a standalone version of it which I'd like to make printer friendly http://www.enfusemagazine.com/community/CV.cfm?user_id=327
[13:12] design editor: you have it off of the profile page and the message seems to be "build your resume"
[13:12] design editor: as opposed to integrating it into the users set of tools to build their profile
[13:12] design editor: i think it's part of building your profile
[13:12] publisher: so, you would just call it "Profile Builder"
[13:13] publisher: Profile Enhancer...?
[13:13] design editor: i don't think i'd call it anything
[13:13] design editor: i think i would include it on the "Edit Profile" page
[13:14] design editor: just like you have "User Detail: (select all that apply)"
[13:14] publisher: hm
[13:14] publisher: I should link to it from Edit Profile at least
[13:14] design editor: i don't know how it integrates... but that's where i see it
[13:14] publisher: i hear that
[13:14] publisher: need to consider that
[13:14] design editor: why is it a separate link?
[13:15] publisher: I suppose I consider Edit Profile just your general stuff, and this more of a tool...
[13:15] publisher: but, it doesn't necessarily have to be a seperate link
[13:15] design editor: Well, I've said before that we need to be able to create more interesting, more robust profiles
[13:16] publisher: although, not sure how complicated it would be to just integrate into edit profile
[13:16] design editor: I think this is part of changing / enhancing how we enfuse users build our profiles
[13:16] publisher: probably not very hard
[13:16] publisher: yep, that's the goal
[13:16] design editor: this is the sort of thing where we can get more creative, include more information about ourselves
[13:16] publisher: i didn't want to add it directly to the "register" page
[13:17] design editor: i like the way this stuff goes up at the top, by the way
[13:17] design editor: i wonder if there's a way for a user to add a category (an aside)
[13:17] publisher: when we allow for that we get junk data very quickly
[13:17] publisher: stuff like "balls salad"
[13:17] design editor: yeah - ok
[13:17] design editor: i understand that
[13:18] design editor: why don't you want to put it on the REGISTER page
[13:18] design editor: isn't REGISTER basically the same stuff as EDIT PROFILE
[13:18] design editor: except just the first time
[13:18] publisher: worried that it will drop adoption
[13:19] design editor: ah
[13:19] design editor: ok
[13:19] publisher: especially for the other user types - venues / event promoters
[13:19] design editor: ok... I'm with that
[13:19] publisher: but, I could have a button that expands the tool that is optional
[13:20] publisher: as in - add details
[13:20] publisher: +
[13:20] publisher: expands it
[13:20] design editor: well, or else we convey that once you're created as a user, we have the ability to add info
[13:20] design editor: by going into Edit
[13:20] design editor: I think that's fine
[13:20] publisher: yeah
[13:20] publisher: I do think I should add it to Edit
[13:20] publisher: you are right
[13:21] publisher: i might keep it seperate also, at least for a while... want to highlight it... part of the problem being that if I add it to Edit Profile - not sure how many people who have already registered will find it

I've started playing with iGoogle and have found that I'm actually looking forward to my Einstein Quote of the Day and Reuters: Oddly Enough feeds... So, I figured I'd make an Enfuse Google Gadget so that us Enfusians (Enfusers?) could enjoy the good groovy googleness of having a different masterwork of underground art delivered to our iGoogles - and to all those other Googlers out there.

Okay, a bit slaphappy with this post - but here it is:

Just put this on your webpage to share this gadget:

Now you can add the Enfuse Google Gadget to your website so that you and your friends can see your art show up on the "Google".

Its about time, I know. But I finally got to fix the registration process a bit. Its always been a bit of a conundrum how to make the flow work better. Unlike other profile oriented sites, our model allows a user to have multiple artists, venues, etc... listed under a single user account. We are attached to that model. However, it can be really confusing for folks who are trying to promote a single entity. They assume, logically, that once they've registered, their profile is the entity that they are promoting. Especially for a writer, or a photographer, or fine artist who's artistic entity is one and the same as their name. Asking a writer to register a user profile, and then separately, register as an artist does not seem logical.

In fact, this multi-artist / multi-entity user profile model has negatively impacted usability and has been the cause of a lot of the negative feedback we get from users about not understanding what they're supposed to do after they register. As a result, there are many user profiles for artists that don't have artists registered under the profile and thus, don't get a lot of the tools that are designed for artists - media upload, for example. It has been a challenge to figure out how to preserve the model but improve the overall flow of user registration.

We began with a simple checkbox - "I perform under this name"... just as a flag for us to preserve the "screenname" and carry it along in the process. We then organized UserTypes into families - Artist / Venue (actually an old concept re-introduced). This "family" allows us to automatically direct the user to the "Add Gallery / Venue" or "Register Artist" form with a number of fields prepopulated with values from the user profile. Then, the distinct usertype, "Writer" as compared to "Filmmaker" allows us to provide appropriate messaging (hopefully).

It all seems simple enough, and in fact, was not an especially challenging technical exercise. It was really more of a process of trying to identify how to best guide users through the first steps in creating a profile that will be of value to their enterprise. Now I am very curious to observe whether we get fewer "incomplete" profiles.