Image via http://www.theverge.com/2013/3/19/4122388/can-oculus-rift-save-virtual-reality
The year is 1995, the climax of the “virtual reality” fad. Virtual reality was about to become a big industry, or something. You could even get a degree in it.
Except… where is it? It’s in movies, some pretty bad movies, at least. It’s at the mall, though it’s pretty awkward. You can buy it at Fry’s Electronics, but it’s quite expensive, very slow, and there are only a handful of games that support it. Virtual reality never really happened all the way, at least not like it was portrayed in science fiction. It had arrived, but only virtually, not in substance.
Fast forward almost twenty years. That should be enough time to rinse away the bad taste of Lawnmower Man.
Last time, I talked about what a sales receipt represented in JSON format might look like. But in the aftermath, I realized something important: I had left too many options open for how to display the information.
Initially that detail wasn’t a concern, and I had been focusing solely on versatility, ease of support, and Murphy’s Law. Considering the file format only in terms of a hierarchy of data fields, I disqualified XML in favor of shorter & sweeter JSON. But part of the "versatility" is in allowing different stores to present their receipts in their own arrangement, not so much because each store might present different optional fields, but because the receipt can be part of the store’s branding, or "user experience," and I shouldn’t be the one to override those subtle details. By using XML, I still allow applications to rearrange the data into an efficiently uniform, clinical presentation if they so desire, but I also allow stores to provide a default presentation of their own choosing. Plus I don’t leave the initial visualization up to your imagination because the XML could be embedded in a browseable XHTML. Or better yet, the receipt could be defined by a "microformat" like RDFa. More people win this way.
When people look over my shoulder, one of the comments I often get is, "What program is THAT?"
Since about 1990 or so, I’d been using this file management utility called XTree. The last version for DOS was called XTreeGold. I used it for many years, even after it became increasingly hindered. The biggest problem was that XTreeGold doesn’t support long filenames.
Fortunately, the persistent demand for the functionality provided by XTreeGold was great enough to prompt several clones. The most accurate and successful of these is called ZTreeWin.
Without trying to invoke stereotypes, I would say that the majority of the people around me today like to work on the Mac. Those people are excused. Those using Windows, however, should at least become aware of this utility. This program is basically what all other file management programs ever made wish to be. The many "commander" programs out there just don’t compare.
I know that more people aren’t using it only because it runs in a text window, not a Windows GUI. But that would be a stupid reason if you only knew the power of the dark side. I mean, uh, let me try to explain some of ZTreeWin‘s more powerful capabilities since they don’t become readily apparent until you’ve been using it for a while.
- It’s much faster to use and more responsive than the Windows GUI. Your computer is faster than you again!
- It can search a group of files faster than the Windows GUI.
- It can perform any of its operations on any arbitrary selection of files across any drives and directories. It has powerful filtering and selection mechanisms. In other words, I can select files from anywhere on my system and act upon them as if they were “all in the same window.”
- It can browse compressed archives (including
docx files), and presents the contents in the same tree UI as for the filesystem. It can be configured to invoke virtually any archive utility, like 7-Zip, within its uniform interface.
- It can show the differences between two text files and can also show differences between two directory branches.
- It has a hex editor built in.
- It can show how many bytes are being used by directory branches.
- It can rename or renumber a group of files.
- It can remember frequently used console commands and batch scripts to be invoked using the currently highlighted files or directories as arguments.
- And more…
So, for example, I could view all the files within a directory branch in a single pane, filter the view to show only files with certain extensions, reduce those by date range, reduce further by a text search, then take the results, regardless of what directories the files in the resulting group are actually in, and 7-zip them (with or without relative paths), all within a few seconds.
After my boss witnessed me perform such operations with ridiculous ease, I was summoned on many occasions to solve tedious little problems that would have taken hours using the standard Windows GUI.
ZTreeWin may be overwhelming at first, especially if you’re fixated on using the mouse for everything. The difficulty in learning the program is due to it being entirely hotkey-driven, and the hotkeys, invented in the DOS era, don’t fully correspond to anything you’re familiar with. But it is well worth learning if you’re going to be using Windows for a while. I would be crippled without it.
Whoops, I forgot to put a disclaimer up front that this protip is only for "power users" or greater. If you have a thousand icons on your desktop, then uh, never mind.
Or: Wielding the Terrible Power
Instead of talking about the code or the tools, I’d like to address the personalities of those responsible for building the web sites and software we have to use every day.
Why is so much software, well, not necessarily broken, but just shoddily built? The website of an international airline that only works in one web browser. Or maybe it’s a famous university. Or my favorite, a manufacturer of CPUs. A mobile phone company that doesn’t seem to understand best security practices. An ISP that doesn’t know passwords need to be encrypted. There is a lot more going on besides just a lack of experience. Today I assert one of the problems is a lack of accountability.
Last time, I rambled for a while about what it might be like to have a file format for itemizing a sales receipt. This spurred a bit of conversation, which was helpful. In particular, Troy Farrell offered some very sound observations, including that printed barcodes could make for a great transit mechanism, although the amount of data I’m interested in cannot be simply packed into a barcode, at least not a QR code. Troy’s suggestion for the barcode to represent a URL leading to the rest of the data is a smart compromise. And although I do miss manipulating the byte-wise data structures of the DOS era, one of the directives here is for the format to be human-editable Unicode text.
I have been very tempted to use YAML because of its seductive lack of extraneous punctuation. However, the full YAML specification is many times as complicated as JSON. And it’s not quite as readily supported as JSON. And the reliance on significant whitespace is perhaps a liability for the not necessarily computer savvy target audience. So I must regrettably concede that JSON presents a smaller "Murphy’s Law" factor.
I also toyed with a recursive structure, but for similar reasons, I quickly nixed it. It could be prudent to impose a self-checking hierarchy requiring all of the embedded totals to balance out. But that would make representing basic cases needlessly complex, at least from the simple expectations of a paper receipt. There’s a reason nobody uses the MNG file format. It’s for this reason that most of the fields are optional, and that
subtotals are expected only to be informative, not to be validated. Still, I think this is worth debating.
It would be premature to write out a long, boring specification at this point. But it’s never too soon to whip out a mockup and see if people have something to say about it. You’ll just have to question anything that isn’t self-evident.