SOTAWatch Alerts: suggestions for improvement

A recent enquiry from a SMP user, in which he asked why a certain alert of his did not show up properly, or at all, in the SMP alerts mapping page, has got me thinking about various aspects of the SOTAWatch alerts system: not only from the activator’s point of view, but also from the point of view of a 3rd-party software developer.

I’ve decided to share my thoughts on this topic with the SOTA community at large, not only to point out what I see as shortcomings in the present incarnation of the system, but also to offer some suggestions for improvement.

When one uses the SOTAWatch alerts entry window, one sees a helpful note under the Freq(s)/Mode(s) input field to remind users how the Freqs/Modes input text should be formatted: the note says the following: “(Format: [Freq-mode, freq2-mode2, …] See examples below, max 40 characters)”. This is helpful advice which, if it were followed to the letter by all users, would result in the Freq/Mode text being of standard format everywhere, and this particular topic in the Reflector would not need to appear.

Of course, not everybody uses the standard format, for a number of reasons, including the following:

  • spelling/typing mistakes;
  • the user has not read the help note and puts something in there which is like what others have written in their alerts;
  • the user has developed his/her own formatting system which is “better” than that given in the help note;
  • the user is well aware of the maximum 40-characters limit on the Freqs/Modes input text, but needs to place more information into that block than would be possible if the “required” formatting were to be followed.

Of the four (there are doubtless more, but let’s stay with these for now), I would guess that the last is the most likely reason for there being such a great variety in formatting of the Freqs/Modes text.

So, where’s the problem? Who cares? Why should we bother to read any further?

OK - here’s the problem, or problems:

  • users are continually frustrated in their efforts to place enough information on frequencies and modes into their alerts, by the maximum 40-characters rule, and are forced to resort to unconventional formatting styles in order to squeeze as much information into 40 characters as they can. The result is more or less understandable by the average user, so all is well. Right?
  • Software developers, such as myself (and I can think of at least two or three others), are hampered in their efforts to untangle the information contained in the blocks by the many unconventional “formatting styles” used by the users. If this were a simple task, I wouldn’t be writing this; but trying to write programming code to “understand” all the very many formatting styles is a very difficult - if not impossible - task. But why would developers worry about such a little thing? Simple: being able to “tease apart”, or parse, the information in the Freqs/Modes text would mean they would be able to achieve meaningful and accurate filtering of alerts lists, and the users of their programs would be able to filter out what doesn’t interest them. So, CW ops could filter out the rest, SSB and PSK ops could filter out the CW and so on, making the lists more useful and more personalised.

So, on the one hand we have users who are hampered in their efforts to pass on enough information to other users; on the other hand, we have developers hampered by a bewildering variety of personal formatting styles which change constantly.

What’s the solution?

The first part of the solution is the simplest: increase the 40-character limit to something more useful to the users: say 100 or 200 characters. Problem solved, right? WRONG! - this would bust the presentation of the alerts in the SOTAWatch alerts page which would mean that, with the present layout, there simply is no room for anything more than 40 characters.

Some live test scenarios

So, here is a page showing some nearly up-to-date data in that format, albeit without the extra text in the above example. Plenty of room for everything.

Now, what about that helpful note on formatting we looked at earlier? How to convince the user to get the format correct in order to help the poor overworked developer? Simple: don’t let the user even try; do it for him, and take over formatting.

So, here’s another page which does just that: each frequency/mode pair is entered separately, with the frequency being written by the user in MHz, and the mode being chosen from a dropdown.

To enter a new frequency/mode pair, the user just clicks the “Add freq/mode” button to activate another pair of frequency/mode inputs, and enters the data as before. All the while as the user inputs or alters the data, the Freqs/Modes text will be updated with the new information. Try it: everything works except that the “Add alert” button doesn’t create a new alert.

So, what would this mean to the overworked SOTAWatch programmers? A huge change, right? WRONG:

  • the length of one db field would need to be changed: one minute’s work maximum, with no repercussions on anything else;
  • a few lines of code would need to be altered in the alerts page: ten or twenty minute’s work, tops;
  • the “New alert” code would need to be altered, but a working copy of the code required is available to make such a transition a much easier prospect.

So, it’s all do-able, and would lead to less frustration for many - a win-win situation, no?



It makes sense Rob. Why not. Agree that it’s a win-win.
Charlie NJ7V

Hi Rob,

Makes all sense, what you are suggesting.

I hope this new entry window will store my previous entry. I would not want to retype the list of frequencies and modes every time. I find myself at the usual SOTA waterholes, which are also stored in my rig.

