Plans and request for feedback

Developer
Feb 11, 2011 at 12:02 AM

Hi all

This is just to let you know what my development plans are (as part of my university project).

I've already posted about improving the speed at which thumbnails are loaded.

My next few changes are then going to be to do some refactoring of the code and upgrade the FlickrNet library. I won't post these changes to the forum because they are not likely to offer anything new to you but the should help me make my later changes. They are:

1. Tag syncing - sync changes in tags from local copies to Flickr and in the opposite direction, ideally without having to retransmit the entire image to save bandwidth and time.

2. Two way syncing - make it so that that changes on the Flickr side are reflected locally e.g. if files are deleted from the set on Flickr or new ones are added then do the same in your local copy

3. Improve the current command line functionality so that you can e.g. specify which folders/sets to sync and in which direction.

In order to do this I will have to make some UI changes which is where I'm really asking for feedback. Because the changes I'm hoping to make will effectively pair the local folder with its Flickr set (as it is now but even more so) I am thinking about removing the Tree List pane on the left of the window and instead having just a list of pairs which you can add, delete, edit, etc. It seems to me that this is the simplest way to do it without making it too confusing. I have a photoshop mockup you can look at here: http://www.flickr.com/photos/danieljryan/5434890338/lightbox/

Please note, this is a very rough mockup, I would also have buttons on the menu bar allowing you to create a new link or remove an existing one as well as sync them up or down. Also I would try to keep it so that you could have subfolders nested and clicking the top one would select them all, that might be more difficult though.

I'm eager to hear if anyone has any thoughts about this.

Thanks for reading.

Coordinator
Feb 12, 2011 at 1:31 PM

A few comments:

1. I've always kept away from writing to local files because any bug on this code could eventually destroy very valuable pictures. In order to have a two way sync, you should have everything that writes to local files very clearly separated and all of this should be disabled by default. Only if the user specifies that he wants to write on the local files and understands the risk should he be able to have the two way sync.

2. Regarding the UI changes, I think they can be useful but again they should be kept as an option (another way of viewing). I believe the tree view is extremely useful. In my case, for instance, I sync all the folders from my pictures main folder. In the tree view, I'm able to see easily the structure of folders and which ones are mapped to flickr or not. Eventually you could put the new columns on the tree view instead of going to a completely different view.

Developer
Feb 21, 2011 at 10:15 PM
geada wrote:

A few comments:

1. I've always kept away from writing to local files because any bug on this code could eventually destroy very valuable pictures. In order to have a two way sync, you should have everything that writes to local files very clearly separated and all of this should be disabled by default. Only if the user specifies that he wants to write on the local files and understands the risk should he be able to have the two way sync.

2. Regarding the UI changes, I think they can be useful but again they should be kept as an option (another way of viewing). I believe the tree view is extremely useful. In my case, for instance, I sync all the folders from my pictures main folder. In the tree view, I'm able to see easily the structure of folders and which ones are mapped to flickr or not. Eventually you could put the new columns on the tree view instead of going to a completely different view.

Thanks for the feedback and sorry for the late reply.

1. I agree and I hope to avoid this by doing several things. If I am writing tag information to local files only this should be safe and not damage the image. If the image is being deleted then it will be moved to the Recycle Bin so the user has to decide to delete it from there. Alternatively, it could be put in a backup folder, I'll have to see how much time I have to play with this. I don't anticipate there being any other actions e.g. overwrite a local image because the only changes which would be brought back would be in the tags which can be done just by writing new tags into any existing image. Since this would be using Microsoft's API hopefully it would be safe. To address the broader point I'm not sure that it will be a true two way sync - it might make more sense to have the user explicitly say I want to do an Upload Sync or a Download Sync not something which would attempt both at the same time as you're right that could be confusing / dangerous.

2. Due to time limits and how much it is used in the current code I agree that the current TreeView will probably be kept. I will try to keep the changes just to the right pane and leave the TreeView intact unless I manage to somehow merge them as you suggest. I realise that having the TreeView as it is can be very useful for the reasons you already posted.

Many thanks again for your input.