@_wb_: Wow, what great achievements!
I am really glad that our co-operation as developer and interaction-designer works out that fine!
Concerning pure technical functionality my suggestions are completely implemented besides some minor technicalities,
concerning interaction design & user interface design, some things can be improved, and I joyfully provide my feedback to you.
INTERACTION DESIGN:
Not showing the pause/proceed usage hint on the help page:
Ok, as it is an extravagant pro feature, a mention in the help-file is sufficient.
Logging status info:
If logging is off and the interval is modified by the user, there nevertheless should be feedback to his/her input in the GUI.
Suggesting to show this line in the "logging-info-area":
Logging off. Interval Xs.
And hide that info after $info-timeout seconds (suggesting 2-3 secs).
Should the user modify the interval before the 3s timeout (most likely use case: successive key presses to achieve a certain number), the $info-timeout starts to count again, and 3 seconds after the last keypress the info disappears.
If logging is paused, this should be shown for $info-timeout secs as well:
Logging paused. Interval Xs.
Additional info. If logging gets turned off, it would be fine to see:
Log file closed: <filename>
for the duration of $info-timeout secs.
Interaction of "L" and "P":
Should behave like this:
"L" is the master toggle, "P" subordinate to it.
"P" only has an effect if "L" is on, else it is ignored. (Currently "P" starts logging although "L" is off)
If "L" if off and gets turned on, the state of "P" (pause or proceed-ready) is irrelevant, shall not prevent "L" from starting to log.
After "L" (logging into a new file) is active, the next "P" press is for pause, then proceed, then pause, and so on.
Praise: Key "5" also linked to the help screen:
Good idea as after successively pressing 1,2,3,4 … you intuitively press 5.
And there are enough available keys in your app anyhow.
GRAPHICAL USER INTERFACE:
Praise: The new lightweight theme is:
- visually pleasing
- with less info (not overwhelming)
thus a good alternative for novice (or less techy) users.
Praise: Consistent navigation metaphor:
"About" only has left signpost ("Network"),
"CPU" only has right signpost ("Battery"),
creates a spatial feeling.
In addition the first (="leftmost") panel has a left text-alignment, the last(="rightmost") a right text-alignment.
But the "help screen"'s remaining text layout is ugly, thus the concept is not grasped immediately, rather seems as a unconscious side effect of the ugly layout.
But I am sure, you had this thinking behind.
If the help screen's remaining layout is improved (no need to describe, I think you have the feeling for it), then also the navigational concept is complete.
SEMANTICAL & TECHNICAL:
File name:
log_YYYY-MM-DD-hhmmss.csv
Somehow a strange mixture of multiple styles:
- Underscore and hyphen symbol.
Suggesting to use only one. My personal taste (and Google's recommendation for URLs): "-" (hyphen aka minus).
[*]Separators between YYYY MM DD, but not hh mm ss.
[*]The generic name "log".
- Would be good if you have a filename which:
Opens with the correct application on launch: ".csv" achieves that well ("filename.log" would transport the meaning just as well and spare log from the filename into the extension, but likely open a unsuited app, such as a Console utility.
- Unambiguity: Can be taken right away and shared without further renaming, bares enough self-immanent info and provides a recognition value, also working as a promotion for the platform & your software.
pandora-sysinfo-log-YYYYMMDD-hhmmss.csv
- pandora-log-YYYYMMDD-hhmmss.csv
[*]Not conflict with filename length and character encoding standards.
- I think DOS 8.3 can be gently ignored, but possibly stay within the 32 char limit of some systems (although most contemporary systems anyhow have 256)
pandora-log-YYYYMMDD-hhmmss.csv
CSV header:
It's a brilliant idea to simply write "Design charge" and "Full charge" as the first 2 rows, and put their corresponding number into the suitable column right away.
I had also thought of a header with basic data such as "Design charge" and "Full charge" and the Pandora model and serial, but my testing in various spreadsheet apps, showed that they all had a problem, if the first lines had a different format then the remaining lines. Thus your solution elegantly solves this!
Suggestions:
- Simply write "Full charge" instead of "'Full' charge", as some speadsheet apps have problems with quotation marks, as they could misinterpret them as string separators.
- Its fine to write out the full names, nevertheless "degrees Celsius" can be abbreviated to "°C" (not ASCII compatible) or at least to "Celsius" or "C".
CSV delimiter format:
- Your format as-is (comma + tab) is inconsistent with itself between the columns "battery temperature" and "downloaded bytes" (tab + comma).
- Regardless of this, I anyhow propose to use a single delimiter character.
Preference from most to least like-able:
Semicolon (works best in most spreadsheet apps, bad to read in pure text editors)
- Tab (troubles some spreadsheet apps, good to read in pure text editors as it aligns columns quite well)
- Colon (Not that good, as this is often used as a decimal-separator in some countries)
I tested your comma+tab file in these apps with these results:
- Apple Numbers 2009 (2.1): Fails, all shown as one column.
- Microsoft Excel 2012 (14.1.4): Fails, all shown as one column.
- NeoOffice 3.1.2 (based on OpenOffice): Fails, although one has many interpretation options at file open time.
All this separator settings fail: Tab, Colon, Tab and Colon, Custom ",\t".
- QuickLookCSV file preview in Mac OS X Finder (file browser): Works.
Even the maliciously formatted column border is shown correctly (as a number only without any disturbing comma within cell content).
Seems to have a very tolerant parser!
SD writing interval:
If I set my logging interval to as low as 1sec, sysinfo writes to SD quite often, I see my LED blinking about every estimated 3-5secs.
As agreed for SD card longevity a lower write interval would be good, somehow in balance with the risk of a potential data-loss for the duration of the last 1 interval in case of a crash.
Logging time continuum:
It seems a timeshift occurs over time.
Run every x seconds + delay from OS + app, instead of run every x seconds as thread, to ensure precise timing.
