I think the basic points are the same as with any rebuttal. The main difference between CHI/UIST and most other venues (e.g. SIGGRAPH) is the addition of meta reviews which might provide helpful summaries for rebuttal.
November 8, 2013
November 4, 2013
While focusing on rushing a project it can be difficult to stop and think about the overall picture, but without that you could end up wasting a lot of time in the wrong stuff.
Spend a few minutes writing down the plan, rationale, and whatever thoughts you have at the beginning of each day before the crunch begins. This little initial investment can greatly enhance the eventual efficiency and happiness.
If you are my collaborator I can vet your sanity through your write ups. I am not looking for a PhD thesis; just a few sentences will be enough.
October 17, 2013
A capital crime for computer science is manual repetition of uninteresting tasks. You will be happier and more productive by proper automation, which, coincidentally, is a main job for computer scientists.
For example, instead of sitting up all night tuning parameters of an experiment, you can write a script to try over a million settings over night while you go home sleep or have a fun time in Lan Kwai Fong.
October 14, 2013
I stumbled upon this article about group brainstorming today.
It echoed well with my own personal experiences and my general take that meetings are almost always completely useless for research/creative works.
I do meetings only when absolutely necessary, such as resolving major confusions or conflicts among multiple team members, evaluating live demonstrations of a UI design, and interviewing (i.e. reading) people.
Some managers and administrators like meetings. Fight them with all your power. Do not let less intelligent people waste your time or reduce your effectiveness.
August 5, 2013
My PhD adviser once told me that the most difficult part for graduation is scheduling the oral defense.
I thought he was joking, but realized he really meant it after doing it myself. It is basically a NP-hard, if not non-computable, problem.
I consider this as part of the ritual for graduation, so I will let the candidate schedule his/her own oral defense. People who cannot even get this done do not deserve to graduate.
I never understand the rationale for hundreds-page thesis or hours-long oral defenses (PhD or other research degrees); it is probably residue from some ancient practices. But I think it is a big waste of time to write or read (or print, for heaven’s sake).
Here is my proposed thesis format:
Part 1: a concise summary of what the thesis is about, and why people should care about it.
Part 2: simply staple (via Latex, not physical papers) the relevant publications together to explain how it is done.
And here is the corresponding format for oral defense:
Part 1: a (sub) 5 minute elevator pitch telling people what the thesis is about and why they should care about it. There is a short break after this stage. The candidate fails if (s)he cannot convince the audience why they should continue to listen.
Part 2: a (sub) 25 minute presentation of more details, which can simply be a re-compilation of past conference talks. What follows is a usual break for committee discussion.
If the candidate does not have solid publications, (s)he should not be able to graduate.
If (s)he does, it should probably take at most a day to prepare the thesis and oral defense, on top of the existing materials.
The committee members can just spend as much time reading the published conference/journal papers instead of bloated mumbo jumbo in hundreds of pages.
If the candidate knows what (s)he has been doing, (s)he should be able to articulate a clear elevator pitch.
Otherwise, (s)he does not, and probably should come back to think and work more.
The committee members can quick see the quality of the research work instead of having to sit through hours-long slug about some technical details.
I plan to implement these for my internal students. And please, just send me the pdf file of your thesis. Spare the trees.
July 17, 2013
I stumbled upon these advices on advising by David Patterson (here) and Jeff Ullman (here) today. I found both insanely useful, especially after having a few years of advising experiences. The advices differ in the way that Patterson is mainly on systems and Ullman mainly on theory. But they also share similarities such as the importance of identifying problems and collaborative work.
(I would really love to hear from someone in graphics and HCI, fields with more emphasis on human side applications. I am thinking about asking my former school advisers/professors to write such articles.)
I reflected upon my (unusual) style of individual work and asynchronous communication. This has been quite effective so far, but I never stop thinking it could go wrong, at least for some students. So what I did is to make sure there is always at least one co-adviser who can help with the normal human side of needs, like in person meetings and emotional support.
Exposure to industry labs or even startups, fortunately, should be the benefit of working with me, given where I came from and whom I know.
I encourage all my past, current, and future students to read these articles, and let me know if you have any comments.
July 10, 2013
I am picking up HCI as it is becoming more relevant to my teaching and research. Here is a log of what I have found useful. As work in progress things are going to be in a flux. If you have suggestions I would love to hear.
PS: Back in grad school my PhD adviser once commented that UI design is my Achilles heel.
The design of everyday things by Donald Norman is an old text but has aged quite well. The thing I like most about the book is that it provides many highly intuitive examples and counter examples to illustrate many of the practical design issues.
I learned about user studies from measuring the user experience by Tullis and Albert. It is pretty comprehensive, but for detailed math/theory you will need to look up elsewhere.
The coursera course by Scott Klemmer covers several main aspects of HCI and is fun to participate. I quickly went through it off season within a few days so I just watched the videos and did the quizzes. I plan to join the next offering and do the homework assignments (for real).
July 8, 2013
I only want to work on projects aiming for top venues with people who are willing to and capable of pull that off.
Not every project can end up in a top venue, but we should at least give it enough chances to ride out random factors and be reasonably polished and complete. If in the end it really cannot make to a top venue, we can go for a lower one, but I will not be able to spend as much time as I could for a top venue.
July 5, 2013
To some of my collaborators who have recent troubles with svn auto notification:
Instead of the usual spam run on my svn mail server, this time the issue seemed to come from over-zealous spam filtering. That is beyond my control, so I did a workaround.
(See below for more details if interested.)
The only difference is that you will see only yourself as the email recipient instead of everyone else on the cc list.
But this is probably a good thing as it can discourage the temptation to reply all through email.
Let me know if you still see issues.
Here is a quick guide on setup for linux. I will let you search online for other systems and more details.
. Under the “hooks” directory of your repository, there should already be a file named “post-commit.tmpl”. Copy it to a file named “post-commit”, and set x permission for ug. As the name implies, this is the file that will be automatically evoked after commit.
. There should already be a line similar to the following at the end of that post-commit file. All you need to do is to set the proper directory for commit-email.pl and append proper email list.
/usr/share/subversion/hook-scripts/commit-email.pl “$REPOS” “$REV” -s “Project Name” email@example.com firstname.lastname@example.org
. Alternatively, you can also use mailer.py in lieu of commit-email.pl. The former will give you more options while the latter is simpler. For mailer.py, use the following line instead of the commit-emai.pl line above:
/usr/share/subversion/hook-scripts/mailer/mailer.py commit “$REPOS” “$REV” “$REPOS”/hooks/mailer.conf
You also need to put a mailer.conf file under the same directory.
Below is a simple basic setup that works well for me.
# This command will be invoked with destination addresses on the command
# line, and the message piped into it.
mail_command = /usr/sbin/sendmail
# This is not passed to the shell, so do not use shell metacharacters.
# The command is split around whitespace, so if you want to include
# whitespace in the command, then ### something ###.
diff = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s %(from)s %(to)s
# The default prefix for the Subject: header for commits.
commit_subject_prefix = Project Name
# The default To: addresses for message. One or more addresses,
# separated by whitespace (no commas).
# NOTE: If you want to use a different character for separating the
# addresses put it in front of the addresses included in square
# brackets ‘[ ]‘.
to_addr = email@example.com firstname.lastname@example.org
# If this is set, then a Reply-To: will be inserted into the message.
reply_to = email@example.com
# Specify which types of repository changes mailer.py will create
# diffs for. Valid options are any combination of
# ‘add copy modify delete’, or ‘none’ to never create diffs.
# add: generates diffs for all added paths
# copy: generates diffs for all copied paths
# which were not changed after copying
# modify: generates diffs for all modified paths, including paths that were
# copied and modified afterwards (within the same commit)
# delete: generates diffs for all removed paths
generate_diffs = add copy modify
# A revision is reported on if any of its changed paths match the
# for_paths option. If only some of the changed paths of a revision
# match, this variable controls the behaviour for the non-matching
# paths. Possible values are:
# yes: (Default) Show in both summary and diffs.
# summary: Show the changed paths in the summary, but omit the diffs.
# no: Show nothing more than a note saying “and changes in other areas”
show_nonmatching_paths = yes
The mail filter appeared to be rejecting and considering as spam some automatic notifications with multiple recipients. So a quick workaround is to send out emails once at a time to individual recipients. This can be easily achieved via commit-email.pl as follows:
for person in firstname.lastname@example.org email@example.com
/usr/share/subversion/hook-scripts/commit-email.pl “$REPOS” “$REV” -s “Project Name” $person
For mailer.py, you will need separate conf files for individual recipients. This does not look very convenient to me.
June 13, 2013
You think GPA is important and spend time boosting your grades.
You think research is as deterministic and well-defined as courses.
You wait to be told what to do rather than figure out your own way.
You think you are working for your adviser rather than yourself.
Instead of work continuously, you let external factors (e.g. holiday and semester breaks) disrupt your flow.
You do not read every paper in the top venues of your fields especially during your first few years.
You try to read and understand every paper completely like textbooks.
You feel that deadline 3 months later is still far away.
You believe you are smart enough so that you do not have to work as hard as others.