Thanks for the effort.

73 Heinz

Hi, Rob.

I feel a little responsible for all this work and thank you very much for your efforts.
I think it’s great!


73 Joao

For me there are real problems with your suggested new layout. Yes, it’s a great data bucket - but the wrong data is in the prime visibility slot! The present layout finishes with a very visible column for the frequency. As a chaser, that is what I want to know FIRST! When I look at spots and alerts, I look at time (and only the colour of the print at that!) and frequency first: the frequency is vital since it will tell me at a glance whether I need to read the rest of the posting. After all, as I am in G/CE a spot for G/LD on two metres FM stands zero chance of being heard here! Also there are bands that I prioritise, such as 5 MHz. So I do not need to glance at the highly visible right hand of the spot and see who spotted it - as a chaser that is a matter of supreme unconcern to me!:grinning: I need the vital data - the frequency - as a matter of priority! This remains true whether we are talking about spots or alerts, every now and again I look down the alerts frequency/mode column to see if anything is coming up to suit my preferences

The second problem is in your first simulated (?) entry - it has bloated to four lines. Why is this a problem? Because the more lines that are permitted to an entry, the fewer entries will be visible on Sotawatch! I use the standard view - well, the modified form that shows Spots, Alerts, the Reflector and the MT reflector. As a chaser it is Spots that is most important to me, in the standard view there are ten lines devoted to Spots, and in busy times - even at this time of the year - still active spots are crowded out of view at the bottom of the column. Yes, you can switch the view to Spots and double the number visible (and even that is inadequate at times, such is the popularity of SOTA!) but then you lose Alerts.

There might be good arguments in favour of increasing the number of characters, but it would be necessary to think carefully about the cost of an increase (loss of numbers of visible entries) and even more carefully about what in the plethora of information is the vital first-to-be-seen data.



Your suggestion is a neat way of overcoming the programmers’ nightmare, trying to decode free form data entered by a variety of people using a variety of input media.

I have found the frequency and mode combination is somewhat limiting, if I want to list all the bands and modes I am prepared to operate on. I think it is fine for what it was probably originally intended for, one band and one mode.

Your proposal also avoids major disruption to the database and to all the 3rd party tools (though a prominent and popular IOS tool currently has a time bug in its alert function and a prominent Android tool does not cater for alerts at all).

Thinking about Brian G8ADD’s concerns, which are about how the users view the data, what is needed there is a filter to display only the alerts each user is interested in. While locating the band-mode data on the right hand side of the display does make that data more visible, the user has to parse it when searching for the data they are most interested in. And unless it is in a standard format, parsing it using software to extract the band-mode data for filtering would be unreliable.

By filtering I mean that the user could be given the option of displaying only the alerts for certain countries, associations, bands or modes. The problem of having, say, 144-ssb alerts from the country you are interested in, mixed in with many other alerts would vanish if you could display only the ones that meet your selection criteria.

The app I use for viewing dx cluster includes band and mode filtering options and with so much data filling up the screen in busy periods of the week, it would be unusable without filtering. Perhaps that is a future change for sotawatch that will eventually be necessary to make the system usable.

To facilitate filtering, either the data stored in the band-mode field needs to be in a standard and totally predicable format or the database would need to be changed.

One way of doing that is to store the band-mode data in a format similar to your proposed New Alert web page, with each band-mode combination having its own sets of fields. That would simplify software trying to filter the alerts for band and mode. Essentially it would remove the need to parse free form data in the alerts list, but it would add the need to process more data fields.

So, there are many more ways to change the way alerts are stored and displayed. Your proposal is a small change to the webpage for posting new alerts and a small change to the display page. It looks like an improvement in usability so yes, I think it is worth considering.

73 Andrew VK1DA VK2UH

tested your dummy alert page. nothing went wrong!


How would you implement that? save the data in a cookie on the user’s web browser?

Hi rob

Thank you and SOTAWatch programmers for all the work done. It seems simple but it’s of huge utility to all SOTA community.

I understand your proposal but there are a problem that I see in your proposal:
The insertion of the exact frequencies in the alert!

SOTA operateurs aren’t the only users of the amateur radio bands and could be a little bit tricky to know in advance the exact frequency that I will use on a summit.

In my view, the combination of band/mode, instead of exact frequency/mode, will be much more adequate towards a more solid alert system. :slight_smile:

BTW: The actual alert page works FB to me. I use often browsers at home, at my IOS IPad/Iphone or at my Android tablet.
The last one is a Samsung but didn’t burst into flames yet… :frowning:

