Greatest Online Product Demo Ever, Palm Foleo

Click on the, "Experience Foleo", button on the Foleo announcement page.

Wow.

Attention Beta Testers!

I wasn't going to do another round of beta testing, but I've made some significant changes to how Pudding operates and I want to do another round of testing. The bad news is when I deploy the next round I'll have to blow away the old database and images. The changes I made were signficant enough to warrant a "do over" on the DB schema.

Look for a new invite email this week.

I've got some more news in the cooker, but I can't announce anything yet. After I launch I'll give everyone the scoop! :)

Tastier Pudding

I've just finished my plan for a looser version of Pudding. It's going to take me at least a week to get everything fully implemented, but I think it's going to be well worth it. Especially from the simplification standpoint.

My original version of Pudding had 2 distinct types of users. "Clients" and "Designers". Which makes sense, but comes with a lot of extra baggage (at least how I implemented it anyway). All the Designers in your account would see all of the active projects, and Clients would only see the projects that were associated with thier "Client Organization". What I found during my beta was that when people were jumping into Pudding they would need an explaination of how to get started. Not good in my book. I would have to explain to them that you need to create a Client Organization, and then you need to add Clients. Then you need to associate the Client Organization with a Project. (I've already lost the person by this point.) Not only is it a lot of mental "associations" to keep track of, but it only allows for 1 Client Organization to be associated with a Project.

So the rigidity came from only having Designers that could see all projects, which is bad if there is more than one creative agency involved. Additionally, each project could only have 1 Client Organization associated, and no-one outside of your account could upload stuff to the project. You could always add an external person to as a Designer, but then they could access all your projects.

It was collaborative inside of the account, but too restrictive for the dynamic world of media-centric creative projects.

I'm implementing a much easier to use system. (and UI)

I'm switching to the concept of "Contributors" and "Reviewers", and each user has either "All Projects" or "Restricted" access. This way the Administrator of the account can mix and match what people can do.

Let's say you're a creative agency, and you're collaborating with another agency for a joint media event for Pepsi Co. & Apple.

The people in your agency are already setup as Contributors with access to all your projects. You would then setup the other agency people as Contributor's, the Nike & Apple people as Reviewers, and using the Restricted access option give them access to only the projects related to this venture.

I've been pretty bored with the last month of Pudding development. I've been working on nothing but billing stuff. Planning this out, and starting the implementation has really gotten me excited again!

I'm sure everyone is tired of hearing (reading) this, but I'm almost done!!! ;)

Pudding, changing taste buds

I'm almost done with my original vision for Pudding. I've literally got some server config to do, and another night's worth of code tweaking.

I've been thinking a lot about what Pudding does, how it does it, who it's competitor's are, and how they work.

Pudding is built around the simple idea of a design group and a client organization. The design group can see all the projects, and "clients" can only see projects that are associated with their "client organization". Only people in the design group can upload, and only people in the client organization can click the "approve" button.

I had a pretty rigid workflow in my head when I made these decisions. But after a lot of thought, and trying to demonstrate Pudding to people, I'm starting to think it's too brittle.

Design projects, teams, and the work they're doing are more fluid and unpredictable.

I was planning on launching in the next day or three.

This sounds crazy, but I want to take the time now to loosen up the app a bit. I've got some ideas and I think I'll have to make some data-model changes. I'd hate to launch it and have to make these changes with people already signed up.

I'm hoping I can implement what I'm thinking of in less than 5 working sessions. That means Pudding can still launch before the end of the month.

Wish me luck! :)

The next release

I've been coding away on the next release of Pudding. The next release will be a private (as in me only) release candidate. I'm implementing all the account management features (payments, upgrade/downgrade, cancelation, etc...) so I can't have anyone in the system.

If I'm lucky the next "release" I put on the server will be the final code base that is used for the launch of Pudding!

If all the stars align I'll be live next Monday. Worst case, I'll be live May, 14th 2008. (It can't much longer than that, can it? ;) )