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?
Rob DM1CM
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
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.
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:
. 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?).