Interactive Development: Photo Transfer Feature Ideas

Tagged Under : , ,

Here are some ideas for the next dev sit-down for my Photo Transfer application, please give me your thoughts on which ones are valid, which ones aren’t and what I am missing…

  • The ability to separate RAW and JPG files into separated folders if you shoot in RAW+JPG modes.
  • The ability to save your previous source and destination folders
  • pre-populate the new folder name with the date/time formatted how you want
  • Removing the status text and using a progress bar with a label to indicate the current action
  • add a preview box so you can view the photos being transferred
  • add a cancel button to stop the process

Those are my current tweaks I will add next, I have decided to make this an interesting project. I am going to build this application from the genesis yesterday and the resulting code I banged out last night, and blog each iteration as well as my comments, thoughts and ideas, and then when this project is done, or at least at a full version number, you can see the entire development lifecycle chronicled and see how it changes from concept to completion.

Anyone up for a Beta Test? Photo Transfer v0.1

Tagged Under : , ,

image I decided I needed a little app to make me more diligent about backing up my photographs and being sure I don’t destroy them while I am making web previews, edits, etc.

I started today with a little user scenario that goes something like this:

I insert a CF card into my computer. Autoplay launches and asks me if I would like to open the photos. I say yes with Photo Transfer and the application is launched.

My source folder is pre-filled in from AutoPlay and I browse a working folder location of my desktop, and a archive folder of my external hard drive’s “Photo Archive” folder.

I enter “06-03-2008 Walkabout Photos” as my new folder.

I check a box to delete the files from the card after I move them.

I click start and blam, my photos are copied to two folders, and the source files are deleted.

Well, I am almost there. Version one is fully functional minus one feature and has one bug (so far!)

So far I haven’t figured out the AutoPlay functionality quite yet. I will ask some of the .net Gurus at work…sometimes it’s handy to work @ Microsoft!

The bug is that so far if you have chosen a folder with folders beneath it, and selected the box to delete the source files, any files in folders aren’t deleted.

It’s a start though! I am uploading the project and a zipped copy of the executable if you want to use it or play with it. By all means let me know of any hiccups that you notice.

Development Discussion - Feature Theory

Tagged Under : ,

software_lifecycle There has been an interesting discussion floating around work recently that I thought would be very interesting to share here. I am excited to hear feedback and discussion on this topic as it is not only fascinating, but very relevant to my work.

Scenario: You have built a fantastic application to build widgets. Your application is a great v1 at building widgets and you have much room for improvement, but the foundation of widget building is solid.

Feature Ask 1: Customer A has been using Widget Builder Plus for a few months and has found that it’s very easy to build thingies with it. If you use a few parameters for different purposes, it builds very slick thingies. Can we put in a thingie generator to keep from having to use widgets to build thingies?

Feature Ask 2: Customer B has been using Widget Builder Plus to build Thingamabobs. By hacking the XML files generated by Widget Builder Plus, you can generate a basic thingamabob that only needs modest modification to be a full fledged thingamajiggy.

Of course this is totally laced in humor and mildly facetious, but you get my point. In the world of software development, it’s very important to be scenario minded so you are sure that your building features for your users, not a Swiss army knife that can do anything but is difficult to navigate.

So the question I pose is this. If you develop an application, and find a large portion of your users are using the application for a different purpose entirely, do you:

A) Add more features from the alternative usage to the application to satisfy the users that are using your program incorrectly?

B) Retrain your users to use your application more effectively for it’s intended purpose.

It’s really a difficult problem, you surely do not want to lose users of your application by removing the abilities that they are finding so useful, but at the same time, if you are looking at the evolution of your product 2, 3 or more versions down the line and comparing it to your product’s vision, do you risk feature bloat and confusion to keep functionality you never intended to provide?

Thoughts?