View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001641 | MMW v4 | Synchronization | public | 2004-12-01 09:53 | 2004-12-07 02:53 |
Reporter | jiri | Assigned To | |||
Priority | immediate | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 2.3 | ||||
Summary | 0001641: Support for general USB Mass Storage devices | ||||
Description | Currently we only have support for specific devices (with a plug-in) or general devices assigned to a drive letter (the general plug-in). It might be useful to have a plug-in for any USB Mass Storage device where user would only specify its USB ID and the device would appear as if it has its own plug-in. | ||||
Tags | No tags attached. | ||||
Fixed in build | 818 | ||||
|
Fixed in build 814. - There is now d_USBMass.dll plug-in. User can specify either USB ID or drive label (or both) and the device works normally then. A 'Find device' button helps in finding the USB ID - it automatically fills this ID in for the first connected USB Mass Storage device found. |
|
I'm a bit confused by some of this. 1) Shouldn't the 'Tracks' box (for enabling WMA/MP3/OGG) that is present in the other general plugin appear here as well? 2) What is a 'Drive Label'? Is this a Drive Letter? (if it's something else, most users will have no idea what it is) 3) In general, the USB Device ID functionality won't work since: a) most users won't know what it is b) In most cases 'Find Devices' functionality won't work, since most systems today have multiple USB devices, and there's no way to choose one device or another. Could we instead have a 'Choose Device' button that opens a dialog similar to the File Monitor's 'Browse for Folder' dialog which allows the user to choose the device (and automatically looks up the Device ID if possible, based on the chosen drive). 4) When should a user use one General plugin vs. another? Or phrased differently, why can't the 2 plugins be combined so that there's no confusion between the two. 4b) The fact that 2 General plugins exist is a good thing, however, they should be named in a manner that makes their purpose clear. --If the user doesn't configure the USB ID In summary, I really like the idea of having a second plugin, however: 1) They should be named as: General USB Mass Storage Device 1 & General USB Mass Storage Device 2 2) Both of these devices should have a common layout e.g. Device Name: __________________ [Find Device] (this button opens a dialog that allows the user to choose the device) Drive: __ (read only) USB ID: __ (read only) Label: __ (read only) Track Formats: [ ] Copy MP3 tracks [ ] Copy WMA tracks [ ] Copy OGG tracks The above solution makes it easy to understand, and solves the problem of the need for multiple devices (in most cases). |
|
1) Actually I think that the checkboxes (WMA/MP3/OGG) are only remains from time we started portable devices support are didn't know all the required functionality. Now that we are much further I think that they are rather obsolete and don't have much use there, they will definitely be fully replaced by auto-convertions once they are implemented. 2) It's the label of drive (as seen in Explorer, can be also changed there or e.g. by DOS Label command). User doesn't have to fill this in, but if he does so he can further constrain the devices plug-in will recognize. Let's say user has two same USB devices (having the same USB ID), he can change their labels and specify to the plug-in that only one will be recognized. 3) 'Find Devices' will work in almost all cases because it recognizes only Mass Storage USB devices and so multiple devices won't be a problem. So we only require the user to have the device he wants to configure connected to PC and press 'Find Device'. That's all and needs to be done only once. 4) The original plug-in is related to a fixed drive letter (which can be useful), i.e. it isn't for USB devices only. The new plug-in is targetted to USB MS devices. It possibly isn't the most user friendly thing ever written, but I don't think it could be much better. Anyway, it's only an addition that will be probably mainly used by at least a bit advanced users. Also, we possibly don't have to distribute it directly with MM, but only have it downloadable from our web. |
|
1) Even when we add auto-conversion, this functionality is still needed as there needs to be a) choice of what file types to copy b) what format(s) to convert to (see: 0001352) (for example, if user has lossless audio, he may not want to transfer the files since conversion will take too long). 3) On my system, my Printer is registered as a USB mass storage device (it's fairly common for printers to have CF card slots) 4) Wouldn't it be relatively easy to implement the suggested UI? it resolves the usability issues and makes it clear how to use multiple devices... |
|
1) That's exactly what auto-conversion will do, i.e. there will be a new sheet in Device configuration dialog where user will specify the conversion rules. Then simple selection of formats to copy won't make any sense. 2) Ok, but I suppose that MM recognizes the printer only if any card is inserted. In that case it can be useful because user could synchronize to that card (and use it in a mp3 player later). 4) As I explained in 1), I think that 'Track formats' are obsolete in this place. The selection of drive letter isn't that easy, it depends on how is user logged to the system, e.g. non-Administrators cannot do the required operations (i.e. find out that letter F: has such and such USB ID). Also I don't think that USB ID should be read-only, although user generally won't know what to fill in there, he can sometimes e.g. get hints from forums related to a particular device, etc. |
|
Per IM discussion it would be useful to have a single plugin that is manually configurable in the following manner: Plugin Name: General Portable/Audio Device Quantity: Ideally there should be 2 of them Suggested UI: Device Name: ____________________ (o) Identify by USB Device ID: ________________ [Find] { } Identify by Drive Letter: ________________ [Find] ( ) Identify by Drive Label : ________________ Notes: - '[Find]' button should only be active for the selected option. - '[Find]' for USB Device ID, should also identify Drive Letter and Label, if possible - '[Find]' for Drive letter should allow the user to browse and select any available drive (and identify USB Device ID and Label, if possible) |
|
Fixed in build 816. - Implemented similarly to the proposal (we can discuss changes over IM). - The current general plug-in was removed. |
|
Tested in 816. I'd recommend a few minor changes: 1) This plugin should appear as the first one in the list 2) It's unclear to the user (and to me) what must be configured vs. what is optional. Also, this UI makes it possible to configure conflicting parameters (e.g. Device ID conflicts with Drive Letter). I would suggest that this can be resolved by making the 3 selections mutually exclusive so that it's clear to the user that only 1 needs to be entered, and to prevent such conflicts. Alternatively, some text along the following lines could be provided: 'Please enter a single parameter to identify your device:' |
|
1) Fixed. 2) I'd like to let user to configure anything because all combinations make sense in some cases and I believe some users will use/need it. If you think it should be clarified, we can add a text saying something like 'Enter one or more parameters to identify the device' above the items, but maybe even without the message it isn't too unclear. |
|
As discussed over IM: 1) Add a line of text above the configuration parameters: 'Please enter at lease one parameter to identify your device:' 2) Change the order of the parameters so that the easiest one is displayed first, and so that it is most aesthetically appealing i.e. -Drive Letter: -Drive Label: -USB Device ID: 3) Add a second device by default so that users don't have to look in the online help for this. Device names should be: -Generic Portable/Audio Device -Generic Portable/Audio Device 2 |
|
Fixed in build 818. 3) As discussed over IM, this wasn't fixed. |
|
Verified 718. |