Wednesday, July 06, 2005

I Give In

In life you win some, and you lose others.  Today I will admit my defeat with regard to my issues with ipowerweb.  I have been unreasonable in my wants, and after talking to more than a few technical support reps trying to convince them that they needed to change php.ini for me, I finally realized that when you have 400,000 customers, making a 'simple' change to a configuration file on one server would introduce inconsistencies making support an utter and complete nightmare.  So with my newly gained understanding, I apologize to ipowerweb.

Understanding the situation still doesn't fix the problem though.  I discussed some of the options with regard to resolution with my father last night. 

  1. Sign up for dedicated server hosting at $65/month.
  2. Change my home ISP, rent a static IP, buy a box, and host it myself.
  3. Find an acceptable 3rd party RSS generator and hosting service.
  4. Try to find a corporate sponsor to host the program where php.ini can be changed.
  5. Modify the program so that it doesn't do file uploads.

 It seems that option three or five seem to be the most reasonable.  I think that I am going to go ahead and pursue option number five, but I feel badly because I know that it really will destroy the ease of use.  You see, with the program the way it currently stands, users don't have to have an FTP account – when they sign up, a directory is created for them, and all they have to do is submit the file in the HTML form, and the program does all the work.  Under the new paradigm, I won't be able to do anything that deals with the upload, because of the values in php.ini.  This means that the user will have to have/know three things:

  1. They will need FTP access to a server somewhere
  2. They will have to know the URL to the directory that they FTP files to (though I may be able to capture this so they only have to learn it once)
  3. They will have to know the name of the file they are uploading, and be cognizant that it can't have any spaces in the name, and that the name must be unique
  4. When updating a podcast .mp3 file, the user will have to delete the old file manually and replace it manually
  5. Once the file is uploaded to the server, the user will then be able to use my program to input the file name, and I can update the RSS feed.

Looks like the program will be loosing a lot of functionality.  In my opinion, it takes the program from something that most any computer user could use to something that only the more "technically savvy" would want to do. 

Maybe I shouldn't worry or care about who could or couldn't use the program and what level of technical expertise one must have to use it.  The argument could be made that only technically savvy people write blogs, and only the people up on the very latest of the World Wide Web are going to be into podcasting.  This would mean that having access to an FTP account probably wouldn't be an issue, right? 

Of course, given enough time, if this podcast thing takes off the content management systems of the world will build automatic support for this stuff into products.  However, if the CMS was written in PHP or even CGI and is hosted on a shared server, I see this as a great problem, as you will hit the upload issue again.

Blogger has its version of podcasting called audioblogger where you can dial a California phone number and record your cast there, and they will post it to your blogger blog.  However this solution just doesn't cut it for me.  It isn't podcasting in its truest form, but I am sure will fill its niche. 

If there is anything I am learning it is that we need to be making things simpler on the Internet – not more difficult.  I watch my grandparents, aunts, uncles, cousins, parents, and siblings work with the Internet, and it seems to me that it is still a very imperfect user experience.  Seriously, filling out an HTML form correctly is hard enough, let alone clicking that browse button, which brings up the dialog box to let you choose the file you want to upload. (If you understand file systems and care where you save stuff, this isn't a problem, if you don't understand file systems – let alone care where you save things this becomes very challenging.)  Walking some of the above-mentioned users through the FTP process with an FTP client, or maybe just IE would be doable, but MUCH more challenging. (Think upload dialog box times 10 with complexity.)  This is not to say that I think my family is dumb, as they are not.  It is to say that the user experience should be something that anyone can do – easily, without a lot of training, experience, or supervision.

So I have this little application.  It does some great things, and has the potential to make a task easier for some family and friends, but because I am not a commercial entity, the project just isn't feasible.  I will make the changes to the program so that my father can upload his podcasts.  I don't want to throw away this version, so I may try to set up a toggle in the installer that would allow me to either run the uploads for the users, or require that the users upload the files external to the program.  It will involve some changes to the database, and program logic, but if I get motivated and excited about it again sometime here soon, I think I will be able to get that pushed through.

In the meantime there are some security fixes that need to be fixed regardless of the upload process, and a really annoying bug dealing with file mime types.  On the positive side, if the users have to do their own uploading, then I don't have to worry about the whole mime game anyway.  Though I think I have a solution, so I may try to implement it just to see if I was right.


1 comment:

jeff said...

Have you looked into I haven't used them myself but I've heard a few good things about them ( I also did a quick google search and it appears they'll let you compile and run your own version of PHP (see or I didn't look at the articles close enough to see if they would work for your situation, hopefully they will.