CHIRP

This is how you import from CSV (or anything else) in chirp-next: https://chirp.danplanet.com/projects/chirp/wiki/CSV_HowTo#Getting-The-Data-Back-Into-A-Radio

Dan Smith wrote in #note-1:

This is how you import from CSV (or anything else) in chirp-next: https://chirp.danplanet.com/projects/chirp/wiki/CSV_HowTo#Getting-The-Data-Back-Into-A-Radio

Yes, from a Chirp coder's viewpoint, this could be considered a satisfactory (maybe even "cleaver") solution. But from a user's perspective, it's a kludgey, poorly documented, work-around with no "affordance" on the UI. We've gone from a symmetrical pair of commands on the UI (Import/Export as CSV) to an asymetrical "Export to CSV" with no corresponding "Import from CSV". This is just plain bad UI design. And it is a completely unnecessary change that makes the cost of transitioning to Chirp-next higher than it needs to be.

While the "import from CSV" functionality exists, it is completely hidden behind the Open command (lacking any "affordance" in the UI to say "we know how to parse CSV files".) And the name of the command "Open" for a CSV file is misleading because it isn't "opening" the file; it is "importing" it. (A user doesn't expect "Open" to reorder and ignore columns; they would expect to be able to see all the data in the file and possibly even save it.) It would make a lot more sense to move the "Import CSV File" functionality hidden behind "File:Open" into a separate "Import from CSV" command on the File menu. This would provide users with an "affordance" and would be a less misleading UI. Otherwise, expect to get lots more "Import CSV missing from Chirp-next UI" bugs/feature-requests/complaints as more users are forced to migrate.

It would also be useful to provide documentation about the rules for each column. No, exporting a CSV file does NOT reveal all possible values. It's only as good as the data in the radio and some fields are defaulted to a single format of several possible formats. (E.g. Duplex column always defaults to empty, "+" or "-" and never to "split" or "off".

Yes, from a Chirp coder's viewpoint, this could be considered a satisfactory (maybe even "cleaver") solution. But from a user's perspective, it's a kludgey, poorly documented, work-around with no "affordance" on the UI.

Actually, leaving import out was the direct suggestion of multiple users. It was also advised by watching in-person users and youtube videos of regular users trying to explain how to import things into their radio. I've seen people export from one radio to csv only to import back into another radio (not realizing they can copy and paste, as if "import" was doing some magic). I've seen them be utterly confused by the import dialog, thinking they had to make changes, renumber memories, and wonder why they can't import 200 memories into a 100-memory radio. In other cases, I've seen people flail around trying to import only memories 50-100 from their CSV master list into their radio using the dialog (a thing that is trivial and intuitive with copy/paste).

I also consider myself the most power of the power users of chirp and I haven't used the import function in probably a decade.

We've gone from a symmetrical pair of commands on the UI (Import/Export as CSV) to an asymetrical "Export to CSV" with no corresponding "Import from CSV". This is just plain bad UI design. And it is a completely unnecessary change that makes the cost of transitioning to Chirp-next higher than it needs to be.

Import could import from any type of file, not just CSV, so it's not really fully symmetric anyway. People also ask why they can't export as a different file type. I could also remove "Export to CSV" if you think it would make it better. You can, of course, just copy all your memories into a new CSV tab and save that...

While the "import from CSV" functionality exists, it is completely hidden behind the Open command (lacking any "affordance" in the UI to say "we know how to parse CSV files".) And the name of the command "Open" for a CSV file is misleading because it isn't "opening" the file; it is "importing" it.

I think maybe you're confused. CSV is and always has been a first-class primary data file format in CHIRP. It's the only type of file you can create from scratch. You can create, open, modify, and save them, as well as export any type of file to CSV. There's nothing even remotely similar to "hiding" import underneath open - if anything it's the only native chirp data format. Import has always been format-independent in that you could import from any file format as well. In reality, under the covers import just opened the source file, copied all the memories and closed the tab for you (regardless of the format).