73 de Pedro, CT1DBS/CU3HF

With an alert do we really care about the frequency and mode? I don’t . All I want to know is that someone is planning to be somewhere at a particular time give or take.

The spot function then tells me frequency and mode once this is established on the summit under the prevailing operating conditions.


1 Like

I think the mode and frequency does matter. It’s pointless waiting around in VK for a 2M FM activation in GW.

Rob - looks good. Anything that force structure on data always helps. It means yours and other peoples tools can parse properly.

Screen “real estate” is always a problem, but some buttons to allow default display in different formats would satisfy those that want to stay the same and those that want more info.

I’m not doing any of the work though!

Rob, I am computer illiterate by your standards - but not THAT computer illiterate!:wink: For instance I know that I can open a second instance on the browser, select alerts in sotawatch, isolate the alerts column and then superimpose it on the convenient blank space on the right of the sotawatch page in the first instance. I can then open spots on the left and as a result get full columns of spots and alerts visible at the same time. So why don’t I do it? The answer is of course that I do, but as currently I only have one computer in operating condition I am often multitasking on it anyway! For instance, currently (when not on the reflector) I am laboriously comparing summit positions in G/GW with the boundaries of National Trust properties from the NT map site to see which SOTA summits may be affected by NT bye-laws.

Oh please - not pink!:grinning: The flexibility that you mention is to my mind important - my point was that however much data you have to display, you have to display it in a way that maximises its usefulness to the consumer - the chaser. Now Compton says:

But that is the attitude of somebody who is prepared to use any mode and will feel able to hear the activator whatever his distance and band. In my world I am prepared to do a mental back-of-the-envelope calculation to decide whether skip and time of day would make it worthwhile lurking to catch the activator as he starts up, and as I am working towards a target score in one mode other modes become irrelevant. At busy times spots are going up like rockets on New Years Eve, we can’t chase 'em all, we need the data highlighted that is most useful to us.

It isn’t that simple a dichotomy! Utility should drive form. What does the consumer - the chaser - need and in which order? Sort that out first and the rest should drop into place.


Or get a bigger monitor or two bigger monitors. I’d be surprised if you were short of screen real estate with 2x 23in monitors. Or just a single 23in display and the laptop screen if you are using a laptop and not a desktop.

I too was wondering if we need the exact frequency in an alert as opposed to the band and would just have a tick box for each band/mode. i.e. for CW you tick 20,17,15 and SSB 20 and for FM 2m. The good thing about a tick box is there’s no input verification needed.

i have enough trouble posting one of those "self spots"now on my phone out in the elements with the current information requirements. As for Alerts before I go to a summit I am with Pedro chances are tomorrow when I get to the summit the alerted frequency is busy. That is why I Self Spot once i am there and find a clear Frequency for my choice of Mode to get the activation underway.
Ian vk5cz …

Jumping into this very late Rob, but if I have not misunderstood something, I thought the whole sotawatch site was on the list for replacement with a more modern looking site with a full API for developers. If this is the case, is it worth modifying the existing site now, and who would do it?

73 Ed.

This is probably a valid point. I like your suggestions, Rob, and I’m sure Jon will include that feedback into the v3 SOTAwatch that is coming (sometime…). Once we have that, we’ll also have a much more maintainable code base to work off, for things like API processing. Of course, a decent API design requires a bit more stringency with the specifications (like you and Andy raise).

I don’t think anyone could doubt SOTAWatch is showing its age. Accusing a Web 1.0 website of being too Web 1.0 is like looking at me and saying I’m a bit beardy :smiley: . Yep, it’s true, but it’s a fundamental part of who I am (hipsters be damned - I was here first). My wife has given up trying to fix me, and will probably just replace me with Andrew 2.0 (or outsource me to a third world country?).

1 Like

Talking off age, Spotlite, the adjunct to SOTAwatch was written when phones had WAP browsers not full browsers and it’s still chugging along nicely!

1 Like

No problem, but if you alert for a preferred frequency then at the outset you will find keen activators sweeping around that frequency looking for you. If only a band is posted - well, that would be like looking for a needle in a haystack! I wouldn’t bother. The thing is, if there is an alert for, say, 14.280, and I find 14.280 already busy, then I will look for the most tempting looking empty channels nearby and keep checking them. The result is a quick contact for the activator and a chaser spot, and incidentally I find chaser spots more useful than an activator self-spot, it tells me where the activator is being heard.


1 Like

Which is why you SPOT when on the summit with the kit set up…