More Fields! Help me out!

Feature Requests
#1

Ok, there have been a lot of requests for extra fields in these templates. I think I found a way to accomplish this without losing the simplicity of the basic form.

I would be introducing ‘Compact Mode’ which is the default state, with the field set currently in the template. If you have the screen real estate, say on a laptop or tablet, you can toggle compact mode off, which reveals more fields. Or if you just want to quickly change say, their grid square or something, you can toggle it off, make your change, and toggle it back on. It looks something like this:

more-fields
more-fields884×371 3.67 MB

Is this useful? If so, what other fields for the person your contact should I add in the main box, and what fields for you should I add in the side box? Sidebox currently has ‘My Grid’ (which will autopopulate when you put in the park name, and ‘My State’ (just as a test)

Let me know what would be useful down there!

2 Likes
Template in 0.10.5
#2

Jarrett…Perhaps include the ability to show compact mode or not by making that selection in the “Profile” set up. The reason I say this, is …State, and grid squares etc. are not required for POTA, so, sure…lots of things are nice to have, but anything other than what is required is just floatsum and jetsum…and clutters things up, as small as they are. Grid Squares are HUGE in VHF and 6 meters, In fact, they are standard for EVERY exchange. But, not at all for POTA exchanges.

#3

a “worked before” that scrapes your previous logbooks would be awesome, and possibly a “worked on date” or something like that. Though, as I’m writing that, it seems that would be helpful in the popup when typing the callsign. It’s very nice, in the field to be able to call out your consistent hunters.

This of course will lead people to ask for the ability to import their previous logs (I believe I’ve already seen this somewhere here)

#4

I don’t know if POTA has opened up their data with an API, but it would be awesome to see how many times the park you’re at has been activated before (and possibly the last activator’s callsign?)

1 Like
#5

County, people love county, also, when you’re uploading to LOTW, you will need to tell it what County you were at while activating (when you create a new QTH). So, having the County retained with the logbook would be great

2 Likes
#6

@Jarrett that is looking good.

#7

I think the overall approach looks good.

However, there are three things that I believe would really help a lot:

  1. Give a configuration option to allow one or two fields to be perpetually included on the main screen. You might even simply display one or two fields on the main screen that have a drop-down list the user can select. For instance, if Grid Squares are your thing, in the field name drop-down list, select “Grid Squares” and fill that information in for every QSO.

  2. I mentioned in another thread displaying the contacted party’s QSO information on the screen and allowing the user to override that with a checkbox (“pull from QRZ” or “Custom”). Not sure if you are considering that already or not, but thought I’d mention it here. This would accommodate entry of a contacted party’s state / location during a P2P or when they aren’t at their home QTH.

  3. You really need to distinguish between fields that are associated with each individual QSO and fields that apply to the entire log.

    A. So if you have a compact and full mode, I would expect those fields to apply to individual QSOs–e.g. they could be different for each one. (Example: the contacted party’s Grid Square or State).

    B. But other fields that would normally apply to the entire log, such as “my” grid square, call, operator, state, rig, antenna, power level, etc. should be made available in a separate pop-up list (normally hidden from view) as optional additional ADIF fields. (I addressed this in another thread.) These fields would be exported to ADIF with the entire log, and would be associated with each record at the time of export–that way it wouldn’t slow things down during entry of each QSO. Note that you will need to do this anyway with some of the other Cabrillo-centric logs, such as Field Day, since those have fields that apply to the entire event and not just to individual QSOs. For POTA specifically, recommend allowing the user to order the universal fields within that pop-up list with an up- or down-arrow placed to the side of each field (or the “hamburger” icon in iOS that allows them to be dragged up or down). That way the fields most desired could be moved to the top. This would apply to all logs opened with that template from that point on.

Just my thoughts… so glad to see this app evolving so well!

1 Like
#8

Ok. Here’s what I’m thinking for base additions to the POTA template. When grabbing data from QRZ, name, state, county, qth, and grid will be populate for the person you’re talking to. When you enter your park, I grab the grid square associate with that park. @KZ3L and @bmwrider1, I added club callsign in the drop down as well.

Also, @KZ3L, I’m not sure what you mean in #3 of your list up there. I tried to keep the persistent fields over on the right hand side, and everything else QSO related in the main input box. Is it confusing somehow that I’m missing?

Thoughts?

pota-extras
pota-extras947×491 3.6 MB

1 Like
My Callsign - Operator
#9

Looks like a good solution . . . IF you keep the compact screen always as it is, i.e. compact. And simple.

I’m a POTA activator. I want to be able to make a quick entry, not peruse all the other ancillary info. There’s no time in a pileup to be a sightseer! Enter the call, maybe the other park number, save it, move on.

For all the other ‘data’ it’s all there once the .adi file is uploaded to a more robust program like Log4OM or N3FJP.

Don’t try to become a 1size fits all log program. We’ve got enough of those.

Jarrett, your wonderful app has been greeted with much enthusiasm not because it does many many things, but because it does one thing very very well.

5 Likes
#10

Yup. Compact mode is default. Always will be. I personally use this as my main logger and upload it to QRZ as well, so I can see the need for a few more fields. I just don’t want them in my way :wink: I want to tab a few fields and move on to the next person in my pileup. If I can autofill information, all the better. But I don’t see the main log templates changing much. If someone mentions a field they’d like to see, and more folks chime in with a ‘me too’, I’ll consider adding it, but it’s going in the hidden section :slight_smile:

#11

Jarrett, as I understand it, the fields on the right-hand side of the screen are inserted into each record at the time a QSO is logged. One can change them mid-stream (e.g. partway through an activation). Subsequent QSOs will contain the new data entered into these fields; older ones contain the prior data.

That is the way it should work for some fields like the mode and frequency. Those don’t change very often.

But assuming by design a log is supposed to cover a single event, such as a park activation, other fields most likely will apply to the entire log: Station Callsign, Operator, my park number, my grid square, my state, my county, etc. A change to any one of these should impact the entire log, not just the QSOs entered from that point on.

My point was that these log-wide fields, some of which could be optional, could be appended to each and every QSO record as discrete fields at the time of export to an ADIF rather than at the time each QSO is logged. That would speed things up during logging, but also allow a single change afterwards to affect the entire log (for instance, if I didn’t have my grid square or county at the time of the activation, but wanted to add it later; or wanted to generate a log for a second park during my two-fer activation).

When you proceed to developing logs for other portable events, such as field day, these log-wide fields will include such things as the station class, power category, etc. There are no ADIF fields for these entries. They would be exported in the header section of a cabrillo-formatted file.

I guess it’s really a design decision–keeping additional hidden fields associated with each and every QSO at the time a contact is logged has the advantage of flexibility, while log-wide fields offer more convenience.

—Break break—

Important: Is “My Callsign” always written to the Station_Callsign ADIF field? Which ADIF field does “Club Callsign” go into? Normally my own call goes in the “Station_Callsign” field, and for WWFF, my callsign also goes into the Operator ADIF field. But if operating under a club call, the club’s call sign goes into the Station_Callsign ADIF field, and MY call goes into the Operator ADIF field. Please make sure you switch the destination if a Club Callsign is entered, or just call the fields “Station callsign” and “Operator callsign” to avoid confusion and align them accordingly.

#12

Yes, when I was looking at the ADIF spec I think I got those fields confused because they’ll both represent the other if the the other is missing.

So just to clear things up so I can get them switched:

Operator - ME
Station Callsign - My Club (or some other use I’m not aware of)

Correct?

#13

Not exactly.

STATION_CALLSIGN and OPERATOR should normally both be your call sign. Both fields are required anyway when submitting to WWFF, so this makes activating under one program (POTA) easier to submit to the other (WWFF).

If you are operating under someone else’s call (like a club), then STATION_CALLSIGN is the Club call and OPERATOR is your call.

Recommend requiring STATION_CALLSIGN and fill the OPERATOR field with the STATION_CALLSIGN upon export, unless the fields contain different contents.

You could also just use the terms as you’ve presented them (“My callsign” and “Club callsign”), then populate STATION_CALLSIGN and OPERATOR in the ADIF file with the contents of “My callsign” if that is the only one filled. If “Club callsign” is filled, then switch the order when you export to the ADIF so that “Club callsign” goes to STATION_CALLSIGN and OPERATOR contains “My Callsign”.

You should make “My callsign” required entry if you haven’t done so already.

1 Like
#14

@KZ3L, thank you for walking me through this! I’ll get it sorted.

#15

I concur on county. I was just reading about the New England QSO Party, and how they (and state QSO parties) require county as part of the exchange.