Thomas, what part is incorrect?
I think everyone on the thread understands that the data portion ends up as an xml file that's attached to the mail and in addition, there is a plain text version of the form that's pasted in the body on the message for convenience. Is there something else that we're fundamentally missing here? (and yes I'm sure there are many other aspects of form I need to learn about like the GPS mapping, etc.)
All,
I think there is a lot of good intentions here, but I sense a definite tendency to re-invent the wheel.
The Winlink applications, both client and server, are OLD. Much of the code is 20 years old and unfortunately written in a SDE strongly linked to Windows and X86-64 or -32 bit architecture.
There is a current development effort to rewrite the code base in a more modern SDE to make it possible to port to multiple architectures, such as X86, ARM, etc. It is all volunteer work and slow.
Andrew Walker (WoAD) has done an amazing job of porting the client app to Android, and it is usable, Forms included, on anything from a cell phone to a Tablet. It is still a work in progress, and suffers some of the same problems as Radiomail such as lack of a native VARA or VARA-FM module.
George has also done an amazing job of working around Apple’s infamous restrictions on app development, ie., unavailability of hardware interfaces.
A serious effort to pull together those who, as a team, might speed this development would include the people most involved in Winlink Forms design and development. That would include Greg Kruckewitt KG6SJT, and Oliver Dully K6OLI.
Another would be Phil Sherrod W4PHS, who has been responsible for most of the code maintenance and improvement
I am a fan, not a naysayer!
Thomas
George - I was specifically addressing the misleading comment that Winlink Forms are not attachments. I meant only to elaborate on the concept - the Forms are not attachments, but the transport relies on attachments.
And congrats on the job you have done in taking Joe’s offhand suggestion and running with it.
Aloha
Thomas /KF7RSF
I'm not enough of a CSS person to know, but is there a blob of CSS that could be added to the existing forms that would make them more responsive on mobile and still function well on desktop? If so, we can probably get that code added to the standard forms, though it will take a lot of time to roll it out. (and the forms manager will probably whack me over the head with the biggest iPad he can find for suggesting this)
-Scott, NS7C
Thomas,
I am going to have to fire up WoAD in the Android Emulator and have a look;
I don't have a modern Android device and I can't find any screenshots
showing what a form looks like on a phone-size screen, only a tablet.
Regarding those people you mentioned doing work on the forms, are they
collaborating somewhere using a mailing list or a forum or something?
- Wes W8WJB
Wes,
All those I mentioned are members of the Winlink Development Team, as am I. I happen to be a lowly tech support person and Moderator of the quite large Winlink Programs Group hosted on Google Groups:
https://groups.google.com/g/winlink-programs-group
Be aware that there is a much smaller, and not officially supported email reflector of the same name here on Groups.io.
The Google Groups list would be the most convenient way to reach those individuals. The members of the WDT monitor that group.
Thomas /WDT
KF7RSF
Scott,
Unfortunately, most of the forms appear to be structured as tables. You
would have to basically break the behavior of a table to get it to flow
correctly. While I'm sure there might be a CSS wizard out there that might
be able to bend tables to their will in this way, it's generally a much
easier route to convert the layout to <div>s.
- Wes W8WJB
Another existing tool is Pat Winlink, available for Unix, MacOS and Windows. https://getpat.io/
Pat has most of the capabilities of RMS Winlink and can work with a GUI through your browser. You can ask Pat to update Forms and Stations with a click if connected to the Internet.
From my limited experience filling and responding to forms, using a smartphone would be challenge on the small screen.
RadioMail is a great tool to send and receive Winlink emails by radio with gear you put in your pockets: iPhone, Mobilinkd and an HT. Continue to improve RadioMail, but follow the KISS philosophy.
Before we get lost in the weeds:
We are certainly open to making forms small screen compatible, provided
a) Someone or several someones volunteer(s) to spend the many, many hours programming that. With 110+ forms in the standard library alone, that could be quite a project.
b) The full functionality of the forms in Winlink is preserved. Sounds easy, but there is a lot going on behind the scenes.
73 de Oliver K6OLI
Winlink Forms Manager
Oliver, welcome to the conversation. Could you enlighten me (and the group) on the current form creation process? For example:
1) How does someone request a form to be added to the global form catalog?
2) Who decides what gets added or not? For example, there are multiple flavors of 213 form, presumably for good reason. Are there criteria for something to be added or not?
3) Who creates the form? Is it always a Winlink volunteer or has there been instances where a user is technical enough to create their own form and submit it to you for inclusion?
4) When a new form is created, is there always a paper counterpart? Are there example of forms that don't follow the layout of their paper counterpart?
5) Is there a public git repo for the forms? Could anyone provide an update to a form via a pull request?
1) For Standard Templates one would contact me.
There are three forms folders in Winlink: CALLSIGN Templates, Global Templates and Standard Templates. The Standard Templates are managed by the WDT and updated. Winlink checks the CALLSIGN Templates first, then the Global Templates, then Standard Templates. That means if the same form exists in the CALLSIGN Templates and the Standard Templates, for example, the CALLSIGN Template takes precedence.
Anyone can add whatever they want to the CALLSIGN and Global Folder Templates. Those are not overwritten when the Standard Templates are updated.
We host some non-standard forms on the Winlink website at
https://winlink.org/content/forms_not_standard_library_download_process_instructions
Those are usually extracted to the Global Folder Templates.
2) The Winlink Development Team (WDT). In practice that means me at present because I manage the forms catalog.
We are pretty selective with Standard Templates, as the forms library needs to be small so it can be downloaded over iffy internet connections.
We look at general applicability, life safety impact, usage, pre-existing paper forms, agency sponsorship and more in the selection process.
We deleted many custom 213 over the past few years. Some legacy 213s still exist because they are in active use.
We encourage everyone to use standard FEMA/HICS forms.
3) Greg is the forms writer, I am the manager.
Yes, there are examples of forms written by users. The IARU Radiogram was written by an Austrian ham, the Hawaii forms by Van. We conduct the same applicability and quality checks on those as on the internal forms.
4) There is almost always a paper counterpart to a form. And we are moving away from implementing forms without actual pre-existing forms. With pre-existing forms it is clear what success looks like. Pre-existing forms are already in regular use.
The DYFI form and JPATS have digital counterparts. The Winlink Check-in and Check-out forms, are "organic", i.e. without paper counterpart.
5) At present Winlink is not set up for Github. That may change at some point in the future, but that would have to be a decision supported by the entire WDT.
Hope that helps.
73 de Oliver K6OLI
Georges,
The majority of the winlink forms are used for reporting i formation to and making formal requests from governmental entities and NGOs. They are designed to duplicate as close as possible the official adopted paper forms of these entities for submission of field information and making requests for aid. They are intended to be delivered by radio or internet to the respective governmental or NGO entities where the are either printed or stored as digital documents.
Your FAQ page response about winlink forms and the need to develop a new phone screen friendly set of forms misses the point that the forms are not generally being sent to another IOS device, but delivered to a microsoft windows based computer which uses winlink express to receive winlink messages. If you develop a new set of input forms for Radio Mail, they will need generate the same data set (named data fields, formatting of the data etc) that allows winlink express to populate its output forms which mimic the official paper forms used by governments and NGOs.
WoAD appears to include the actual wilnink forms and provides for easy scrolling to portions of the form that do not fit on a phone screen. I have used WoAD with forms on a 10 year old android phone and have not had any issues in filling in the fields. Any missed mandatory fields generate an error response that shows the user the blank field so that it can be completed. I believe that error response is the same as imbedded in the windows based winlink express forms.
I strongly caution against developing an IOS set of duplicate forms unless they are fully compatible with the standard winlink forms that will be used to deliver the generated messages to governmental entites and NGOs. And as the form set used in winlink is generally updated weekly, you will have a fairly busy schedule in keeping up the forms compatibility. Sticking with the standard winlink forms and providing a mechanism for updating them from winlink.org would be the best solution.
Don
N7WTR
Don, thanks for sharing your experience with WoAD.
To clarify, the goal would be to achieve interoperability, not to create a parallel system. When talking about forms, there are 3 parts:
1. Compose
2. Serialize to a machine readable attachable payload
3. View
(I'll omit the bit about generating a human readable payload in the mail body)
When we're talking about optimizing the UX experience, we're mainly talking about Compose and to lesser extend View. The idea being that as long as payload are generated in a compatible manner, "forms" can interoperate between systems.
I'm curious to know why forms need such frequent update? Is it to correct implementation bugs or to keep up with changes in the actual forms (do paper form change that often?)
I understand the desire for a good UX in RadioMail since it's so polished and nice to use. It's probably causing all kinds of anxiety viewing desktop HTML forms on an iPhone screen. I use Winlink weekly and almost always use forms (e.g. ICS 213 or Local Weather Report or Winlink Check-In or a custom form shared by a group).
I'd say: Fulfill the need for client interoperability by first releasing a pass-through version that simply references/uses existing Winlink forms and lets the user deal with the horrendous desktop UX on a tiny screen. I know it probably breaks all kinds of design principles of RadioMail, but the functionality is important. Iterate later on improving the UX for each form if you so choose-- like K6OLI said, a daunting project in itself. Now that I mentioned custom forms, that is something to add to the feature request: The ability to import one's own custom forms for local group use. File transfer in iOS is surprisingly frustrating, so I'm not even sure how that would work... iCloud drive?
Another thought: Forms getting stale from periodic Winlink updates could become a maintenance nightmare for this app, how does WoAD update? (I'm shocked there's no source control on these forms, can we get WDT to put these in github please?) I swear every time I open Winlink Express there's a popup to update forms.
I would also want the option to toggle between desktop version and any "improved mobile" versions, so not to confuse some people.
All in all, I echo the sentiments of others. This is a highly publicized Winlink client, so by definition it inherits the responsibility of conforming to established Winlink System functions such as the standardized forms framework used by many groups.
My 2¢
73,
Dennis AD6DM
outside of the source control discussion:
A radiomail-specific CSS file can redefine how table and related html elements are presented.
As already mentioned, this may not be a trivial exercise, especially since existing Winlink forms are not available in a source-control system like Github.
Making that available would allow easier experimentation, and the existing maintainers would retain control over what gets into any updates.
Overall, moving source code for Winlink into repositories, then exposing to the broad community of experimenters and code experts, would open opportunities for making cross-platform OS/HW versions available.
Again, the existing controllers and maintainers would still manage what happens as a result of the willing experimenters offering their “patches” for review.
Basically moving away from the world of proprietary coding to specific OS/HW can improve interoperability. It will take time, but there’s untapped potential by moving to open-source and related modelling.
Picking up this thread and hoping to get some feedback from experienced form users. I've finally got some time to play around with forms and have created a rough proof of concept that can compose, view, and serialize filled forms to XML for attachment. There's still a lot to do, such as updating forms over the air, handling replies, adding custom forms, error handling, etc.
With iOS WebKit, all of this can happen in an embedded browser view, making the experience quite seamless. I can even inject arbitrary CSS to make some adjustments and improve the mobile-friendly layout. Another benefit is that once a form is filled, it's easy to save it as a fully rendered PDF, allowing users to print forms and share PDFs via SMS, regular email, or other means using iOS built-in share capability.
So, I'm at a crossroads where I need to decide if this functionality should remain within RadioMail proper or if there's any value in creating a standalone form app for iOS (that integrates with RadioMail). I know that most forms allow users to save and load form data as JSON, so presumably, there is a subset of users who fill out those forms but aren't equipped or licensed to transmit them via Winlink. Would a standalone form app make sense for any audience, and is it a large enough group to matter?
I'd appreciate any informed opinions or examples of such standalone form usage.
Georges,
I am a member of the Winlink Dev Team, mostly involved as Tech Support, with a particular interest in EMCOMM and the installation and use of Winlink Gateways , their configuration, and sometimes creative use.
I am not a programmer, but I have been involved in the functional development of Forms/Standard Templates since their introduction. Joe Speroni can tell you more about my work with John Trinterud (a real rock star) and unusual derivations of Template use and transport.
I am a very long-term Apple Fanboy and applaud your work on Radiomail.
I think you should aim to duplicate the FEATURES of Winlink Express within the constraints of IOS. If desired for serious EMCOMM work, your client must be able to select, compose, submit, etc., and yield the same plaintext message plus two attachments as happens in WE. One is the .XML file - daata used to re-populate the fields of the Template Form at the recipient's end. The other is the FormData.txt file which contains data that gives the template the huge value of GPS tagged, detailed info that can be filtered by multiple criteria and displayed by common GIS software mapping tools.
The Save and Load Data feature is used much more often to allow quick additional updates of prior messages than for use of unlicensed personal. Send one SitRep now, save the Data, and then one can very quickly load that data, edit the updates, and send a second very quickly without needing to re-type all the fields that are unchanged.
I cannot help with writing code (I peaked with COBOL and FORTRAN), but if you want to discuss strategy and usefulness of design, get my number from Joe AH0A and call.
Thomas
KF7RSF
Hi Georges,
My perspective as a frequent forms user… For the past few months, I’ve been volunteering with Winlink Wednesday (https://winlinkwednesday.net/) as one of the alternate NCS for the morning and evening peer to peer sessions.
Winlink Wednesday is a weekly emcomm drill to help people attain and maintain proficiency in using winlink for emergencies. Once a month, we ask participants (free and open to all amateur operators — we currently get some 700 or so weekly check-ins) to use an ICS-213 form to fill in their station check-in information. We do this because many recognized EMCOMM organizations routinely use forms. (There’s also a monthly weather observation week and two basic check-in weeks.)
As an ANCS, I estimate 80-90% of my station’s check-ins correctly make use of the ICS-213 form.
The standardized form makes it easy to ingest a large amount of data quickly, as the fields are standard and normalized quite well. It can easily be pulled into a database for further processing. (Of course, so could XML, JSON, etc., but the EMCOMM world uses ICS forms.)
So, from this user perspective, I’d say supporting the capability would be worth doing. Now, how you implement that is entirely up to you as the developer, of course.
When a Winlink Express user selects a form, he’s thrown into a browser to edit the input fields and press the submit button, so there’s already precedent for using an external process for data entry.
Happy to help in any way I can.
Cheers,
Ken van Wyk
Armata Scientia
I think the key question for individuals and groups that use these forms
is: "Will you ever have the need to send a form like this via some other
mechanism than Winlink?" i.e. if you would want to send and receive these
forms via email or SMS or even another radio protocol, then I think it
makes sense to create a separate app that integrates with Radiomail. As far
as I know, the other major way that EMCOMM folks send ICS forms is with
*Fldigi*, to the extent that there is a "flmsg" companion app for this
purpose. Now, I don't think a version of Flgidi exists for iOS yet, but
some enterprising iOS developer could make it happen. Wouldn't it be pretty
nice to have an "EMCOMM Forms" app that was able to compose a form and send
it via Radiomail and/or a Flgidi protocol?
A couple other points to consider:
- Pace of versioning. Right now, if you bundle the forms functionality in
with Radiomail, every time you make a tweak to a form, you would have to
release a new version of Radiomail to the app store. Users might get tired
of constant updates and defer them, causing them to miss an update to core
functionality. However, you could host the form data externally and
alleviate that issue. Perhaps the app could periodically download the
latest forms from a Github repository.
- Source licensing. I'm assuming you'll be keeping Radiomail closed source,
but you may want some assistance with a forms app, by making it a separate
app, you could potentially put it in a Github repo and accept pull requests
from people that want to help update and fix forms.
Personally, I looked into it a bit, and what I saw was a mountain of work
to get the CSS laid out right on a smaller screen for a community that
tends to get grumpy at any change. Or in other words, lots of work == lots
of criticism and little thanks. So, I'm super supportive of your efforts
and would probably assist with code if there was a place to do that, but
the overall feedback so far has put me off from undertaking it myself.
- Wes W8WJB
