Hello,
I ahve a folder in my docs folder called Settings and in Settings I store all
the configuration/settings/preferences files from applications installed on my
system. This allows me to quickly import those back into brand new fresh
insatllations after a reinstall or on a different system to get it customized
to my liking.
I have found the filepath to all the settings for Adobe Lightroom and have
created a folder within my Settings folder into which I want the Adobe
Lightroom Preferences to be backed up in.
Basically, I have my FFS sync settings file which I need to backup the adobe
lightroom stuff to my main drive first, then backup all those to my backup
drive.
I expected that If I addded another folder pair to mirror the lightroom
settings then this should work but when I run a "Compare", I get an
"Directories are dependent, Be careful..." error.
How can I solve this. I would rather not have multiple Sync Settinsg files but
have it all in 1 file that I can start running and it will complete the backup
all autonumously for me.
If you wish me to send you my sync settinsg file, let me know and what email
address to send it to.
Also, does the order of folder pairs make any difference to how the sync is
done. Is the top folder pair completed first then move down the list or not? I
hope it does as it would make sense to me. If so, how can I move folder pairs
up and down to get them in the correct order?
Help with baking up Adobe Lightroom Prefs
- Posts: 50
- Joined: 7 Nov 2009
- Posts: 50
- Joined: 7 Nov 2009
Also, maybe you could add a disable button to folder pairs so you can toggle a
pair on or off temporarily. - Just a little extra feature that some users may
find helpful at times.
pair on or off temporarily. - Just a little extra feature that some users may
find helpful at times.
- Posts: 50
- Joined: 7 Nov 2009
Any chance of some help with this? It would be highly appreciated.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
>"Directories are dependent, Be careful..." error.
This error comes up, when one folder name is part of another folder name. When
using one folder pair, this usually doesn't make sense. When using more than
one folder pair, there is the risk, that syncing one pair may affect the sync
of another pair: The reasons is that synchronization works top to bottem with
regards to folder pairs (your second question). Therfore If the
synchronization of the first FP changes files, this change is not reflected in
the data shown for the dependent folder pair. This could lead do undefined
results (although in practice you'll see an error "source file missing" or
"target file already existing", which isn't too bad)
>how can I move folder pairs up and down to get them in the correct order?
Currently this can only be done by manually exchanging paths. (the feature
request is partly tracked here: [404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=2789932&group_id=234430&atid=1093083]
>could add a disable button
Generally I try to keep the GUI lean from buttons that one needs only
seldomly. In this case the behavior can be achieved by deleting a folder pair,
but not saving the change to the configuration.
This error comes up, when one folder name is part of another folder name. When
using one folder pair, this usually doesn't make sense. When using more than
one folder pair, there is the risk, that syncing one pair may affect the sync
of another pair: The reasons is that synchronization works top to bottem with
regards to folder pairs (your second question). Therfore If the
synchronization of the first FP changes files, this change is not reflected in
the data shown for the dependent folder pair. This could lead do undefined
results (although in practice you'll see an error "source file missing" or
"target file already existing", which isn't too bad)
>how can I move folder pairs up and down to get them in the correct order?
Currently this can only be done by manually exchanging paths. (the feature
request is partly tracked here: [404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=2789932&group_id=234430&atid=1093083]
>could add a disable button
Generally I try to keep the GUI lean from buttons that one needs only
seldomly. In this case the behavior can be achieved by deleting a folder pair,
but not saving the change to the configuration.
- Posts: 50
- Joined: 7 Nov 2009
Right so running my sync should do exactly as I want then?
It's syncing settinsg from their default location to a location in documents
and then the next folder pair syncs all my documents onto my external drive.
So it basically does one folder pair after another?
A suggestion then, If multiple folder pairs are being used, it would seem
logical to have a file list shown for what will happen for each sync. Maybe
these could be in a list and you expand and collapse them to see which ever
you are after.
I also do think that buttons or functionlaity such as moving folder pairs up
and down, removing a pair entirely and to temporarily disable a pair should be
included in the GUI as it does seem logical.
Also, I do think that the program would benefit from a redesign of the GUI
layout. This is not to say it is bad but to improve on what is existing
already as extra features have been added they have just been placed on top
and I do think a bit of reorganisation would do the application a world of
good and also help people to more easily figure out and manage to set up an
effective sync routine.
Even I had difficulties figuring out what parts did what as some are badly
identified or located in a strange place.
I would like to offer my services to you to work alongside you to maybe have a
go and designing a restructured interface for FFS to improve its usage or its
users.
I would be willing to work with you on this, if you would like more feedback
on the ideas I ahve please let me know or either email, or IM me. I use the
email set up on this forum and can be added by that on Windows Live Messenger,
Skype or AIM.
If you do not wish to see my feedback then no worries, but I do think it would
be beneficial to everyone involved.
Thanks
Regards,
Neil
It's syncing settinsg from their default location to a location in documents
and then the next folder pair syncs all my documents onto my external drive.
So it basically does one folder pair after another?
A suggestion then, If multiple folder pairs are being used, it would seem
logical to have a file list shown for what will happen for each sync. Maybe
these could be in a list and you expand and collapse them to see which ever
you are after.
I also do think that buttons or functionlaity such as moving folder pairs up
and down, removing a pair entirely and to temporarily disable a pair should be
included in the GUI as it does seem logical.
Also, I do think that the program would benefit from a redesign of the GUI
layout. This is not to say it is bad but to improve on what is existing
already as extra features have been added they have just been placed on top
and I do think a bit of reorganisation would do the application a world of
good and also help people to more easily figure out and manage to set up an
effective sync routine.
Even I had difficulties figuring out what parts did what as some are badly
identified or located in a strange place.
I would like to offer my services to you to work alongside you to maybe have a
go and designing a restructured interface for FFS to improve its usage or its
users.
I would be willing to work with you on this, if you would like more feedback
on the ideas I ahve please let me know or either email, or IM me. I use the
email set up on this forum and can be added by that on Windows Live Messenger,
Skype or AIM.
If you do not wish to see my feedback then no worries, but I do think it would
be beneficial to everyone involved.
Thanks
Regards,
Neil
- Posts: 50
- Joined: 7 Nov 2009
Hey, I ahve just tried running the sync.
It synced the settinsg from the default location in which they are kept by
lightroom to a folder in my documents area - That worked fine - First Folder
Pair
The second FP was to sync all of my Documents folder to my external HDD and it
DId make a new folder called "Lightrrom Settings" within documents like I had
done, BUT it did NOT copy the settings into as as it should have done.
Surely, each folder pair should be treated separatley?
This is another reason why each folder pair should ahve it's own file listing
in order to all the user to see what will be synced and each one should be
independant from each other and base it's listings on whatever state the
filesystem is in, AFTER all previous folder pairs have been completed.
I know this sounds confusing but it really would simplify multiple folder
pairs.
It synced the settinsg from the default location in which they are kept by
lightroom to a folder in my documents area - That worked fine - First Folder
Pair
The second FP was to sync all of my Documents folder to my external HDD and it
DId make a new folder called "Lightrrom Settings" within documents like I had
done, BUT it did NOT copy the settings into as as it should have done.
Surely, each folder pair should be treated separatley?
This is another reason why each folder pair should ahve it's own file listing
in order to all the user to see what will be synced and each one should be
independant from each other and base it's listings on whatever state the
filesystem is in, AFTER all previous folder pairs have been completed.
I know this sounds confusing but it really would simplify multiple folder
pairs.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> Right so running my sync should do exactly as I want then?
I'd check first why you have dependent folders in first place. In most
synchronization scenarios independent folder should suffice. So most of the
time it is an indication of a configuration error, but not in principle.
> So it basically does one folder pair after another?
Yes.
> A suggestion then, If multiple folder pairs are being used, it would seem
logical to have a file list shown
Yes, there is open room for improvement. E.g. [404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=2789932&group_id=234430&atid=1093083]
> I also do think that buttons or functionlaity such as moving folder pairs up
and down, removing a pair entirely and to temporarily disable a pair should be
included in the GUI as it does seem logical.
I agree. But I don't have a nice design idea yet.
> Also, I do think that the program would benefit from a redesign of the GUI
layout.
> Even I had difficulties figuring out what parts did what as some are badly
identified or located in a strange place.
If you see something that really can be improved it should be! So generally
I'm always interested in improvments. But it may not be that easy in detail.
The target audience is large and you can't serve everybody. But this shouldn't
stop one from thinking about improvements, of course. Even if it turns out to
be a smaller thing, the large user base makes is worthwhile.
> I would like to offer my services to you to work alongside you to maybe have
a go and designing a restructured interface for FFS to improve its usage or
its users.
You're welcome. Email is fine but a separate forum thread may be better in
case someone else sees it and has a good idea.
> The BUT it did NOT copy the settings into as as it should have done.
I'd need a closer look on the configuration to find out what you want to do.
But maybe you can find out yourself by trying to sync the second folder pair
in isolation. I'm really busy, as always ;)
> Surely, each folder pair should be treated separatley?
It is completely separate (Although it is shown in a simple merged list.).
Unless of course the user configured it to be dependent, by using the same
folder name in multiple folder pairs, e.g. as single source for multiple
targets, which is fine.
I'd check first why you have dependent folders in first place. In most
synchronization scenarios independent folder should suffice. So most of the
time it is an indication of a configuration error, but not in principle.
> So it basically does one folder pair after another?
Yes.
> A suggestion then, If multiple folder pairs are being used, it would seem
logical to have a file list shown
Yes, there is open room for improvement. E.g. [404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=2789932&group_id=234430&atid=1093083]
> I also do think that buttons or functionlaity such as moving folder pairs up
and down, removing a pair entirely and to temporarily disable a pair should be
included in the GUI as it does seem logical.
I agree. But I don't have a nice design idea yet.
> Also, I do think that the program would benefit from a redesign of the GUI
layout.
> Even I had difficulties figuring out what parts did what as some are badly
identified or located in a strange place.
If you see something that really can be improved it should be! So generally
I'm always interested in improvments. But it may not be that easy in detail.
The target audience is large and you can't serve everybody. But this shouldn't
stop one from thinking about improvements, of course. Even if it turns out to
be a smaller thing, the large user base makes is worthwhile.
> I would like to offer my services to you to work alongside you to maybe have
a go and designing a restructured interface for FFS to improve its usage or
its users.
You're welcome. Email is fine but a separate forum thread may be better in
case someone else sees it and has a good idea.
> The BUT it did NOT copy the settings into as as it should have done.
I'd need a closer look on the configuration to find out what you want to do.
But maybe you can find out yourself by trying to sync the second folder pair
in isolation. I'm really busy, as always ;)
> Surely, each folder pair should be treated separatley?
It is completely separate (Although it is shown in a simple merged list.).
Unless of course the user configured it to be dependent, by using the same
folder name in multiple folder pairs, e.g. as single source for multiple
targets, which is fine.
- Posts: 50
- Joined: 7 Nov 2009
Hello,
Here is my proposed new User Interface. I understand that it is a radical
change but I do feel that it allows for easier understanding as to what part
of the interface applies to what part of the sync process.
Also apologies for my layout, it's just rough but should show my idea
effectively:
[404, Invalid URL: http://www.neiltonge.co.uk/external/Proposed%20FFS%20UI.jpg]
It basically utilises a slightly wider window than currently.
- At the top left are the standard buttons for loading and saving configuration files.
- Below that is a list box with each row being a folder pair. The item highlights the source and destination directories. (Grey one is currently highlighted/selected pair) This list would obviously scroll if lots of folder pairs were set up.
- The buttons below the folder pair list item then allow the user to assign specific settings to each of the folder pairs. So they can choose, compare settings, filters, disable/enable the pair temporarily, remove the pair completely, move the pair up or down and choose sync settings. - This is all on a per folder pair basis. - Entirely separatley.
- The stats box below should be global and is only populated once a compare has been run.
- In the right hand side of the application, is the file list indicating the changes, this populates once a compare has been run and as you click the folder pair buttons in the list item to the left hand side the file lists change to show the changes per folder pair.
- The stats box on the right hand side, shows the stats for the folder pair currently selected.
-Then the Compare and Sync buttons are at bottom right in large for easy usage.
I feel that this layout makes it very easy to understand what settings are
being applied to which folder pair.
It all basically revolves around the folder pair list item on the left and the
rest of the interface changes around what pair is highlighted.
Any other functionality basically needs to be decided whether it is relevant
JUSt to the folder pair, or globally. Global things can be placed on the left
hand side at the botttom and per folder pair things are placed on the right
hand side at the bottom.
I hope this will be of some use as I am sure trying out this User Interface
would be extremely beneficial.
Of course, I am not the one writing the application so I'm sure you will have
some feedback on it. I really like FFS and ahve reccomended it to many people
so far who are pretty much using it on a daily basis for backup purposes so I
am trying to be of use and be helpful to you.
I can't wait to hear what you think. What is your email address by the way?
Thanks
Regards,
Neil
Here is my proposed new User Interface. I understand that it is a radical
change but I do feel that it allows for easier understanding as to what part
of the interface applies to what part of the sync process.
Also apologies for my layout, it's just rough but should show my idea
effectively:
[404, Invalid URL: http://www.neiltonge.co.uk/external/Proposed%20FFS%20UI.jpg]
It basically utilises a slightly wider window than currently.
- At the top left are the standard buttons for loading and saving configuration files.
- Below that is a list box with each row being a folder pair. The item highlights the source and destination directories. (Grey one is currently highlighted/selected pair) This list would obviously scroll if lots of folder pairs were set up.
- The buttons below the folder pair list item then allow the user to assign specific settings to each of the folder pairs. So they can choose, compare settings, filters, disable/enable the pair temporarily, remove the pair completely, move the pair up or down and choose sync settings. - This is all on a per folder pair basis. - Entirely separatley.
- The stats box below should be global and is only populated once a compare has been run.
- In the right hand side of the application, is the file list indicating the changes, this populates once a compare has been run and as you click the folder pair buttons in the list item to the left hand side the file lists change to show the changes per folder pair.
- The stats box on the right hand side, shows the stats for the folder pair currently selected.
-Then the Compare and Sync buttons are at bottom right in large for easy usage.
I feel that this layout makes it very easy to understand what settings are
being applied to which folder pair.
It all basically revolves around the folder pair list item on the left and the
rest of the interface changes around what pair is highlighted.
Any other functionality basically needs to be decided whether it is relevant
JUSt to the folder pair, or globally. Global things can be placed on the left
hand side at the botttom and per folder pair things are placed on the right
hand side at the bottom.
I hope this will be of some use as I am sure trying out this User Interface
would be extremely beneficial.
Of course, I am not the one writing the application so I'm sure you will have
some feedback on it. I really like FFS and ahve reccomended it to many people
so far who are pretty much using it on a daily basis for backup purposes so I
am trying to be of use and be helpful to you.
I can't wait to hear what you think. What is your email address by the way?
Thanks
Regards,
Neil
- Posts: 50
- Joined: 7 Nov 2009
Sorry, linked failed. Here is the design:
[404, Invalid URL: http://www.neiltonge.co.uk/external/FFSUI.jpg]
[404, Invalid URL: http://www.neiltonge.co.uk/external/FFSUI.jpg]
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> Here is my proposed new User Interface.
> I understand that it is a radical change
Radical change is no problem in general if it is the "right" thing to do. But
there are a lot of constraints as well as pros and cons that need to be
evaluated. Mostly centered around the "vision" and a set of core requirements
that initially lead to the creation of FFS. This means that most of the time
there is no valid argument of "better" or "worse" per se, but only in relation
to what the tool wants to represent. I'm saying this so that you don't
misinterprete a denial of a design change as a criticizm of its underlying
idea. The question here is more whether it fits for this particular tool and
(most of) its users. A tool that tries to please everybody ultimatively serves
no one. So I go as far as possible to satisfy most users, but no further.
> but I do feel that it allows for easier understanding as to what part of the
interface applies to what part of the sync process.
A picture is always a very good idea to convey abstract information.
> It basically utilises a slightly wider window than currently.
Additional window width is a problem here. The number of columns already
constrains width to a high degree. Especially with regards to lower
resolutions and netbooks I fear, a change increasing overall width is not
acceptable. Please also don't forget the single-folder pair sync-scenario,
which is probably the dominant usecase. It may not be impeded by the
possibility of having multiple pairs. The paradigma here is "don't pay for
what you don't need".
> At the top left are the standard buttons for loading and saving
configuration files.
This is a strong bias towards backup scenarios. The usecases FFS wants to
support are: 1. folder comparison, for example binary comparison to identify
structural changes between different versions of data and also to enable data
integrity checks 2: synchronization/backup: these cannot be strictly
separated. Former emphases the idea of sharing data ownership between
different physical media while latter is more about fail safe data redundancy.
Most users problably tend to use features of 2. Feature 1 on the other hand is
functionality that I personally require from time to time but found a shortage
of good tools to conveniently and effectifly accomplish this task. Fortunately
1 can be combined almost seamlessly with 2 within a single tool, without
creating contradiction or dependency in program usage. To make this long story
short: I strive to keep a balance between 1 and 2.
> Below that is a list box with each row being a folder pair.
Folder paths are very long, which is a problem with width as mentioned above.
Also the path information is redundantly shown above both grids. The general
idea of having a group of high level clickable objects, that show their
associated data on the grids is interesting. But this approach has much
similarity with the scenario where a user has a list of gui configuration
files, containing one folder pair each. There he also would sync one config
after another, seeing only the information specific for this pair.
Orthogonality of function is an important design aspect which would be partly
violated here. I think the good part of this idea is that it allows the user
to distinguish data related to different pairs. The downside is, the user
needs to click on each pair to see its data. This design is pretty much
equivalent to a tabbed main screen that some sync-tools have implemented.
Maybe there is some way to distill the good parts of the idea avoiding the
drawbacks. Seeing data related to a single folder pair is similar to a view
filter. This however would introduce the need to add additional buttons, which
I want to avoid in general...
> - The buttons below the folder pair list item then allow the user to assign
specific settings to each of the folder pairs. So they can choose, compare
settings, filters, disable/enable the pair
Buttons are really my least-favorite device to allow interfacing with the
user. It is too easy to get into the "one function, one button" thinking that
way too many other overbloated software has chosen to. I think it's better to
see yet another gui option as the last design alternative rather than the
first. Successful sofware implementing this philosopy is represented by Google
or Apple. Surprisingly often you get away solving a problem in another, non-
intrusive way, even more elegantly and user-friendly than a button-option, by
just thinking harder about what it really is the user wants. If this answer
kann be determined by the tool, e.g. by an algorithm under the covers, there
is no need to bother the user with another visual distraction. To make it
short: Way too many buttons.
> temporarily, remove the pair completely, move the pair up or down and choose
sync settings. - This is all on a per folder pair basis. - Entirely
separatley.
This would be an improvement against current implemenation where sync-config
and filter-buttons are shown for each pair at once. As for "temporarily
disabling a folder pair" I'm not sure if this really is such a big usecase.
> - The stats box below should be global and is only populated once a compare
has been run.
This is something that theoretically could be implemented in the current GUI
layout already. It would however have a negative impact on the overall
perception of the main screen. Notice the high symmetry between left and right
hand side of the screen.
> - The stats box on the right hand side, shows the stats for the folder pair
currently selected.
I'm not sure if its a good idea to show statistics twice. As this is rather
detailed information its impact on visual distraction should be minimized. And
when having to choose between global and local sync-stats I'd choose the
global ones, as they should not be affected by view-filter-like functionality.
> -Then the Compare and Sync buttons are at bottom right in large for easy
usage.
Now this is something I really want to keep how it is: These buttons represent
the program's two most important algorithms, which are central for its usage.
Therefore they should be positioned highly prominently. In our western
culture, top-left is a good place for the first button that needs to be
clicked. Following in a sequence like layout is the sync-button on the right
side, which is positioned adhering to natural reading order.
> I hope this will be of some use as I am sure trying out this User Interface
would be extremely beneficial.
Sure, hearing about other's design ideas is a great source of inspiration.
It's not easy to think "out of the box" when you are familiar with something,
even more so if you are the developer of a certain program. As you've seen I
haven't made final statements or evaluations concerning the ideas presented
above. This is because it may (and in practice often does) give rise to an
enhancement of an already existing feature.
> I can't wait to hear what you think. What is your email address by the way?
Nobody looking at "about" dialogs anymore? ;)
Best regards, Zenju
> I understand that it is a radical change
Radical change is no problem in general if it is the "right" thing to do. But
there are a lot of constraints as well as pros and cons that need to be
evaluated. Mostly centered around the "vision" and a set of core requirements
that initially lead to the creation of FFS. This means that most of the time
there is no valid argument of "better" or "worse" per se, but only in relation
to what the tool wants to represent. I'm saying this so that you don't
misinterprete a denial of a design change as a criticizm of its underlying
idea. The question here is more whether it fits for this particular tool and
(most of) its users. A tool that tries to please everybody ultimatively serves
no one. So I go as far as possible to satisfy most users, but no further.
> but I do feel that it allows for easier understanding as to what part of the
interface applies to what part of the sync process.
A picture is always a very good idea to convey abstract information.
> It basically utilises a slightly wider window than currently.
Additional window width is a problem here. The number of columns already
constrains width to a high degree. Especially with regards to lower
resolutions and netbooks I fear, a change increasing overall width is not
acceptable. Please also don't forget the single-folder pair sync-scenario,
which is probably the dominant usecase. It may not be impeded by the
possibility of having multiple pairs. The paradigma here is "don't pay for
what you don't need".
> At the top left are the standard buttons for loading and saving
configuration files.
This is a strong bias towards backup scenarios. The usecases FFS wants to
support are: 1. folder comparison, for example binary comparison to identify
structural changes between different versions of data and also to enable data
integrity checks 2: synchronization/backup: these cannot be strictly
separated. Former emphases the idea of sharing data ownership between
different physical media while latter is more about fail safe data redundancy.
Most users problably tend to use features of 2. Feature 1 on the other hand is
functionality that I personally require from time to time but found a shortage
of good tools to conveniently and effectifly accomplish this task. Fortunately
1 can be combined almost seamlessly with 2 within a single tool, without
creating contradiction or dependency in program usage. To make this long story
short: I strive to keep a balance between 1 and 2.
> Below that is a list box with each row being a folder pair.
Folder paths are very long, which is a problem with width as mentioned above.
Also the path information is redundantly shown above both grids. The general
idea of having a group of high level clickable objects, that show their
associated data on the grids is interesting. But this approach has much
similarity with the scenario where a user has a list of gui configuration
files, containing one folder pair each. There he also would sync one config
after another, seeing only the information specific for this pair.
Orthogonality of function is an important design aspect which would be partly
violated here. I think the good part of this idea is that it allows the user
to distinguish data related to different pairs. The downside is, the user
needs to click on each pair to see its data. This design is pretty much
equivalent to a tabbed main screen that some sync-tools have implemented.
Maybe there is some way to distill the good parts of the idea avoiding the
drawbacks. Seeing data related to a single folder pair is similar to a view
filter. This however would introduce the need to add additional buttons, which
I want to avoid in general...
> - The buttons below the folder pair list item then allow the user to assign
specific settings to each of the folder pairs. So they can choose, compare
settings, filters, disable/enable the pair
Buttons are really my least-favorite device to allow interfacing with the
user. It is too easy to get into the "one function, one button" thinking that
way too many other overbloated software has chosen to. I think it's better to
see yet another gui option as the last design alternative rather than the
first. Successful sofware implementing this philosopy is represented by Google
or Apple. Surprisingly often you get away solving a problem in another, non-
intrusive way, even more elegantly and user-friendly than a button-option, by
just thinking harder about what it really is the user wants. If this answer
kann be determined by the tool, e.g. by an algorithm under the covers, there
is no need to bother the user with another visual distraction. To make it
short: Way too many buttons.
> temporarily, remove the pair completely, move the pair up or down and choose
sync settings. - This is all on a per folder pair basis. - Entirely
separatley.
This would be an improvement against current implemenation where sync-config
and filter-buttons are shown for each pair at once. As for "temporarily
disabling a folder pair" I'm not sure if this really is such a big usecase.
> - The stats box below should be global and is only populated once a compare
has been run.
This is something that theoretically could be implemented in the current GUI
layout already. It would however have a negative impact on the overall
perception of the main screen. Notice the high symmetry between left and right
hand side of the screen.
> - The stats box on the right hand side, shows the stats for the folder pair
currently selected.
I'm not sure if its a good idea to show statistics twice. As this is rather
detailed information its impact on visual distraction should be minimized. And
when having to choose between global and local sync-stats I'd choose the
global ones, as they should not be affected by view-filter-like functionality.
> -Then the Compare and Sync buttons are at bottom right in large for easy
usage.
Now this is something I really want to keep how it is: These buttons represent
the program's two most important algorithms, which are central for its usage.
Therefore they should be positioned highly prominently. In our western
culture, top-left is a good place for the first button that needs to be
clicked. Following in a sequence like layout is the sync-button on the right
side, which is positioned adhering to natural reading order.
> I hope this will be of some use as I am sure trying out this User Interface
would be extremely beneficial.
Sure, hearing about other's design ideas is a great source of inspiration.
It's not easy to think "out of the box" when you are familiar with something,
even more so if you are the developer of a certain program. As you've seen I
haven't made final statements or evaluations concerning the ideas presented
above. This is because it may (and in practice often does) give rise to an
enhancement of an already existing feature.
> I can't wait to hear what you think. What is your email address by the way?
Nobody looking at "about" dialogs anymore? ;)
Best regards, Zenju
