"This tutorial will show you how to use OnMyCommand to create customized "right-click" (contextual) menus in OS X. If you're a recent Windows 'switcher', you might have noticed that the right-click options lack some of the commonly used tasks (move-to, copy-to etc). OnMyCommand allows you to add these, and hundreds of other commands, back to your contextual menu."
http://www.simplehelp.net/2007/06/12/how-to-add-commands-to-the-os-x-right-click-menu/
MongoDB is Web Scale
A very funny rant on no-sql repository advocates
What is your toolset?
After quitting all the non-development tools running on my MacBook I realized this is another kind of Minimal Mac. 
This minimalism has little to do with a tidy surface but instead a tidy toolset. Apart from the Drag application used to take the screen shot these applications -- iTunes, NetBeans, Screen Sharing, FireFox, Skype, and Terminal -- are my toolset. What is your toolset?
This minimalism has little to do with a tidy surface but instead a tidy toolset. Apart from the Drag application used to take the screen shot these applications -- iTunes, NetBeans, Screen Sharing, FireFox, Skype, and Terminal -- are my toolset. What is your toolset?
Halo around the foremost window
I want to stop closing the wrong window in Mac OS X. This error is caused, in part, by OS X's poor contract between active and inactive window framing. So, when I bring an application to the front I want the front-most window to be quickly haloed and then not. This would greatly help the user to know which of the several application's windows is actually the foremost.
16 months is too short a time to adopt Wave
Google recently announced that it discontinuing its Wave communications tool [1,2]. Wave was announced in May 2009 and discontinued in Aug 2010. Wave existed for 16 months. Google states "Wave has not seen the user adoption we would have liked." The rate of user adoption for such a radical change in communication is not going to happen in 16 months. Facebook took many years and its services are based on existing means of communication. Skype and Twitter also took years and they too offer services based on existing means of communication. Wave has little precedent in the wild (although many academic ancestors). Only now is the company I am working for considering moving to Google Apps and that has been out for years. Change happens slowly. The time of rapid internet tools adoption is over. We are returning to a new normal.
Every group establishes the tools and protocols of communication very early in its formation. Only new groups -- and perhaps only new groups in new situations -- have the chance to immediately adopt new forms of communication. For every other group, the group needs a lot of time to 1) recognize what is being lost in the current means of communication, 2) understand the loss's cost to the group, 3) set out to discovered tools and/or protocols that enables both to continue the successful communication and to reduce/eliminate the recognized lose, and, finally, 4) adopt the change with planning for the concomitant communications turbulence. 16 months is far too short a time to adopt Wave. For those that have adopted Wave within those 16, the time since adoption has been far too short to understood Wave effectiveness.
Google pulled the plug on Wave too soon.
[1] http://googleblog.blogspot.com/2010/08/update-on-google-wave.html
[2] http://wave.google.com/about.html
[3] http://googleblog.blogspot.com/2009/05/went-walkabout-brought-back-google-wave.html
Every group establishes the tools and protocols of communication very early in its formation. Only new groups -- and perhaps only new groups in new situations -- have the chance to immediately adopt new forms of communication. For every other group, the group needs a lot of time to 1) recognize what is being lost in the current means of communication, 2) understand the loss's cost to the group, 3) set out to discovered tools and/or protocols that enables both to continue the successful communication and to reduce/eliminate the recognized lose, and, finally, 4) adopt the change with planning for the concomitant communications turbulence. 16 months is far too short a time to adopt Wave. For those that have adopted Wave within those 16, the time since adoption has been far too short to understood Wave effectiveness.
Google pulled the plug on Wave too soon.
[1] http://googleblog.blogspot.com/2010/08/update-on-google-wave.html
[2] http://wave.google.com/about.html
[3] http://googleblog.blogspot.com/2009/05/went-walkabout-brought-back-google-wave.html
Corporate Blogs: Front Page Structure (Jakob Nielsen's Alertbox)
Jakob Nielsen has a useful posting today about how to organize a corporate blog's front page: "Showing summaries of many articles is more likely to draw in users than providing full articles, which can quickly exhaust reader interest." I agree. See the fully posting at
Corporate Blogs: Front Page Structure
http://www.useit.com/alertbox/blog-front-pages.html
Sounds in presentations
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.
My very first posting to this blog was about sound <http://calliopesounds.blogspot.com/2007/07/i-had-weird-moment-today.html>.
My very first posting to this blog was about sound <http://calliopesounds.blogspot.com/2007/07/i-had-weird-moment-today.html>.
Gobby and reviewing some source code
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.
Overall, Gobby has too many network connectivity issues and not enough document navigation features. If Gobby were to be implemented today then it should be a web application built using the Etherpad <http://etherpad.com/> and Bespin <https://bespin.mozillalabs.com/> toolkits with a little of the Nautilus file manager <http://live.gnome.org/Nautilus>.
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.
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.
Overall, Gobby has too many network connectivity issues and not enough document navigation features. If Gobby were to be implemented today then it should be a web application built using the Etherpad <http://etherpad.com/> and Bespin <https://bespin.mozillalabs.com/> toolkits with a little of the Nautilus file manager <http://live.gnome.org/Nautilus>.
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.
Streaming content for non-media applications
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
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!)
Most schema designers will create something like this
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.
In the case of the movie listings it might look like
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.
node := data children children := node* data := field+ field := name value name := string value := stringThe 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!)
Most schema designers will create something like this
movies := (movie)*
movie := title rating director casting
poster-url trailer-url movie-reviews
showtimes
movie-reviews := star-rating reviews
director := person
casting := person part
person := string
part := string
showtimes := showtime+
showtime := start-time end-time
start-time := number ':' number
reviews := review*
review := person star-rating comment-string
...
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
movies := count id* ( title |
showtime |
poster-url |
trailer-url |
... )*
title := id 'title' string
showtime := id 'showtime' timestamp
poster-url := id 'poster-url' url
trailer-url := id 'trailer-url' url
review := ...
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.
In the case of the movie listings it might look like
6 m1 m2 m3 m4 m5 m6 ; # now get the titles and next showtimes for the movies m1 title Inception ; m1 showtime 6:30 ; m1 showtime 3:10 ; m2 title The Sorcerer's Apprentice ; m2 showtime 4:50 PM ; m2 showtime 7:20 PM ; m3 title Despicable Me ; m3 showtime ... m3 showtime ... m4 title ... ; m3 showtime ... m3 showtime ... m5 title ... ; m3 showtime ... m3 showtime ... m6 title The Last Airbender ; m3 showtime ... m3 showtime ... # now get the remaining showtimes m1 showtime 12:00 ; m1 showtime 9:40 ; m2 showtime 11:45 AM ; m2 showtime 2:15 PM ; m2 showtime 10:00 PM ; ... # now get the star-ratings for the movies ... # etcHere 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.
RFPs that discourage response
Integrated Computer File Integrity Monitoring Infrastructure via http://www.transitchicago.com/
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.
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.
Animag Photo Stands
I bought a big box of these magnets for some LED throwies but do you think I can find them now? No.
Using logrotate to manage Apache Tomcat's catalina.out log file
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
Set the logrotate.conf to
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.
0 0 * * * /usr/sbin/logrotate -v --state $HOME/var/logrotate.status $HOME/etc/logrotate.conf
Set the logrotate.conf to
$HOME/lib/apache-tomcat-5.5.28/logs/catalina.out {
daily
rotate 10
copytruncate
compress
missingok
}
# END
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.
Manual duplex printing with OSX presets
I have wanted to be able to manually print duplex for sometime but never scratched the itch until today. With a quick Google search and I discovered
http://www.maclovin.de/2009/03/manual-duplex-printing-with-osx-presets/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.
Sidewalk Graffiti Provides Navigational Assistance For Subway Commuters
"A considerate cartographer wielding a stencil and a can of spray paint has left a helpful navigational compass at the top of the stairs outside the NRW train at Prince Street for commuters exiting the station. As even native New Yorkers cant attest, everyone has exited a subway station and needed a moment to reorient themselves; a directional compass will make it that much easier. The unknown compass crusader stenciled the sidewalk at the uptown 6 train station on Spring Street as well. "
http://nyctheblog.blogspot.com/2010/06/sidewalk-graffiti-provides-navigational.html
I love simple, unobtrusive signage. It can be used in physical space and virtual space. Brainstorming on this example from NYC that painted a compare rose at the exit of subway stations you could use the same technique too
* point to bathrooms near parking
* point to information booths
* point to insert-your-favoriate-coffee-franchise-here
What would you point too?
Helping out Instapaper
The Instapaper iPhone app is wonderful for reading web pages later. Some web site's content does not show up very well because the Instapaper parser can't determine which HTML elements contain the content and what is ephemera. To help it, web sites can add CSS classes that point directly at content and non-content. Add the "instapaper_body" class to the parent content element and "instapaper_ignore" to non-content within the content element. See Preview: Community text-parser configuration for more detail.
I can't swipe horizontally to read email
Yesterday I walked into the Burlington Mall's Apple Store and tried out the iPad for the first time. (I have decided to buy the new iPhone 4 rather than an iPad and so the impulse to have one has waned.) It was much smaller than I expected but this does make it more book-bag friendly. I was very impressed with its speed especially compared to my iPhone 3G. I really wanted it to have a cover. The screen just screams at you "Please take care of me! I am going to be scratched." I don't want a sleeve: Where would I put it when it is not in use? I want a cover that works something like a triptych that folds flat into the back of the iPad or can be folded for use as a stand.
I have been thinking about interface design for the iPhone and iPad for a while now. I have been working through ideas with the design of an issue tracking application as this is a tool I will use every day. (I am a software developer, after all.) I am greatly inspired by Mag+ design. It is such a deep source of ideas. The Mag+ magazine is virtually laid out in a very strong 2d space: The horizontal is used to hold the articles side by side and the vertical is used to hold the article's content. This is a very easy visual model to internalize and it can be used for lots of different kinds of content with strong peer relationships and long content. I had assumed that Apple had this idea too. You see it in their photograph applications, but I was wrong. When reviewing the iPad's email application I was shocked that I could not swipe to view the next or the previous email. This was such a natural gesture that I assumed I did something wrong. As far as I can tell, I did not. Afterwards I realized that I can't swipe horizontally with the iPhone either.
I have been thinking about interface design for the iPhone and iPad for a while now. I have been working through ideas with the design of an issue tracking application as this is a tool I will use every day. (I am a software developer, after all.) I am greatly inspired by Mag+ design. It is such a deep source of ideas. The Mag+ magazine is virtually laid out in a very strong 2d space: The horizontal is used to hold the articles side by side and the vertical is used to hold the article's content. This is a very easy visual model to internalize and it can be used for lots of different kinds of content with strong peer relationships and long content. I had assumed that Apple had this idea too. You see it in their photograph applications, but I was wrong. When reviewing the iPad's email application I was shocked that I could not swipe to view the next or the previous email. This was such a natural gesture that I assumed I did something wrong. As far as I can tell, I did not. Afterwards I realized that I can't swipe horizontally with the iPhone either.
The A Future of Information Interfaces for Emergency Management
The video The Future of Information Interfaces for Emergency Management is a good envisioning of the very possible with the possible exception of the "grab and drop" transfer of visualizations between physical machines. The front line responders all have head mounted video and, I would assume, other environmental sensors. The amount of information given to the front line was less than what I would have expected. That is, there was too much emphasis on centralized management and control when distributed management and localized control is a better approach. Other interesting features in the video include* big displays with three-heads being common
* virtual whiteboard+touch screen that shows the distant participant as if on the other side of the device.
* pie menus are finally (!) showing their strengths in a touch-screen world.
* more direct touch interaction with specialized virtualized controls.
* heads-up display on the truck's windshield.
MonoTouch and Apple's Section 3.3.1: Two Theories
I do believe that Mono has meaning for developers. Everytime I listen to the Mono folks I hear them saying the right things. Here is another one of the right things:
MonoTouch and Apple's Section 3.3.1: Two Theories
"[...] MonoTouch has been misrepresented, initially by Gruber and by most people covering the debate over section 3.3.1. Probably because few of them have actually used MonoTouch or because they are not familiar with .NET. Probably folks think that MonoTouch is .NET, and .NET is Microsoft's Java and draw their own conclusions.
MonoTouch brings the C# language and the core of .NET to the iPhone, but does nothing to provide a cross-platform UI experience or for that matter any sort of mobile device cross-platform APIs.
We bring the C# language, garbage collection, a type safe system that help reduce errors, make programmers happier and more productive on the iPhone while getting access to every single iPhoneOS API that they want to.
We have also been able to expose new APIs that Apple has exposed in record time thanks to the fact that we are not really an abstraction layer over the iPhoneOS, but merely a compiler that talks to the native APIs. [...]"
MonoTouch and Apple's Section 3.3.1: Two Theories
"[...] MonoTouch has been misrepresented, initially by Gruber and by most people covering the debate over section 3.3.1. Probably because few of them have actually used MonoTouch or because they are not familiar with .NET. Probably folks think that MonoTouch is .NET, and .NET is Microsoft's Java and draw their own conclusions.
MonoTouch brings the C# language and the core of .NET to the iPhone, but does nothing to provide a cross-platform UI experience or for that matter any sort of mobile device cross-platform APIs.
We bring the C# language, garbage collection, a type safe system that help reduce errors, make programmers happier and more productive on the iPhone while getting access to every single iPhoneOS API that they want to.
We have also been able to expose new APIs that Apple has exposed in record time thanks to the fact that we are not really an abstraction layer over the iPhoneOS, but merely a compiler that talks to the native APIs. [...]"
Subscribe to:
Posts (Atom)