(A user doesn't expect "Open" to reorder and ignore columns; they would expect to be able to see all the data in the file and possibly even save it.)

I think by "a user" you mean "you" - I've literally never heard that argument. Many other radio data formats store channels in memory in a different order than they are presented in the UI (of the radio, the OEM software, and chirp). Basically none of them store the fields (i.e. the columns) in the order that CHIRP presents them in. Chirp doesn't mirror the order in which the actual fields are stored in an image of, say, a Kenwood TK-8180, nor does the order of columns in a CSV file affect the presentation of that data in the CHIRP UI. CHIRP is an abstraction - it would be utter madness to base the presentation on the actual structure of the data, and defeats the entire point of its existence.

Perhaps the fundamental thing you're misunderstanding is that CSV is an encoding method, not a data structure itself. CHIRP's interpretation of a record has nothing to do with the order, in CSV, or any of the other formats it reads. You seem like an spreadsheet kinda guy. A spreadsheet is a different thing from chirp - its data format is the rows and columns, and the position matters. CHIRP is not a spreadsheet, and CSV to it is just an encoding of data, where the data structure is a row-based record with fields that can be in any order (as defined by the first record).

It would make a lot more sense to move the "Import CSV File" functionality hidden behind "File:Open" into a separate "Import from CSV" command on the File menu. This would provide users with an "affordance" and would be a less misleading UI. Otherwise, expect to get lots more "Import CSV missing from Chirp-next UI" bugs/feature-requests/complaints as more users are forced to migrate.

Sounds like a threat, which is really not very helpful. It would also be a lot more constructive if you would present your opinions as your own, and not as if you're representing a bunch of people standing behind you. It might be helpful to respect that some of us have been doing this (and answering user questions) for almost fifteen years, and understand that not everyone thinks about it the same way you do.

In watching people use chirp over that time, I've seen about 75% of people be confused by the old import dialog as it was implemented and only about 25% really use it properly. As such, I do not plan to re-implement that.

On a whim I just went looking for the first google hit of someone explaining the import workflow and found this:

https://theprepared.com/gear/guides/program-ham-radio-chirp-software/

You can see it calls import "clunky" and goes on to show each step, explains how to keep it from putting memories in places you don't want it to, etc. A substantial amount of the article is explaining how to use the import function. Most of the things it shows would be much easier as a copy/paste workflow.

That all said, we could add a simpler import method that just imports everything, in order, if you really think it's that important. It would just always import all the channels from the source file. Here are some questions about how that would work:

• What to do for CSV files with more memories than the target radio? Warn the user about truncating the list? Refuse entirely? Silently only import the first N? In the case where they only need 50-100, they'd have to revert to the copy/paste workflow.
• What to do for memories not in the CSV file? Delete those channels in the target radio? If yes, then the CSV must be a full and complete set of what the target should look like. If not, there's no way to move things in your CSV master list without creating dupes in subsequent imports. Exporting from a small radio to import into a large radio would be destructive and they'd have to revert to the copy/paste workflow.

I think that it would probably not be that useful (except maybe for your workflow where you're maintaining a whole-radio mapping in CSV), but it would require effort to implement.

I myself maintain a master channel list for myself in CSV. I group together VHF, UHF, public safety (VHF and UHF), HF, broadcast, etc channels. Some of my radios can store that whole list, but many can't, so I take the VHF block, or VHF/UHF block, or the HF block. Import literally doesn't do anything helpful for me for that scenario (ether in the simplified approach above, or the complex one provided in chirp-legacy), but the copy/paste workflow is very straightforward.

Yes, by "user", I definitely include myself. Someone who isn't intimately familiar with how CHIRP is built. But the general rule of thumb is that for every user that complains about something, there are 10 more that just grumble to themselves and never submit a problem report. So that makes 11 of us in total. ;-) And BTW, I am very familiar with software development having been a Smalltalk, Java and Ruby programmer in the distant past. And a strong advocate of TDD and developer test automation (search for my book on the topic in Amazon.)

I whole-heartedly agree that the old Import command is confusing. And it rightly deserved criticism. But that criticism can be blamed on the confusing nature of the old import workflow, not on the "Import" vs. "Open" terminology. So let's not throw out the baby with the bath water. The omission of an Import command is just as confusing.

I don't have a problem with switching to Copy/Paste between the CSV and IMG files; I just had a hard time figuring out how to import the CSV because, not being a CHIRP developer, I had no idea that CSV was a "native" format to CHIRP. (And I have been using CHIRP for at least 10 years so it's not like I'm not very familiar with how it works.) The asymmetry of the Export-with-no-Import exposes something that the "abstraction" of CHIRP is supposed to hide. If CSV is a "native" format than there should be no "Export as CSV" either; it should be "Save as". But the only thing one can change with Save As is the file name/location, not the format. (.csv is not a file type option; only .img is available.) Changing "Export as CSV" to "Save as" would make it more consistent but would also increase the transition cost for users of CHIRP-old unnecessarily.

So all I am asking is that we don't make the transition any harder than necessary for existing Chirp-old users.

If you want to add the .csv file type to "Save as" to be more self-consistent in treating CSV files as "native" to Chirp, that's fine too. But then show me all the columns in the CSV file, not just the ones that CHIRP understands. Sure, indicate somehow that those columns will be not be sent down to the radio but let me sort and maybe even filter by them. Then I might not have to use Excel to manage the CSV. (Actually, you already have added a column that my radio doesn't understand: "Comment". It had me hoping that I could store the comment in the radio but alas, after testing sending it to the radio and getting it back, it was gone. So I still have to manage my frequencies in the CSV file.)

But really, how hard would it be to include an "Import from CSV" in the UI as well so that us ignorant CHIRP-old users can move to CHIRP-next more easily. And maybe facilitate the transition to CHIRP-next by showing a message telling the user to use Copy/Paste to insert the relevant lines into the .img file pulled from the radio.

If later, you want to deprecate the Export and Import commands, you can have them tell us where they have been moved to. Instead of forcing us to search through the help trying to figure it out for ourselves. I'd bet that a good developer like you could have implemented that in about the same amount of time as you have spent on replying to my problem report.

Thanks for listening,

Gerard Meszaros
Author of xUnit Test Patterns - Refactoring Test Code