A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
From: Frank Reed
Date: 2018 Jun 10, 11:43 -0700
Right: no colors available. If you want to indicate new items, just tag them [NEW] or some such. And then after a few more edits or a few days, whichever comes first, you can remove those tags. By the way, if you want to use other software to do your editing offline, that's ok, but try to avoid making a copy of the current file on a Monday, e.g., doing a bunch of edits, and then pasting that entire document into the editor on a Thursday. You'll wipe out any changes that were made in between (this is not disastrous since copies are always saved, but it's inconvenient since someone will have to manually merge the changes). The best approach, if you work offline, is to mark your items [NEW] or [EDITED] and then copy and paste them into the latest version of the chronology individually. Best choice is to edit online. And seriously, it's as easy as I could make it. There are lots of clever tools online for collaboration on documents like this, including of course the "wiki" software, but most of these would quickly exceed the tech skills of the majority of NavList users.
And speaking of colors, let me remind you all that marking up online text documents of any type, here on the NavList message boards or anywhere else, with colors is a really bad idea. Text colors are not considered "semantic" on the Internet. They're merely decorative styling which means that web browsers and other tools are free to ignore or change text colors as they wish by whatever algorithm they choose. In addition (and partially connected to the general Internet practice denying "semantic" status to text colors), many people are color-blind to some degree.
Oh, and if you encounter any technical difficulties with the online editor, please let me know. It's brand new code that I knocked together this morning and there are bound to be bugs. I'm not inclined to make it more complicated, so I'll only consider feature requests if they really make sense and add value, but if something is broken I'll certainly fix it as soon as possible.