I am sitting at my studio desk now wondering where the wireless phone is. I can hear its ring and it sounds like it is coming from the house. Did Chris take the studio phone into the house? She says no. Then what the hell is happening? I have never been able to hear the neighbors' phones. It turns out that the sound is background noise in a video interview I am listening to! I have had the same experience when listening to pod-casts: I hear an email arrive and so I check my mail; I hear a text message arrive and I check my phone; while driving I hear an ambulance and I pull over. Perhaps these are just signs of my declining mental health or perhaps there is just too much directionless noise in our lives. Our physicality did not evolve for this.

Evans Lin and I used Gobby <http://gobby.0x539.de/trac/> last night to review a sub-system that he is implementing. It worked but was less useful than anticipated.

1. Gobby is a peer-to-peer networked application and so your application is both a server and a client. This kind of networking does not play well between corporate and ISP firewalls. The only way we were able to communicate was to have three instances of Gobby running: One for me, One for Evans, and one running on my home Linux box acting as a server. And even then, Evans needed to ssh tunnel to the Linux box. To effectively use Gobby in a WAN much consideration needs to be given to network connectivity.

2. As anticipated, Gobby's document management is very weak. The documents are listed alphabetically with no meta-data about ownership, modification time, directory path, revision number, etc. I also found the floating document list to get in the way more time than not.
3. When Evans and I were discussing our first document Evans asked if I was seeing his highlighting. I was not. We both assumed that not only would you see other's changes but you would also see other's highlighting. This is a good example of not knowing what you want until to actually trial your tools.

4. Gobby knows almost nothing about the documents it is presenting and editing. It does highlight the syntax of the document based to the document's file name extension. However, our experience with IDEs is that we want really good navigation between source code elements. For example, with Java source code we want, at a minimum, 1) class name to definition source file, 2) method name use to definition location in source file, and 3) method name definition to locations of use.

5. Gooby has a instant-messaging feature but we used Skype's voice chat. Gobby as an extension to Skype would be more useful.

A tool for informal review of a tree of documents is needed. (As opposed to a set of patches for which there are great tools. For example, Rietveld <http://codereview.appspot.com/>.) So, I will keep looking. Tell me if you find something good.

The vast majority of web app and mobile app use JSON or XML on the wire to transfer data. It is relatively easy to design a utility schema and textual data on the wire is easier to debug. The schema designs, however, tend to emphasize an analytical perspective rather than a performance one. For example, the schema for hierarchal data will typically look like this

The problem with this design is that it you can only know about the structure of the data only after reading the whole document. You can not do anything for the user between making the request for data and getting the last byte of the response.

I don't know about you, but I hate waiting for all the data when I don't want it. When I am in browsing mode or manual indexing mode [*] I only want to get the gist and move along quickly. For example, if I am flipping through a list of the movies playing at the local cinema I don't need an image of the movie's poster. What I do need is to know that there are 6 movies, the 6 titles, and the next two showings of each movie. When I settle on a movie then I might be interested in seeing the promotional poster, trailer, and reviews and so am willing to wait for this data to fill-into the UI. (Don't have me press a "more details" button, please!)

You get the idea: A straight forward and clear hierarchical organization of the data. The problem with this design is that for web apps or mobile apps the app needs to read far more bytes than it needs to enable browsing and manual indexing. It needs to read all the bytes up to the last movie's node first byte just to know that there are 6 movies. That could be several thousand bytes of data just to know the number 6.

Network performance is not instantaneous. Cell network performance is worse than network performance. Schema designers need to stop designing data structures as though the data will be instantaneously transferred from the host to the client. We don't do this for audio or video and we should not do it with other data either. Data on the wire should be designed more as packets to be explicitly organized. And it should be ordered so as to ensure the application's usability remains high even under poor network throughput conditions.

In the case of the movie listings, the following is a better data structure

Here the related data is explicitly linked together with ids, tags, and values rather than implicitly by position within a hierarchy. Next, order the transfer of data to the client such that the client can use progressive disclosure. The user will now be able to see some structure and some content and so be able to perform some interaction with the application before the whole structure and all the content is delivered.

Here I am using a semi-colon delimited encoding to simplify this example. There is no reason to abandon using JSON or XML as the encoding. You must, however, use a streaming JSON or XML parser so that the application client is able to get at the data as soon as it arrives.

This lesson was taught to me by David Durand when we were working on MAPA at Dynamic Diagrams. A visualization within MAPA was a Java applet that displayed a map of locations within a web site. The maps needed to display the canonical path to the location, the local structure of the site around the location, and the kinds of pages there. The data structure we used to communicate the data needed to display the map had the structural data up front so the applet could start rendering the map (in another thread). Meanwhile, the details about each page came trickling in and could be rendered piecemeal to the existing skeletal frame as it arrived. (David wanted me to use fixed-width data but I could not bring myself to do that.)

It is only now that I more regularly use mobile apps that I really want his lesson to be spread as far as possible because mobile app usability in conjunction with cell network activity just plain sucks. I don't think the primary reason for this condition has to do with hardware, or the network, and, probably, not the algorithms. That leaves the data.

[*] Manual indexing is when you have a list of 10 items and you flip through them until you find the one item that you want. I am sure there is a interaction-design term for this but I don't know what it is.

Wow! It is not until page 48 that you finally get some detail on what this RFP is asking for. And, of the 61 pages only 2 are about the work. I thought (mostly in passing) I might submit a proposal regards this request but the effort to complete the submission is by far more time consuming than the completion of the work itself. No wonder government costs are so high and RFPs are submitted by companies filled by mid-level employees.

I love these photo stands. The price is high, but this does inspire me (the good Scott that I am) to make them myself. All you need is to pickup plastic animals (or other things you can cut in half!) from the yard sales (25 cents each), a hack saw (1 dollar), some epoxy glue, and two neodymium magnets per photo stand (50 cents each). Total cost for 4 photo stands is $6 and a lot of fun.

I bought a big box of these magnets for some LED throwies but do you think I can find them now? No.

Apache Tomcat does not roll its catalina.out log each day (or after a given size). It is a small annoyance but nevertheless it is an annoyance. The solution is to have logrotate do for you. Add the following to the crontab

Notes: I run Tomcat from within its own user directory and so all paths are relative to $HOME. Logroate does not perform environment variable substitution on the configuration and so replace $HOME in logrotate.conf with the actual path.

The basic plan is to print the document twice. The first print prints only the odd pages. The second print prints only the even pages and (very importantly) with a reverse page orientation. So, print the document using the first settings. Next, take the stack of pages from the output tray and place them in the input tray as is, that is, don't flip them or turn them in anyway. Lastly, print the again document using the second settings. The result is a duplex document with the pages in the correct order in the output tray.

Max OS X allows for creating printing presets and so I have created a "Duplex Pass 1" and a "Duplex Pass 2" presets. The only bug is that the "Reverse page orientation" setting (aka checkbox) seems to be independent of the preset so be sure to make sure it is unchecked for pass 1 and checked for pass 2.

HP has a very useful application for manual, duplex printing but it has stopped working since OS X 10.8.4.