DonationCoder.com Software > N.A.N.Y. 2010
NANY 2010 Idea: A 'polite' reminder/diary system
doctorfrog:
Wow...lots of replies and requests. I'll try to answer them all. That initial build only represented about an hour of work so, obviously, there is plenty of room for improvement.
-skwire (November 06, 2009, 12:49 AM)
--- End quote ---
Thanks for taking the time to make the additions. I really like what we have so far.
To save time and sanity, I'll directly address your questions and clarifications, skipping over unimportant things:
* (Nice to have) Taskbar blinking: user-configurable, with a default of 9 blinks (with 20 maximum). 0 no blinks, -1 is blink forever.
* (Nice to have) Missing CR bug: This is very minor, and doesn't bug me much. I'm just being thorough. See my thoughts on a viewer below.
* File extension (rejected): this is fine, we can figure out the file extension after the program name is settled. TXT works for me, anyway.
* Timestamp in entries: If we do move to a viewer format, I vote we keep the date human-friendly, so the logfile itself can still be read separately from the viewer. That said, it can be a little friendlier than it is now. See my thoughts below.
* Timestamp in filename: Currently, the log filename only has the date affixed to it. If FrogDiary creates more than one log in a day, this means that they have the following name structure: logfile_for_20091105.txt, logfile_for_20091105[1].txt, logfile_for_20091105[2].txt. It's not terrible, but a the option for a configurable timestamp would be better.
* Timestamp feeds off of one setting/individual settings: If it's easy enough to create individual settings for logfile entry, logfile name, and popup titlebar, let's do it. :)
* Application name: Anuran is the best of those you list, and it's unique enough. And Frog Diary very quickly turns into "Frog Dairy" if you type it enough times, the implications of which are mildly disturbing. Alternatives: Anura, Ainu, EndOfLine, EndLine, Fritter. (Fritter? Frog+Twitter? Yes, this is like a personal offline Twitter feed of a sort. *shudder*)
Feature request (yes, more):
User-configurable location for log files. Archive will continue to be a subfolder of this location.
Possible bug:
I left my PC running overnight, whereupon it went into Standby. I started it again today and notice that FrogDiary did create a new logfile, but did not move the old one into archive. Not a big deal as-is, but once we get a viewer the expectation for smarter automation will be greater.
A general curmudgeony statement about a viewer:
I like text files. They're simple, portable, and viewable a year from now or a hundred years from now. I'm not opposed to a viewer at all (indeed, I could definitely see a use for it), but I do request:
* that the log files remain in a human-readable text format, whether seen through the viewer or notepad.exe. For me, this is vital.
* that we retain the user-configurable rotating archive model (avoiding cramming a whole bunch of data into a single fat database).Why: The last thing I want is to cram all this personal info into a database or an XML file (not that this is necessarily where this is headed). With Firefox, EssentialPIM, Outlook, Thunderbird, Pidgin, etc., I have plenty of non-human-readable databases holding my personal data. I barely can be arsed to dig through their individual data viewers, and I'm up a creek if the database file becomes corrupted. This selfish little software request of mine started out as a means to escape the tyranny of other bloated, proprietary productivity software. (Rant ends here.)
That said, I still consider this app to be the work of another (if not a community) and will not complain if it evolves accordingly. If other features makes it useful to others, I'm happier for it!
I'm going to do some brainstorming on the file format and the viewer, and get back to you later in the day. I'll see if I can't get a sketch up as well.
--frog
doctorfrog:
Hey look I wrote another impenetrable wall of text. :tellme:
Viewer paper prototype (see notes at end):
[attachthumb=#1][/attachthumb]
File format and viewer brainstorm:
Requirements:
* Keep format human-readable, but meaningful for an external viewer.
* Sufficient information stored so that the viewer can organize the data in a meaningful, interesting, and useful way.
Logfile Sample:
--- ---[[[[What are you doing?]]]]
[[[personal_log]]]
[[20091106 09:03:00 AM]]
[20091106 09:07:00 AM] - Eating a sandwich []
[20091106 09:35:00 AM] - Working on TPS reports []
Format:
External viewer should be smart enough to only need six bits of data:
1. Title
2. Logfile Name
3. Logfile Timestamp
4. Entry Timestamp
5. Entry Content (following the timestamp)
6. EOL Marker (following Entry Content)
That's it.
Elements:
Title
* Comes from: "Pop-up note title text" setting
* Format: text string enclosed in quadruple brackets, ie. [[[[What are you doing?]]]]
* Viewer: sees the quad-brackets and knows it is looking at the title
* User: title is presented to user in title bar and/or subtitlebar. Depending on how the user is using FrogDiary, this title may change (ie. What are you doing?, Write a creative sentence!, etc.)
Logfile Name
* Comes from: "Archive note prefix text" setting
* Format: text string enclosed in triple brackets, ie. [[[personal_log]]]
* Viewer: sees the triple-brackets and knows it is looking at the logfile name prefix
* User: sees the logfile name in a titlebar and/or sub-titlebar
Logfile Timestamp
* Comes from: timestamp automatically affixed to the logfile title when it is created
* Format: time/date enclosed in double brackets. actual time/date format TBD.
* Viewer: sees the double brackets knows it's looking at the logfile's creation date/time. Expects a specifically formatted time/date.
* User: is presented the logfile timestamp when viewing the logfile in the viewer, likely in a titlebar (see the attached illustration).
Entry Timestamp
* Comes from: obvious
* Format: time/date enclosed in single brackets. actual time/date format TBD.
* Viewer: sees the single brackets and knows it is looking at the beginning of a logfile entry, and knows the timestamp of the entry. Expects a specifically formatted time/date.
* User: is presented the timestamp (less the date), along with the entry, in the logfile viewer. (Date already should appear in the subtitlebar as previously described.)
Entry Content
* Comes from: obvious
* Format: user text string
* Viewer: sees string in between Entry Timestamp and EOL Marker and knows it is looking at a user entry.
* User: is presented the Entry Content in the viewer, along with the Entry Timestamp, visually separated from other Entry Content.
EOL Marker
* Comes from: automatically put in after each entry to demarcate the entry's end
* Format: empty bracket, ie. []
* Viewer: sees the empty bracket pair and assumes an entry has concluded
* User: doesn't see this unless he opens the log file with a text viewer. The EOL marker should be minimal and not interfere with plaintext readability.
Viewer Example:
Viewer sees the data in the logfile sample (way up at the top of this post) and presents it as follows:
* [[[[What are you doing?]]]] - becomes the titlebar and subtitlebar text in the viewer
* [[[personal_log]]] - becomes subtitlebar text in the viewer.
* [[20091106 09:03:00 AM]] - demarcates the beginning of an entry. Time and/or date is used as the beginning part of an entry as presented to the user.
* Eating a sandwich - becomes the 'body' of a log entry
* [] - the viewer sees this and marks it as the end of the entry. No visual cue to user, except that the next entry, if any, is appropriately placed further down on the timescale.
* AND SO ON.
Notes:
* My use of brackets can obviously be substituted with other computer-friendly markup, but it's still vital that the file be human-readable.
* Having both title and logfile name in the same title or subtitlebar may be confusing, but I don't want to dispense with one or the other.
Illustration notes:
* Look and function is somewhat similar to Outlook, Palm Desktop, EssentialPIM, etc.
* Log viewer presents data in the form of a vertical timescale. Each entry is timestamped and the relevant text is shown.
* Timescale automatically lengthens vertically based on the density of entries.
* Clicking on a date in the calendar causes viewer to search through all logfiles specific to that date and compile that information in chronological order in the Log viewer pane.
* Clicking on an individual logfile in the file browser causes the viewer to present data for that logfile only.
skwire:
Points:
When I mentioned file format, I was just thinking something VERY simple. As in, no more complex than it needs to be to parse reliably. Maybe something like:
§ 2009-11-06 14:30:56
<Entry - 1st line>
<Entry - 2nd line>
<Entry - 3rd line>
§ 2009-11-06 15:30:56
<Entry - 1st line>
<Entry - 2nd line>
I like the name Anuran as well so feel free to come up with an extension. anu/ana/anr/ann...whatever.
Regarding your concerns about a viewer...don't fret. I love straight up text files as well. I wasn't thinking of anything more than a simple listview for the entries and an edit field to display the text. The neat thing about a viewer is that I can parse and display ALL the log files' entries at once in the listview. Maybe add a simple search functionality and call it done. Very simple.
So far today, I've implemented the following:
+ Made popup window always-on-top. (Thanks, tomos)
+ Made application single-instance. (Thanks, doctorfrog)
+ Added option for wave file play on popup. (Thanks, doctorfrog)
+ Added option to flash the taskbar on popup. (Thanks, doctorfrog)
+ Added Enter/Ctrl-Enter options to popup. (Thanks, doctorfrog)
* Popup window now remembers its last position.
! Blank entries are no longer saved.
Also, I've spoken with Mouser and, due to the interest and ideas, I'm going to make this my NANY 2010 entry. I hope nobody minds.
skwire:
Hey look I wrote another impenetrable wall of text. :tellme:
Viewer paper prototype (see notes at end):-doctorfrog (November 06, 2009, 01:03 PM)
--- End quote ---
Holy moly. :o I wasn't thinking anything nearly that complex. Again, I was just thinking of a simple listview and edit field. Perhaps a search option. Maybe an option to display all the text from all the logs in one shot. So, trying to keep this simple but still useful.
doctorfrog:
It sounds like we want the same thing in terms of simplicity, so please just take my spec as suggestion and the fleshing out of an idea, nothing more. I've written for some pretty persnickety folks, so being extremely specific is a force of habit.
In the end, I'm happy with a polite popup, and automatically archived text files.
The .anu extension works for me.
I'm also totally stoked that you're using my idea for NANY. Let me know if I can help out with any drudgery.
Looking forward to a snapshot!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version