XYplorer Beta Club

I share the desire to have the box at the bottom left.
I'm also thinking about packing the Tips and Editor buttons into a small toolbar.

I don't see a reason to make it as big as the list though. But 125 DLUs would be okay.

zer0 wrote:

TheQwerty wrote:While we're on the topic of the List Management dialog, I think everyone is in agreement that they should all be combined into a single dialog, right? One dialog where you select which list you want to view/modify instead of a long menu of options that you have to jump back and forth with.

I have been bashing about this for quite some time. In fact, it was one of my original complaints a year and a half ago that started this thread (http://i49.tinypic.com/m8k192.png)

I'm quite sure that I've been asking for this for longer than that...though finding the right tread in all the many posts I've written might be very difficult.

I was asking for something as simple as a Next/Prev so you could navigate between the lists...make it more like Config is now.

admin wrote:I share the desire to have the box at the bottom left.
I'm also thinking about packing the Tips and Editor buttons into a small toolbar.

I don't see a reason to make it as big as the list though. But 125 DLUs would be okay.

Eh... it's better.

I like the idea of the toolbar but think it would be better above the list, and hope to see it replace the entire column of buttons on the right. It also seems odd that the less frequently used "Tips" button appears before the Editor one, seems like it would be better to either disable it, or put it in a place where its presence doesn't affect other controls.

If you did all of that then you could follow the MS guidelines more closely and put the search/filter box on the right side of the toolbar. I don't quite understand why they make that suggestion though, so I'm not sure it would really be any better.


Frankly, I still feel the box is too narrow but I say that as a judgement of appearance/feeling and not usability, so if no one else seems to mind I'm content being the lone fool.

Let's not beat around the bush, the interface isn't good. Yep, I know it is a work-in-progress, hence this feedback from me.

1. The dialogue is modal. That's a no-no straight away, because there is simply no need for it to be. If I can't carry on working with other files while some are being copied then I am not going to use this functionality.

2. The visual footprint is too large. Why does it have to be so big? It's just a progress dialogue. There are excess of white (header) and grey space (bottom right quadrant) that can be trimmed down. Compare this with the progress dialogue in Explorer on Win 7. A much smaller footprint and the information is delivered succinctly. The width of XYplorer's dialogue is about 150% of Explorer's. If you shrink the dialogue's width and align items along the vertical axis (see point 9), it would make things much better.

3. Showing time to thousandth of a second is over the top. Is there any benefit to it?

4. Showing a percentage progress for individual file copying and progress bar and % for the overall progress is an inconsistent approach. I believe that showing individual file progress is unnecessary -- again, what's the benefit? -- so a progress bar showing the overall progress would suffice.

5. The positioning of the progress bar isn't good amongst the textual information. It should go to the bottom for clear separation of graphical elements.

6. Positioning of buttons is peculiar without obvious reason why each button is where it is. Pause should be next to Abort.

7. "View details" is unnecessary once backup becomes supported for background processing because details would be available through Background Jobs. Same for "View failures".

8. Captions would benefit from some love. Abort -> Cancel. Continue -> Resume. Transfer rate -> Speed. Copying -> Name.

9. Layout needs rejigging for better presentation and to eliminate wasted space. This is how it should be:

White header: "<Copying/Moving/Backing up> <number of items> (<total size of items>)
First line: Name: <name of file that is currently being copied/moved/backed up>
Second line: From: <full path of the source location>
Third line: To: <full path of the destination location>
Fourth line: Time elapsed: <time elapsed so far, with seconds the smallest unit>
Fifth line: Time remaining: <time remaining, with seconds the smallest unit>
Sixth line: Items remaining: <number of items remaining> (<size of data remaining>)
Seventh line: Speed: <speed in MB/second>
Eighth line: Overall progress bar
Ninth line: Pause/Cancel/etc buttons

Do you need to me to mock it up for you for better illustration?

10. Integration with Windows 7 progress bar for visual status of the overall progress.

Yes, it seems like a lot, but I'd rather influence the design from an early stage than battle months later.

zer0 wrote:4. Showing a percentage progress for individual file copying and progress bar and % for the overall progress is an inconsistent approach. I believe that showing individual file progress is unnecessary -- again, what's the benefit? -- so a progress bar showing the overall progress would suffice.

I see a benefit from knowing some details on where a given individual file is because if I'm waiting on that large file to complete, having a clue when it's going to finish would help.

8. Captions would benefit from some love. Abort -> Cancel. Continue -> Resume. Transfer rate -> Speed. Copying -> Name.

I think this is a matter of personal preference and I've seen both transfer rate and speed used (as well as some other similar captions), for example...same with copying/name/etc.

Those are the two items that really stood out to me as not being an issue here.

I agree it's looks big, but I have some ideas for the future that need the space. But I think about making it at least a little smaller.

Thanks for the other comments, but I'm still in favor of the current layout.

can't stand aside, so a bit of oppinion:

zer0 wrote:4. Showing a percentage progress for individual file copying and progress bar and % for the overall progress is an inconsistent approach. I believe that showing individual file progress is unnecessary -- again, what's the benefit? -- so a progress bar showing the overall progress would suffice.

i guess that was "why showing % for overal process if it already has a progress bar?" - if so = agreed; otherwise, IMO, percentage for current file and progress bar for overall = quite good.

zer0 wrote:5. The positioning of the progress bar isn't good amongst the textual information. It should go to the bottom for clear separation of graphical elements.

not agreed totally. bottom position distracts from actual useful info. maybe it's just me, but such positioning in Win7 is one of the causes i always used some "copy-managers" dealing with it. besides, i don't think most of file managers were mistaken to put it to the top(like TC, for example).

zer0 wrote:6. Positioning of buttons is peculiar without obvious reason why each button is where it is. Pause should be next to Abort.

same as with progress bar i see a good idea in placing Pause and Abort in different corners - people are different and their mastering of mouse is too = like buttons are now, one can never push "wrong one".

zer0 wrote:9. Layout needs rejigging for better presentation and to eliminate wasted space. This is how it should be: ...

waste space- yes. but why just copy all to line as it's done in 7? does it really so good?!

j_c_hallgren wrote:

8. Captions would benefit from some love. Abort -> Cancel. Continue -> Resume. Transfer rate -> Speed. Copying -> Name.

I think this is a matter of personal preference and I've seen both transfer rate and speed used (as well as some other similar captions), for example...same with copying/name/etc.

With Abort and Continue, I don't think it's a matter of personal preference. In fact, I think instead of Cancel, it should be Stop.

eil wrote:

zer0 wrote:4. Showing a percentage progress for individual file copying and progress bar and % for the overall progress is an inconsistent approach. I believe that showing individual file progress is unnecessary -- again, what's the benefit? -- so a progress bar showing the overall progress would suffice.

i guess that was "why showing % for overal process if it already has a progress bar?" - if so = agreed; otherwise, IMO, percentage for current file and progress bar for overall = quite good.

The thing is, it is not immediately obvious -- and it should be made so -- that the progress bar does not show progress for the overall copying (unless copying 1 file with no verification).

eil wrote:

zer0 wrote:5. The positioning of the progress bar isn't good amongst the textual information. It should go to the bottom for clear separation of graphical elements.

not agreed totally. bottom position distracts from actual useful info. maybe it's just me, but such positioning in Win7 is one of the causes i always used some "copy-managers" dealing with it. besides, i don't think most of file managers were mistaken to put it to the top(like TC, for example).

How does it distract exactly? It is a good practice to separate textual elements from the graphical ones. Humans comprehend visual information much easier than textual, so it requires less effort to do so. I can be looking at textual data of the progress and notice the completion state visually with my peripheral sight.

Besides, click here and notice how progress bars are usually either at the bottom or at the top, but relatively rarely mixed up in the middle of the dialogue.

eil wrote:

zer0 wrote:6. Positioning of buttons is peculiar without obvious reason why each button is where it is. Pause should be next to Abort.

same as with progress bar i see a good idea in placing Pause and Abort in different corners - people are different and their mastering of mouse is too = like buttons are now, one can never push "wrong one".

Once "View details" and "View failures" are relegated, only buttons to pause and stop would be needed. In that situation, they do not have to be miles apart..

eil wrote:

zer0 wrote:9. Layout needs rejigging for better presentation and to eliminate wasted space. This is how it should be: ...

waste space- yes. but why just copy all to line as it's done in 7? does it really so good?!

Yes, it is. In Explorer progress dialogue, I can see everything I see in XYplorer dialogue, save for time elapsed and individual item progress. Adding those would only enlarge it by a couple of lines height-wise. According to my approximate calculations, XYplorer's dialogue's area is almost twice as large as Explorer's. Is that really necessary for a progress dialogue?

admin wrote:I agree it's looks big, but I have some ideas for the future that need the space.

What more information/functionality one could possibly want Anyway, in that case, you can start small and enlarge it as you go on. Creating wasted space with hope to fill it with something in the future is not an efficient approach.

admin wrote:Thanks for the other comments, but I'm still in favor of the current layout.

I hope you won't ignore my comment about the lack of necessity for the dialogue to be modal. If that's what you're sticking with, then I hope I would be able to use kernel copy without that dialogue. If not, then I'll stick with shell copy. For me, modal, unpolished and lagging GUI is a bad apple that would spoil the whole barrel of XYcopy 2.0.

zer0 wrote:

admin wrote:Thanks for the other comments, but I'm still in favor of the current layout.

I hope you won't ignore my comment about the lack of necessity for the dialogue to be modal. If that's what you're sticking with, then I hope I would be able to use kernel copy without that dialogue. If not, then I'll stick with shell copy. For me, modal, unpolished and lagging GUI is a bad apple that would spoil the whole barrel of XYcopy 2.0.

As I understand it, XYcopy 2.0 will very much incorporate one of the biggest advantages of its predecessor, namely running out-of-process. I take that to mean that both the UI as well as the actual operation will be handled by XYcopy.exe rather than the main executable.

Don seems to have chosen an incremental development model for this especially, with all functionality for now contained within XYplorer.exe. I'm guessing that development and especially debugging, are reasons for this.

zer0 wrote:

eil wrote:

zer0 wrote:4. Showing a percentage progress for individual file copying and progress bar and % for the overall progress is an inconsistent approach. I believe that showing individual file progress is unnecessary -- again, what's the benefit? -- so a progress bar showing the overall progress would suffice.

i guess that was "why showing % for overall process if it already has a progress bar?" - if so = agreed; otherwise, IMO, percentage for current file and progress bar for overall = quite good.

The thing is, it is not immediately obvious -- and it should be made so -- that the progress bar does not show progress for the overall copying (unless copying 1 file with no verification).

i really don't understand why it shouldn't? where is obviosity?.. i'm almost sure, many users will consider no process bar as excessive spartan interface. ones more taking notice= most of copy operations in other file managers or likewise have even 2 progress barы, so 1 overall and % for current file is more that sufficient.

zer0 wrote:

eil wrote:

zer0 wrote:5. The positioning of the progress bar isn't good amongst the textual information. It should go to the bottom for clear separation of graphical elements.

not agreed totally. bottom position distracts from actual useful info. maybe it's just me, but such positioning in Win7 is one of the causes i always used some "copy-managers" dealing with it. besides, i don't think most of file managers were mistaken to put it to the top(like TC, for example).

How does it distract exactly? It is a good practice to separate textual elements from the graphical ones. Humans comprehend visual information much easier than textual, so it requires less effort to do so. I can be looking at textual data of the progress and notice the completion state visually with my peripheral sight.

well, each user has his own understanding of visual comprehendance(i'm talking about positions). there are statics that say "reading from top to bottom as well as pulling mouse down, is much easier". that's why task bar in Win is placed at the bottom an close button at the top. but still there are many users that put task bar at the top(or any place).

zer0 wrote:Besides, click here and notice how progress bars are usually either at the bottom or at the top, but relatively rarely mixed up in the middle of the dialogue.

now i get your point. but i just don't consider 2 lines of Source/Destination as some real part of info below. it's just like heading.

zer0 wrote:

eil wrote:

zer0 wrote:6. Positioning of buttons is peculiar without obvious reason why each button is where it is. Pause should be next to Abort.

same as with progress bar i see a good idea in placing Pause and Abort in different corners - people are different and their mastering of mouse is too = like buttons are now, one can never push "wrong one".

Once "View details" and "View failures" are relegated, only buttons to pause and stop would be needed. In that situation, they do not have to be miles apart..

even with 2 just buttons i stay with my opinion - with buttons at different corners, one will never miss-click('cause he'll need to decide what to do first and move mouse in right direction). besides, even with them at 2 opposite corners there is still a keyboard for speed.

zer0 wrote:

eil wrote:

zer0 wrote:9. Layout needs rejigging for better presentation and to eliminate wasted space. This is how it should be: ...

waste space- yes. but why just copy all to line as it's done in 7? does it really so good?!

Yes, it is. In Explorer progress dialogue, I can see everything I see in XYplorer dialogue, save for time elapsed and individual item progress. Adding those would only enlarge it by a couple of lines height-wise. According to my approximate calculations, XYplorer's dialogue's area is almost twice as large as Explorer's. Is that really necessary for a progress dialogue?

you're right about same information containing in both dialogs right now. but aside from info Win7 shell-copy in no real better that XP one. yet i was more talking about Win7 copy-visual-style..
didn't you just above said visual info in better comprehended?!

nas8e9 wrote:

zer0 wrote:

admin wrote:Thanks for the other comments, but I'm still in favor of the current layout.

I hope you won't ignore my comment about the lack of necessity for the dialogue to be modal. If that's what you're sticking with, then I hope I would be able to use kernel copy without that dialogue. If not, then I'll stick with shell copy. For me, modal, unpolished and lagging GUI is a bad apple that would spoil the whole barrel of XYcopy 2.0.

As I understand it, XYcopy 2.0 will very much incorporate one of the biggest advantages of its predecessor, namely running out-of-process. I take that to mean that both the UI as well as the actual operation will be handled by XYcopy.exe rather than the main executable.

Don seems to have chosen an incremental development model for this especially, with all functionality for now contained within XYplorer.exe. I'm guessing that development and especially debugging, are reasons for this.

Of course!

eil wrote: i really don't understand why it shouldn't? where is obviosity?.. i'm almost sure, many users will consider no process bar as excessive spartan interface. ones more taking notice= most of copy operations in other file managers or likewise have even 2 progress bars, so 1 overall and % for current file is more that sufficient.

It's not obvious because if you're gonna put "Copying: <file name>" and a progress bar below it then the connection that is made is the progress shown in the bar is for that file. Sometimes it is and sometimes it is not.

eil wrote:well, each user has his own understanding of visual comprehendance(i'm talking about positions). there are statics that say "reading from top to bottom as well as pulling mouse down, is much easier". that's why task bar in Win is placed at the bottom an close button at the top. but still there are many users that put task bar at the top(or any place).

Progress bar and taskbar are distinctly different controls. The positioning of the latter is governed by Fitt's law of human-computer interaction, whereas progress bar is not.

eil wrote:now i get your point. but i just don't consider 2 lines of Source/Destination as some real part of info below. it's just like heading.

a) They shouldn't be in the header b) If you look for "file progress dialog" images, the vast majority are shown at the bottom.

eil wrote:even with 2 just buttons i stay with my opinion - with buttons at different corners, one will never miss-click('cause he'll need to decide what to do first and move mouse in right direction). besides, even with them at 2 opposite corners there is still a keyboard for speed.

If that principle is used in GUI design, we'd have buttons all over the place to prevent user miss-clicks Buttons must be grouped logically. That's why OK and Cancel in UDC dialogue, Preview, Submit, Save and Cancel go together.

eil wrote:you're right about same information containing in both dialogs right now. but aside from info Win7 shell-copy in no real better that XP one. yet i was more talking about Win7 copy-visual-style..didn't you just above said visual info in better comprehended?!

I don't understand what you mean here

zer0 wrote:It's not obvious because if you're gonna put "Copying: <file name>" and a progress bar below it then the connection that is made is the progress shown in the bar is for that file. Sometimes it is and sometimes it is not.

kinda agreed about that progress bar can be thought as a file progress, but that is a problem of depicting that progress is overall(as "Copying: <file name>" already has percentage showing progress) and not current file only.

zer0 wrote:Progress bar and task-bar are distinctly different controls. The positioning of the latter is governed by Fitt's law of human-computer interaction, whereas progress bar is not.

thanks for useful info- i didn't know about that law!. still for me this law "doesn't work" 'cause since long time ago my task bar is on the left= this allows me to have more programs in list, smooth task bar, and more place at the desktop.)

zer0 wrote:a) They shouldn't be in the header b) If you look for "file progress dialog" images, the vast majority are shown at the bottom.

but this is to much info for real dialog header, so as it's now, it's really "header-like" separated from all other things.
i watched the link you provided, thanks. but that doesn't convince me that it's useful(by the way most of those dialogs are Win7 style -which i don't like at all ). TeraCopy or SuperCopier position all useful info below the progress bars; TC does have info above, yes, but that is only Source/Destination and Speed - same as XY does. besides, mentioned by you law correlates with mentioned by me statistics = info from top to bottom - so progress dialog above the process info, places it in peripheral and info in sight.
one more plus for such positioning is that there are users who watch such processes closely, and there those who just check "what is coping" and "how much does it left" - main for them would be progress bar and From/To in above in periphery.

zer0 wrote:If that principle is used in GUI design, we'd have buttons all over the place to prevent user miss-clicks Buttons must be grouped logically. That's why OK and Cancel in UDC dialogue, Preview, Submit, Save and Cancel go together.

design is a thing creativity buttons doesn't have to be all in one place + there is anyway a spare place to position them as it's likened. for example, buttons in Opera that are placed in all 4 corners are much more useful, than Maxton ones, that are grouped in bottom-right and top-left. logic has almost no impact here 'cause as well "logically to group", is "logically to preserve miss-clicks and make choice more determined". XYplorer is already much better then all other file managers - my guessing is that's because he's "out of other Fms (same-)logics".

zer0 wrote:

eil wrote:you're right about same information containing in both dialogs right now. but aside from info Win7 shell-copy in no real better that XP one. yet i was more talking about Win7 copy-visual-style..didn't you just above said visual info in better comprehended?!

I don't understand what you mean here

i was talking about that a Win7 copy dialog, aside from more info then in XP's one, has nothing better. and last thing about design was about yours "Is that really necessary for a progress dialogue?"(but now i thinks it may happen i was the one to miss-understand )

eil wrote:kinda agreed about that progress bar can be thought as a file progress, but that is a problem of depicting that progress is overall(as "Copying: <file name>" already has percentage showing progress) and not current file only.

Exactly why they should be kept apart so to avoid the confusion

eil wrote:but this is to much info for real dialog header, so as it's now, it's really "header-like" separated from all other things.
i watched the link you provided, thanks. but that doesn't convince me that it's useful(by the way most of those dialogs are Win7 style -which i don't like at all ). TeraCopy or SuperCopier position all useful info below the progress bars; TC does have info above, yes, but that is only Source/Destination and Speed - same as XY does. besides, mentioned by you law correlates with mentioned by me statistics = info from top to bottom - so progress dialog above the process info, places it in peripheral and info in sight. one more plus for such positioning is that there are users who watch such processes closely, and there those who just check "what is coping" and "how much does it left" - main for them would be progress bar and From/To in above in periphery.

So it is also a matter of personal taste, no? Most of the time, the progress bar appears at the bottom. Like in pictures that I linked to, player applications, etc It has been at the bottom in Explorer progress dialogues as far back as I can remember.

eil wrote:design is a thing creativity buttons doesn't have to be all in one place + there is anyway a spare place to position them as it's likened. for example, buttons in Opera that are placed in all 4 corners are much more useful, than Maxton ones, that are grouped in bottom-right and top-left. logic has almost no impact here 'cause as well "logically to group", is "logically to preserve miss-clicks and make choice more determined". XYplorer is already much better then all other file managers - my guessing is that's because he's "out of other Fms (same-)logics".

Logic has the most impact here. It's not software's job to make a user learn new ways of working. It's a de facto standard that certain command buttons are in the bottom right corner. Just check other dialogues in XYplorer

eil wrote:i was talking about that a Win7 copy dialog, aside from more info then in XP's one, has nothing better. and last thing about design was about yours "Is that really necessary for a progress dialogue?"(but now i thinks it may happen i was the one to miss-understand )

I get a feeling that English is not your native language (is it Russian?), which may be causing a misunderstanding/confusion.

I went ahead and did a mockup of what I would like the dialogue to look like. Let me know what your thoughts. I believe it provides all the necessary information and functionality in a more organised manner than XY's current dialogue